Mit rs-485Schnittstelle über usb-serial Adapter mit Modbus RTU ein Fu ansprechen

Hallo zusammen,

ich stehe vor folgendem Problem:
Die Drehzahl einer Pumpe soll über den RS-485 serial port gesteuert werden.Ich verwende dafür eine Modifikation des BeispielVIs "Basic Serial Write and Read"
Der FU empfängt das gesendete Frame, das Empfangsfenster erhält aber keine Antwort. Es gibt aber auch keine Fehlermeldung.

Wo liegt mein Fehler?

Lösungsansätze die meinerseits bereits unternommen wurden:
Kabel defekt? Nein, denn die vom Hersteller mitgelieferte Konfigurationssoftware funktioniert und die Pumpe kann damit stabil angesprochen werden.
NI-Visatreiber? sind vorhanden
CRC-Checksumme falsch? Nein, ich habe mit dem Hersteller Rücksprache sprache gehalten (sehr kompetenter Mitarbeiter). Die von mir zuvor verwendete BigEndian Darstellung war falsch. Die littleEndian Darstellung (jetzt implementiert) der Checksumme ist die richtige. Ist übrigens der CRC-16 Algorithmus.
Falscher Frame: Falsche Frames führen zu einem timeout-Fehler, genauso wie eine falsche CRC-Checksumme.
Falsche Angaben für den Serial Link: Ich habe für die Kommunikation folgende Werte gewählt: Baudrate 9600, Databits 8bit, parity none, Stopbits 2, flowcontrol none, timeout on RJ45 500ms. Diese Werte habe ich maschinenseitig mit der Herstellersoftware auf Übereinstimmung überprüft. Falsche Werte bei Stopbits oder Databits führen zu Fehlermeldungen. Verschiedene timeout-Werte scheinen keinen Fehler auszulösen.

Kommunikationsprotokoll: Modbus RTU
LabVIEW-Version: 8.5.1
FU: Leroy Somer Varmeca 32T 300
Verbindung Frequenzumrichter-PC: USB-Serial-Adapterkabel (Hersteller oder Chipsatz unbekannt, da die Platine in einer schwarzen Platikbox verschweißt ist)

Danke für eure Geduld und eure Mühen. Ich bin froh über jede Idee.

(11.03.2011 15:25 )schuch schrieb:  RS-485

Zitat:flowcontrol none

Die RS485 ist eine Zwei-Draht bidirektionale Schnittstelle. Nach dem Senden muss der Sender seinen Ausgangstreiber auf hochohmig stellen. Woher weis der Umsetzer auf RS485, dass er den Ausgangstreiber auf hochohmig umstellen muss - ohne DTR/DSR etc. ??

Und der USB-Adapter ist tatsächlich einer, der RS485 macht und das auch noch von alleine richtig?

In solchen Fällen nehme ich immer ein Oszilloskop und schau mir die physikalischen Leitungen an.

Du weisst schon, dass es für das Modbus-Protokoll eine Library bei NI zum Herunterladen gibt?
http://sine.ni.com/nips/cds/view/p/lang/de/nid/201711
bzw.
http://sine.ni.com/devzone/cda/epd/p/id/4756

Gruß, Jens

Ich danke euch für die Hilfe.

Von der MB-Bibliothek wusste ich, ging aber davon aus, dass die Kommunikation mit serial write and read auch gehen müsste, da mir von verschiedenen Seiten gesagt wurde, dass das funktionieren sollte. Aber ich werde mal damit ein VI entwerfen. Vielleicht klappte es ja damit. Was für mich da nicht ersichtlich ist, ist ein CRC-Check irgendwie in die Struktur bereits eingebettet oder muss dieser wieder beim zu übertragenden String zwischengeschaltet werden?

@IchSelbst:
Meinst du ein virtuelles Oszilloskop aus der Bibliothek oder ein richtiges Speicheroszilloskop, das ich an die Leitungen klemme?

Bei den Erläuterungen zu RS485 habe ich verschiedene Varianten gefunden, bei denen zwischen RS485, RS485/2 und RS485/4 unterschieden wurde. Soweit bin ich dann aber doch noch nicht in der Materie, um den den Unterschied und deren Bedeutung für mich zu erkennen.

Hochohmigen Ausgang: Mal sehen ob ich das richtig verstanden habe. Hochohmig heißt ja bei RS485 nichts weiter als das eine null anliegt. Wenn also mein PC nicht sendet, sollte doch der Ausgang automatisch den hochohmigen Wert annehmen, anderenfalls würde ja unentwegt eine eins gesendet.
Wenn also nach dem gesendeten Frame eine Pause von mehr als 500ms (wurde als timeout-Zeit gewählt) eintritt, müsste der FU auf den Frame antworten.

(14.03.2011 11:33 )schuch schrieb:  Von der MB-Bibliothek wusste ich, ging aber davon aus, dass die Kommunikation mit serial write and read auch gehen müsste, da mir von verschiedenen Seiten gesagt wurde, dass das funktionieren sollte. Aber ich werde mal damit ein VI entwerfen. Vielleicht klappte es ja damit.

