siemens sps zu hardware kommunizieren mit Rs422/485

[spsEngineering]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich habe hier mit s7-1200 sps mit Rs485 zwei Temperatur messung kamera angeschlossen , und habe ich jeder kamera eine mit Busadresse definiert. 001 und 002 . das problem ist das jetzt kamera nimmt alle daten was mit port Rs485 kommt , hat jemand ahnung wie kann ich die 2 unterscheiden damit nimmt eigene daten. ich habe von punkt zu punkt kommunikation , send ptp und rcv ptp gearbeitet. wenn ich mit kommando 001?T$L$R schicke dann es muss ein antwort mit 001!T = 25.5°C$R geben , manchmal kriege ich das aber ab und zu kriege komische zeichen. Und der Kamera hat auch terminierung widerstand drinne,

 

[Heinileini]

Das habe ich im letzten JahrTausend mit einem PC per Basic-Programm und mit zig Jumo-Reglern problemlos zum Laufen gebracht - allerdings an Siemens vorbei.
Ich hoffe, Du schüttest die Schnittstelle nicht mit Aufträgen so zu, dass es eng wird. Immer schön abwarten, bis ein Auftrag zu Ende ausgeführt ist, eher der nächste ausgegeben wird. Mehr kann ich leider nicht beitragen.

 

[spsEngineering]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das habe ich im letzten JahrTausend mit einem PC per Basic-Programm und mit zig Jumo-Reglern problemlos zum Laufen gebracht - allerdings an Siemens vorbei.
Ich hoffe, Du schüttest die Schnittstelle nicht mit Aufträgen so zu, dass es eng wird. Immer schön abwarten, bis ein Auftrag zu Ende ausgeführt ist, eher der nächste ausgegeben wird. Mehr kann ich leider nicht beitragen.

kannst du mir bisschen hinweis geben wie kann ich die 2 hardware in einem serial port einsetzen , waere sehr dankbar.

 

[Thomas_v2.1]

Bei RS485 ist das Protokoll ja nicht festgelegt, d.h. wann sich ein Teilnehmer überhaupt vom Empfangs- auf den Sendemodus umschalten darf.
Wenn das bei dir mit 001? und 002? als geschieht, muss das ja in den Geräten dokumentiert sein. Was sind das denn genau für Temperaturmessungen?
Ich würde mal versuchen nur einen Teilnehmer am Bus anzuschließen wie es sich dann verhält. Dann sollte sich ja nur unter einer Adresse jemand melden.

 

[JSEngineering]

Moin Sarjan,

das Thema hängt doch bestimmt mit diesem Thread zusammen:

TIA Portal V17 kommunikation fehler.

Ich habe mit CM1241 RS422/485 ein temperatur sensor verbundet und will der temperatur auslesen. ich habe als baustein punkt zu punkt kommunikation benutzt aber manchmal kriege ich gute temperatur aber manchmal mit unknown zeichen. Habe so viel recherchiert aber kriege ich kein antwort. können...

www.sps-forum.de

Bisher war von einer Kamera die Rede. Funktioniert das denn jetzt mit einer Kamera?
Erst einmal nur mit einer probieren und das sauber zum Laufen bekommen und dann um die zweite Kamera kümmern.

 

[spsEngineering]

Zuviel Werbung?
-> Hier kostenlos registrieren

Moin Sarjan,

das Thema hängt doch bestimmt mit diesem Thread zusammen:

TIA Portal V17 kommunikation fehler.

Ich habe mit CM1241 RS422/485 ein temperatur sensor verbundet und will der temperatur auslesen. ich habe als baustein punkt zu punkt kommunikation benutzt aber manchmal kriege ich gute temperatur aber manchmal mit unknown zeichen. Habe so viel recherchiert aber kriege ich kein antwort. können...

www.sps-forum.de

Bisher war von einer Kamera die Rede. Funktioniert das denn jetzt mit einer Kamera?
Erst einmal nur mit einer probieren und das sauber zum Laufen bekommen und dann um die zweite Kamera kümmern.

es funktioniert ohne problem des erste kamera. Nachdem ich zweite kamera verbundet habe bei receive buffer nimmt alle temperatur mit unknown zeichen, das ist die problem jetzt.

 

[JSEngineering]

