TIA Sensor Anschluss über CB 1241 RS485

[holgermaik]

Zuviel Werbung?
-> Hier kostenlos registrieren

Warum hat die Simulation funktioniert?

Weil er da die Voreingestellten Werte des Sensors benutz hat (8N2)

 

[Heinileini]

(8N2)

- Anzahl DatenBits (Ziffer, üblicherweise 7 oder 8 )
- Parität, Buchstabe (N=no/"nix", E=even/gerade, O=odd/ungerade)
- Anzahl StoppBits (Ziffer, üblicherweise 1 oder 2)
Habe nie erlebt, dass die falsche Angabe der Anzahl StoppBits zu Problemen geführt hätte. Ich vermute, dieses Thema war - wenn überhaupt - vielleicht zur Zeit der Fernschreiber relevant.
Habe aber oft erlebt, dass man 8 DatenBits MIT Parity (even oder odd) problemlos parametrieren kann - sogar dann, wenn die so parametrierte Schnittstellen"Hardware" gar nicht in der Lage ist, mehr als 8 Bits (DatenBits + ParityBit) zu verarbeiten!

 

[ban-al]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Holger,
ja, das hatte ich gesehen. Parallel habe ich dazu aber ein Skript vom Hersteller bekommen, in dem ein anderer Kunde den Anschluss auch über eine S7 1200 angeschlossen hat und dort "keine Parität" und 2 Stoppbits verwendet. Da der MB_Comm-Load Baustein bei mir mit gerader Parität nicht funktionierte habe ich das wieder verworfen (hätte damals wahrscheinlich auch gleich den Modbus_Comm_Load nehmen sollen)

Beste Grüße
Al

 

[ban-al]

Hmmm.
Ist denn für ModBus das DatenFormat nicht festgelegt? Ich hätte jetzt vermutet, 8 DatenBits mit ohne ParityBit, weil 8 DatenBits mit ParityBit (egal, ob even oder odd) eher "exotisch" sind (ausser Siemens-intern).
Wenn das DatenFormat also nicht "in Stein gemeisselt" ist, dann sollte es doch eigentlich S7-seitig auch anpassbar sein.
Warum muss der Hersteller des Sensors den Sensor anpassen? Hat er versäumt, dem Anwender die Möglichkeit dafür zu geben?
Wenn das DatenFormat doch "in Stein gemeisselt" sein sollte, wer ist dann vom Standard abgewichen? Die S7-Seite oder die Sensor-Seite?
Warum muss der Hersteller des Sensors den Sensor anpassen? Hat er den Sensor falsch parametriert ausgeliefert? Oder hat es der Anwender (unwissentlich) geschafft, den Sensor umzuparametrierten?
Hat der Hersteller des Sensors nicht auf diese Falle hingewiesen?
Warum hat die Simulation funktioniert? Ist die Simulation so intelligent, automatisch festzustellen, ob der Sender ohne Parity oder mit Parity even oder mit Parity odd arbeitet?
Und insbesondere, ist die Simulation so intelligent zu wissen, ob der Empfänger ohne Parity erwartet oder mit Parity even oder Parity odd?
Hmmm.
Durch irgendetwas hätte man doch auf die Spur des ParityBits gelenkt werden müssen. Klar war nur, dass sich der Sensor anscheinend überhaupt nicht angesprochen fühlte.

Leider habe ich nicht gewusst, dass man die Anzahl der Stoppbits noch mal im DB des Comm_Load Bausteins einstellen muss.
Was jetzt hier Standard ist, kann ich nicht sagen, der Hersteller des Sensors hat halt offenbar einen Standard und kann diesen auf Wunsch ändern.

Ich danke Euch auf jeden Fall allen für Eure Hilfe und bin froh, dass es jetzt funktioniert!