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