Für mein Verständnis:
Du sendest: 001?T$L$R
Antwortet jetzt Kamera 1 oder Kamera 2 oder beide?

Wenn beide senden, dann hast Du Überlagerung der Telegramme = kaputt.

 

[spsEngineering]

Für mein Verständnis:
Du sendest: 001?T$L$R
Antwortet jetzt Kamera 1 oder Kamera 2 oder beide?

Wenn beide senden, dann hast Du Überlagerung der Telegramme = kaputt.

ich habe 2 send und Rcv bausteine . erste kamera habe ich busadresse 001 und zweite 002 , deswegen schicke ich erste 001?T$L$R danach 002?T$L$R . aber in Receive habe ich nicht genau temperatur gekriegt.

 

[JSEngineering]

Zuviel Werbung?
-> Hier kostenlos registrieren

Du fragst also beide gleichzeitig an?
Das wird nicht funktionieren...

1. Frage Kamera 1
2. Warte auf Antwort Kamera 1
3. Frage Kamera 2
4. Warte auf Antwort Kamera 2
5. Beginne mit 1.

Ich hoffe, Du schüttest die Schnittstelle nicht mit Aufträgen so zu, dass es eng wird. Immer schön abwarten, bis ein Auftrag zu Ende ausgeführt ist, eher der nächste ausgegeben wird.

 

[spsEngineering]

Du fragst also beide gleichzeitig an?
Das wird nicht funktionieren...

1. Frage Kamera 1
2. Warte auf Antwort Kamera 1
3. Frage Kamera 2
4. Warte auf Antwort Kamera 2
5. Beginne mit 1.

Ich habe mit clock eingesetzt in frage des send ptp und danach timer zum Rcv . genauso habe ich mit andere camera gemacht. Ist es ordnung oder noch etwas müssen wir machen

 

[Heinileini]

"AlwaysTRUE" am Eingang des Timers? Was soll das bewirken?
Ich mache mir mittlerweile Gedanken, ob nicht der Receive bereits das Abfragen der Information enthält. Ich kenne leider den FunktionsUmfang und die Funktionsweise des Bausteins nicht.

 

[JSEngineering]

Zuviel Werbung?
-> Hier kostenlos registrieren

"AlwaysTRUE" am Eingang des Timers? Was soll das bewirken?
Ich mache mir mittlerweile Gedanken, ob nicht der Receive bereits das Abfragen der Information enthält. Ich kenne leider den FunktionsUmfang und die Funktionsweise des Bausteins nicht.

Das bewirkt nur, daß der Receive 1s nach Programmstart aktiv wird.
Ob der Receive auch das Senden empfängt gute Frage... Vermute aber, daß der CP so intelligent sein wird, das zu unterscheiden.

Ich würde auf jeden Fall das Send_PTP.Done an das RCV_PTP.EN_R anbinden.

Und wie gesagt: nicht beide Kameras gleichzeitig ansprechen, dann wollen auch beide gleichzeitig antworten.

Das ganze am besten in eine Schrittkette einbauen.

 

[Heinileini]

Ob der Receive auch das Senden empfängt gute Frage... Vermute aber, daß der CP so intelligent sein wird, das zu unterscheiden.

Ich glaube, da haben wir uns falsch verstanden. Die Leitungen für Senden und Empfangen sind doch zwei separate Leitungen und die SendeLeitung des CP ist doch nicht auf die EmpfangsEingang verdrahtet!?
Mir schwebte eher etwas in der Richtung Get vor. Dass nämlich mit dem Baustein eine bestimmte Information abgeholt werden soll und dazu selbstverständlich zunächst die Information gesendet werden muss, welche Information man zu lesen gedenkt.
Ich denke mal, dass man diesen Ablauf zu Fuss mit Send und Receive in "EigenRegie" programmieren muss.

Das bewirkt nur, daß der Receive 1s nach Programmstart aktiv wird.

Wie kann man dem Receive mitteilen "jetzt bitte den EmpfangsPuffer nicht mit dem nächsten empfangenen Telegramm überschreiben, weil ich ihn noch nicht ausgwertet habe"? Ich würde erwarten, dass man dazu den EN_R "wegnimmt", bis man wieder bereit ist, etwas zu empfangen.
Was macht denn der Receive, wenn ich den EN_R dauernd (sozusagen für mehrere Telegramme) auf TRUE belasse?

