CP 340 - Messwerte empfangen

[Question_mark]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das geht nicht wirklich, schmeiss den CP340 endlich weg..

Hallo,

ihr seid euch aber darüber im klaren, dass zum Protokollrahmen von RK512 auch Reaktionstelegramme und Quittierungen wie 'ETX', 'DLE' u.s.w. gehören ??
Wenn die nicht innerhalb der QVZ (Quittungsverzugszeit) beim Partner eintreffen, wird die Verbindung mit 'NAK' abgebaut und dann hat man den nächsten Versuch frei ...
Sieht ganz lustig aus, wenn man z.B. mit SIOCheck den Datenverkehr mitloggt
Der CP-Protokolltreiber legt tatsächlich auch empfangene Daten im Empfangsbereich ab, sogar wenn der Protokollrahmen mit Fehlern abgewickelt wurde. Manchmal empfängt man sogar Daten, aber durch die Framefehler können die auch schon mal > 5 Sekunden alt sein, eben durch das Einhalten der QVZ und der ZVZ (Zeichenverzugszeit) und Abbau und Wiederaufbau der Verbindung.
@rs-plc-aa : Vergess es, es geht nicht. Eine fehlende Quittierung im Protokollrahmen und Du hast Probleme. Sporadisch natürlich
Rechne einfach den Unterschied im Kaufpreis zwischen CP340 und CP341 aus und die Kosten, die bisher Durch Deine Forschungsarbeit entstanden sind (und Du bist ja noch nicht fertig damit).
Ich habe mal einen PC-Protokolltreiber RK 512 und auch für 3964R geschrieben. Und aus meiner Kenntnis über die Protokolle kann ich Dir nur raten : Versuche niemals, das RK512 Protokoll über 3964R in Deinem SPS-Programm nachzubilden, Du baust eine Krücke mit tausenden potentiellen Fehlermöglichkeiten.

Gruß

Question_mark

 

[rs-plc-aa]

@QM: Danke für deine aufmunternden Worte...

Tu mir bitte einen Gefallen: Erlöse mich und sag was ich jetzt machen soll.

Ich kann bei der ganzen Sache nur eins nicht verstehen. Warum zum Teufel steht das nirgens???

Du schreibst hier Sachen von denen ich immer davon ausging daß dies "automatisch" geschieht, wie z.B. die Quittierung etc.

Ich finde es problematisch daß zu so einer Baugruppe keine Lösung in der Lib beigelegt wird die auch zum Ziel führt - was soll das?

Dieses Thema ist sowieso nicht meins, und vielleicht habe ich mich zu anfang auch nicht genug damit auseinandergesetzt, wahrscheinlich aber deswegen weil diese Aufgabe mit der Funktion meiner SPS nichts zu tun hat sondern ich diese Daten (=Fremddaten) rein als durchlaufenden Posten behandeln muss weil meine SPS die Anbindung zum endgültigen Empfänger bereits hat.

Mir ist es mittlerweile auch egal ob ich nun eine CP340 oder eine 341 dafür nehme - der Grund wurde ja schon öfter genannt und liegt auch auf der Hand. Ich habe es nur nicht recht glauben wollen weil eben genau bei diesem Kunden bereits so eine Verbindung existiert - von einer S7-300 zur einer B&R gleichen Typs mit einer CP340!.

Ich habe gestern nacht noch mal im Handbuch der CP341 geschaut und so wie ich das verstanden habe ist das dort aber gleich -> sprich ich muss das auch wieder mit zweierlei FBs machen (senden/empfangen - obwohl ich doch "nur" aktiv empfangen will). Mein Gefühl sagt mir jetzt jedenfalls daß das auch noch heiter werden kann, bzw. es keinen großen Unterschied machen wird - oder?

Die Länge ist ja genau so auf 128byte begrenzt daher vermute ich jetzt spontan dass es auch wieder in die Hose geht.

Was ich jetzt brauche ist eine klare Antwort auf folgende Frage:

"Wie programmiere ich einen Fetchauftrag für 300 zusammenhängende Bytes die ich als Aktiver Parnter aus einem Passiven (er macht absolut NULL) Parnter holen soll und bei mir in einen DB zur weitergabe reinkriege?"

 

[Larry Laffer]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo RS,
tue mir doch bitte einmal den Gefallen und schreibe mal dén Inhalt deiner Anforderung an B&R ... (dezimal oder hex - Zeichen für Zeichen).
Nicht das ich dir irgendetwas versprechen könnte, aber wer weiss ...
QM hat mich da auf eine Idee gebracht ...

Gruß
LL

 

[argv_user]

Was ich jetzt brauche ist eine klare Antwort auf folgende Frage:

