RK512 / Fetch, Zugriff verweigert

noeppkes

Level-1
Beiträge
150
Reaktionspunkte
5
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo an alle,

nachdem ich nun nach 3 Tagen endlich es mal geschafft habe meiner S5 ein Antworttelegramm zu entlocken kommt nun die Fehlermeldung:

0 0 0 A 10 0 19.
Was heisst: Zugriff verweigert.
Der Datenbaustein existiert.
Muss ich noch irgendwelche Einstellungen in meiner S7 machen.
Habe einfach einen CP341 mit RK512 hinzugefügt und einen Datenbaustein mit Inhalt angelegt.
Nun wollt ich mal Daten aus diesem lesen.

Ich hoffe mch kann jemnd retten.

noeppkes ...
 
Mach noch ein paar Freds auf ..

Hallo,

noeppkes schrieb:

noeppkes schrieb:
Einstellungen in meiner S7 machen.

Also erstmal solltest Du Dir darüber im klaren sein, mit welcher Steuerung Du nun wirklich kommunizieren willst. Obwohl das einem funktionierendem RK512 Treiber eigentlich egal sein sollte. Zeigt eigentlich nur, dass Du nicht so richtig weisst, was Du da eigentlich machst.

noeppkes schrieb:
Was heisst: Zugriff verweigert. Der Datenbaustein existiert.

Schön dass der DB existiert. Hoffentlich auch in der erforderlichen Länge ..
Kann es evtl. sein, dass Du in der Hochsprache, mit der Du den RK512-Treiber ansprichst, noch nicht so richtig fit bist und da einige Fehler bei der Parametrierung und Aufruf des Treibers eingebaut hast ???
Aber Du kannst ja noch einen neuen Fred aufmachen ...
Gruß

Question_mark
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
RK512 Zugriff verweigert

Hallo,





Also erstmal solltest Du Dir darüber im klaren sein, mit welcher Steuerung Du nun wirklich kommunizieren willst. Obwohl das einem funktionierendem RK512 Treiber eigentlich egal sein sollte. Zeigt eigentlich nur, dass Du nicht so richtig weisst, was Du da eigentlich machst.
Question_mark

Na das ist doch schon mal schön zu hören.


Hallo,
Kann es evtl. sein, dass Du in der Hochsprache, mit der Du den RK512-Treiber ansprichst, noch nicht so richtig fit bist und da einige Fehler bei der Parametrierung und Aufruf des Treibers eingebaut hast ???
Aber Du kannst ja noch einen neuen Fred aufmachen ...
Gruß

Question_mark

@Question Mark.
Ich will mich mit dir eigentlich nicht anlegen.
Ich dachte immer das ist ein Forum in dem einem geholfen wird.
Hätte ich keine Probleme, würde ich hier ja auch wohl nicht schreiben.

Ich habe deswegen einen neuen Fred aufgemacht, da ich nun eine Antwort von der SPS erhalte und das Problem ein anderes ist.
Ich habe hier schon viele Lösungen durch suchen gefunden und da ist es doch schön wenn alles ein wenig strukturiert ist.
(So programmiert man doch auch in einer Hochsprache)

Bei meinen bisherigen Versuchen verwendete ich den Treiber von Rothenbacher.
Da habe ich dann nach ca. 3 Tagen festgestellt, dass dieser unter gewissen Umständen die Checksumme falsch berechnet.
Liegt das etwa an mir ? 3 Abende für nichts.
Ich war zumindest so schlau und habe es herausgefunden, indem ich das Protokoll mitschnitt.
Sobald die Datenübertragung läuft und es eindeutig bewiesen ist, dass der Treiber falsche Daten sendet, wende ich mich an Rothenbacher.

Anschliessend habe ich mir ein VB Progr. geschrieben das genau das gleiche Protokoll mit richtiger Checksumme schickt. siehe da, die SPS antwortet, allerdinsg mit der Meldung Zugriff verweigert.

