# CP 340 - Messwerte empfangen



## rs-plc-aa (21 Mai 2007)

EDIT am 11.01.2008 : Der Thread war eingefroren - hier sollte es hauptsächlich weitergehen: http://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" ?


----------



## borromeus (21 Mai 2007)

1. Der CP 340 kann S3964R
2. Blockung übernimmt der CP bzw. die Prozedur 3964R, wieso bist Du nicht immer auf Receive enable?


----------



## rs-plc-aa (22 Mai 2007)

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) ?


----------



## argv_user (22 Mai 2007)

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) ?



Für 3964R brauchst Du Sende- und Empfangsleitung; die Handshakeleitungen sind überflüssig.


----------



## rs-plc-aa (22 Mai 2007)

argv_user schrieb:


> Für 3964R brauchst Du Sende- und Empfangsleitung; die Handshakeleitungen sind überflüssig.


 
Also RxD; TxD; GND und Schirm beidseitig ?

Wie sieht´s mit meinen anderen Fragen noch aus ?


----------



## rs-plc-aa (23 Mai 2007)

*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 !


----------



## borromeus (23 Mai 2007)

rs-plc-aa schrieb:


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


 
Also bei mir klappt das so wenn ich Daten einlesen will.


----------



## rs-plc-aa (23 Mai 2007)

Danke,

Und -> RxD; TxD; GND und Schirm beidseitig ?


----------



## jabba (23 Mai 2007)

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 !


----------



## rs-plc-aa (23 Mai 2007)

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.
> ...


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?


----------



## jabba (23 Mai 2007)

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.


----------



## rs-plc-aa (23 Mai 2007)

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.


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?


----------



## jabba (23 Mai 2007)

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.


----------



## rs-plc-aa (23 Mai 2007)

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.


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?


----------



## jabba (23 Mai 2007)

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.


----------



## rs-plc-aa (24 Mai 2007)

@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)


----------



## jabba (24 Mai 2007)

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.


----------



## rs-plc-aa (25 Mai 2007)

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...


----------



## jabba (25 Mai 2007)

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.


----------



## rs-plc-aa (25 Mai 2007)

...wäre super


----------



## rs-plc-aa (11 Januar 2008)

*Fortsetzung...*



rs-plc-aa schrieb:


> ...wäre super


 
na ja, da ist wohl nix mehr draus geworden :???: 

Ich bin aber auch kein Stück besser weil ich mich auch nicht mehr weiter damit beschäftigen durfte (Projekt war "eingefroren")  

So, nun soll ein neuer Anlauf genommen werden.

Ein paar Details haben sich seither geändert - das Problem ist aber im Prinzip noch das selbe:

Ich habe den CP340 RS232 gegen einen 20mA TTY tauschen müssen - sollte aber Softwaretechnisch egal sein (wollte ich nur gleich erwähnen falls es doch nicht egal ist.)

Der Aufbau steht jetzt also und ich kann immer noch nichts empfangen - dafür aber testen weil Kabel etc. nun verlegt und Gegenstelle bereit!


Noch mal kurz die Aufgabe erklärt:

"Die" verlangen von mir daß ich mit meiner S7 mittels dem CP340 auf eine B&R (älteren Baujahres, schätze mal so ca. 1993) zugreife und Daten abhole. Die B&R-Seite meint das müsste gehen ohne daß die B&R was dabei tut (ausser die Schnittstelle bereitzustellen, natürlich).

Nach dem was ich so im Handbuch gelesen habe scheint das aber unwahrscheinlich da ich ja nicht direkt sagen kann: "Ich möchte bei dir (B&R) aus DBxy (oder da heißt es ja anscheinend "Counter") dies und jenes Wort haben"

Das einzige wo ich das schon mal gelesen habe war bei dem SFB64 "FetchRK" - der aber in der CPU 318 nicht drin ist und wohl auch nicht 3964R - kompatibel ist...

Mein Ziel ist nach wie vor die Daten in einen DB einzulesen in dem ein Array[0..150] of Int deklariert ist (weil der maximale Bereich von Counter 1500-1798 (= 300Byte, wenn 1798 u.99 mitgezählt werden) erfasst werden können soll). Wenn die Daten dort mal erfasst sind möchte ich dann nur auf einzelne Elemente des Arrays zugreifen und diese dann weitersenden. Es sind natürlich keine 300Byte Nutzdaten aber ich muss wohl mit den Lücken dazwischen leben und den ganzen Bereich einlesen 

Meine Frage ist jetzt also hauptsächlich die wie ich die Daten in den DB kriege.

Der passende FB zur CP340 wäre der FB2 "P_RCV" - an dem kann ich aber nicht angeben wo die Daten beim Partner liegen - nur wo bei mir das Ziel ist. Wie also teile ich der Gegenseite mit welche Daten ich will??? Da ein Empfang nur 32Byte lang sein kann muss ich das sowieso in mehreren Schritten machen - das ist auch auf meiner seite kein Problem, ich muss ja nur den Offset weiterschieben - aber wo schiebe ich den Offset am Partner weiter?

Ich würde mich sehr erleichtert fühlen wenn sich noch mal Jemand des Problems annehmen könnte...


