CP 340 - Messwerte empfangen

[rs-plc-aa]

Zuviel Werbung?
-> Hier kostenlos registrieren

Fortsetzung...

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

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

 

[rs-plc-aa]

Zuviel Werbung?
-> Hier kostenlos registrieren

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]

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]

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]

Zuviel Werbung?
-> Hier kostenlos registrieren

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]

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]

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]

Zuviel Werbung?
-> Hier kostenlos registrieren

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]

Hast Du die folgenden Sachen bei Siemens schon gefunden ?

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

 

[rs-plc-aa]

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]

Zuviel Werbung?
-> Hier kostenlos registrieren

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]

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]

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]

Zuviel Werbung?
-> Hier kostenlos registrieren

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]

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]

Mal was zum RK512

Hallo,

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]

Zuviel Werbung?
-> Hier kostenlos registrieren

So geht das nicht ...

Hallo,

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]

Da hat Dich jemand schlecht beraten

Hallo,

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]

Einspruch ...

Hallo,

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