Und nun kommt von dir so ne schlaue Antwort:
Hallo,
Schön dass der DB existiert. Hoffentlich auch in der erforderlichen Länge ..
Question_mark
Wäre der DB nicht anleget, würde wohl eine andere Fehlermeldung kommen oder ?
Wäre das Lesen ausserhalb des Bereiches, was würde dann wohl für eine Meldung kommen ? Ironisch gesagt nicht die von mir beschriebene.
Also zusammengefasst. Deine Antwort war gänzlich unpassend, was ich als Laie schon bemerke.
Das sollte dir doch eindeutig zeigen, dass ich mich mit dem Protokoll schon intensiv beschäftigt habe.
Ich hoffe ich habe mich jetzt nicht zu weit aus dem Fenster gelehnt.

Da im Internet sehr sehr wenig über das Protokoll zu finden ist, was bleibt mir da anderes übrig, als auf Leute zurückzugreifen, die es wissen.
(google: Zugriff verweigert fetch RK512. 7 Treffer. Nichts passend).
Anscheinend habe ich dich gestern auf dem falschen Fuss erwischt.

Ich würde dir nun heute morgen vorschlagen:
Trinke eine Tasse Kaffee oder Tee, lass es dir gutgehen und sofern du jetzt noch Muse hast einem Programmierer zu helfen der weder hier noch im Internet Lösungen auf diese Frage findet, kannst du ja noch einmal schreiben.

Ansonsten lasse es. Reine Zeitverschwendung und unötiges aufblähen von Fred's, sofern die Antwort:
Hallo,
Schön dass der DB existiert. Hoffentlich auch in der erforderlichen Länge ..
Question_mark
heisst.

Für alle die es interessiert:
Der DB ist übrigens 46 Bytes lang ( 5 Integer Var. angelegt). Es wird zum Test auf den 2. Integer zugegriffen, mit der Länge 1.
Die Bytefolge ist wie folgt:
0x00, 0x00, 0x45,0x44,0x17,0x01,0x00,0x01,0xFF,0xFF,0x10,0x03,0x05

So hier die Auflösung des Protokolles:

0x00,0x00 Befehlstelegramm, kein Folgetelegramm.
0x45,0x44 Greife auf Datenbaustein zu mit Fetch-Telegramm
0x17 Der Datenbaustein DB23 ist gemeint
0x01 Startadresse im Datenbaustein (1 bedeutet: 2 Variable)
0x00, 0x01 (High und Low-Byte der Länge. In meinem Fall Länge 1)
0xFF, 0xFF (Keine Angabe der Koordinierungsmerker, daher beide 0xFF)
0x10, 0x03 (Telegrammende)
0x05 Checksumme aller Bytes XOR verknüpft.

@Question Mark,
Ich hoffe ich habe keine Fehler gemacht bei der Erklärung des Telegrammes.

noeppkes ...
 
Hätte da mal eine Frage: RK512 kommt ja bekannterweise aus der Steinzeit. Die Definition ist etwa von 1988. Dort war die S5 aktuell und die hatte bei Daten einen Wortzugriff. Wie wird dies jetzt auf die S7 abgebildet? Werden hier auch Wortadressen und Wortlängen im Protokoll angegeben? Zum Spaß einfach mal Staradresse und Länge als gerade Zahl (= 2) testen. Ändert sich dadurch etwas? Klar im Protokoll, aber im Ergebnis?
 
Nachtrag zu Fehlernummer 0A:
"Prüfen Sie, ob RECEIVE ALL oder SEND ALL in Ihrem STEP-5-Programm aufgerufen werden; werten Sie PAFE am Hantierungsbaustein aus."
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Nachtrag zu Fehlernummer 0A:
"Prüfen Sie, ob RECEIVE ALL oder SEND ALL in Ihrem STEP-5-Programm aufgerufen werden; werten Sie PAFE am Hantierungsbaustein aus."

Hallo,

danke für die schnelle Antwort.
Ich habe gehört, ich muss in der SPS nichts weiter machen als den CP einbinden und auf RK512 stellen (Baudrate etc. ist klar)

