LabVIEWForum.de

Guten Tag

Ich schlage mich seit einiger Zeit mit einem Projekt herum, welches vorsieht, eine Lampe bestehend aus vier LEDs mittels Labview zu steuern.
Dazwischengeschaltet ist der MCP2221 USB - I2C converter von Microchip, welche seit einem Release (März 2016) Labview-kompatible .dll und .h Dateien
("unmanaged" version) zur Verfügung stellt. Die Lampen lassen sich ebenfalls problemlos mit dem von Microchip zur Verfügung gestellten MCP2221 I2C-Terminal steuern, jedoch soll dies nun mit Labview geschehen. Die .dll konnte ich problemlos in Labview laden. Als Labview-Anfänger bin ich nun mit folgendem Problem konfrontiert:

In meinem Programm (siehe Anhang MCP2221.vi) funktionieren folgende Funktionen: "open" und "set speed"; zumindest erhalte ich dabei keine Fehlermeldungen.
Mir ist nicht ganz klar, welche Informationen die Funktion "Write" benötigt. Insbesondere ist mir nicht klar, welche Angaben und in welchem Format
"i2ctxdata" gefüttert werden sollte. Zudem sehe ich vor, einen Pointer Slide für die Steuerung der LED Lichtintensität (in diesem Beispiel GRÜN) zu nutzen.
Ich habe versucht, das Feld mit den volatile und non-volatile Angaben des Gerätebauers (siehe settings.pdf) mittels string array einzubinden, doch eine
Verbindung des string arrays mit "write" ist nicht möglich. Dürfte ich die Frage in die Runde werfen, wie ich den Bereich "write" gestalten müsste; insbesondere welche Informationen das Feld "i2ctxdata" benötigt? Besten Dank im Voraus! sisc

Es wäre hilfreich wenn Du auch Deine MPC2221 I2C Library mit anhängen würdest. Ohne diese ist es ziemlich schwierig zu sagen was Du überhaupt machst.

Im Anhang habe ich meine Labview .lib angehängt; generiert aus der unmanaged x64 .dll vom Hersteller Microchip.

(03.06.2016 12:15 )sisc schrieb: [ -> ]In meinem Programm (siehe Anhang MCP2221.vi) funktionieren folgende Funktionen: "open" und "set speed"; zumindest erhalte ich dabei keine Fehlermeldungen.
Mir ist nicht ganz klar, welche Informationen die Funktion "Write" benötigt. Insbesondere ist mir nicht klar, welche Angaben und in welchem Format
"i2ctxdata" gefüttert werden sollte. Zudem sehe ich vor, einen Pointer Slide für die Steuerung der LED Lichtintensität (in diesem Beispiel GRÜN) zu nutzen.
Ich habe versucht, das Feld mit den volatile und non-volatile Angaben des Gerätebauers (siehe settings.pdf) mittels string array einzubinden, doch eine
Verbindung des string arrays mit "write" ist nicht möglich. Dürfte ich die Frage in die Runde werfen, wie ich den Bereich "write" gestalten müsste; insbesondere welche Informationen das Feld "i2ctxdata" benötigt? Besten Dank im Voraus! sisc

Erst einmal, die MCP Library had einen Bug!! Das handle, das alle Funktionen verbindet ist ein Pointer, kein unsigned int. Für 32 bit LabVIEW würde das zwar kein Problem sein, denn dort ist sizeof(int32_t) == sizeof(void*). In 64 bit LabVIEW ist aber sizeof(void*) == sizeof(int64_t).

Also müssen alle Call Library Nodes umkonfiguriert werden, wobei dieser Parameter jeweils statt eines 32 Bit Integers in einen Pointersized Integer verändert werden muss und alle LabVIEW-Kontrolls für die Handles müssen als 64 Bit Integer ausgeführt sein.

Zudem hat der, der diese Library generiert hat sich wieder mal voll auf den Import Library Wizard verlassen und danach gar nichts mehr daran gemacht. Es wäre sinnvoll um das Interface zu überarbeiten und einige Dinge zu vereinfachen.

Beispielsweise führt die Write Funktion völlig unnötig den Parameter bytesToWrite heraus. Da würde man besser aus der i2cTxData die Länge bestimmen und diesem Parameter diesen Wert übergeben. Zudem ist es ziemlich unsinnig um diesen Writebuffer wieder aus der Funktion herauszuführen.

Das sähe dann so aus:

[attachment=56039]

Und eigentlich geht es hier um binäre Daten. C kennt keinen eigenen Datentyp für Strings. char ist typischerweise ein Byte (das ist von C nicht strikt vorgegeben obwohl das für alle bekannten gegenwärtigen C Compiler so ist, aber C lässt ausdrücklich zu, dass ein char jede für die CPU sinnvolle Grösse haben darf und es gab in der Vergangenheit CPUs die 9 bits pro Dateneinheit besassen und ein C Compiler benützte dann auch 9 bits für einen char).

Ein Byte-Array ist deshalb ein Array of chars, und da ein ANSI Character in 8 bits passt wird auch ein ANSI-String als Byte-Array implementiert.

Da in diesem Fall binäre Daten über I2C verschickt werden und eigentlich nie Strings, wäre es deshalb sinnvoller um auch an der LabVIEW Seite ein Array of Unsigned 8 bit Integers zu verwenden. Damit würde auch der Fehler den Du hier begangen hast weniger schnell passieren.

