CP 340 - Messwerte empfangen

rs-plc-aa

rs-plc-aa

Level-1
Beiträge
727
Reaktionspunkte
57
Zuviel Werbung?
-> Hier kostenlos registrieren
EDIT am 11.01.2008 : Der Thread war eingefroren - hier sollte es hauptsächlich weitergehen: https://www.sps-forum.de/showthread.php?p=114341#post114341

Hallo, ich hab folgende Aufgabe:
Eine S7-318 soll um eine CP340 erweitert werden um von einer anderen SPS (B&R) Daten (hauptsächlich Temperaturmesswerte) zu empfangen, und über Ihre bereits bestehende SINAUT Leitung nach draußen weiterzugeben.

Ich muss dazu sagen daß ich bisher noch keinen Kontakt mit dem anderen Hersteller (Sendepartner) hatte. Ich will mich vorher schon mal ein wenig schlau machen...

Was glaube ich bereits zu wissen?:
1.) Die CP340 in die Station einbinden, Adresse vergeben, Protokoll (3964R ist mal vorgesehen weil das die Gegenstelle *glaube ich* [laut Kunde] benötigt) einstellen, Speichern/Übersetzen+Laden.

2.) Den FB_Rcv in das Programm einbinden, DB zuweisen.

Wo es jetzt noch klemmt: wie wird der Empfang angestossen -> also woher weiß ich letztlich daß ein neuer Auftrag gestartet werden soll - bzw. ob es genügt in einem Zeitraster einfach zu empfangen...

Zeitraster: Das Startbit wird in einem Intervall gesetzt (das auf jeden Fall länger als die Bearbeitungszeit ist) und mit dem Ausgang "Auftrag erledigt" wieder zurückgesetzt.
Könnte das so gehen ? (Hierbei würde ja keine sendebereitschaft abgefragt)

Mal noch ganz nebenbei: geht das was ich da vorhabe überhaupt mit einer CP 340? Wenn der Sender die Messerte als einen Block überträgt kann ich sie dann z.B. wortweise aus dem DB (Empfangsfach) weiterverarbeiten ?
Oder wie wird das normalerweise "zerkpflückt" ?
 
Zuletzt bearbeitet:
1. Der CP 340 kann S3964R
2. Blockung übernimmt der CP bzw. die Prozedur 3964R, wieso bist Du nicht immer auf Receive enable?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
So weit bin ich ja noch gar nicht - es ist noch in der Entwurfsphase (bislang noch keine Kabelverbindung zum Sender)

Mir geht es momentan nur darum abzuchecken ob das Konzept so möglich ist und mich im Vorfeld ein wenig schlau zu machen (hatte ja noch nie eine CP340 im Einsatz -> daher)

Du meinst also ich kann auch RCV_Enable mit TRUE dauernd belegt lassen ?
Dann triggert sie sich quasi selbst ?

Das mit den Messwerten ist also kein Problem ?

Dann muss also der Sender seine Werte in einen DB packen dessen Struktur er mir mitteilt, ich erstelle den selben DB bei mir und lasse dort die empfangenen Daten von der CP 340 reinschreiben und fertig -> ist das so einfach ? (falls ja, um so besser...)

Apropos Kabelverbindung:

Falls von meiner Seite aus keine Daten gesendet werden müssen - genügt es dann das Kabel nur dahingehend (also nicht vollständig) zu belegen, oder müssen generell alle Pins belegt sein (also wie im Handbuch) ?
 
rs-plc-aa schrieb:
Apropos Kabelverbindung:

Falls von meiner Seite aus keine Daten gesendet werden müssen - genügt es dann das Kabel nur dahingehend (also nicht vollständig) zu belegen, oder müssen generell alle Pins belegt sein (also wie im Handbuch) ?
Zum Vergrößern anklicken....

Für 3964R brauchst Du Sende- und Empfangsleitung; die Handshakeleitungen sind überflüssig.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich will ja nicht "pushen" ...

Ist die Kabelbelegung so korrekt ? (es ist deswegen interessant weil ein 4*0,5mm² LIYCY schon vorhanden wäre...)

Und ob ein dauerndes TRUE am Recieve_Enable zulässig ist wäre noch interessant zu wissen.

Der Rest kann dann kommen wenn´s in Betrieb ist.

Danke schon mal !
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ja
RXD->TXD, TXD->RXD. GND->GND, Shield->Shield.

Der Empfang kann immer auf Enabled bleiben, der muss nur beim senden aus sein.