Daher bin ich jetzt etwas verwundert, dass ich Receive All und Send All aufrufen soll ? Sind das die FB7 bzw. FB8. die benötige ich doch eigentlich nicht oder ?
Was ist PAPE, das habe ich noch nicht gehört.
Der Handtierungsbaustein ist wohl der zu lesende Baustein. Im meinem Fall der DB23.

noeppkes ...
 
Hätte da mal eine Frage: RK512 kommt ja bekannterweise aus der Steinzeit. Die Definition ist etwa von 1988. Dort war die S5 aktuell und die hatte bei Daten einen Wortzugriff. Wie wird dies jetzt auf die S7 abgebildet? Werden hier auch Wortadressen und Wortlängen im Protokoll angegeben? Zum Spaß einfach mal Staradresse und Länge als gerade Zahl (= 2) testen. Ändert sich dadurch etwas? Klar im Protokoll, aber im Ergebnis?

Hallo,
ja das wäre ein Versuch wert.
Kann es aber erst heute abend testen.
Ich glaube ich habe es zwar schon gemacht und ohne Erfolg, probiere es aber trotzdem noch einmal aus.
Melde mich hierzu wieder
Danke vorerst mal.

noeppkes ...
 
Hallo,

danke für die schnelle Antwort.
Ich habe gehört, ich muss in der SPS nichts weiter machen als den CP einbinden und auf RK512 stellen (Baudrate etc. ist klar)

Daher bin ich jetzt etwas verwundert, dass ich Receive All und Send All aufrufen soll ? Sind das die FB7 bzw. FB8. die benötige ich doch eigentlich nicht oder ?
Was ist PAPE, das habe ich noch nicht gehört.
Der Handtierungsbaustein ist wohl der zu lesende Baustein. Im meinem Fall der DB23.

noeppkes ...
Das war die Fehlerbeschreibung aus dem Jahre 1988. Wie das heute aussieht mit einer CP341 weiß ich nicht. Ich hatte da noch nie das Vergnügen, mich mit dieser Baugruppe rumzuärgern. qm ist da sowieso der kompetentere Ansprechpartner.
Ich selbst greife auf die S7 lieber direkt, d.h. über MPI, PB oder RFC1006, zu.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Das war die Fehlerbeschreibung aus dem Jahre 1988. Wie das heute aussieht mit einer CP341 weiß ich nicht. Ich hatte da noch nie das Vergnügen, mich mit dieser Baugruppe rumzuärgern. qm ist da sowieso der kompetentere Ansprechpartner.
Ich selbst greife auf die S7 lieber direkt, d.h. über MPI, PB oder RFC1006, zu.

Danke für die Info,

es ist natürlich sehr bequem und auch von den Kosten her relativ gering, wenn man über RS485 und CP341 von einem Laptop aus auf eine S7 zur Visualisierung zugreift.
Ich hatte es mir auf jeden Fall einfacher vorgestellt.
Sieht wohl so aus, als sollte ich mir lieber einen CP343-1 (TCPIP) kaufen.
Dann geht es über das Netzwerk.

noeppkes ...
 
Ich denke, ein normaler PC-Adapter ist günstiger als die CP 341. Als Bibliothek käme hier dann libnodave, AGLink oder andere in Frage. Wenn es schneller sein soll, dann NetLink-PRO oder eine CP 343-1, lean genügt da ja. Auch hier kann libnodave oder AGLink verwendet werden.
Ich persönlich habe zwar das RK 512-Protokoll ebenfalls in AGLink eingebaut, mag es aber nicht sehr. Es ist uralt, bietet wenig Möglichkeiten und heutzutage weiß fast keiner mehr welche Fehlernummer was bedeutet. Unklar ist auch, ob die Originalbedeutung auch bei den heutigen CPs erhalten blieb. Selbst in großen Häusern geht so manches verloren. Bei einer normalen S7-Kommunikation habe ich da wesentlich mehr Möglichkeiten. Außerdem ist hier der Datendurchsatz entsprechend höher.
 