Was das Device will sind zwei Bytes mit den Werten 0x70 und 0xFF. Was Du zu verschicken versuchst ist der String "70 FF" und das ist in ASCII Codierung 5 Bytes mit den Werten 0x37, 0x30, 0x20, 0x46, 0x46. Und um es alles noch viel schlimmer zu machen, sagst Du der Funktion, dass sie 8 Bytes verschicken soll, gibst ihr aber nur 5 und dann werden da halt einfach 3 zufällige Werte aus dem Speicher mitgeschikt, die direkt hinter dem Buffer den der String belegt im Speicher liegen.

Dann kommt die Read Funktion! Ein klarer Fall von blind das vom Import Library Wizard erzeugte VI benützen. Die Funktion probiert soviele Bytes in den Readbuffer zu kopieren wie man ihr in bytesToRead sagt. Zwar ist die Call Library Funktion so konfiguriert dass Sie einen Buffer von 8192!!!!!! Bytes reserviert. Das verhindert zwar dass es eine Exception wegen Speicherverletzung geben kann, ist aber für eine Funktion wie I2C wo man maximal 255 Bytes lesen kann ziemlich extremer Overkill. Zudem scannt LabVIEW für Strings die als C Strings an eine DLL übergeben werden nach der Ausführung dieser Funktion den Stringbuffer nach einem NULL Byte und schneidet dort den String ab. Da I2C aber binäre Daten hat, ist es sehr gut möglich dass da NULL Bytes zurückkommen und dass auch dahinter noch gültige Bytes im Buffer sind. Durch diesen Parameter als Bytearray zu behandeln wird diese NULL Byte Termination nicht vorgenommen.

Ich hätte die so implementiert:

[attachment=56038]

Und dann muss man natürlich das Datensheet gut lesen. Dort steht scheinbar, dass das erste Byte die Led adressiert, wobei man da nonvolatile und volatile wählen kann. nonvolatile bedeutet dass es im Speicher abgespeichert wird der auch bei ausgeschaltetem Strom seine Daten behält und wahrscheinlich wird dann beim wieder Einschalten dieser Wert gelesen und verwendet bis ein anderer programmiert wird. volatile ist flüchtiger Speicher, das heisst was man dort hineinschreibt beeinflusst zwar die Led direkt aber ist nach Abschalten der Speisung vergessen. Du musst also abhängig von der Farbe der Led deinen Schieberwert zwischen 0 und 100 in einen Bytewert für das 2te Byte skalieren. Also für die rote Led zum Beispiel 0% =~ 0x70 und 100% = 0xFF. Das ist dann nur annähernd korrekt da aus der Tabelle eindeutig ersichtlich ist dass die Skalierung nicht linear ist. Du könntest hier ein Polynomfit machen und mittels eines entsprechenden Poynoms, zweiter oder dritter Ordnung eine besser übereinstimmung erreichen, aber ich denke mal dass das etwas Overkill sein könnte.

Vielen Dank, rolfk, für die rasche und ausführliche Antwort! Melde mich am 06. oder 07.06. mit Ergebnissen auf dieser Plattform.

tut mir leid für die späte Antwort, doch den "Glücksmoment" habe ich erst vor einer halben Stunde erlebt.

Ich habe auf einem 64-bit Labview System gearbeitet und habe, nachdem ich mehrmals Fehlermeldungen bei der DLL Implementierung erhalten habe, nun vor zwei Tagen auf ein 32-bit Labview System gewechselt. Das Problem lag darin, dass Labview nicht mit dem handle Format umgehen konnte. Ich weiss nicht, ob die 64-bit dll einen Fehler hat.

Das Gerät lässt sich nun einwandfrei mit dem angehängten .vi steuern. Mein nächstes Ziel ist die Anpassung / Entwicklung einer Benutzeroberfläche.
Nochmals herzlichen Dank an rolfk!

(22.06.2016 14:23 )sisc schrieb: [ -> ]Ich habe auf einem 64-bit Labview System gearbeitet und habe, nachdem ich mehrmals Fehlermeldungen bei der DLL Implementierung erhalten habe, nun vor zwei Tagen auf ein 32-bit Labview System gewechselt. Das Problem lag darin, dass Labview nicht mit dem handle Format umgehen konnte. Ich weiss nicht, ob die 64-bit dll einen Fehler hat.

LabVIEW kann sehr wohl mit HANDLEs umgehen. Du musst ihm nur sagen dass es ein Pointersized integer ist!

Besten Dank Rolf! Nun habe ich das Gerät auch auf dem 64-bit Labview zum Laufen gebracht. Ich vermute meinen ursprünglichen Fehler darin, dass ich beim Ausführen von "OpenByIndex" jeweils kein "GetLastError" angehängt habe. Gemäss MCP2221 Manual das Ausführen dieser Funktion notwendig.

Davor erhielt ich jeweils die Fehlermeldungen "invalid handle" oder "invalid handle format".

Hello.
I need to communicate with MCP2221 USB-I2C converter and read Current/Voltage values from all channels.
I have used application that you have posted here but i have a problem with I2C read function - array of I2cRxData consist of zeros.
When i have used MCP2221 I2C/SMBus Terminal everytihng was fine. See SMBus Terminal.JPG attachment.
I hope you can solve me this problem, i do not know what i am doing wrong.

I am attaching Labview programm that i am using.