----------



## argv_user (11 Januar 2008)

Wenn B&R RK512 versteht, dann brauchst Du den CP 341;
oder Du bastelst Dir das RK512-Geraffel selber.


----------



## rs-plc-aa (11 Januar 2008)

argv_user schrieb:


> Wenn B&R RK512 versteht, dann brauchst Du den CP 341;
> oder Du bastelst Dir das RK512-Geraffel selber.


 
Das bringt mir auch nichts - es soll/muss per 3964R gemacht werden, ich weiss ja "nur" nicht wie ich beim Partner an die richtigen Daten komme (Adresse bzw. Counter)...

Trotzdem danke.


----------



## rs-plc-aa (11 Januar 2008)

hmm, könnte es sein daß ich zuerst ein Telegramm senden muss in dem steht welche Daten ich beim (nächsten) Empfang haben will ?

Hat wirklich keiner eine Idee?


----------



## rs-plc-aa (13 Januar 2008)

Ich weiss, das ist jetzt kein "Allerweltsthema" - aber es haben seit meinem letzten Post doch einige Leute hineingeschaut...

Ich finde es ein weing lasch daß es hierüber so gut wie nichts nachzulesen gibt, würde ich ja gerne.

Ich bin mir mittlerweile ziemlich sicher daß es nur folgendermaßen funktionieren kann:

- Ich sende zuerst mittels P_SEND ein Telegramm in dem ich der Gegenstelle mitteile WAS ich (anschließend) empfangen will -> Art, Ort und Länge der Daten.

- Dann starte ich den P_RCV und gebe dort das Ziel auf meiner Seite an


Mir fehlen jetzt im Prinzip die Infos wie das angegeben werden muss was ich als "Wunsch" senden muss - also wie Art, Ort und Länge deklariert sein muss daß es funktioniert.

Im normalen Handbuch der CP340 habe ich das jedenfalls nicht gefunden und im Internet allgemein und im Form leider auch nicht.


Es kann doch wohl nicht sein daß man dies nur durch probieren rausfinden kann - oder?

Der Rest - also wenn die Daten dann mal da sind - sollte wohl nicht das Problem sein, denke ich...


Also *BitteBitteBitte* wenn jemand irgendwelche Infos darüber hat wäre mir echt geholfen.


----------



## Larry Laffer (13 Januar 2008)

Hallo RS,
mit dem, was ich jetzt schreibe lege ich mich ziemlich weit aus dem Fenster. Ich bin mir dessen auch nicht wirklich sicher, aber vielleicht ist ja was brauchbares dabei, ansonsten ignorier meinen Beitrag einfach.

Nach meiner Meinung gibt es zwischen dem 3964R-Protokoll und dem AS511-Protokoll eine funktionelle Verwandtschaft. Ich hatte leider mit dem ersten nicht viel zu tun, mit dem zweiten umso mehr. Ich erinnere mich allerdings, dass ich mir die Funktionalität des AS511 aus dem 3964R hergeleitet habe.

Wie auch immer. Du hättest dann mit deiner Vermutung bezüglich des Anforderns Recht. Du musst in dem Protokoll der Gegenseite zunächst mitteilen was und wieviel du Lesen möchtest und erhälst im Gegenzug (im gleichen Telegramm) die gewünschten Daten zurück. Hier ist es natürlich wichtig, wie auf den Gegenseite welche Daten angefragt werden. Das müsste in deinem Fall von B&R kommen und von denen angegeben werden. Das Protokoll selbst ist in seiner Struktur zwar genormt, die Adressierung der Datenbereiche des Partners m.E. nicht.
In diesem Zusammenhang noch einmal der Hinweis, dass ich mittels PC mit einer S5-Steuerung kommuniziert habe. Trotzdem müßte das Ganze vergleichbar sein ...

Viel ist es nicht, aber vielleicht kommst du damit einen Schritt weiter ...

Gruß
LL


----------



## rs-plc-aa (13 Januar 2008)

Danke schon mal.

Im gegensatz zur RK512 und vermutlich auch dem AS511 Verfahren - wo eben in einem Aufruf (an dem FB für RK512 wird z.B. direkt angegeben wie man die Gegenstelle ansprechen will) muss das im Fall 3964R wohl in zwei Schritten erfolgen...

Die Infos WAS der Gegenstelle gesendet werden muss - da hast du recht - kriege ich wohl nur von B&R bzw. meiner Gegenstelle. Ok.

Ich hatte gehofft hier jemand zu finden der eventuell genau das schon gemacht hat weil:

- Ich bei B&R im web schon mal nach infos gesucht habe und nach kurzer Zeit aufgab -> Saftladen!

- Sich die Gegenstelle verhält als ginge sie das alles nichts an...


Also im Prinzip ist es so daß ich gerne hier so weit wie möglich kommen will um dann ganz gezielt die restlichen Infos einzuholen...

Jeder Beitrag ist also willkommen - außerdem ist jeder Beitrag nützlich auch wenn er nicht genau den Punkt trifft (man weiß nie wo/wann man es nicht doch wieder braucht)


----------



## Larry Laffer (13 Januar 2008)