Bloß mal so die Frage, es gibt da ein Handbuch

"Punkt-zu-Punkt-Kopplung CP 341 Aufbauen und Parametrieren"

von Siemens. Schon mal reingeschaut? In Kapitel 6.3.2 findet sich:

Anwendung der Funktionsbausteine bei Rechnerkopplung RK 512
Für die Kopplung zu einem Kommunikationspartner mit der Rechnerkopplung
RK 512 stehen Ihnen folgende Funktionsbausteine zur Verfügung:
• FB 8 P_SND_RK zum Daten senden bzw. Daten holen
• FB 7 P_RCV_RK zum Daten empfangen bzw. Daten bereitstellen
Und weiter:

Passive Aufträge:
Mit dem Funktionsbaustein FB 7 P_RCV_RK können Sie über passive Aufträge
das Einlesen und die Bereitstellung der Daten auf dem CP 341 koordinieren. Der
Kommunikationpartner ist aktiv. Sie können
• vom Kommunikationspartner gesendete Daten in einem S7-Datenbereich Ihres
Automatisierungsystems einlesen (siehe Abschnitt “Daten empfangen mit
FB P_RCV_RK”)
• Daten in Ihrem Automatierungsystem für einen remoten Kommunikationspartner
bereitstellen (siehe Abschnitt “Daten bereitstellen mit FB P_RCV_RK”)
Kurz gesagt: FB7 muss auf der (passiven) S7-Seite verwendet werden
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich denke, ein normaler PC-Adapter ist günstiger als die CP 341. Als Bibliothek käme hier dann libnodave, AGLink oder andere in Frage. Wenn es schneller sein soll, dann NetLink-PRO oder eine CP 343-1, lean genügt da ja. Auch hier kann libnodave oder AGLink verwendet werden.
Ich persönlich habe zwar das RK 512-Protokoll ebenfalls in AGLink eingebaut, mag es aber nicht sehr. Es ist uralt, bietet wenig Möglichkeiten und heutzutage weiß fast keiner mehr welche Fehlernummer was bedeutet. Unklar ist auch, ob die Originalbedeutung auch bei den heutigen CPs erhalten blieb. Selbst in großen Häusern geht so manches verloren. Bei einer normalen S7-Kommunikation habe ich da wesentlich mehr Möglichkeiten. Außerdem ist hier der Datendurchsatz entsprechend höher.

Vielen Dank für die vielen Info's.
PC-Adapter, NetLink Pro habe ich zwar noch nie gehört, mache mich aber mal schlau.
CP343-1 lean habe ich schon ins Auge gefasst, da bei mir zuhause sowieso ein Netzwerk liegt und sich dieses anbietet.
Des weiteren kann ich ja die SPS über den CP343-1 lean programmieren, was für mich zuhause wesentlich angenehmer ist, als mit Profibus (MPI).

libnodave habe ich mir schon mal angesehen. Ich denke damit komme ich klar.
Also muss ich mir wohl einen CP343-1 zulegen.

noeppkes ...
 
Bloß mal so die Frage, es gibt da ein Handbuch

"Punkt-zu-Punkt-Kopplung CP 341 Aufbauen und Parametrieren"

von Siemens. Schon mal reingeschaut? In Kapitel 6.3.2 findet sich:

Und weiter:

Kurz gesagt: FB7 muss auf der (passiven) S7-Seite verwendet werden

Ich habe schon einige Fred's hier aufgemacht bzgl. RK512 und Datenübertragung.
Es hieß immer: KEIN FB7 nötig für die Datenübertragung.
Das geschieht alles von alleine in der SPS.
Jetzt sagtst du mir, ich benötige den FB7 ?

Was soll ich denn nun glauben.

Im Moment ist er nicht im OB1.
Die SPS antwortet. die Kommunikation scheint zu laufen.
Allerdings eben mit der Antwort:
Zugriff verweigert.

noeppkes ...
 
