RS-485 Dateninput

Hallo,

ich versuche zur Zeit mein Haus und unter anderem die Heizungssteuerung mit Hilfe von Symcon zu visualisieren.
Die Steuerung besitzt einen P-Bus (RS-485). Auf dem Bus wird schon zyklisch im Abstand von 1Minute ein komplettes Datenpaket übertragen. Der Gedanke liegt also nahe das Paket einfach mit zu loggen und anschließend mit Hilfe des cuters die Daten entsprechend aufzuteilen.
Leider wird neben dem Datenpaket noch zyklisch ein Token von dem Systemregler ausgegeben. Ich kenne den Sinn nicht ganz und vermute dass die hohe Frequenz der Ausgabe letztendlich mir ein Problem macht, dass die Datenabtrennung probleme bekomm und nicht stabil funktioniert.
Ein einzelnes Paket wird immer mit FF FF begonnen und mit FE FE beendet.

Gibt es jemand der schon unter ähnlichen Umständen versucht hat Daten von einer seriellen Schnittstelle in Symcon einzulesen und zu verarbeiten.

Vielen Dank im Voraus für eure Hilfe
LG

Seriell -> Cutter -> Registervariable -> Script.

Im Cutter linkes Trennzeichen FF FF, rechtes FE FE. Somit kannst Du im Script die Daten verarbeiten.

Hallo Rainer,

zunächst mal - Vielen Dank für die Antwort.

Ich hatte mir das auch so vorgestellt, leider ist das Ergebnis aber nicht wie ich mir das vorgestellt habe.

Hier mal meine Einstellungen

ich möchte nur den großen Datenblock (siehe meine erste mail) slicen. Die anderen Daten brauche ich nicht.

Gibt es da eine Idee was ich da falsch mache?

Gruß
Franz

Hallo Franz,

der Cutter, schickt dir ja die Daten immer im entsprechenden Paket. Wenn Du jetzt nur das grosse benötigst, werte doch die Daten über die Anzahl aus. So ala if strlen >= 20 nimm die Daten ansonsten brauch ich sie nicht.

Sieht dann im Script so ähnlich aus.

if(strlen($_IPS['VALUE']) >=20) print_r $_IPS['VALUE'];

Die Ausgabe siehst Du dann in den Meldungen.

Hallo Rainer,

ich habe da noch ein Verständnissproblem.
Wenn ich dem Cuter die Start und die Stop-bedingung sage, dann würde ich jetzt in meiner naiven Erwartungshaltung annehmen, dass es danach Byte folgen gibt die mit der eingebenen Startbedingung anfangen und mit der gewählten Stopbedingung aufhören.
Dies kann ich nicht nachvollziehen. Eher das Gegenteil ist der Fall. Ich finde in dem Cuterteil auch Teile der Meldung die ich bewußt durch durch die Schneidbedingung auschliesen will.

Franz

Hallo Franz,

nein, der Cutter sendet alles zwischen Anfang und Endzeichen. Die Zeichen selber, werden nicht übertragen.

Im Cutter, musst Du also bei FF FF - FE FE bei SendChunk deine Bytefolge haben.

Hallo Rainer,

ich formulier meine Frage mal anders.
Hier ist der reale Datenfluss noch mal.
Ich habe dabei die Daten die ich wollte grün markiert. Die Startbedingung ist blau markiert (ist immer gleich) und am Schluss wieder das „FE FE“.

Wie würdest Du den Cutter einstellen, dass am Ende möglicht die grün markierten Daten übrig bleiben.

Danke, für deine Mühe im Voraus

Franz

Blau linkes und FE FE rechtes Trennzeichen, dann bleibt grün übrig.

OK,

hier gibts leider einen Unterschied zwischen Theorie und Praxis.
Ich hatte das probiert und das Ergebnis schaut ungefähr wie im Beitrag #3 aus.

Wie gesagt/geschieben ist der Rest ein wildes durcheinander von Daten die eigentlich excludiert sein sollten.

Gibts da noch eine Idee?

Gruß

Franz

Die Trennzeichen hast Du aber mit setzen übernommen. Wenn es trotzdem nicht geht, stimmen deine Rohdaten nicht. Am besten mal im Debug vom Comport nachsehen.

Hallo,

ich hab das jetzt noch mal verifiziert. Die Daten stimmen. Ich hab Sie mit einem Terminalpprogramm angesehen. Die gleiche Sequenz kann ich im Debugfenster des Com ports finden.
Nach dem Slicer ist aber das Chaos. Irgendwie findet er offensichtlich den Einstieg nicht.
Kann es sein, dass eventuell hier intern was überläuft oder arbeitet der Slicer ähnlich einem Filter und läßt alles durch was die Start und Stopbedingung erfüllt.

Ich kann leider die Vielzahl der unnützen und ungewollten Buskommunikation nicht abstellen und muss damit leben.

Gibt es noch eine Idee was ich tun kann oder was ich eventuell noch falsch eingestellt habe.

Viele Grüße

Franz

Nimm bitte wirklich einmal die Debug Ausgabe vom Comport. Vielleicht ist da etwas was dir dein Terminprogramm unterschlägt.
Micha

Gesendet von meinem TAB-PROTAB2XXL(4) mit Tapatalk 2

Hallo Franz,

wenn Du willst, schick mir doch mal einen Dump vom Comport. Ich schau dann mal drauf am Wochenende.

Hallo Rainer,

dump habe ich gemacht.
Es geht wie gesagt um den Block der mit

FF 00 65 05 01 02 64

beginnt.

Sorry, wenn das so eine schwere Geburt ist.

Gruß
Franz

serial-dump_long.txt (42.6 KB)

Hallo Franz,

häng bitte nochmal einen Dump als String an nicht in HEX.

Hallo Rainer,

die Daten sind eigentlich keine ASCII Daten. Aber wenn das hilft - hier sind sie.

serial-dump_ASCII.txt (12.1 KB)

Viele Grüße

Franz

Hallo Franz,

der Cutter macht das was er machen soll. Allerdings ändert sich deine Sequenz.

Trag mal als linke Trennzeichen FF FF 00 65 05 01 02 64 ein und rechts FE FE.

Hallo Rainer,

ja, die Sequenz ändert sich. Ich habe die Sequnz eh schon so.
Das Ergebniss ist so wie schon gepostet.
Außerdem sollte eigentlich wenn die Startbedingung nicht erfüllt wird (weil die Sequnz sich ändert) dann einfach nichts mehr rauskommen.
Es gibt hier irgend was wo das Ganze aushebelt.
Komme einfach nicht drauf.

Gruß
Franz

Moin Franz,

mich interessiert jetzt noch mal der Debug vom Cutter mit Trennzeichen links FF FF + rechts FE FE.

Hallo Rainer,

hier ist er.

Symcon hat natürlich, da alle anderen Sequenzen auch mit FF FF anfangen und FE FE aufhören auch diese mit durchgelassen. Das ist soweit logisch.

dump_FF FF-FE FE.txt (47.2 KB)

hier noch mit der erwiterten Startbedingung
FF FF 00 65 05 01 02 64

dump FF FF 00 65 05 01 02 64 - FE FE.txt (187 KB)

Gruß

Franz