Die Modbus-Lib macht auf unterster Ebene auch nur Serial Read & Write. Aber hiermit ersparst du dir, das Modbus-Protokoll selber nachzuprogrammieren, angefangen bei der Prüfsumme über Header, Codierung, Adressenvergabe etc. pp.
Wieso etwas selber entwerfen, wenn es schon fertig vorhanden ist?

Gruß, Jens

(14.03.2011 11:33 )schuch schrieb:  Meinst du ein virtuelles Oszilloskop aus der Bibliothek oder ein richtiges Speicheroszilloskop, das ich an die Leitungen klemme?

Ein richtiges Oszilloskop an die Leitungen anschließen ...

Zitat:Bei den Erläuterungen zu RS485 habe ich verschiedene Varianten gefunden, bei denen zwischen RS485, RS485/2 und RS485/4 unterschieden wurde.

Da tippe ich mal auf folgendes: RS485/2 ist eine Zwei-Draht-Verbindung, RS485/4 eine Vier-Draht-Verbindung (und die hieß früher mal RS422). Was hast du den für eine Verbindung? Eine Zwei-Draht oder eine Vier-Draht? Guckst du auch hier

Zitat:Hochohmig heißt ja bei RS485 nichts weiter als das eine null anliegt.

Nein.
Hochohmig heißt, dass weder eine Null noch eine Eins anliegt. Es liegt also gar keine Spannung an. Man kann auch Tristate sagen.
Wenn der Sender sendet, egal ob eine Null oder eine Eins, liegt immer Spannung zwischen den zwei Drähten an. Ist der Sender mit senden fertig, muss er die Spannung wegnehmen. Würden zwei Sender Spannung auf die Leitungen geben (also senden), würde es zu einem Kurzschluss kommen ...

Aus deinem ersten Eintrag hier schließe ich folgendes:
Der FU macht alles richtig. Solange er nicht sendet, hält er die Zwei-Draht-Leitung von sich aus auf hochohmig. Daher kann der PC senden und der FU empfängt den Frame. Jetzt möchte der FU gerne antworten, tut dies wahrscheinlich auch - nur: der PC hält die Leitung weiterhin unter Spannung, sodass das Datenpaket des FU kaputt geht.

Zitat:Wenn also mein PC nicht sendet, sollte doch der Ausgang automatisch den hochohmigen Wert annehmen

Das würde ein expliziter RS485-Treiber bestimmt auch machen. Von selbst allerdings geht das nicht.

Zitat:Wenn also nach dem gesendeten Frame eine Pause von mehr als 500ms (wurde als timeout-Zeit gewählt) eintritt, müsste der FU auf den Frame antworten.

Ich gehe davon aus, dass der FU möglicherweise bereits nach 10ms auf das Datenpaket vom PC antwortet. Oder anders ausgedrückt: Die Antwort des FU sollte innerhalb dieser 500ms am PC ankommen.

Du solltest folgendes zuerst verifizieren: Hast du eine 2-Draht- oder eine 4-Draht-Verbindung? Je nach dem tritt ein anderer Fehler auf. Den von mir beschriebene Effekt gibt es nur bei RS485 (RS485/2)

Anzeige

hallo nochmals,

Als allererstes: es liegt (laut Hersteller) eine RS485/2 Schnittstelle vor.

Wegen Zeitmangel konnte ich bis jetzt nicht viel an dem Problem weiterarbeiten.

Danke an jene, die sich die Mühe machten und sich dazu geäußert haben.

Grüße
Elmar

Schmeiss die Null vor der 3 und der 6 in der Case-Struktur raus.
Du wandelst in eine Zahl, da gibt es dann keine führende Null.

Gruß, Jens

(11.04.2011 10:44 )schuch schrieb:  Die Fehlermeldung lautet:
Ort: Blockdiagrammfehler -> case-Strucktr ...
Detail: Einige der für die Case-Struktur definierten Auswahlwerte konnten nicht in den Typen des Selektors umgewandelt werden.

Ein Case hat einen Fehlerhaften Selektor. D.h. du willst eine Typ Selektieren, der nicht erlaubt ist. Konkret sieht das in deinem Fall so aus:

1) Du kannst an der Casestruktur erkennen, welcher Case fehlerhaft ist:

   

D.h. alles was rot ist, ist ein falscher Typ am Selector.

2) Der Typ ist Dezimalzahl, wobei in deinem Fall die 0 vor der 3 (bzw. 6) fehlerhaft ist. Mit '03' wird der Case als String bewertet und mit Anführungszeichen ("03") versehen, da er als Zahl '03' nicht kennt. Also einfach die '03' (und '06') ohne die '0' schreiben.

Ich hoffe ich konnte es verständlich erklären.

Beste Grüße,
NWO

Danke, hab es so gemacht, den String auch als solchen in den Case laufen zu lassen.
Das Programm läuft jetzt für alle 3 relevanten Fälle fehlerlos durch. Juhu, keine Fehlermeldungen mehr.

Der Fall "03" read sollte mir eigentlich eine Antwort des FUs liefern. (Also nur um das nochmal abzuklären: ich habe es doch richtig verstanden, dass MB Read eine Antwort liefern soll.)
Leider geht der Antwort-String irgendwohin, nur nicht in das dafür vorgesehene Fenster. Hat da einer ne Idee?