Temperatursensor in Ladegerät integrieren

Hallo Titus,

Zitat:das sind fertige VIs vom Hersteller die werden doch die RaceConditions berücksichtigt haben

Die Code-Qualität von DeviceDrivern der verschiedenen Hersteller schwankt sehr stark. Richtig "guten" Code habe ich bisher nur selten gesehen…
Dein Treiber scheint aus einer relativ alten LabVIEW-Version zu stammen und wurde seitdem kaum überarbeitet. (Einige Konstrukte sind Rube-Goldberg-würdig.)

Dein Treiber verwendet ebenfalls die einfachen CAN-Funktionen. Wenn ich das richtig deute, wurde er auch so programmiert, dass er davon ausgeht, dass das CHROMA exklusiv am CAN-Interface angeschlossen ist. Damit wäre es kein Wunder, wenn die Kommunikation durcheinander kommt, wenn ein zweites Gerät am CAN-Bus mitreden will…

Ich verwende für meine Sachen hier entweder direkt CANopen-Funktionen (die dann strikt auf die jeweilige ArbID achten) oder "einfaches" CAN, wobei aber eine (konfliktfreie) CAN-DBC als Grundlage dient…

Die RaceConditions traten oben in deinem VI auf, in welchem die VIs des Geräteherstellers verwendet wurden. Warum muss man "Strom", "Spannung", etc. als lokale Variable verwenden, wenn direkt daneben das Terminal vorhanden ist?

Als Ergänzung hier mal ein Bild, wie ich die MicroControl-Box initialisiere:
   
Es werden Funktionen aus der NI-CANopen-Library verwendet. Im späteren Programmverlauf werden dann einfach die PDOs gelesen/geschrieben und ein paar Settings per SDO vorgenommen…

Wichtige Info dazu: Du kannst leider auf einem CAN-Interface nicht gleichzeitig Funktionen aus NI-CAN mit NI-CANopen mixen. Das führt sofort zu einem BSOD! (Ja, auch ein relativ modernes Windows kann man noch in einen BSOD zwingen…)

Anzeige

(25.07.2014 09:10 )GerdW schrieb:  Die RaceConditions traten oben in deinem VI auf, in welchem die VIs des Geräteherstellers verwendet wurden. Warum muss man "Strom", "Spannung", etc. als lokale Variable verwenden, wenn direkt daneben das Terminal vorhanden ist?

Also nochmal, vor zwei Monaten hat man mir einen Schaltschrank mit ne Lade/Entlade-Einheit ins Büro gerollt und gesagt... die Software dafür ist Müll keiner bringt das Ding zum Laufen programmier mal in Labview ne neue Software dafür.... meine Antwort darauf war:

"Was ist Labview ?"

Das Programm ist mit meinem Wissensstand gewachsen und ich würde es nicht noch einmal so schreiben.... ich hab damals gedacht wenn ich lokale Variablen nehme dann wäre es übersichtlicher weil ich keine Leitungen ziehen muss.... dann hat es sich weggeguckt..... ja jetzt weiß ich das es Bullshit ist aber damals halt nicht.

(25.07.2014 09:10 )GerdW schrieb:  Dein Treiber verwendet ebenfalls die einfachen CAN-Funktionen. Wenn ich das richtig deute, wurde er auch so programmiert, dass er davon ausgeht, dass das CHROMA exklusiv am CAN-Interface angeschlossen ist. Damit wäre es kein Wunder, wenn die Kommunikation durcheinander kommt, wenn ein zweites Gerät am CAN-Bus mitreden will…

Ich verwende für meine Sachen hier entweder direkt CANopen-Funktionen (die dann strikt auf die jeweilige ArbID achten) oder "einfaches" CAN, wobei aber eine (konfliktfreie) CAN-DBC als Grundlage dient…

Was ist jetzt das Fazit? Soll ich gleich ein zweites Interface nehmen oder kann ich das noch iwie in Einklang bringen?

Fazit:
Entweder beiden Geräten ein eigenes CAN-Interface gönnen (aka mit Geld aus Kostenstelle "Hardware-Komponente" auf das Problem schmeißen) oder für beide einen ordentlichen Treiber programmieren (aka mit Geld aus Kostenstelle "EDA-Zeit" auf das Problem schmeißen).

Du darfst entscheiden, was schneller geht und weniger kostet…

Zurück auf Anfang: Vielleicht wäre es auch einfacher, einen Pt100 über einen Messumformer in ein Normsignal umzuwandeln, welches man mit einer USB6008 einliest. Kosten hier: für den MU von 5€ (ganz billig) bis 100€ (Industriequalität) und 170€ für die USB6008…