Wenn dein Problem oder deine Frage geklärt worden ist, markiere den Beitrag als "Lösung",
indem du auf den "Lösung" Button rechts unter dem entsprechenden Beitrag klickst. Vielen Dank!
ich versuche per MB aus unserer Heizung Werte auszulesen um diese dann mit LV aufzeichnen zu lassen. Laut dem Hersteller unterstützt der Regler der Heizung MB und er hat mir auch alle einzustellenden Parameter mitgeteilt. Der RS485-Regler ist über einen RS485/RS232-Koverter mit dem PC verbunden.
Zuerst hatte ich versucht mit MODBUS POLL die Verbindung zu testen, was auch prima funktioniert hat. Danach habe ich das gleiche mit einem selbst geschriebenen VI versucht, was trotz identischer Schnittstellen-Parameter nicht richtig funktioniert. Beim Erstellen des VIs habe ich die NI-modbus-library genutzt. Mein VI findet ihr im Anhang.
Ich habe mir auch mal die Schnittstelllen-Kommunikation angeschaut. MODBUS POLL und LV senden genau die gleiche Anfrage an den Heizungs-Regler. MODBUS POLL bekommt daraufhin auch die richtige Antwort, LV allerdings nur ein Echo seiner Anfrage zurück. Ich habe kurze Aufzeichnungen des MBpoll- und LV-Traffics als Screenshot dem Anhang beigefügt.
Man sieht, dass die Anfragen identisch sind. MBpoll und LV unterscheiden sich sonst nur in der Tabellenansicht, womit ich leider nicht viel anfangen kann. Des Weiteren ist bei MBpoll nur DTR aktiviert, bei LV sind es DTR und RTS (nicht ersichtlich aus Screenshot). Wenn ich RTS bei LV deaktiviere, bekomme ich ein timeout.
Ich würde mich sehr darüber freuen, wenn ihr mir bei dieser Sache weiterhelfen könntet. Ich bin nach einer Woche rumprobieren leider absolut ratlos...
MfG und vielen Dank im Voraus!
Sebastian
' schrieb:Kann mir denn niemand sagen warum's mit MODBUS POLL funktioniert aber mit LabVIEW nicht?
Ich habe keine Ahnung.
Ich beschäftige mich nicht mit Modbus. Aus dem IOCTL-Protokoll kann ich auch nicht wirklich was herauslesen. Da ist zwar ein Unterschied bei Puffer löschen (PURGE) und HANDFLOW (SetCommControl und/oder Handshake) das scheint mir aber wenig relevant.
Ich tippe ja fast auf falsche Konfiguration des NI-Modbus-Treibers. Möglicherweise stimmt da was nicht mit dem Handshake und/oder der Konfiguration des RS485/RS232-Wandlers.
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
' schrieb:Ich tippe ja fast auf falsche Konfiguration des NI-Modbus-Treibers.
Ich kann mich über die NI-Modbus-Lib nicht beschweren, hat bei mir bisher immer funktioniert.
Leider habe ich auch keine Ahnung, was in diesem Fall nicht funktioniert.
Gruß, Jens
Wer die erhabene Weisheit der Mathematik tadelt, nährt sich von Verwirrung. (Leonardo da Vinci)
!! BITTE !! stellt mir keine Fragen über PM, dafür ist das Forum da - andere haben vielleicht auch Interesse an der Antwort!
Hey,
erst mal Danke für eure Antworten!
Ich hatte mir auch schon überlegt, dass es an der Konfiguration/ Kommunikation mit dem RS485/RS232-Konverter liegen könnte. Diesem muss ich anscheinend über den Kanal RTS mitteilen, dass ich eine Abfrage an die Heizung schicken will. In einer Datei der NI-MB-library habe ich daher vor dem Senden RTS aktiviert und dann direkt danach wieder deaktiviert. Wenn ich dann noch vor und nach dem Senden jeweils eine Warteschleife von 10ms eingefügt habe, hat LV zumindest ab und zu eine Antwort von der Heizung erhalten. Allerdings stand immer noch der gesendete String davor, was die Antwort für LabVIEW wiederum unsinnig machte.
Des Weiteren habe ich bei MODBUS POLL mal die Einstellung "RTS toggle" deaktiviert. Daraufhin hat auch MODBUS POLL nur sein Echo zurückbekommen. Meiner Meinung nach scheint es also an der Ansteuerung des RS485/RS232-Konverters zu liegen.
Ich habe zu diesem Konvertertyp mal hier im Forum nachgeschaut, aber nichts gefunden, was mir wirklich hilft; außer dass es anscheinend oft Probleme mit diesen Dingern gibt.
Gibt es denn ggf. eine Möglichkeit den RS485-Port der Heizung direkt, ohne Komverter mit dem RS232-Port des PC zu verbinden? Oder würde vielleicht ein USB/RS485-Adapter helfen?
Oder kennt jemand die genauen Unterschiede zwischen MODBUS POLL und LabVIEW, was die genaue Abfolge der Schnittstellenkommunikation angeht?
Für jede Antwort wäre ich sehr, sehr dankbar!
' schrieb:Wenn ich dann noch vor und nach dem Senden jeweils eine Warteschleife von 10ms eingefügt habe, hat LV zumindest ab und zu eine Antwort von der Heizung erhalten. Allerdings stand immer noch der gesendete String davor, was die Antwort für LabVIEW wiederum unsinnig machte.
RS485 hat (hier) den Nachteil, dass sowohl die Sendedaten wie die Empfangsdaten über die selben physikalischen Leitungen übertragen werden. Das hat aber zur Folge, dass im Falle, wenn empfangen werden soll, die physikalischen Sendetreiber abgeschaltet werden müssen. Dies geschieht oft mit den Handshakeleitungen der Seriellen Schnittstelle. Problem dabei ist, dass die Abschaltung sofort nach dem Senden des letzten Zeichens geschehen muss. Mindestens schneller, als die Gegenseite antwortet. Wenn du also in LV eine "10ms-Pause" reinprogrammiert hast, deutet das darauf hin, dass es am Sperren der Sendeleitung vom PC zur Heizung liegt.
Das Empfangen des gesendeten Telegrammes (Echo) ist bei RS485 prinzipiell normal (siehe Protokoll Modbus Poll). Da Sender und Empfänger die selben Leitungen haben, geht der Sender immer rückwärts auch auf den Empfänger. Das kann man im übrigen dazu verwenden, die DÜ-Strecke zu testen.
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
Zitat:Problem dabei ist, dass die Abschaltung sofort nach dem Senden des letzten Zeichens geschehen muss.
Heißt das, dass ich RTS sofort nach dem Senden der Anfrage abschalten muss? Oder muss ich dafür etwas anderes reinprogrammieren? Liegt es vielleicht auch an der "Handshake"-Einstellung und wie kann ich diese in LV bearbeiten? Ist das die Flusssteuerung?
Zitat:Das Empfangen des gesendeten Telegrammes (Echo) ist bei RS485 prinzipiell normal (siehe Protokoll Modbus Poll).
Ich sehe das Echo beim Protokoll von MODBUS POLL nicht. Da steht doch nur:
Request: 01 03 00 25 00 01 95 C1
Answer: 01 03 02 FF EA 78 3B
Bei LV sieht das Protokoll mit RTS-Ein/Aus, wie ich es nachträglich reinprogrammiert habe, so aus:
Request: 01 03 00 25 00 01 95 C1
Answer: 01 03 00 25 00 01 95 C1 01 03 02 FF EA 78 3B
Aber auch nur manchmal. Ab und zu meldet LV auch ein timeout. Aber es steht niemals nur die Antwort der Heizung da. Schnappe ich ggf. noch meine herumgeisternde Anfrage auf? Ein Löschen der Puffer vor dem Senden und Empfangen hat übrigens nichts gebracht.
Zitat:Da Sender und Empfänger die selben Leitungen haben, geht der Sender immer rückwärts auch auf den Empfänger. Das kann man im übrigen dazu verwenden, die DÜ-Strecke zu testen.
Das heißt ich sende im Kreis, oder? Ich sende vom PC zum Konverter, der leitet es aber nicht weiter und so kommt es wieder bei mir an? Aber das Kabel ist in Ordnung...
--> Also ich werde mal Folgendes ausprobieren: Ich schalte RTS an, warte 10 ms, sodass der Konverter auch Zeit hat sich umzustellen. Oder sollte ich besser / muss ich auf einen High-Pegel auf dem CTS-Kanal warten, über den der Konverter mir mitteilt, dass er die Daten annehmen kann? Dann sende ich meine Anfrage und sofort danach schalte ich RTS wieder aus. Dann müsste der Konverter die Daten ja weiterschicken, die Heizung antworten und ich die richtige Antwort empfangen.
Eigentlich müsste dies (RTS, CTS etc.) doch alles automatisch laufen, wenn ich die Flusssteuerung auf Hardware einstelle, oder? Aber wie ich es bisher ausprobiert habe, klappt's auch dann nicht...
Ich werde nochmal versuchen mich bei wikipedia schlauzulesen und dann ein paar Sachen ausprobieren. Wenn ihr noch Tipps, Tricks oder Ideen habt, nur her damit. Sollte es an meinem generellen Verständnis liegen, wäre ich für jegliche Aufklärung sehr dankbar!
