Hallo,
ich habe hier als Erbstück eines früheren Kollegen eine VBA-Anwendung
(Excel), die Daten aus einer Messhardware von NI verarbeitet. Dazu ist
eine NI-DAQmx C API eingebunden.
Diese API stellt eine Funktion names DAQmxRegisterEveryNSamplesEvent
bereit, mit der man die Callback-Funktion registrieren kann, die
aufgerufen wird, wenn entsprechend Messdaten vorhanden sind.
Mein Problem ist nun, dass ich einen neuen Rechner mit 64bit-Office hier
stehen habe und "AddressOf" ein type missmatch generiert, weil die
API-Funktion wohl eine 32-Bit Adresse erwartet und eine 64-Bit Wert
geliefert wird.
Wie kann ich dieses Problem lösen? Benötige ich eine 64-Bit Version der
API? Ich weiß nicht mal, ob es die gibt. Kann ich Office irgendwie
sagen, mache 32 Bit? Bin etwas ratlos.
Grüße, Alex
Alexander H. schrieb:> enötige ich eine 64-Bit Version der> API?
Ja.
Alexander H. schrieb:> Kann ich Office irgendwie> sagen, mache 32 Bit?
Nö. Prozesse in 64 Bit Umgebung kömnnen keine 32-Bit DLLs laden.
Allerdings könnte man die 32-Bit Version von Office installieren.
Alexander H. schrieb:> Wie kann ich dieses Problem lösen? Benötige ich eine 64-Bit Version der> API? Ich weiß nicht mal, ob es die gibt. Kann ich Office irgendwie> sagen, mache 32 Bit? Bin etwas ratlos.
Die Verwendung von Office in 64 Bit wird auch von Microsoft - glaube ich
- nur dann empfohlen, wenn Du einen dem entsprechenden
Speicherplatzbedarf hast.
Ansonsten solltest Du Office in 32 Bit installieren.
Mit einem Office in 32 Bit könnte es gehen.
Du benötigst vermutlich die Software die die API (dll-Datei vermutlich)
bereitstellt.
Wenn du deine API-Aufruf bei google eingibst, dann landest du bei
www.ni.com . Hier mal ein Beweis :
https://forums.ni.com/t5/LabWindows-CVI/DAQmx-DAQmxRegisterEveryNSamplesEvent-when-is-called/td-p/3283854?profile.language=en
<- Der Link hat NICHT direkt mit deiner Frage zu tun. ER soll dir nur
helfen, dein Problem zu lösen.
Und das bedeutet folgendes : Deine API ist NICHT von MS sondern von
einen 3-Anbieter.
Sie wird einfach reingelinkt (meist als DLL Datei), und dann aufgerufen.
Ich kenne mich mit DER DLL(Typ der Datei selbst i.d.R.) nicht aus, aber
ich habe genau so was ähnliches oft gemacht, zuletzt als ich eine
Software für ein QL-560 Etikettendrucker geschrieben habe. Einfach die
DLL gelinkt, und dann die API deklariert und aufgerufen. Diese Daten
gehörten zum Entwicklerpaket von Brother.
Grundsätzlich gilt. MS hat kaum API-Aufrufe für die es kein
64-Bit-Gegenstück gibt. Aber man kann Mio. von DLL-Dateien (Api ist nur
der Aufruf) dazu linken.
Aber wie richtig gesagt : 32 Bit + 64 Bit kann man nicht mischen.
Guten Morgen,
danke für die Antworten. Ich habe eben mal im Excel nachgeschaut ->
64bit-Version. Ich fasse eure Antworten mal zusammen: entweder
32Bit-Variante von Office oder eine 64Bit-Version der DLL. Richtig?
Womit wir beim Thema wären:
physicist schrieb:>> API? Ich weiß nicht mal, ob es die gibt. Kann ich Office irgendwie>> gibt es
Wenn Du das weißt, weißt du doch sicher auch, wo ich diese finden kann.
Der neuste DAQmx-Treiber von NI ist intalliert. In Excel unter
Versweisen den Haken für NI Daqmx C API habe ich gesetzt, dann sollte er
doch die 64Bit-Variante der DLL einbinden, wenn es die gibt. Korrigier
mich bitte, wenn ich mich irre.
Grüße, Alex
>Aber wie richtig gesagt : 32 Bit + 64 Bit kann man nicht mischen.
==> Quatsch mit Sauce!!!
Du brauchst bloss das Keyword "PtrSafe" vor jede 32-Bit
Funktionsdelaration einzufügen, zB so:
Public Declare PtrSafe Function CAN_SetValue Lib "PCANBasic.DLL" ...
Hallo Mike,
Das hatte ich schon recherchiert und versucht, hat irgendwie nicht
funktioniert. Vielleicht habe ich da was falsch gemacht.
Bei mir ist es ja die Eventhandler Funktion, die ärger macht. Diese hab
ich selbst geschrieben und deren Addresse ist natürlich 64 Bit lang in
einer 64-Bit-Anwendung. Wie kann ich da nun eine 32-Bit Addresse draus
machen?
Ok...
Das geht natürlich nicht: Einer 32 Bit Funktion kannst Du keinen 64 Bit
Pointer als Parameter mitgeben (nur umgekehrt), du brauchst eine 64 Bit
Version von DAQmxRegisterEveryNSamplesEvent()
Aber es sollte sich auch 32Bit Office Subsystem parallel installieren
lassen.
Es kommt in seltenen Fällen vor, das eine DLL o.ä. nicht registriert
ist.
Entweder weil Windows die Registrierung verloren hat, oder sie nicht
gemacht wurde.
https://support.microsoft.com/de-de/help/249873/how-to-use-the-regsvr32-tool-and-troubleshoot-regsvr32-error-messages
Das meinte ich.
Ich habe schon einige Male so Probleme beseitigt. Besonders dann wenn
die Software KEIN Installation-Prg. hatte. Und irgendwelche Scripte
verloren gingen.
Aber die sicherste Methode ist, sich bei NI eine neue 64-bit Version zu
besorgen mit Setup. Ein gutes Setup korrigiert so Fehler.
Laut NI-DAQmx git es eine 32Bit & 64Bit Version:
https://www.ni.com/de-de/support/downloads/drivers/download.ni-daqmx.html#348669
Falls Du Dich nicht mit C rumschlagen willst und Python magst:
https://nidaqmx-python.readthedocs.io/en/latest/
Solche Problematik hatte ich in der Vergangenheit auch 64Bit Anwendung
nur 32Bit Treiber / Vice Versa und dann noch zusätzlich unterschiedliche
Compiler etc.
Um die ganze Problematik zu entgehen, hab alles in Microservices
ausgelagert und über TCP mit der MainApplikation kommunizieren lassen.
Die Alternative wäre das Teil raus zu schmeissen, und die Email mit ein
paar kleinen VBA-Befehlen selbst zu lösen. ;)
Hier mal ein Link von "auf die schnelle gefunden".
https://www.makro-excel.de/2017/03/06/per-vba-makro-eine-email-mit-outlook-versenden/
Ich persönlich hasse VBA. Ich nehme lieber richtiges VB und nutze dann
Excel aus das was es ist. Geht viel einfacher.
Mike schrieb:>>Aber wie richtig gesagt : 32 Bit + 64 Bit kann man nicht mischen.> ==> Quatsch mit Sauce!!!>> Du brauchst bloss das Keyword "PtrSafe" vor jede 32-Bit> Funktionsdelaration einzufügen, zB so:>> Public Declare PtrSafe Function CAN_SetValue Lib "PCANBasic.DLL" ...
Quatsch - das funktioniert nur so lange deine App im unteren 4GB Bereich
angesiedelt wird (beleg einfach mal 4GB dann geht das nicht mehr) -
sonst kann das nicht gehen weil deine Pointer sich nicht mappen lassen
cppbert schrieb:> das funktioniert nur so lange deine App im unteren 4GB Bereich> angesiedelt wird
Wobei sich mir bei mein 32 GB Rechner die Frage stellt wie ich den
Programm sage in welchen Speicherbereich es muss.
Ich weiß viel über Windows aber DAS nicht.
Ergo war meine Aussage richtig. Und selbst wenn es mit einen Trick geht.
So was ist dann höchstens was für mein Nachfolger. Weil der bekommt (wie
der TO auch) richtig Probleme.
Was bedeutet : Ich trickse NIE. Und die Software die ich vor 20 Jahren
in 32 Bit geschrieben habe, läuft heute noch unter Win-10 einwandfrei.
Wie schon gesagt, es ist ein zehn oder zwölf Jahre altes Erbstück eines
Kollegen, für Excel in VBA geschrieben und weit weg von schön. Nun will
der Kunde eine neue Messhardware und da muss ich den Code anpassen.
Rechner ist vom Kunden, konnte ihn überzeugen, ein 32Bit-Office zu
installieren, Problem gelöst. Für die paar Messwerte reicht das. Hätte
ja am liebsten was Ordentliches geschrieben, ohne Office und mit
Messprotokoll als pdf. Aber man kann nicht alles haben.
Grüße, Alex
Schlaumaier schrieb:> cppbert schrieb:>> das funktioniert nur so lange deine App im unteren 4GB Bereich>> angesiedelt wird>> Wobei sich mir bei mein 32 GB Rechner die Frage stellt wie ich den> Programm sage in welchen Speicherbereich es muss.>> Ich weiß viel über Windows aber DAS nicht.>> Ergo war meine Aussage richtig. Und selbst wenn es mit einen Trick geht.> So was ist dann höchstens was für mein Nachfolger. Weil der bekommt (wie> der TO auch) richtig Probleme.>> Was bedeutet : Ich trickse NIE. Und die Software die ich vor 20 Jahren> in 32 Bit geschrieben habe, läuft heute noch unter Win-10 einwandfrei.
Pure 32bit ist auch keon Problem, aber 64bit Zeiger an 32Bit API
uergeben eben nicht und nur weil es nicht abstürzt ist das kein Beweis -
ich habe in meinen Testszenarien extra Funktionen welche die unteren 4GB
belegen und habe damit schon oft API Fehler in Windows und Linux
gefunden, in Software die seit Jahren im Einsatz ist :)