Aber beim Programm mit 3964R auf die zyklische Bearbeitung aufpassen.
Das NDR (Daten empfangen) ist nur für einen Zyklus da,
dann müßen sofort die Empfangsdaten umgeschaufelt werden !
 
jabba schrieb:
Ja
RXD->TXD, TXD->RXD. GND->GND, Shield->Shield.

Der Empfang kann immer auf Enabled bleiben, der muss nur beim senden aus sein.

Aber beim Programm mit 3964R auf die zyklische Bearbeitung aufpassen.
Das NDR (Daten empfangen) ist nur für einen Zyklus da,
dann müßen sofort die Empfangsdaten umgeschaufelt werden !
Zum Vergrößern anklicken....
Ok, Kabel abgehakt.

Ich dachte mir das mit den Daten folgendermaßen:

Da es nur ein durchlaufender Posten ist (die empfangenen Daten werden über eine SINAUT-Schnittstelle an den endgültigen Empfänger weitergegeben) kann das Umschaufeln doch eigentlich entfallen - oder?

D.h. die SINAUT Bausteine arbeiten "änderungsbasiert" -> wenn ich also die Daten des P_RCV DBs an die SINAUT FBs verknüpfe dann prüft ja SINAUT ob sich die Daten/Werte seit der letzten Abfrage geändert haben (bei Temperaturen kann dies ohnehin auch mal etwas länger dauern) und übertragen (Telegramm) wenn eine Änderungsschwelle überschritten wurde.

Sollte doch funktionieren - oder?
 
Da wäre ich vorsichtig,

1. wenn Du mehr als einen Block an Temperaturen überträgst, weiss ja Sinaut nicht welche Daten das sind ! und wenn da z.B. immer die Temperaturnummer mit übertragen wird, könnte die schon nach einem SPS Zyklus überschrieben werden (eher mehrere).
2. Beim umschaufeln (ist ja nur ein Pointer basteln) hast du den Vorteil, das die die Daten beobachten und kontrollieren kanst.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
jabba schrieb:
Da wäre ich vorsichtig,

1. wenn Du mehr als einen Block an Temperaturen überträgst, weiss ja Sinaut nicht welche Daten das sind ! und wenn da z.B. immer die Temperaturnummer mit übertragen wird, könnte die schon nach einem SPS Zyklus überschrieben werden (eher mehrere).
2. Beim umschaufeln (ist ja nur ein Pointer basteln) hast du den Vorteil, das die die Daten beobachten und kontrollieren kanst.
Zum Vergrößern anklicken....
Oh, ich glaube dann habe ich was nicht richtig verstanden...

Ich dachte bis jetzt daß (als Beispiel jetzt) wenn 8 Temperaturen vom Sender bereitgehalten werden ich diese dann in einem Zug empfangen kann da die Länge der Daten länger als nur ein Messwert sein kann - diese also der reihe nach im DB liegen. Beim nächsten Empfang werden dann die bisherigen Werte einfach überschrieben. Weiter ging ich davon aus daß ich dem DB lediglich eine Struktur verpassen muss um die einzelwerte auslesen zu können (also DBW0;DBW2;DBW4...) Die Anzahl und die Reihenfolge der Messwerte ändert sich doch nicht... Also hätte ich SINAUT (welches pro Telegramm 4 Werte überträgt) das so mitgeteilt:

Telegramm1 : W1=DBxy.DBW0 W2=DBxy.DBW2 ...

Liege ich da jetzt auf dem Holzweg?
 
Alle daten hab ich auch nicht mehr parat, ist schon ein paar Jahre her , wo ich die letzte mal 3964R gemacht hab, geht ja heut alles übern BUS.

Die Blöcke sind glaub ich 64byte, da sind Status und Nutzdaten drin, wenn die Daten mehr sind als möglich kommen halt mehrer Blöcke an.
Deshalb kann es sein, das es bei deinem Fall ausreicht.
 
jabba schrieb:
Alle daten hab ich auch nicht mehr parat, ist schon ein paar Jahre her , wo ich die letzte mal 3964R gemacht hab, geht ja heut alles übern BUS.

Die Blöcke sind glaub ich 64byte, da sind Status und Nutzdaten drin, wenn die Daten mehr sind als möglich kommen halt mehrer Blöcke an.
Deshalb kann es sein, das es bei deinem Fall ausreicht.
Zum Vergrößern anklicken....
Ok, das krieg ich raus (schätze es sind nicht mehr als 32Byte Nutzdaten) -> wenn dem so ist sollte aber mein Gedanke prinzipiell funktionieren ?

P.S.: SINAUT Task läuft im OB1; P_RCV im OB 35 (250ms) -> ok?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo rs-plc-aa,