"Wie programmiere ich einen Fetchauftrag für 300 zusammenhängende Bytes die ich als Aktiver Parnter aus einem Passiven (er macht absolut NULL) Parnter holen soll und bei mir in einen DB zur weitergabe reinkriege?"

Du baust in einem Array der Länge 10 das Befehlstelegramm zusammen,
nimm als Länge 50 Worte = 100 Bytes, Startwort 0.
und sendest es an den Partner.
Dann wartest Du auf eine Antwort.
Der Partner antwortet mit einem Reaktionstelegramm: Davon sind die
ersten 4 Bytes der Kopf mit Fehlermeldung im 4. Byte (0 bedeutet kein Fehler).
Dahinter stehen dann die Daten. Die kopierst Du an den Anfang eines Array
von 300 Byte Länge.
Jetzt hast Du die ersten 100 Bytes.

Dann dasselbe mit Startwort 50 und nochmal mit 100, die empfangenen Daten schön hintereinanderhängen.


Um Sachen wie STX, DLE und sowas brauchst Du dich nicht kümmern,
das erledigt 3964R schon.


Tut mir leid, dass ich das nicht für S7 hier notieren kann, da kenn ich mich
nämlich überhaupt nicht aus.

 

[rs-plc-aa]

Hallo RS,
tue mir doch bitte einmal den Gefallen und schreibe mal dén Inhalt deiner Anforderung an B&R ... (dezimal oder hex - Zeichen für Zeichen).
Nicht das ich dir irgendetwas versprechen könnte, aber wer weiss ...
QM hat mich da auf eine Idee gebracht ...

Gruß
LL

geposteter DB-Code sieht kacke aus, ich versuch´s mal als Bilder:

 

[Larry Laffer]

Zuviel Werbung?
-> Hier kostenlos registrieren

... da war ich wohl etwas voreilig. War nichts schönes drin für mich. Ich hatte da nach dem Posting von QM etwas anderes erwartet.

Aber ...
Wir haben da (anscheinend) einen "Widerspruch" zwischen QM und AU. Nach Mark (QM) wäre es besser, auf die Antwort zur Frage zu warten - so habe ich das verstanden und so passt es in mein Bild. Willst du das nicht vielleicht doch mal testen ...?
Es deckt sich ja auch ein wenig mit dem, wie ich den FBxyz, den ich habe interpretiert habe ...

Gruß
LL

 

[rs-plc-aa]

@LL: Ja irgendwie kommt das auf keinen gemeinsamen Nenner...

Daher habe ich noch mal mit Siemens Kontakt aufgenommen -> da hat es danach zumindest mal funktioniert letzte Woche. Das Problem war ja dann nur noch daß der Nutzdatenbereich nicht in meiner gewünschten Länge ankam.

Ich habe nun genau dies noch mal geschildert und habe einen Tip bekommen wie es gehen könnte. Daraufhin habe ich das mal umgesetzt und werde heute nachmittag noch einen Versuch starten, sieht zumindest schlüssig aus.

Wenn es gelingt daß sich die 3 Teilbereiche im ziel nicht in die Quere kommen dann ist der Fall schon erledigt -> es geht also um die korrekte gegenseitige Verriegelung der Teilbereiche (was mir gestern einfach nicht gelingen wollte)

Denn: Einen einzelnen Bereich zu empfangen funktioniert ja einwandfrei - der Fehler war dann nur immer in der Koordination.

Und: Auf keinen Fall verschiedene IDBs verwenden!

Die (mögliche) Lösung sieht nun wie folgt aus:

Durch 3 Merker werden die Sequenzen verriegelt. Es wird gar nichts gemacht so lange eine Übertragung läuft. Ist eine Ü. fertig - entweder mit oder ohne Fehler - wird das Senden neu gestartet. Fehlt also in diesem Zyklus die positive Flanke für das Senden werden die Parameter gewechselt und nach einem Durchgang mit neg. Flanke wieder gesendet.

Dann ist also im nächsten Zyklus die Ü. wieder aktiv und der Wechsel blockiert bis der Empfang wieder fertig ist.

Recieve_Enable bleibt statisch auf 1. Send_Enable wird durch Recieve_Done/Error resetet und setzt sich dann einen "0-Zyklus" später (wo dann der Wechsel stattfindet) wieder selbst.

Klingt zumindest mal vernünftig...

 

[Larry Laffer]

Klingt zumindest mal vernünftig...

Für mich auch ...
Viel Erfolg - ich drück dir die Daumen - und schreib bitte, was dabei herausgekommen ist ...

Gruß
LL

 

[rs-plc-aa]

Zuviel Werbung?
-> Hier kostenlos registrieren

War ja total einfach...

So, also hier das Ergebnis:

Es läuft fantastisch!

Erstens mal ein dickes Lob an Siemens! - die können schon wenn sie wollen...