Die SendeAufträge bei betätigter Taste im 10-Hz-Rhythmus hinauszudonnern finde ich etwas abenteuerlich.

 

[JSEngineering]

Ich glaube, da haben wir uns falsch verstanden. Die Leitungen für Senden und Empfangen sind doch zwei separate Leitungen und die SendeLeitung des CP ist doch nicht auf die EmpfangsEingang verdrahtet!?

Naja, eigentlich nicht, RS485 arbeitet in der Regel mit 2-Draht... also kann ich theoretisch selber hören, was ich sage... aber das sollte eigentlich der CP regeln können...

Wie kann man dem Receive mitteilen "jetzt bitte den EmpfangsPuffer nicht mit dem nächsten empfangenen Telegramm überschreiben, weil ich ihn noch nicht ausgwertet habe"?

Nun ja, den Empfangspuffer steuerst Du damit glaube ich nicht, nur die Auswertung des selben. Denn der Puffer liegt ja im CP und der Receive geht nur vorbei und guckt nach, ob da was liegt. Wenn jetzt der Puffer durch irgendwas geflutet würde, könntest Du das nicht verhindern. Dann gibt es den Puffer-Überlauf. Dann muß man öfter mit Receive vorbeikommen und den Inhalt abholen.

Ich bin immer noch bei der Schrittkette - und da kann man dann auch schick bestimmen, wie oft man die anstößt, ob mit 1Hz oder schneller...
Vielleicht will man ja bei Tastendruck auch nur einmal lesen!?

 

[Heinileini]

Zuviel Werbung?
-> Hier kostenlos registrieren

Naja, eigentlich nicht, RS485 arbeitet in der Regel mit 2-Draht... also kann ich theoretisch selber hören, was ich sage... aber das sollte eigentlich der CP regeln können...

Dafür finde ich keinen Beleg. Da ist die Rede von HalbDuplex mit 2 Leitungen und VollDuplex mit 4 Leitungen.
In beiden Fällen wird das Vorhandensein einer weiteren Leitung (GND bzw. BezugsPotenzial) oft verschwiegen bzw. nur angedeutet.
Die 2 Leitungen bei 2-Draht sind RxD und TxD (receive und transmit = send).
Die 4 Leitungen bei 4-Draht sind RxD+ und RxD- sowie TxD+ und TxD-, weil hier Differenz-Ausgänge und -Eingänge verwendet werden.

In beiden Fällen ist damit nicht gemeint, dass Sende- und EmpfangsDaten sich dieselbe Leitung teilen bzw. abwechselnd belegen.
Im Übrigen enthalten beide Bezeichnungen (HalbDuplex und VollDuplex) das Wort Duplex, das ja besagt, dass gleichzeitig empfangen und gesendet werden kann.

Vielleicht will man ja bei Tastendruck auch nur einmal lesen!?

Davon gehe ich auch aus. Aber das muss man erst mal schaffen, wenn man mit dem TastenDruck ein 10-Hz-Signal moduliert.

 

[PN/DP]

Der hier beim Fragesteller verwendete RS485 verwendet wie üblicherweise 2 Leitungen (A und B, oder P und N, manchmal auch als RxTx+ und RxTx- bezeichnet, GND wird nicht benötigt!), die abwechselnd für Senden und Empfangen verwendet werden (halbduplex). Es darf immer nur ein Teilnehmer senden. Slaves dürfen nur nach Aufforderung senden in einem je nach Protokoll vorher festgelegten Zeitfenster. Deshalb muß immer zu nur einem Teilnehmer etwas gesendet werden und die Antwort (oder Timeout) abgewartet werden, bevor mit dem nächsten Teilnehmer kommuniziert werden kann.

Harald

 

[spsEngineering]

Der hier beim Fragesteller verwendete RS485 verwendet wie üblicherweise 2 Leitungen (A und B, oder P und N, manchmal auch als RxTx+ und RxTx- bezeichnet, GND wird nicht benötigt!), die abwechselnd für Senden und Empfangen verwendet werden (halbduplex). Es darf immer nur ein Teilnehmer senden. Slaves dürfen nur nach Aufforderung senden in einem je nach Protokoll vorher festgelegten Zeitfenster. Deshalb muß immer zu nur einem Teilnehmer etwas gesendet werden und die Antwort (oder Timeout) abgewartet werden, bevor mit dem nächsten Teilnehmer kommuniziert werden kann.