Der NetLink-PRO wird bei der SPS auf die MPI- oder PB-Schnittstelle gesteckt und ist mit dem PC über Ethernet verbunden. Der PC-Adapter ist der normale Seriell-MPI-Wandler. Infos zu beiden Produkten sind auch auf unserer Homepage unter S7-Adapter zu finden. libnodave unterstützt beide Adapterarten und natürlich auch den CP 343. Vorteil eines externen Adapters: er ist nicht an die CPU gebunden und muss nicht über die Hardwarekonfig parametriert werden. Nachteil: es ist ein separates Kästchen und nicht nur ein dünnes Kabel.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Versuch mal

Hallo,

Rainer Hönle schrieb:
Zum Spaß einfach mal Startadresse und Länge als gerade Zahl (= 2) testen. Ändert sich dadurch etwas? Klar im Protokoll, aber im Ergebnis?

Soweit ich es für die S7 noch im Hinterkopf gespeichert habe, muss immer eine gerade Anzahl als Datenlänge angefordert werden, die S7 setzt sonst in den Telegrammen bei den Daten ein Füllbyte.
Den Vorschlag von Rainer solltest Du mal ernsthaft versuchen.

Gruß

Question_mark
 
Da fehlt was ...

Hallo,

noeppkes schrieb:
Anschliessend habe ich mir ein VB Progr. geschrieben das genau das gleiche Protokoll mit richtiger Checksumme schickt. siehe da, die SPS antwortet, allerdinsg mit der Meldung Zugriff verweigert.

Danke, das wir das auch erfahren dürfen. Wegen Kristallkugel und so :ROFLMAO:
Trotzdem hättest Du den alten Fred benutzen können, das Problem war doch noch nicht gelöst, aber jetzt ist es nun mal passiert.

noeppkes schrieb:
So hier die Auflösung des Protokolles:

0x00,0x00 Befehlstelegramm, kein Folgetelegramm.
0x45,0x44 Greife auf Datenbaustein zu mit Fetch-Telegramm
0x17 Der Datenbaustein DB23 ist gemeint
0x01 Startadresse im Datenbaustein (1 bedeutet: 2 Variable)
0x00, 0x01 (High und Low-Byte der Länge. In meinem Fall Länge 1)
0xFF, 0xFF (Keine Angabe der Koordinierungsmerker, daher beide 0xFF)
0x10, 0x03 (Telegrammende)
0x05 Checksumme aller Bytes XOR verknüpft.

@Question Mark,
Ich hoffe ich habe keine Fehler gemacht bei der Erklärung des Telegrammes.

Also erstmal würde ich den von Rainer Hönle vorgeschlagenen Versuch mit gerader Startadresse und gerader Anzahl durchführen. Aber pass auf die Checksumme auf, die wird sich zwangsläufig ändern.

Als Reaktion auf Dein o.a. gesendetes Telegramm sollte dann erstmal ein DEL (0x10) vom CP341 kommen. Dann musst Du ein STX (0x2) an den CP341 senden. Und diese beiden Befehle finde ich jetzt in Deiner Telegrammbeschreibung nicht.
Danach erst kommt das Reaktionstelegramm vom CP341.

noeppkes schrieb:
0
0
0
A - Die Fehlermeldung
10 - DLE
0 - Tippfehler ? muss 3 (ETX) sein
19 - BCC

Gruß

Question_mark
 
RK512 / Zugriff verweigert

@Question Mark,

Danke für deine Nachricht.
Das mit dem Ablauf (Senden, 0x10 dann STX etc) habe ich soweit im Griff.
Das funktioniert auch soweit.
Das einzige was ich noch probieren muss, ist das mit den geraden Adresse.
Die Checksumme wird in meinem VB Prog ausgerechnet, je nachdem was ich vorgeben. Das funktioniert auch, ansonsten würde ich ein NAK erhalten, was nicht der Fall ist.

Was mir aber immer noch nicht klar ist, dass eineiseits (von dir) behauptet wird, dass man keinen FB7 benötigt, allerdings hier in deisem Fred (weiss im Moment nicht mehr genau wer) geschrieben wurde, dass unbedingt der FB7 verwendet werden muss.
Lt. Handbuch vom CP341 verstehe ich das auch so, dass der FB7 unbedingt in den OB1 muss. Auch bei RK512 und gerade wie bei mir, CP als passiv, Laptop als aktiv.

