Ethernet.lib

[Benno]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo zusammen,

ich nutze eine Wago 750-881 und möchte in meinem Haus die Be- und Entlüftung ComfoAir 350 über RS232 auslesen. Ich habe mir einen Schnittstellenwandler gekauft (RS232->Modbus ) und habe diese so eingestellt, dass sie als UDP-Server arbeitet. Da ich absoluter Anfänger in Sachen Kommunikation bin, habe ich mir das Programm EthernetClientExample von Wago als Einstieg genommen. Eine Verbindung habe ich am stehen und Daten bekomme ich auch schon. Nun möchte ich aber gerne Kommandos rüber schicken um zu steuern. Hier fangen meine Probleme an. Anbei habe ich euch mal ein Bespielkommando angehangen. Was ist das für ein Zahlenformat und wie kann ich dies am besten verschicken (umwandeln)? Wie kann ich dies am besten umsetzen?

Ich wäre über jede Hilfe dankbar.

Gruß
Benno

 

[Thruser]

Hallo,

meinnst Du die hhexadezimale Darstellung der Bytes? (0x07 = 7, 0xFF = 255)

0x07 wird als 16#07 eingegeben, oder dezimal als 7. 0xFF dann als 16#FF oder 255

Gruß

 

[Benno]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ah ok, das war mein Problem. Wie kann ich das am besten umsetzen?

Danke und Gruss
Benno

 

[.:WAGO::015844:.]

Hallo Benno,

grundsätzlich wäre es sicherlich deutlich einfacher gewesen, den Wago Controller 750-881 mit einer seriellen Klemme (z.B. 750-652) auszustatten und die Kommunikation direkt zu lösen. Die Hardware ist für diesen Fall vielleicht nicht ganz glücklich gewählt.

Wenn dein Umsetzter auf RS232 mit Modbus UDP arbeitet, wirst du diesen auch mit Modbus ansprechen müssen.
Dafür würde ich dir die WagoLibModbus_IP_01.lib empfehlen, anstatt der Ethernet.lib (WagoLibEthernet_01.lib ???).
Danach müsstest du dich mal damit beschäftigen, wie der Umsetzer die umzusetzenden Daten erwartet (Register Mapping) um das entsprechende RS232 Telegramm zu bilden.

 

[Benno]

Hallo zusammen,

ich bin ein bisschen weiter gekommen. Ich muss mich korrigieren. Ich habe einen Schnittstellenwandler von RS232 zu Ethernet TCP/IP. Dann müsste die Ethernet.Lib doch passen, oder? Ich arbeite immer noch mit dem Beispielprogramm "EthernetClientExample" von Wago. Daten empfangen klappt schon. Bloß beim Kommando verschicken habe ich noch Probleme. Im Anhang hab ich ein Beispielkommando aus der Protokollbeschreibung der ComfoAir. Dieses hab ich versucht in CoDeSys nachzubilden (siehe Anhang). Nur Leider bekomme ich keine Antwort. Ist der Aufbau des Kommandos in CoDeSys korrekt oder mach ich noch was falsch?

Danke für Eure Unterstützung.

Gruß
Benno

 

[Thruser]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

Du mußt den count auf die Anzahl der zu sendenden Bytes setzen, hier bei Deinem Beispiel 8.

Dann wirst Du auch noch response anpassen müssen. Hier findet eine Umformung im einen String statt, den kannst Du aber nicht nutzen. Du mußt dort auch ein Array of Bytes nehmen. Am besten Du nimmst dort erst einmal typEthernet_buffer zum beobachten.

Gruß

 

[Benno]

Funktioniert! Besten Dank!

Gruß
Benno

 

[Benno]

Hallo zusammen,

ich bin gerade dabei Kommandos zu senden und die Empfangenen Daten auszuwerten. Ich hangele mich dabei ganz nahe an dem Anwendungsbeispiel von
Wago(Client-Server Anwendung mit Ethernet.lib ). Leider bekomme ich es nur hin ein Kommando automatisiert zu senden und auszuwerten. Sobald ich ein weiteres Kommando in meiner Case-Anweisung hinzufüge (in diesem Fall VentilatorStatus abrufen ), wertet er nur letzteres aus und nicht mehr die Temperaturen(siehe Anhang). Was mache ich falsch?

Danke für Eure Hilfe.

Gruß
Benno

 

[Thruser]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

das liegt wahrscheinlich an Deiner Weiterschaltbedingung. Du mußt iSTep:=2; zumindest mit einem False von xSTART_SEND verknüpfen, damit das erste Kommando sauber abgearbeitet werden kann. Das ganze kann nämlich wahrscheinlich länger als ein Zyklus laufen.

Eventuell sogar auch noch mit einem weiteren Flankenimpuls Deines Triggers, da sonst sofort das zweite Kommando gesendet wird und Du das ganze besser beobachten kannst

Gruß

 

[Benno]

Wie vermutet hat die Abarbeitung länger als ein Zyklus gedauert. Habe dies jetzt mit einer Verzögerung gelöst.

Danke.

 

[Thruser]

Hallo,

wenn ich Dich richtig verstehe verwendest Du einen Timer (oder ähnliches), um eine zeitlichen Versatz zwischen den beiden Komanndos zu bekommen.

Die Lösung ist eigentlich nicht sehr schön und auch nicht ganz richtig. Nach dem Dokument läuft die Kommunikation ja in 4 Schritten ab, die Du hier auch als Zustandsautomat bzw. Schrittkette abbilden kannst. Erst wenn diese Kette abgearbeitet ist, solltest Du das nächste Kommando senden. Eventuell kommt noch ein Schritt für die Auswertung der Antwort dazu.

1. Kommando senden (xSTART_SEND setzen, warten bis zurückgesetzt durch Funktion)
2. Auf ACK warten (lesen bis Antwort kompletter ACK)
3. Auf komplette Antwort warten (lesen bis Ende zeichen erkannt, Länge und Checksumme prüfen - falls nicht: wieder Schritt 3? (Keine Ahnung ob Antwort sonst wiederholt wird))
4. ACK senden (ACK Folge als Daten setzen, xSTART_SEND setzen, warten bis zurückgesetzt durch Funktion)

Und danach kann dann als 5. Schritt die Antwort ausgewertet werden, z.B. Variablen zuordnen.

Gruß

 

[Benno]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hi Thruser,

ja momentan Verzögere ich 5 Zyklen bis ich das nächste Kommando sende. Dein Ansatz leuchtet mir ein und ich werde es auch so umsetzen, danke dafür . Wofür ist der 4. Schritt notwendig, sprich das ich nochmal ein ACK zurück sende?

Danke für eine kurze Info.

Gruß
Benno

 

[Thruser]

Hallo,

das habe ich so aus der Protokollbeschreibung. Ob es tatsächlich notwendig ist kann ich nicht sagen, ich habe kein Gerät zum testen.

Gruß

 

[Benno]

Achso, ok. Ich bin bis dato so verfahren, dass ich kein ACK mehr zurück sende. Bis jetzt hatte ich keine erkennbare Einschränkung.

Gruß
Benno