Genau so wie oben beschrieben hat es letztendlich auch funktioniert.

Die Messwerte habe ich abgeglichen - sie sitzen alle an der erwarteten Stelle, also keine Verschiebungen.

Ein wenig wundert es mich aber schon daß hier keiner konkret damit rauswollte (ich will jetzt niemand zu nahe treten) aber wenn ich mir das Ergebnis so ansehe war es wirklich halb so wild - man muss eben ein ganz bestimmtes Schema einhalten dann geht´s auch...

Danke noch mal für alle Antworten!

@Larry: ein "extra Danke" für´s Daumendrücken...

 

[Larry Laffer]

Hallo RS,
ich freue mich, wenn das "Daumendrücken" geholfen hat.
Was war denn jetzt konkret der "Key to Success" - welche Maßnahme hat geholfen ? Das habe ich nicht so richtig herauslesen können ...

Gruß
LL

 

[rs-plc-aa]

Hallo,

also noch mal zum Mitschreiben:

Die DBs die ich als Screenshot gepostet hatte sind unverändert -> sie waren also korrekt.

Jetzt zum Code.

Wie schon gesagt darf es pro physikalischer CP340 nur je (send/recieve) einen IDB geben da dort auch Infos drin stehen die für den Anwender irrelevant - wohl aber sehr wichtig für den Ablauf sind.

Je nach dem wie viele Einzelblöcke benötigt werden, müssen die DBs belegt sein, und jeweils ein Hilfsmerker für die Verriegelung angelegt sein.

Jetzt gehts los:

Als erstes frägt man ab ob das Senden aktiv ist - wenn ja -> Sprung direkt zum Send FB, wenn nein kommt später...

Der Send FB sendet so lange den Kopf bis der Empfang beendet ist (also gleichzeitig).

Der fertige Empfang setzt das Send_Enable Bit zurück (ob Empfang gut/schlecht - egal)

Dies steht ganz am Ende. Unmittelbar davor wird das Send_Enable abgefragt und bei 0 auf 1 gesetzt.

Dies bewirkt dann eben daß für einen Zyklus der Send FB mit einer 0 am Enable aufgerufen wird!

Genau in diesem "0-Zyklus" werden oberhalb dann die Parameter gewechselt, dann kommt ja wieder die Stelle wo Send_Enable abgefragt wird und wieder gesetzt wird. Somit ist einen Zyklus später der Wechsel wieder verriegelt und das Senden beginnt neu mit der vorher gebildeten Flanke + den neuen Sende-/Empfangsparametern.

Das liesse sich so jetzt um quasi beliebig viele Teile erweitern ohne das was falsch gemacht werden kann.

Ganz zu beginn (nach CPU start wo die Hilfsmerker alle 0 sind) wird der erste gesetzt -

UN Teil1
UN Teil2
UN Teil3
S   Teil1

Ab dann geht es reihum bis unendlich...

Ich habe überlegt ob ich den kompletten Code gleich posten soll oder nicht. Ich habe mich mal entschlossen es nicht zu tun da es m.e. viel wichtiger ist diese Grundlagen zu verstehen!
Wenn das später jemand so brauchen sollte werde ich selbstverständlich mit Rat und Tat beiseite stehen, versprochen - aber ich gehe einfach mal von mir selbst aus: Ich will nicht abschreiben, sondern es verstehen - dann ist es auch plötzlich einfach!

 

[argv_user]

Zuviel Werbung?
-> Hier kostenlos registrieren

Also hat es die ganze Zeit nur am korrekten Aufruf von
Senden und Empfangen gehapert?
Das kam m.E. nicht so rüber; freut mich aber trotzdem
dass es jetzt funktioniert.

Beste Grüße...

 

[Larry Laffer]

Hallo RS,
Danke dir für das Feedback. Ich habe mir die EMail-Benachrichtigung gleich mal abgespeichert. Ich denke, dass mir das noch irgendwann einmal nützlich sein wird.

Wie auch immer, schön das es nun geht.
Bis zum nächsten Mal.

Gruß
LL

 

[rs-plc-aa]

Also hat es die ganze Zeit nur am korrekten Aufruf von
Senden und Empfangen gehapert?
Das kam m.E. nicht so rüber; freut mich aber trotzdem
dass es jetzt funktioniert.

Beste Grüße...

Oh ja, im Endstadium schon... (nach dem das mit den DBs wasserdicht war)

Ich müsste jetzt noch mal zurückgehen um mich selbst zu zitieren aber jedenfalls hatte ich geschrieben daß es an der Koordination von P_SEND und P_RCV hapert.

Das vergesse ich auf jeden Fall nicht mehr, das sind so sachen die behält man unauslöschlich im Gedächtnis!