Ich probiere heute Abend mal beide Version aus.

Ich melde mich wieder sobald es neues gibt.

Bis später

noeppkes ...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
RK512 Zugriff verweigert

@Question Mark,

Hallo Mark,

so. nun habe ich es zumndest was das Lesen betrifft auf den Punkt gebracht.

Die Checksumme stimmt, der Protokollrahmen auch und nachdem ich den FB7 im OB1 aufrufe, bekomme ich ENDLICH die Werte die in meinem DB stehen.
Somit wäre das für mich mal geklärt ob oder ob nicht der FB7 in den OB1 kommt.

Allerdings funktioniert das Schreiben noch nicht.
Muss ich das noch etwas in der SPS tun.
Irgend etwas am FB7 (ausser der Adresse und dem enable) einstellen .
Ich probiere mal weiter.
Melde micht dann.
Vielleicht kommt in der Zwischenzeit ja auch ein Vorschlag.

noeppkes ...
 
RK512. Die Lösung

Hallo an alle,
nachdem ich jetzt seit Tagen damit beschäftigt war mit RK512 Daten aus und in den CP341 (Genauer gesagt in/aus den Datenbausteien zu lesen / zu schreiben), hier die Lösung meines Problemes.

Das Lesen funktioniert ja jetzt (siehe oben).
Das Schreiben war noch das Problem.
Das Rothenbacher RK512 OCX schickt für das Schreiben in den Datenbaustein als Word:
0x00, 0x00, 0x41 und 0x57 ...
Von meiner SPS wird aber erwartet:
0x00, 0x00, 0x41, 0x44 ...
Tja, ich frage mich warum Rothenbacher 0x57 sendet.
Würde mich schon interessieren.

noeppkes ...
 
Verbindung projektiert ?

Hallo,

noeppkes schrieb:
nachdem ich den FB7 im OB1 aufrufe, bekomme ich ENDLICH die Werte die in meinem DB stehen.

Was mich jetzt etwas wundert. Aber dazu muss ich erstmal etwas ausholen. Bei der S5 war das so (der PC ist aktiv, der CP ist passiv also vom PC wird "FETCH" und "SEND" abgeschickt) :
In der S5 brauchten in diesem Falle keine expliziten Aufrufe von FB's mit programmierten Aufträgen gesendet werden. Es genügte ein Aufruf von "SEND-ALL" und "RECEIVE-ALL". Diese Bausteine sorgten für den Transfer der Daten von der CPU zum PC und umgekehrt. Und fertig war die Kiste. Der große Vorteil war eigentlich, dass für jedes Protokoll (egal ob 3964, RK512, DP, H1) die gleichen FB's zuständig waren.
Bei der S7 stellt es sich so dar, dass ich zwar alle Verbindungen in NetPro projektieren muss (ausser natürlich PG-Verbindungen) und in die CPU runterladen muss, aber der Datentransfer CP-CPU und umgekehrt ist dadurch automatisch integriert. Dadurch kann z.B. der OPC-Server mit allen möglichen Protokollen ohne besondere Aufrufe von Standard-FB's in der S7 kommunizieren.
Dafür gibt es jetzt aber im Gegensatz zur S5 eine nicht mehr überschaubare Anzahl von Standard-FB's für jedes mögliche Protokoll, CPU, CP etc. für auftragsbezogene Kommunikation.
Ich kann mich aber nicht erinnern, dass beim CP441 (CP341 habe ich noch nicht eingesetzt) für passive Kommunikation Standard-FB's erforderlich waren.

noeppkes schrieb:
Allerdings funktioniert das Schreiben noch nicht.
Eventuell musst Du noch eine zusätzliche Verbindung mit der Zusatzsoftware PtP projektieren ?

Gruß

Question_mark
 
Zurück
Oben