Harald

Habe ich mit Clock gearbeitet jeder 1sekunde schickt die daten und nimmt mit Receive Buffer. Aber wie kann ich da fragen zu warten nach etwas geschickt habe. kann ich mein program zeigen wenn du willst. Danke erst mal für Hilfe.

 

[spsEngineering]

Zuviel Werbung?
-> Hier kostenlos registrieren

ich habe hier mein code unten eingefügt . kann jemand helfen damit der program zu lösen und wollte auch schrittkette bauen aber irgendwo der program stoppt selber. und da in code habe ich length genommen weil wenn etwas buffer in Receive kommt dann incrementiert die length.
wenn jemand mit quellcode hilft dann wäre hilfreich.

 

[JSEngineering]

Moin SPSengineering,

sind die beiden Code-Fragmente Alternativen oder laufen die irgendwie zusammen?
Beim FUP-Ausschnitt sehe ich am ersten Send ein dauerhaftes TRUE. Ich weiß nicht, ob der Baustein auf Flanke reagiert... Entweder sendet er genau ein Mal oder aber dauerhaft. Die weiteren Bausteine hingegen sind mit FALSE deaktiviert!?

Im SCL-Ausschnitt wird es noch konfuser: Du fragst ein Request vom Send ab und aktivierst damit den Receive!? Warum benutzt Du nicht die Done und NDR Ausgänge der Bausteine?

Wenn Du schon in SCL programmierst, dann nutze doch die CASE-Anweisung, um eine vernünftige Schrittkette zu programmieren:

VAR Temp
    step : int;
end_var

CASE step OF
    0: //Send-Bausteinaufruf mit REQ := true
       step := step + 1;
    1: //Send-Bausteinaufruf mit REQ := false
       IF Send.Done THEN
          step := step + 1;
       END_IF;
    2: //Receive-Baustein-Aufruf
       IF Receive.NDR THEN
             step := step + 1;
       END_IF;
    3: // Auswerung der empfangenen Daten
       step := ...// entweder wieder zu 0 springen oder weiter mit weiteren Schritten für die zweite Kamera
          
END_CASE;

Das muß natürlich weiter ausgeschmückt werden mit Fehlerabfrage etc. pp.

 

[spsEngineering]

Moin SPSengineering,

sind die beiden Code-Fragmente Alternativen oder laufen die irgendwie zusammen?
Beim FUP-Ausschnitt sehe ich am ersten Send ein dauerhaftes TRUE. Ich weiß nicht, ob der Baustein auf Flanke reagiert... Entweder sendet er genau ein Mal oder aber dauerhaft. Die weiteren Bausteine hingegen sind mit FALSE deaktiviert!?

Im SCL-Ausschnitt wird es noch konfuser: Du fragst ein Request vom Send ab und aktivierst damit den Receive!? Warum benutzt Du nicht die Done und NDR Ausgänge der Bausteine?

Wenn Du schon in SCL programmierst, dann nutze doch die CASE-Anweisung, um eine vernünftige Schrittkette zu programmieren:

VAR Temp
    step : int;
end_var

CASE step OF
    0: //Send-Bausteinaufruf mit REQ := true
       step := step + 1;
    1: //Send-Bausteinaufruf mit REQ := false
       IF Send.Done THEN
          step := step + 1;
       END_IF;
    2: //Receive-Baustein-Aufruf
       IF Receive.NDR THEN
             step := step + 1;
       END_IF;
    3: // Auswerung der empfangenen Daten
       step := ...// entweder wieder zu 0 springen oder weiter mit weiteren Schritten für die zweite Kamera
         
END_CASE;

Das muß natürlich weiter ausgeschmückt werden mit Fehlerabfrage etc. pp.

ich habe probiert erst mal nur eine kamera in schrittkette zu laufen aber es schickt nur einmal die Temperatur und stoppt. ist da irgendwo fehler mit Send REQ ? Habe ich foto unten beigefügt .