hab auf die schnelle nix gefunden wie gross der Nutzdatenbereich ist.
Aber wo liegt das Problem die Daten umzuschaufeln sind ja nur ca 10-15Zeilen AWL.

Also unter der Vorgabe, das die Nutzdaten in einen Block passen
und die Daten in längeren Abständen gesendet werden, als die Bearbeitung dauert, dann sollte es gehen.
Aber warum den Baustein nicht im OB1 aufrufen .
Pro Zyklus werden vom Rückwandbus ich glaube nur 16Byte (bin mir aber nicht mehr sicher) übertragen, bei 60 Byte wären das 4 Zyklen also 1s.
 
@jabba: Danke für die Geduld...

Hm, da verstehe ich jetzt was nicht so ganz -> wofür soll das Umschaufeln gut sein ? Wenn RCV_Enable = TRUE ist dann wird ja (wenn ich richtig verstanden habe) sobald ein Empfang fertig ist der nächste gestartet.? Dabei werden die bisherigen Werte mit den neuen übeschrieben.? Paralell dazu schaut SINAUT in den DB ob sich Werte geändert haben - wenn ja (>Hysterese) dann neues Telegramm mit den aktuellen Werten - wenn nein (<Hysterese) dann mach nix.

Das einzige was ich mir vorstellen kann was da passieren könnte wäre folgendes: SINAUT erkennt, im OB1 gestarteter weise, daß es ein Telegramm senden soll -> während dessen unterbricht der OB35 den OB1 und fängt an neue Werte in den DB zu schreiben -> bei fortsetzung des OB1 wären die Daten dann inkonsistent -->> meinst du das ?

Würde das aber nicht auch passieren wenn "umgeschaufelt" wird ?

Was würde sich ändern wenn beide im OB1 laufen -> wenn es so ist daß die Empfangsdaten mehrere Zyklen benötigen dann wäre es natürlich besser zwischenzuspeichern, wobei das wichtigste ist daß kein "halber Wert" geschrieben wird (also z.B. 4 Stück-weise füllen wäre doch auch o.k. -oder?)

Dazu sollte man die genaue Vorgehensweise von P_RCV kennen, aber da kann man ja nicht reingucken..., und testen kann ich das momentan noch nicht da noch kein Sender aktiv ist. (wie gesagt ich will vorher so viel wie möglich zusammentragen damit die IB möglichst zügig von statten geht)
 
Hallo rs-plc-aa,

ich will dir das ja nicht aufschwatzen, aber wie wir in Köln dazu sagen:

"et hät noch immer jod jejange"

Was passiert wenn später mal mehr Daten kommen sollten,
da blickt dann keiner mehr durch.
Ich hatte ja angemerkt, wenn das vom Timing passt, ist es kein Problem.

Weisst Du denn schon mehr über die Gegenseite, wann bzw wie oft werden denn Daten gesendet. Bei Temperaturen reichen ja manchmal alle 10s aus, dann reichen auch die 250ms. Wenn du dann erst an Sinaut das Signal zum senden gibts , wenn NDR kommt geht es auch.

Ansonsten hast du ja die Funktionen soweit drin, das du das bei der Inbetriebnahme noch anpassen könntest.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
O.K., aber eines verstehe ich immer noch nicht so ganz...

Wenn die Nutzdaten größer sind als die maximal auf ein mal übertragbaren -> wie sortiere ich das dann auseinander ? Also woher weiss ich daß es Teil1,Teil2... ist ?

Stehe da irgendwie auf dem Schlauch...
 
Hallo,

das steht mit in den Daten, da ist der Header der angibt in welchen DB an welche Stelle.
Ich hab damal Schrauberdaten empfangen, am Schrauber konnte ich direkt sagen in welchen DB an welche Stelle die Daten sollen.
Da hab ich auch gedacht, "Holla dat is ja einfach",
bis dann nix kam, irgendwann hab ich es dann in der Doku gefunden,
das die Adresse mit übertragen wird, und dann war es ganz einfach.
Ich schaue mal am Wochenende nach , ob ich den alten Baustein noch habe, da ich die Maschine von 3964R auf ASCII umgestellt habe, da das viel schneller ging.
 

Similar threads

G
Step 7 Kommunikation über CP 340
Antworten
3
Aufrufe
2K
Garviel
G
maxi
CP 340 Nur Empfangen von frei definierten Signalen.
Antworten
1
Aufrufe
2K
seeba
S
A
Senden über CP koordinieren
Antworten
1
Aufrufe
3K
Dagobert
D
Zurück
Oben