-> Hier kostenlos registrieren
Hallo zusammen,
wir empfangen auf einem serverseitigen System TCP-IP-Nachrichten von SPS-Steuerungen.
Im Rahmen einer Weiterentwicklung haben wir beschlossen, künftig auch Wago bzw. Beckhoff Steuerungen an unserem Konnektor zu betreiben.
Problematisch ist an dieser Stelle, dass sich die Telegramme trotz dem identischen Inhalt von Nutzdaten, je nach Steuerungstyp unterscheiden.
Siemens verwendet ein PackMode 2, Beckhoff lässt sich einstellen und Wago kann nur PackMode 4.
Bei der Analyse des empfangen Bytestreams ist es somit unterschiedlich, an welchem Byteoffset die nächste Variable beginnt, da je nach PackMode sogenannte Padding-Bytes vom PLC-Controller eingefügt werden. --> http://infosys.beckhoff.de/index.ph...cPlcLibSys_F_GetStructMemberAlignment.htm&id=
Behoben wäre das Problem innerhalb unserer Applikation (C#) durch die Abbildung eines Telegramms in Form von Strukturen. Diesen Strukturen könnte je nach Steuerung ein spezifisches LayoutAttribute vorangestellt werden. --> [StructLayout(System.Runtime.InteropServices.LayoutKind.Sequential, Pack=4)]
https://msdn.microsoft.com/de-de/li...ces.structlayoutattribute.pack(v=vs.100).aspx
Hierbei könnte über die Marshalklasse sowohl die Länge einer Variable als auch ihr Offset erfragt werden und anschließend mit dem PLC-spezifischen Converter in den entsprechenden .Net Datentyp gewandelt werden.
Da wir zum Start unserer Applikation die Vielzahl von Nachrichten nicht kennen, müssten wir zur Laufzeit mit CodeDom die Strukturen erstellen und laden. Da dies zu einem nur schwer lesbaren Quellcode führt, würde ich bei der Implementierung gerne darauf verzichten.
Jetzt zur eigentlichen Frage:
Ziel sollte es sein, dass unsere Converter-Klasse die Berechnung des nächsten Offsets selbständig übernehmen kann und somit den Algorithmus des LayoutAttributes "Pack" übernimmt.
Leider habe ich hier bei meiner bisherigen Suche im Netz noch nichts brauchbares gefunden.
Grundlage des Pack-Algorithmus ist meiner Meinung nach eine Modulo Berechnung. Allerdings bilden auch weitere Faktoren die Grundlage. Beispielsweise: Was ist mein nächster Datentyp im Stream... Je nachdem kann die Anzahl von Padding Bytes variieren.
Hatte von Euch evtl. jemand bereits vor einem ähnlichen Problem gestanden?
Vielen Dank für die Mithilfe!
Grüße,
spsTec
wir empfangen auf einem serverseitigen System TCP-IP-Nachrichten von SPS-Steuerungen.
Im Rahmen einer Weiterentwicklung haben wir beschlossen, künftig auch Wago bzw. Beckhoff Steuerungen an unserem Konnektor zu betreiben.
Problematisch ist an dieser Stelle, dass sich die Telegramme trotz dem identischen Inhalt von Nutzdaten, je nach Steuerungstyp unterscheiden.
Siemens verwendet ein PackMode 2, Beckhoff lässt sich einstellen und Wago kann nur PackMode 4.
Bei der Analyse des empfangen Bytestreams ist es somit unterschiedlich, an welchem Byteoffset die nächste Variable beginnt, da je nach PackMode sogenannte Padding-Bytes vom PLC-Controller eingefügt werden. --> http://infosys.beckhoff.de/index.ph...cPlcLibSys_F_GetStructMemberAlignment.htm&id=
Behoben wäre das Problem innerhalb unserer Applikation (C#) durch die Abbildung eines Telegramms in Form von Strukturen. Diesen Strukturen könnte je nach Steuerung ein spezifisches LayoutAttribute vorangestellt werden. --> [StructLayout(System.Runtime.InteropServices.LayoutKind.Sequential, Pack=4)]
https://msdn.microsoft.com/de-de/li...ces.structlayoutattribute.pack(v=vs.100).aspx
Hierbei könnte über die Marshalklasse sowohl die Länge einer Variable als auch ihr Offset erfragt werden und anschließend mit dem PLC-spezifischen Converter in den entsprechenden .Net Datentyp gewandelt werden.
Da wir zum Start unserer Applikation die Vielzahl von Nachrichten nicht kennen, müssten wir zur Laufzeit mit CodeDom die Strukturen erstellen und laden. Da dies zu einem nur schwer lesbaren Quellcode führt, würde ich bei der Implementierung gerne darauf verzichten.
Jetzt zur eigentlichen Frage:
Ziel sollte es sein, dass unsere Converter-Klasse die Berechnung des nächsten Offsets selbständig übernehmen kann und somit den Algorithmus des LayoutAttributes "Pack" übernimmt.
Leider habe ich hier bei meiner bisherigen Suche im Netz noch nichts brauchbares gefunden.
Grundlage des Pack-Algorithmus ist meiner Meinung nach eine Modulo Berechnung. Allerdings bilden auch weitere Faktoren die Grundlage. Beispielsweise: Was ist mein nächster Datentyp im Stream... Je nachdem kann die Anzahl von Padding Bytes variieren.
Hatte von Euch evtl. jemand bereits vor einem ähnlichen Problem gestanden?
Vielen Dank für die Mithilfe!
Grüße,
spsTec