Dieser Beitrag ist jetzt eigentlich rethorisch, ich machs aber trotzdem ...

Du hast aus meiner Sicht nur 2 Möglichkeiten :

1.  B&R auf die Füsse treten, dass sie dir die benötigten Info's zum Handling der Schnittstelle zur Verfügung stellen. Die Unterlagen dazu muss es bei denen noch geben.

2.  Plan B - du ersetzt das "Geraffel" von 1993 (ist ja vielleicht auch nicht mehr unbedingt Up-to-Date durch etwas, was zu deiner Steuerung passt und deinen Anforderungen entspricht (wäre möglicherweise mein Weg). Hier ist natürlich das Problem, dass das auch von irgendwem bezahlt werden wollen muss. Auf der anderen Seite - was ist, wenn mal was kaputt geht - oder noch schlimmer, wenn alles gar nicht so geht wie gewünscht ...

Gruß
LL


----------



## rs-plc-aa (13 Januar 2008)

Hallo Larry,

werde am Montag Plan A anwenden...

Plan B wäre mir auch lieber aber da klemmt´s an dem Argument der Bezahlung. Ich kenne mich halt mit B&R gar nicht aus aber ich fragte mal nach ob es für diese nicht auch eine DP-Slave Schnittstelle gegeben hätte -> das wäre Hardwaremäßig sogar billiger gewesen da S7-seitig die CP340 entfallen wäre und B&R-seitig eben eine andere (sie hätte ja um den CP340 Preis teurer sein dürfen) Schnittstelle zum Einsatz gekommen wäre die in dem Zusammenhang sicherlich wesentlich einfacher zu handeln wäre. Aber das gibt es anscheinend nicht.

Unsere Steuerung hat zumindest mal ne S5 überflüssig gemacht die auch noch in der Anlage ist - bzw. macht sie erst richtig überflüssig wenn die Kopplung zur B&R vollends läuft.


----------



## jabba (13 Januar 2008)

Hast Du die folgenden Sachen bei Siemens schon gefunden ?

http://support.automation.siemens.c...extranet=standard&viewreg=WW&load=treecontent


----------



## rs-plc-aa (13 Januar 2008)

jabba schrieb:


> Hast Du die folgenden Sachen bei Siemens schon gefunden ?
> 
> http://support.automation.siemens.c...extranet=standard&viewreg=WW&load=treecontent


 
Nun, im Prinzip ist das dort gezeigte Beispiel genau so wenig vollständig wie das Beispiel das bei der Parametriersoftware mitinstalliert wird.

Hier wird einfach "Irgend WAS" gesendet und "Irgend WAS" empfangen - wobei speziell die Quelle des Empfangenen unklar bzw. undefiniert bleibt.

Genau das ist ja mein Problem - ich möchte ganz bestimmte Daten von der Gegenstelle haben und weiss nicht wo ich das angeben soll daß auch das richtige ankommt.

Wenn ich lediglich den P_RCV aufrufe weiss ich ja immer noch nicht was da u.U. ankommt.

Daher gehe ich jetzt einfach mal davon aus - da im P_RCV dergleichen ja nicht angegeben werden kann - daß ich zuerst etwas senden muss damit die Gegenseite weiss was genau ich empfangen möchte.


----------



## jabba (13 Januar 2008)

Hallo rs-plc-aa,

ich denke mal Du bist schon auf dem richtigen Weg, aber ohne zu Wissen, was man an die B&R schicken muss, wird es nicht gehen.

Bei mir waren die Zieladressen damals ja im Schrauber hinterlegt, und der hat mir die Zieladressen und die Daten nach einem Schraubauftrag gesendet. 
In deinem Fall müßte die Anfoderung mit Datenbereich , Anfangsadresse und Länge im Anforderungsauftrag stehen.


----------



## rs-plc-aa (13 Januar 2008)

genau dieses, und da ich das zu anfangs gar nicht wusste bin ich ja erst mal nur so weit gekommen bis es keine andere Erklärung mehr gab.

Werde das Montag mal versuchen in Erfahrung zu bringen.

Stay tuned...


----------



## rs-plc-aa (20 Januar 2008)

So, also als kleine Rückmeldung kann ich schon mal sagen dass die Sache nun läuft. (noch nicht alles aber Daten kommen an und halbweg richtig auch)

Wie sich nach einem Telefonat mit Siemens bestätigt hat ist diese Vorgensweise etwa so zu betiteln:

"Wir gehen eben RK512 mit 3964R zu fuss"

Wenn ich das vorher so gewusst hätte dann wäre die CP341 auf der Bestellung gestanden - aber nur weil beim Kunden schon mal einer so ein "Meisterwerk" erbracht hat wurde mir blindlinks die CP340 vorgeschrieben.

Wie auch immer, jetzt wo der Aha-Effekt da war ist es eigentlich fast schon wieder simpel:

Man nehme das Handbuch der CP341 und schaue dort wie der Telegrammkopf aufgebaut ist. Diesen setzt man nun 1:1 um und sendet ihn während des Empfangs mit dem Sendebaustein...

Das Bit NDR (Daten vollständig empfangen) triggert dabei das Freigabebit des Sendebausteins.


Wo ich jetzt noch dran bin:

Die maximale Länge der Daten pro Telegramm ist doch deutlich kürzer als bei RK512 - wohl wegen des fehlenden CRC.

Jedoch habe ich schon festgestellt daß mehr geht als von Siemens angegeben (128byte) - nur wieviel mehr muss ich noch genau testen.

Ich würde mich ja gerne darum drücken es in mehrere Teile zu splitten - dann wird´s wieder umständlich zu programmieren, aber schaun mer mal.

Wenn alles fix fertig ist schreibe ich noch mal -> ausser es gibt dann nichts mehr hinzuzufügen.


----------



## argv_user (20 Januar 2008)

Als Hinweis:
die RK512 überträgt immer nur max. 128 Nutzdatenbytes pro
Telegramm; bei mehr sind Folgetelegramme erforderlich.

Das heißt der Datenpuffer muss 138 Bytes ( Senderichtung) 
bzw 132 Bytes  ( Empfangsrichtung) lang sein . Ist der größer,
dann schadet das nichts, bringt aber auch nichts...

Falls im CP341 Handbuch dazu nichts steht:
Versuch's mal im Handbuch COM525 für CP525, da steht das drin.

(Warum nimmst Du keinen CP341, ist Deine Arbeitszeit umsonst
oder sparen wieder welche auf Teufel komm raus?
Kann man den CP nicht umtauschen?)


----------



## rs-plc-aa (20 Januar 2008)

Jetzt habe ich noch mal im Handbuch der CP340 und der CP341 wegen der max. Telegrammlänge geschaut. Da steht (hinten bei den technischen Daten) überall 1024byte - sowohl bei 3964R (340+341) als auch bei RK512 (341)

Was stimmt denn nu


----------



## Question_mark (20 Januar 2008)

*Mal was zum RK512*

Hallo,



			
				rs-plc-aa schrieb:
			
		

> max. Telegrammlänge geschaut. Da steht (hinten bei den technischen Daten) überall 1024byte -



Wir müssen wahrscheinlich unterscheiden zwischen der max. Telegrammlänge eines Einzeltelegramms und der max. Telegrammlänge, die mit einem Aufruf des entsprechenden SFB oder SFC in der S7 gehandelt werden kann. Man wird also durchaus bei einem RK512 Send-Auftrag an den SFB oder SFC einen Datenbereich von 1024 Bytes übergeben können, der im CP implementierte RK512 Protokolltreiber teilt dies das eben für den Anwender unsichtbar in eine entsprechende Anzahl Folgetelegramme auf.  
Das war schon beim S5-CP525 so und wird sich bis heute auch nicht geändert haben. Beim S5-CP525-1 (unter PCPM) war allerdings der max. größte Datenblock 128 Byte und Folgetelegramme waren nicht möglich. Mit Einführung des CP525-2 (unter MS-DOS) war dann der größtmögliche Datenblock 512 Byte, automatisch aufgeteilt vom Protokolltreiber in bis zu max. 4 Einzeltelegrammen zu je 128 Byte (incl. Folgetelegrammen).
Wobei sich auch mit Einführung der S5-946/947 und 948 der RK512-Protokollheader geändert hat. Wie soll man sonst bei "Ausgabe absolute Adresse" damit umgehen, dass die Adressen nun nicht mehr 16-Bit breit, sondern 20-Bit breit sind ?
Die S7 kann mit dem CP341 offensichtlich noch mehr Folgetelegramme.
Wer jetzt versucht, mit einem CP340 mit dem blanken 3964R das RK512 in der S7 nachzubilden, fällt unweigerlich auf die Schnauze. Wer die paar Euronen Aufpreis für den CP341 einspart, hat da mit Zitronen gehandelt. Der Protokollrahmen stimmt einfach nicht mehr und das Senden und Empfangen von Daten wird eher zum Glücksspiel. Schmeiss dem Pfennigfuchser den CP340 auf seinen Schreibtisch und mach eine Excel-Tabelle, wieviel Geld und Zeit die Fehlentscheidung bisher gekostet hat. Vielleicht noch eine Folie für den Overhead-Projektor erstellen, was anderes begreifen die BWL-Köpfe sowieso nicht...
Übrigens, es gibt ausser dem 3964R noch das 3964 (also ohne R), ist im Prinzip das gleiche, nur ohne Prüfsumme BCC.

Gruß

Question_mark


----------



## Question_mark (20 Januar 2008)

*So geht das nicht ...*

Hallo,



			
				rs-plc-aa schrieb:
			
		

> Die maximale Länge der Daten pro Telegramm ist doch deutlich kürzer als bei RK512 - wohl wegen des fehlenden CRC.



CRC, damit meinst Du wohl die Prüfsumme BCC des RK512 Protokolls. Es gibt kein RK512 ohne BCC ..., im RK512 ist grundsätzlich die BCC Prüfsumme enthalten. Wenn Du z.B. mit SIOCheck den Datentransfer mitloggst, werden wahrscheinlich vor lauter BREAK und NAK Deine Augen tränen. Manchmal kommen Daten an, manchmal nur Datenfragmente und wenn Du Pech hast, gar keine. Der Protokolltreiber ist voll damit beschäftigt, die Verbindung aufzubauen, Daten zu transferieren und wegen Protokollfehlern wieder abzubauen....

Gruß

Question_mark


----------



## Question_mark (21 Januar 2008)

*Da hat Dich jemand schlecht beraten*

Hallo,



			
				plc-rs-aa schrieb:
			
		

> Wie sich nach einem Telefonat mit Siemens bestätigt hat ist diese Vorgensweise etwa so zu betiteln:
> 
> "Wir gehen eben RK512 mit 3964R zu fuss"



Dein Gesprächspartner am anderen Ende der Leitung bräuchte da wohl noch einige Fortbildungsmaßnahmen. Ich habe mal einen Protokolltreiber für RK512 geschrieben (für Verbindungen zwischen S5/S7 und PC). Wer das RK512 über 3964 per SPS-Programm abbilden will (besonders über Folgetelegramme), hat einfach einen an der Klatsche. 
Ist nicht gegen Dich persönlich, sondern eher gegenüber Deinem Ansprechpartner am anderen Ende der Leitung. Und dem Trottel, der den CP340 bestellt hat.  

Gruß

Question_mark


----------



## Question_mark (21 Januar 2008)

*Einspruch ...*

Hallo,



			
				jabba schrieb:
			
		

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



Nein, stimmt nicht. Der Empfang kann immer enabled bleiben, der Protokolltreiber regelt das schon selber über die Priorität.
Den Sende/Empfangskonflikt regelt der Protokolltreiber automatisch. Wer natürlich so bescheuert ist, im 10ms Raster (vielleicht noch bei eingestellten 300Bd) Daten an den Partner zu senden, darf sich natürlich über Fehlermeldungen vom Protokolltreiber nicht wundern..


Gruß

Question_mark


----------



## rs-plc-aa (21 Januar 2008)

Oh mann!

Da hab ich mich jetzt wohl zu früh gefreut oder wie?

Mein (haupt-) Problem hast du aber ja schon erkannt:

Der Kunde hat bereits jahrelang eine solche Kopplung laufen die eben mit dem CP340 so gemacht wurde und ich soll jetzt kommen und sagen daß das Kacke ist. Der wird natürlich sagen: "Da funktioniert es doch auch, warum also bei Ihnen nicht"?

Es wäre, wie ich das so sehe, generell möglich mit Folgetelegrammen zu operieren - bzw. durch entsprechende Verriegelungen der S/R FB´s mit jeweils anderen Parametern zu Arbeiten. Diese Arbeit wollte ich mir natürlich zunächst ersparen.

Momentaner Stand:

Ein DB welcher die 10byte mit den Sendedaten beinhaltet wird an den P_SEND übergeben. Dessen Enable-Bit wird vom Done-Bit des P_RCV zurückgesetzt und im nächsten Zyklus wieder automatisch gesetzt. Durch diesen Flankenwechsel geht das Spiel von neuem los. Das Enable-Bit des P_RCV bleibt statisch True.
Die so empfangenen Daten werden in einen separaten DB mit 4byte "Kopf" und einem ausreichend großen Array für die Nutzdaten reingeschrieben.
Die bislang empfangenen Nutzdaten sahen bis jetzt zumindest sehr vielversprechend aus - daher glaubte ich quasi schon am Ziel zu sein.
Das einzige was jetzt noch fehlt ist der endgültige Abgleich zwischen Quelle und Ziel um wirklich auf nummer sicher gehen zu können. Ein paar "markante Einzelwerte" konnte ich bereits als "richtig empfangen" zuordnen, daher war ich eben noch guter Hoffnung.

Falls das jetzt je so geht lasse ich das auch so - eben weil ich jetzt keinen Ärger will und es wohl die "letzte Kopplung dieser Art" sein wird (bei diesem Kunden zumindest...). Wenn ich das wo anders mal brauchen sollte kläre ich das natürlich ab daß ein CP341 zum Einsatz kommen MUSS.

Wenn nicht muss ich irgendwie belegen können daß die alte Kopplung auch schon fehlerhaft ist, aber die kam ja nicht von mir.

Schwierig, schwierig...


----------



## argv_user (21 Januar 2008)

Stell doch mal Dein 10-Byte-Befehlstelegramm hier rein,
und gib an, auf welche Daten-Nummern in B&R Du zugreifen
musst. Vielleicht hat sich dann alles ganz schnell erledigt.


----------



## rs-plc-aa (21 Januar 2008)

argv_user schrieb:


> Stell doch mal Dein 10-Byte-Befehlstelegramm hier rein,
> und gib an, auf welche Daten-Nummern in B&R Du zugreifen
> musst. Vielleicht hat sich dann alles ganz schnell erledigt.


 
Das funktioniert ja schon...

Es geht jetzt ja nur noch um die max. Länge die mit einem Mal übertragen werden kann.


----------



## argv_user (21 Januar 2008)

Lt. RK512 sind das max. 128Bytes, habe ich ja weiter oben
schon geschrieben. Allerdings gibt es in dem 10-Byte-Befehlstelegramm
auch einen Offset; der ist in Deinem Fall wohl 0.
Diesen Wert kannst Du erhöhen; musst aber beachten, dass er
max. 255 sein kann.
Und da lauert die nächste Falle: es hängt vom Datentyp auf den
zugegriffen wird ab, ob der Offset als Byte oder als Word gerechnet wird.
Gilt auch für die Anzahl.
(Nur deshalb wollte ich Deine Befehlssequenz sehen).

Nachtrag: die 128 Bytes verstehen sich ohne Folgetelegramme;
aber die willst Du ja gerade vermeinden!


----------



## rs-plc-aa (21 Januar 2008)

Als Anmerkung beim Telegrammkopf steht:



> Die RK512-Adressierung beschreibt Datenquelle und -ziel mit Wortgrenzen. Die Umrechnung auf Byteadressen in SIMATIC S7 erfolgt automatisch.


 
D.h. ich gebe im Byte5 die DB Nr. an und im Byte6 die Wort(DW)-Nr. an.
Hier habe ich momentan 0, richtig...

Ich habe den Telegrammkopf Byte für Byte im DB deklariert, ausser die letzten 2 - da habe ich ein Wort mit FFFF genommen (kein Koppelmerker).

Mein Aufbau:

01: B#16#0
02: B#16#0
03: B#16#45h // Fetch-Auftrag
04: B#16#44h // Quelltyp = DB
05: B#16#D //QuellDB = DB13
06: B#16#0 //QuellDBW=0
07: B#16#0 // Länge in Byte = 0 weil in 08 in Wort angegeben!
08: B#16#96h // Länge in Worten = 150 (geht aber nicht)
09: W#16#FFFF // Kein Koppelmerker

Ich werde es nun wohl so machen müssen:

Um die Länge nicht zu überschreiten brauche ich einen koordinierten Sende-/Empfangsablauf -> Ich hänge also für jeden Teil (max64Wort) einen Telegrammkopf hinten an den Kopf-DB. Je nach dem welcher Teil gerade dran ist schicke ich einen der "Köpfe".
In meinem Ziel-DB richte ich analog dazu weitere Empfangsfächer ein, da ja jedes mal ein Header mit übertragen wird - also einen neuen Header plus ein neues (Teil-)Array.

Jetzt muss ich nur noch dafür sorgen daß bei der Koordination nichts schief geht -> Die P_Send/P_RCV Bausteine dürfen ja nur einmal da sein ebenfalls der IDB (bezogen pro CP). Deshalb muss ich sie "einfach" abwechselnd mit anderen Telegrammköpfen und den passenden Zielbereichen aufrufen.

Hierzu sind natürlich Anregungen erwünscht, bin aber quasi schon dran...

Edit: Noch mal wegen der Byte/Wort Deklaration -> Oder ist das so gemeint daß wenn im Kopf das Byte07 ODER 08 verwendet wird auch im Byte06 das auf Byte/Wort angepasst sein muss ?


----------



## argv_user (21 Januar 2008)

Aha, DB-Zugriff also!
Nun, der ist immer wortweise; d.h. auch die Länge ist in Worten.
Mehr als 64 Worte benötigen die Folgetelegramme, aber bis 64
Worte geht es ohne!

Byte 7 ist das Highbyte, 8 das Lowbyte der Länge, gerechnet in
Worten.

Aber in Byte 6 gibst Du den Bereichsanfang ein.
Ebenfalls in Worten. Auf Byte 298 & Byte 299 des DB greifst Du direkt
zu, indem Du Byte 6 auf 149 setzt und als Länge 1 angibst.

Ich hoffe das hilft Dir weiter.


----------



## rs-plc-aa (21 Januar 2008)

Ja, tut es...

Nur noch mal langsam zum Mitschreiben:

Ich will aus ein und dem selben DB ab DBW0 insgesamt 300 byte holen.

Ich würde es dann in 3*100 aufteilen wollen.

Jetzt immer auf die Bytenummer des Telegrammkopfs bezogen:

Teil 1 ist also:
06: B#16#0
07: B#16#0
08: B#16#32h // 50 Worte (ab DW0)

Teil 2:
06: B#16#32h // ab Wort 50 (= Byte100)
07: B#16#0
08: B#16#32h // 50 Worte (ab DW50)

Teil 3:
06: B#16#64h // ab Wort 100 (= Byte200)
07: B#16#0
08: B#16#32h // 50 Worte (ab DW100)

Ich dachte bisher dass die Bytes 07 und 08 wahlweise anzugeben sind - also entweder in Bytes oder in Worten - oder ist das falsch?


----------



## argv_user (21 Januar 2008)

rs-plc-aa schrieb:


> Ja, tut es...
> 
> Nur noch mal langsam zum Mitschreiben:
> 
> ...




Das mit dem wahlweise ist falsch, denn Byte 7 und 8 bilden einen Wortwert.
Die drei Teile 1,2 und 3 sollten so richtig sein.


----------



## rs-plc-aa (21 Januar 2008)

Danke.

Ich bin etwas irritiert von der Formulierung im Handbuch. Da steht:


> 07: Länge High-Byte Länge der zu übertragenden Daten je nach Typ in Byte oder
> 08: Länge Low-Byte Wörtern


(genau so steht´s da...)

Für Teil1 muss aber schon beim Beginn die 0 angegeben werden - oder die 1? (ich meine aber schon 0)


----------



## argv_user (21 Januar 2008)

Byte 7 und 8 definieren die Anzahl der zu übertragenden Datenworte,
wenn es um DB geht, aber Datenbytes wenn es zB um Merker geht.

Dh. die Vielfachheit hängt nur vom Datentyp ab.

Byte 7 = 1 heißt Anzahl >= 256


----------



## rs-plc-aa (22 Januar 2008)

Hallo, ich sitze jetzt schon seit heute morgen vor dem Elend und versuche das mit der Koordination des 3-teiligen Empfangs auf die Reihe zu kriegen -> Katastrophe!

Es ging mal so halbwegs, aber dann kam es immer wieder vor daß aus dem Puffer der CP noch was "altes" in den nächsten Bereich geschrieben wurde.

Bislang habe ich es noch so probiert an P_RCV und P_SEND den selben Instazdatenbaustein zu lassen, einen Versuch noch und dann stelle ich um.

Falls wer noch spontan einen Einfall dazu hat - ich schaue regelmäßig hier vorbei, und danke schon mal (wollte eigentlich heute fertig werden...)


----------



## Larry Laffer (22 Januar 2008)

rs-plc-aa schrieb:


> Katastrophe !
> 
> Es ging mal so halbwegs, aber dann kam es immer wieder vor daß aus dem Puffer der CP noch was "altes" in den nächsten Bereich geschrieben wurde ...


 
? ... wie soll das gehen, dann hättest du ja eine Durch-Mischung der drei Teil-Aufträge.
Du fragst doch w50..99 erst an, wenn du w00..49 erhalten hast ... oder ?

Gruß
LL


----------



## rs-plc-aa (22 Januar 2008)

Ja, theoretisch schon...

Ich wollte es so machen daß ich über eine Zeit die im Hintergrund läuft 3 Zonen baue von der jeweils nur eine scharf ist.

In diesen Zonen habe ich dann die Freigabe gemacht und die Parameter "DBB_NO" (Quell-DB mit Telegrammkopf und Ziel-DB Bereich) geändert.

Wenn sich aber der Wechsel mit einem laufenden Auftag überschnitt kam das zu stande.

Ich habe mich dann mit S/R Verriegelungen so überschlagen daß ich irgendwann selbst nicht mehr durchblickte. Es fehlt eben auch noch am prinzipiellen Verständnis wie die Sende- und Empfangs-FB´s auf einander abgestimmt sein müssen.

Bei meinem ersten Versuch mit Recieve_Enable = statisch TRUE und Empfang_beendet_ohne_Fehler hat Send_Enable getriggert hat es funktioniert - allerdings nicht mit ausreichender Länge -> daher jetzt das.

Nun habe ich mal pro Aufruf eine separate instanz genommen und alles wieder in die Zonen verpackt (vielleicht liegt hier ja schon der Denkfehler).

Vielleicht sollte ich das hintereinander laufen lassen und nur die Bits in den Zonen verriegeln?

1000 Möglichkeiten irgendwie aber die richtige finden...


----------



## Larry Laffer (22 Januar 2008)

... ich befürchte jetzt nur, dass deine 3 I-DB's das Problem vielleicht nicht wirklich lösen. Das Problem einer Teil-Durchmischung (jetzt nur mit alten Daten) besteht doch dann ggf. immer noch - oder nicht ...?


----------



## rs-plc-aa (22 Januar 2008)

Hiermit geht es mal so lala...



> // Sequenz für Sende-/Empfangsfreigabe und Parametrierung erzeugen:
> UN T 9
> L 300 // Gesamtlaufzeit entsprechend der Zeitbasis (Wert*Basis)
> ITB
> ...


 
Der Code wurde schon zig mal geändert, ist eben mal ein aktueller Schnappschuss...

Ich setze jetzt in den letzten 2 sekunden jeder Zone beide FBs zurück -> geht auch, nur der Knackpunkt ist wohl noch daß da wiederum das Ende vorher abgewartet werden sollte?

Na ja egal, schaut´s euch halt mal an...


----------



## Larry Laffer (22 Januar 2008)

Hallo RS,
ich habe da gerade mal meinen Fundus durchsucht. Da gibt es ein zwar nicht von mir geschriebenes aber funktionsfähiges CP340-Programm. Nicht so schön wie deins (vor allem nicht so anspruchsvoll), aber ...

Beim Senden wir dort als Weiterschalt-Bedingung das DONE-Bit abgefragt und beim Empfangen das NDR-Bit und die Rcv_Len. Letztere wurde vorher zurückgesetzt (weiß nichtt ob das was bringt).

Senden war erledigt wenn DONE, dann gings zum Empfangen. Dies dann wenn NDR und LEN = erwartete Länge. Wieder Senden ...
Keine Zeit-Steuerung - nur ein Timeout. Wenn Timeout, dann hat es nicht geklappt und Fehler und neuer Versuch (? nach weiterer Zeit ?).

Das Listing  hier einstellen bringt nicht, weil 1. in SCL und 2. unübersichtlich (das geht auch in SCL). Vielleicht hilft es dir trotzdem weiter ...

Gruß
LL


----------



## rs-plc-aa (22 Januar 2008)

Diese Lösung die ich gepostet habe ist schon wieder gelöscht...

Es muss machbar sein das in einem Bruchteil von Zeilen zu lösen -> nur dann geht´s auch, meistens.


Dein Hinweis zu dem Programm nehme ich gerne entgegen, was hat es denn gemacht? "Nur" einen (immer den selben) Bereich empfangen?

Die vorgehensweise erst wenn das Senden Fertig ist zu empfangen verwirrt mich ein wenig - auf grund des Telefonats mit Siemens neulich, daher ging ich immer davon aus dass gleichzeitig gesendet und empfangen werden muss?? Schon komisch, daß sich da alle so uneinig sind - für mich war das ganze bis jetzt ein riesen Griff ins Klo.

Ich habe schon einen neuen Weg in Arbeit - ohne Zonen, nur mit Bits zum sperren/freigeben eventuell kann ich von deinem Hinweis was verwerten.

Zwischendurch könnte ich manchmal an der glatten Wand hoch, grr! (aber es hilft ja auch nix)


----------



## Larry Laffer (22 Januar 2008)

Hallo RS,
ich habe dir nur eine Interpretation von dem geschrieben, was "mein" Programm macht. Diese liest 2x und schreibt 2x. Empfangen werden 16 Bytes, gesendet so wie bei dir.
Das mit dem Senden und Empfangen nacheinander ist bei mir so gemacht. Müßte aber nach der Beschreibung deiner Aufgabenstellung bei dir ähnlich sein, da du ja auch erst sagst, was du haben willst und das dann in der Zustellung erwartest - das ist für mich nicht gleichzeitig ...

Ach ja, ich wollte dich nicht ärgern und auch nicht, dass du dich ärgern mußt. Tut mir leid, dass dieser Job Scheiße ist. Ich persönlich mag so etwas auch nicht und bin (bis jetzt) um so etwas auf SPS-Basis auch immer herumgekommen. Aber das hilft dir ja wenig.

Gruß
LL


----------



## argv_user (22 Januar 2008)

Im Prinzip kannst Du den Empfang immer erlauben.
Du solltest das auch tun, um Fehlerzustände zu erkennen.

Wenn Du eine Anforderung sendest, prüfe ob was im Empfangspuffer steht
und schmeiß das weg. Solange der Sendevorgang andauert, darf
eigentlich nichts empfangen werden, es sei denn, die 3964(R) Priorität
ist falsch eingestellt und/oder es sind Übertragungsfehler aufgetreten.
Das ist dann auch ein Fehler: warte ein Weilchen und beginne von vorn...

Die Daten aus dem selben Block in drei Happen lesen bringt
erstmal niemand durcheinander. Erst wenn sich die Daten in der 
Zwischenzeit ändern wird es interessant. Für diese Fälle
gibt es Verfahren, um Inkonsistenzen zu vermeiden.

Eines verwendet zB ein Freigabe-Bit/Byte/Word, das der Partner
bei Lesen fertig zurücksetzt.

Ein anderes liest die Daten einfach mehrmals und erkennt sie als gültig,
wenn sie sich zwischenzeitlich nicht geändert haben....


----------



## rs-plc-aa (22 Januar 2008)

Empfang immer erlauben? 

Aber wie soll ich das jetzt unter einen Hut kreigen da ich ja drei verschiedene Ziele angeben muss?

So langsam verstehe ich gar nichts mehr...

Ich bin heute auch ziemlich enttäuscht da einfach nichts ging (war den ganzen Tag vor dem Schrank gesessen und hab alles mögliche probiert)

@Larry: Ich habe mal probiert nur den Kopf zu senden - sonst gar nichts, da kam nicht ein mal ein Lebenszeichen (TX/RX Led)...
Auch anschliessend zu empfangen war nichts.
[\Larry]

Ich habe auch noch mal die Handbücher studiert, da wird dringend abgeraten verschiedene IDBs zu verwenden (für die selbe CP) - auch noch so ein Punkt wo ich vielleicht in der Sackgasse bin.

Wo ist denn jetzt der wirkliche Unterschied zur Vorgehensweise mit der CP341?

@ARGV: Du scheinst die Lösung zu kennen, willst sie mir aber nicht verraten?


----------



## Question_mark (22 Januar 2008)

*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 (23 Januar 2008)

@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 (23 Januar 2008)

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 (23 Januar 2008)

rs-plc-aa schrieb:


> 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 (23 Januar 2008)

Larry Laffer schrieb:


> 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 ...
> ...


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


----------



## Larry Laffer (23 Januar 2008)

... 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 (23 Januar 2008)

@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 (23 Januar 2008)

rs-plc-aa schrieb:


> 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 (23 Januar 2008)

*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 (24 Januar 2008)

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 (24 Januar 2008)

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 (24 Januar 2008)

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 (24 Januar 2008)

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 (24 Januar 2008)

argv_user schrieb:


> 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.
> ...


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!


----------

