Hallo, hat sich hier im Forum schon mal jemand mit IO-Link beschäftigt? Speziell intressiert mich, ob jemand schon mal das Protokoll für einen Slave implementiert hat? Sonstige Erfahrungen damit? Allgemeine Anmerkungen zu dem Thema? Wie komplex ist das? usw.??? Gruß Delta
... wow, das ist Weltpremiere! Niemand der ne Ahnung zu einem Thema hat das ich poste.. irgendwie cool, aber sehr schade
die Spezifikationn ist noch gar nicht so lange draußen! Schau mal wieviel Geräte es mit dieser Schnittstelle schon gibt!
Hallo Delta, IO-Link ist wie Feldbusse auch, mit einer weitreichenden Spec gesegnet, um im industriellen Umfeld eine hohe Verfügbarkeit unter unterschiedlichen Bedingungen zu erreichen. Wenn's darum geht irgendwas zu steuern, ist eine Anlehnung daran mit Kanonen auf Spatzen zu schießen. Wenn Du ein eigenes Gerät dafür erstellen willst muß Du eh die Spec erfüllen, sind nur 129 Seiten also zügig gehen. Wenn Du genauer beschreibst was Du machen willst, kann Dir vielleicht eher geholfen werden. Grüße Hans-Josef
Hans Josef schrieb: > Wenn Du ein eigenes Gerät dafür erstellen willst muß Du eh die Spec > erfüllen, sind nur 129 Seiten also zügig gehen. LOL! Das nenn ich mal einen gesunden Humor! Kannst Du tatsächlich länger als 15 Minuten am Stück pro Tag in dieses oben genannte PDF reinschauen ohne Dich gleichzeitig einer Aggressionsbewältigungstherapie zu unterziehen und ohne den Drang zu verspüren Stühle und Tische umherzuwerfen? Wenn ja dann Hut ab! Zurück zum Thema: 7 Jahre sind vergangen, hat mittlerweile jemand anderes als die Mitglieder dieses Gremiums die Spezifikation gelesen und verstanden, gibt es evtl. irgendwelche hilfreiche Sekundärliteratur die diesen überaus unnötig verknoteten, mit tonnenweise redundantem irrelevantem Füllgeschwafel angereicherten und mit unverlinkten Querverweisen nach jedem zweiten Wort in einem PDF ohne Inhaltsverzeichnis bewußt unleserlich gestalteten Krampf in menschenlesbarer Sprache zusammenfasst oder gar simple Codeschnipsel (gerne auch pseudo-code) für das minimalst-mögliche Device oder exemplarische Kommunikationsmitschnitte eines solchen vom Wakeup bis zum Beginn der zyklischen Prozessdaten?
Mhm, also ich weiss nicht welche PDF's ohne Inhaltsverzeichnis du hast, aber nach 10sec googeln kommt man doch auf ganz schöne Spezifiaktionen: http://www.io-link.com/de/Download/Download.php?thisID=8 Ausserdem sieht das ganze sehr ähnlich wie Modbus aus. Und wenn man nicht weiter weiss, einfach bei Siemens oder Beckhoff anfragen...
Kauft den Stack von TMG, der ist super einfach zum implementieren und verstehen. Ist für STM8 geschrieben. Außerdem benötigt man einen passenden Treiberbaustein.
Patrick B. schrieb: > hm, also ich weiss nicht welche PDF's ohne Inhaltsverzeichnis du hast, Die Version 1.0 hat kein Inhaltsverzeichnis (nur ein gedrucktes, kein klickbares). Ein 130 Seiten PDF dieser Art ohne Inhaltsverzeichnis ist der Horror.
:
Bearbeitet durch User
Mit IO-Link überfordert? Das ist die am besten verständlichste und einfachste Spec. die ich bisher im Berufsleben umsetzen durfte (Master teilw. u. Slave). Wenn man da an Profibus denkt ... kurz weg ... müsste mich kurz über die Kloschüssel hängen ;) Wo gibt es hier Probleme? Sehe hier gar nicht die Notwendigkeit einer Zusatzliteratur. Warum liest du Version 1.0?
Bastler schrieb: > Kauft den Stack von TMG, der ist super einfach zum implementieren und > verstehen. > Ist für STM8 geschrieben. STM8 hab ich nicht. Auch kann ich mir den IO-Link Transceiver nicht aussuchen, der ist ebenfalls vorgegeben, aus elektrischen und räumlichen Zwängen heraus. Ich müsste diesen Stack also aufwendig portieren, oder zumindest die Teile davon (die 1% dessen was in der Spezifikation steht die tatsächlich praxisrelevant und notwendig sind) und genau das ist momentan mein Problem: Die Nuztlast an notwendiger Information aus dem Rauschen dieser Spezifikation zu extrahieren um dann am Ende die vielleicht 50 Zeilen Code hinzuschreiben die wirklich notwendig sind.
NichtSoSchnell schrieb: > Warum liest du Version 1.0? Weil jeder Master 1.0 implementieren muss, es also keinen Grund gibt 1.1 ins Device einzubauen, vor allem auch weil Version 1.1 aus 260 statt nur 130 Seiten bei identischem Informationsgehalt besteht. Außerdem ist 1.1 nicht vollständig, das Dokument enthält Auslassungen und Fehler.
NichtSoSchnell schrieb: > Wo gibt es hier Probleme? Sehe hier gar nicht die Notwendigkeit einer > Zusatzliteratur. Spezifikation 1.1, Seite 216, "M-Sequence Capability" * Frage: Was muss das Device antworten? Es wird auf 2 Tabellen verwiesen, diese enthalten jedoch nicht die gewünschte Information. * Frage: Woher weiß der Master zu diesem frühen Zeitpunkt schon ob das Device 1.0 oder 1.1 ist? Das kommt anscheinend gleich als zweites nach dem Wakeup (wenn ich keinen Fehler beim Mitschreiben der ankommenden Frames zu Debuggingzwecken im Device gemacht habe was ja auch möglich ist). Der selbe Parameter bei 1.0 hieß er noch "Frame Capability" (WTF?? warum umbenennen?) hier ist er wenigstens ordentlich spezifiziert und es besteht kein Zweifel was geantwortet werden muss. An dem Punkt hab ich dann beschlossen erstmal die Finger von 1.1 zu lassen so lange bis ichs mit 1.0 zum Laufen bekommen habe.
Hi Leute, ich habe auch die Spec digestiert und muss sagen, dass die den Master beschreibenden Statemachines leider an entscheidenden Stellen nicht konsistent sind. Beim Device hat man sich dann doch etwas mehr Mühe gegeben. Wie es aussieht, gab es auch noch kein Approve von der IEC (still pending). Ist denn jemanden‘s KMU schon Mitglied bei der POE e.V ? Zumindest würde mich mal interessieren, worauf sich dieser Satz: „Den freien Zugriff auf die Gesamt-Spezifikation zur IO-Link-Technologie, einschließlich Arbeitsstände, Feldbusintegrationen usw.“ von der Community Page denn beziehen soll ? Gibt es vielleicht noch andere (geheime) Specs, die mehr auf die Praxis hin reflektieren ?
Ich kenne zwei zur Feldbusintegration, aber dort muss man aufpassen. Sind Flüchtigkeitsfehlerchen drin. Können aber schon hilfreich sein für eine auch nicht Feldbusintegration. ... ja Master ist zugegeben nicht so toll. Aber ich finde man kommt mit zurecht. Wenn du es so simpel wie möglich machen willst bist du glaube eher gut damit beraten dir mal einen Aufbau anzuschauen und dort einfach die Kommunikation stur nachzubilden ohne die extra Features. Das ist dann halt nur funktioniert und nicht nach Spec. ...
NichtSoSchnell schrieb: > die Kommunikation stur nachzubilden ohne die extra Features. > > Das ist dann halt nur funktioniert und nicht nach Spec. ... Ich versuch halt den Teil zu implementieren der mandatory ist und zusätzlich nur die optionalen Teile die ich darüberhinaus noch brauche. Das ist durchaus nach Spec. Hier die nächste konkrete Frage: Ich initialisiere die Parameter Page 1 wie folgt:
1 | param_page_1[PARAM_ADDR_FRAME_CAPABILITY] = (1 << 1); // type 1 supported, spdu not supported |
2 | param_page_1[PARAM_ADDR_VENDOR_ID_1] = (uint8_t)(IOLINK_VENDOR >> 8); |
3 | param_page_1[PARAM_ADDR_VENDOR_ID_2] = (uint8_t)(IOLINK_VENDOR); |
4 | param_page_1[PARAM_ADDR_DEVICE_ID_1] = (uint8_t)(IOLINK_DEVICE >> 16); |
5 | param_page_1[PARAM_ADDR_DEVICE_ID_2] = (uint8_t)(IOLINK_DEVICE >> 8); |
6 | param_page_1[PARAM_ADDR_DEVICE_ID_3] = (uint8_t)(IOLINK_DEVICE); |
7 | param_page_1[PARAM_ADDR_FUNCTION_ID_1] = (uint8_t)(IOLINK_FUNCTION >> 8); |
8 | param_page_1[PARAM_ADDR_FUNCTION_ID_2] = (uint8_t)(IOLINK_FUNCTION); |
9 | param_page_1[PARAM_ADDR_IOLINK_REV_ID] = (1 << 4); |
10 | param_page_1[PARAM_ADDR_PROCESS_DATA_IN] = (1 << 6) | 1; // 1 bit process data from device |
11 | param_page_1[PARAM_ADDR_PROCESS_DATA_OUT] = 0; // 0 bit process data to device |
Also Protokoll-Version 1.0 und auch explizit kein SPDU in der frame capability. Dies wird alles vom Master schön abgefragt, dann schickt er mir noch seine MasterCycleTime und dann das Master command "DeviceOperate", soweit alles gut. Aber dann kommt völlig unerwartet gleich als nächstes ein Type 2 Frame: 0xf1 0x94 .... also: * Read * SPDU (WTF???) * Addr 17 * Type 2 (WTF???) Wie um alles in der Welt kommt der dazu mir einen type2 Frame zu schicken? Und vor allem welchen Untertyp? In der Spec steht geschrieben daß der Link-layer im App-layer(!) nachschauen muss (was ist das für ein Design?) um zu sehen wie viele Bytes Prozessdaten vereinbart wurden und daraus irgendwie (wie genau steht dort leider nicht) ableiten muss welcher Frame 2 Untertyp das jetzt sein soll und wie lang der sein wird. Nun habe ich aber 1 bit in und 0 bit out angegeben für die Prozessdaten also ergeben sich daraus (nach meinen Berechnungen) nur eine Notwendigkeit für Typ-1 Frames für PD und in der FrameCapability hab ich auch explizit gesagt ich will kein SPDU (denn SPDU ist optional), warum also um alles in der Welt wll der mir jetzt ein Typ2 Frame mit SPDU schicken? Bitte helf mir mal auf die Sprünge, was hab ich überlesen?
Hallo, kannst Du mal Deine Wakeup/Startup Sequenz posten – hier sollte nach dem Master- seitigem Zugriff auf die Param- channel – Adressen: 06h, 05h ,04h dann in 03h für die FrameCapabilty irgend sowas wie 02h vom Device zum Master geschickt werden, um in diesem Fall Type1 Frames für mit PHY2 ohne PDU für den zyklischen Betrieb zu initialisieren. Insofern würde es schon verwunderlich sein, wenn der Master Type2 Frames schicken würde
Bernd K. schrieb: > Die Version 1.0 hat kein Inhaltsverzeichnis (nur ein gedrucktes, kein > klickbares). Ein 130 Seiten PDF dieser Art ohne Inhaltsverzeichnis ist > der Horror. Jemandem, der gewohnt ist, jedes PDF Dokument vor der Nutzung erstmal auszudrucken (zu lassen) und ansonsten damit beschäftigt ist, den "Durchbruch in Sachen Kommunikation" mit IO-Link zu verkaufen, fällt das wahrscheinlich nicht mal auf ;-)
42 schrieb: > kannst Du mal Deine Wakeup/Startup Sequenz posten – > hier sollte nach dem Master- seitigem Zugriff auf die Param- channel – > Adressen: 06h, 05h ,04h dann in 03h für die FrameCapabilty irgend sowas > wie 02h vom Device zum Master geschickt werden, um in diesem Fall Type1 > Frames für mit PHY2 ohne PDU für den zyklischen Betrieb zu > initialisieren. für FrameCapability sende ich 0b00000010: siehe mein anderes Posting oben für die ganze page 1.
1 | param_page_1[PARAM_ADDR_FRAME_CAPABILITY] = (1 << 1); // type 1 supported, spdu not supported |
Jetzt hab ich aber beim weiteren Suchen gefunden dass Addresse 17 bei einem SPDU bedeutet IDLE und auf Seite 67, Table 46 steht: "The device always supports a CMD.req (R,SPDU, FlowCTRL=IDLE), even if it does not support any Service PDUs. It responds with CMD.res (NO_SERVICE)." Genau sowas meine ich wenn ich diese Spezifikation als unter aller Sau und einen großen Haufen notdürftig zusammengewürfelten und mit Spucke zusammengeklebten Mist bezeichne. Beim Lesen obiger Zeilen geht mir echt das Messer in der Tasche auf. Man bedenke ich bin im Kapitel 7.2 "Link Layer Protocol" und jetzt werfen die plötzlich mit Bezeichnungen um sich die nirgendwo in diesem Layer oder den darunterliegenden erklärt wurde: Ich soll mit "CMD.res (NO_SERVICE)" antworten, was bitte ist ein "CMD.res()" und wie ist "no_service" definiert? Wenn ichs nicht geraten hätte wüsste ich nichtmal wo man jetzt überhaupt eine Antwort plazieren könnte denn: * es gibt 5 verschiedene Untertypen von Frame 2 und ich muss vor dem Parsen und dann vor dem Antworten "wissen" (raten? ausprobieren?) welcher Untertyp das ist und wieviele Bytes der hat denn im CHECKTYPE byte stehts nicht. Nur wenn ich das weiß kann ich meine Antwort verpacken. * Wie antworte ich auf ein SPDU? Natürlich steht das nicht im Kapitel 7.2 Link Layer Protocol" denn SPDU ist ja ein nachträglich drangeflicktes Protokoll, ein Protokoll im Protokoll sozusagen (hab ich schon erwähnt daß das ein elender Flickenteppich ist) das weil ihnen eh schon bei Frame-typ 2 die Nummern ausgegangen sind (2 bit ought to be enough for anybody) einfach stattdessen über missbrauchte OnRequest Read und Write Aufrufe getunnelt wird, Hier haben wir es also mit Datenstrukturen aus einer höheren Protokollschicht zu tun, jedoch tu ich einfach mal so als wäre das ein normaler OnRequest-Read den ich mit dem OnRequest-Handler behandeln kann und schreibe einfach eine 0 in die Antwort (das wäre der Header für ein SPDU mit Länge 0 und service no_service), vielleicht reicht das schon. * Jetzt ist nur noch ein Problem: Wo kommt die Antwort überhaupt hin? Muss ich mit 1 Byte antworten oder mit 2 oder gar 3? Welcher Untertyp von Frame 2 ist es, ich weiß es immer noch nicht, es steht ja nicht im Header! Der erste der mir hier zeigen kann auf welcher Seite der Spec glasklar definiert ist welcher Frame 2 Untertyp da zu erwarten ist gewinnt eine hohe Auszeichnung und meine Anerkennung! Durch Raten und Ausprobieren hab ich mich mal auf Frame 2.1 festgelegt, vermute daß das bereits der Prozessdatenzyklus ist und antworte einfach mal Pi mal Daumen mit 2 Byte + CHECKSTAT. Ich schreibe die OnRequest-Antwort in Byte 0 und die Prozessdaten in Byte 1. Erneut die Frage: Wo in der Spec steht geschrieben wie der Prozessdatenframe aussieht, und wo steht geschrieben daß er als SPDU-Read mit IDLE daher kommt? Wo? Momentan meckert die IFM-Parametriersoftware (IFM-Container) nicht mehr und ich kann mich mit dem Device verbinden, Prozessdaten werden zyklisch abgefragt und in der GUI ausgegeben. Soweit so gut, jedoch der automatische Scan und Erkennung geht immer noch nicht. (Ich sehe gerade ich habe die MinCycleTime verschludert, da antworte also versehentlich 0 und das könnte falsch sein, aber das muss jetzt mal 4 Tage warten ich muss das erstmal sacken lassen)
Hi, wie sieht denn Deine Device Antwort auf das Paramchannel - CMD "04h" aus ? Falls es sich um ein 1.0 Spec Device handelt, müsste da laut Spec 1.0 S.58 im Major eine "10" und im Minor eine "0" stehen - also: 0b10100000 (Atmel: << 160). Zumindest wäre ich mir nun in diesem Falle sicher, das ausschließlich Type1 Frames erlaubt sind.
42 schrieb: > Hi, > > wie sieht denn Deine Device Antwort auf das Paramchannel - CMD "04h" aus > ? Falls es sich um ein 1.0 Spec Device handelt, müsste da laut Spec 1.0 > S.58 im Major eine "10" und im Minor eine "0" stehen - also: 0b10100000 > (Atmel: << 160). Zumindest wäre ich mir nun in diesem Falle sicher, das > ausschließlich Type1 Frames erlaubt sind. Ähm, moment mal, jetzt bin ich leicht verunsichert. In der Spec steht:
1 | 7.2.2.3.5 IO-Link Revision ID |
2 | The IO-Link Revision ID parameter is the two-digit version number of the IO-Link specification in |
3 | accordance with which the device has been implemented. Its structure is illustrated in Figure 36. |
4 | |
5 | |
6 | |MajorRev | MinorRev| |
7 | [_] [_] [_] [_] [_] [_] [_] [_] |
8 | Figure 36 — IO-Link Revision ID |
9 | |
10 | Bits 0 to 3: MinorRev |
11 | These bits contain the minor digit of the version number, e.g., 0 for IO-Link Version 1.0. |
12 | Permissible values for MinorRev are 0 to 9. |
13 | Bits 4 to 7: MajorRev |
14 | These bits contain the major digit of the version number, e.g., 1 for IO-Link Version 1.0. |
15 | Permissible values for MajorRev are 0 to 9. |
Das interpretiere ich mal so daß ich bei 1.0 dort ein 0b00010000 reinschreiben muss. Wie kommst Du auf 0b10100000? Wie schon gesagt, hier nochmal die komplette Parameter 1 Page meines Devices so wie ich sie vor dem Start initialisiere, mein OnRequest Handler liefert dann die Werte so aus wie ich sie in diesem Array definiert habe:
1 | uint8_t param_page_1[32] = {0}; |
2 | |
3 | [...]
|
4 | |
5 | param_page_1[PARAM_ADDR_FRAME_CAPABILITY] = (1 << 1); // type 1 supported, spdu not supported |
6 | param_page_1[PARAM_ADDR_VENDOR_ID_1] = (uint8_t)(IOLINK_VENDOR >> 8); |
7 | param_page_1[PARAM_ADDR_VENDOR_ID_2] = (uint8_t)(IOLINK_VENDOR); |
8 | param_page_1[PARAM_ADDR_DEVICE_ID_1] = (uint8_t)(IOLINK_DEVICE >> 16); |
9 | param_page_1[PARAM_ADDR_DEVICE_ID_2] = (uint8_t)(IOLINK_DEVICE >> 8); |
10 | param_page_1[PARAM_ADDR_DEVICE_ID_3] = (uint8_t)(IOLINK_DEVICE); |
11 | param_page_1[PARAM_ADDR_FUNCTION_ID_1] = (uint8_t)(IOLINK_FUNCTION >> 8); |
12 | param_page_1[PARAM_ADDR_FUNCTION_ID_2] = (uint8_t)(IOLINK_FUNCTION); |
13 | param_page_1[PARAM_ADDR_IOLINK_REV_ID] = (1 << 4); |
14 | param_page_1[PARAM_ADDR_PROCESS_DATA_IN] = (1 << 6) | 1; // 1 bit process data from device |
15 | param_page_1[PARAM_ADDR_PROCESS_DATA_OUT] = 0; // 0 bit process data to device |
Wie Du siehst ist die Revision-ID bei mir 0b00010000 Was mir allerdings vorhin noch aufgefallen ist da fehlt noch die MinCycleTime, ich kann mich erinnern daß ich dieses Byte an irgendeiner Stelle schonmal zusammengebastelt habe und bin mir jetzt nicht sicher warum das in obigen copy/paste nicht auftaucht, evtl ein Versehen, ich kann das jetzt aber nicht verifizieren, der Code ist 4km entfernt von hier und ich lass ihn dort jetzt erstmal mal 3 Tage ruhen.
Hi in der Spec 1.0 vom Jan 2009 (Order No. 10.002) steht auf Seite 55 “Version ID for the implemented IO-Link specification (shall be set to 10 for this version)”, was allerdings wohl doch laut Seite 58 so zu interpretieren ist, das die "1" die MajorRev und die "0" die MinorRev ist. Ich hatte das dann wohl falsch interpretiert. Dennoch stellt sich die Frage, warum Dein IFM Master einem Spec. 1.0 Device Type 2 Frames schickt - das sollte doch eigentlich so nicht sein. Vielleicht klärt sich das Problem durch eine MinCycleTime > 0.
42 schrieb: > warum Dein IFM > Master einem Spec. 1.0 Device Type 2 Frames schickt - das sollte doch > eigentlich so nicht sein. Rätsel teilweise gelüftet (und neue aufgeworfen): für Prozessdaten wird ein Frametyp ausgesucht der zu der konfigurierten Länge von PD-In und PD-Out passt und das ist ein Frame 2.x, in meinem Fall ein 2.1. Was nicht eindeutig aus der Spec hervorgeht (in diesem Bereich redet sie äußerst kunstvoll um den heißen Brei herum ohne das Kind auch nur ein einziges Mal beim Namen zu nennen) ist wie eine Anforderung von Prozessdaten überhaupt auszusehen hat: Irreführenderweise gibt es einen eigenen Channel (nachzulesen in 7.2.5.3.1 DL Command) der da heißt: 0b00 "Process Data". Der wird aber niemals benutzt. Stattdessen sendet der Master auf dem Channel 0b11 "Service PDU" einen Read-Request und in der Addresse steht dann 0x11 was "FlowCTRL: IDLE" bedeutet und das Device muss dann ins erste OnRequest Byte der Antwort eine 0 reinschreiben was im Kontext einer SPDU soviel bedeutet wie "no service" und das/die Prozessdatenbytes wird mit den Prozessdaten (PD-In) befüllt. Für OnRequest Parameter Read nimmt der Master den Channel 0b01 "Parameter Data" so wie man es erwarten würde (obwohl ich alle paar Frames zwischendurch ein SPDU ignorieren bzw abschmettern muss) und für Parameter Write verhält sich der Master standardkonform. Ich ignoriere jetzt grundsätzlich jeden SPDU-write und ich beantworte jeden SPDU-Read mit "no service". Das erscheint mir die einzig plausible Vorgehensweiuse zu sein. Immerhin hab ich in der FrameCapability explizit mitgeteilt daß SPDU nicht unterstützt word. Der Master den ich hier habe (IFM-"Container" mit USB-IO-link-Dongle) macht jedoch eigenartige Dinge: * Der erste Frame nach DeviceOperate ist ein SPDU-read-IDLE (siehe oben, anscheinend OK) der zweite ist ein SPDU-write-START (Index hab ich vergessen) (WTF???), der dritte und alle folgenden sind wieder SPDU-read-IDLE als wär grad nichts gewesen. Eigentlich sollte man erwarten daß nach einem SPDU-write-START noch die restlichen SPDU-Frames kommen, die kommen aber nie! Nur der eine einsame START. * Beim Parameter Read versucht er alle 4 Bytes mir ein SPDU (welches weiß ich jetzt nicht auswendig) aufzunötigen, dieses ignoriere ich bzw weise es ab, dann liest er 4 Bytes normal über den Parameter Channel im PD Frame. Dummerweise wiederholt er jedesmal 3 von 4 bereits gelesenen Bytes so daß er am Ende jedes Byte 4 mal gelesen hat, ich glaub langsam daß dieser Master ein paar virtuelle Schrauben locker hat. * Wakeup -> Startup -> Operate geht. Prozessdaten werden transportiert, DirectParameter können gelesen und geschrieben werden, lesen geht langsam (wegen oben), schreiben zügig. Aber der Master erkennt das Device nur wenn ich es explizit von Hand in die Topologie hinzufüge, der automatische Scan geht nicht: Wakeup->Startup->Operate (10 Sekunden lang Prozessdaten als wäre alles normal)->Fallback->(0.5 Sekunden Pause)->Wakeup->...etc. Nach 2 Minuten: "Fehler beim Scannen". :-/
>Rätsel teilweise gelüftet (und neue aufgeworfen): für Prozessdaten wird >ein Frametyp ausgesucht der zu der konfigurierten Länge von PD-In und >PD-Out passt und das ist ein Frame 2.x, in meinem Fall ein 2.1. Ab Seite 196 (Annex A - Version 1.1.2 July 2013, Order No: 10.002) der Spec 1.1 scheint der Versuch einer Erklärung unternommen zu sein. Demnach scheint sich der Frametype Master -seitig entweder aus dem Read - Request zu ergeben (wenn eben zwei Octets zu den geforderten Daten gehören, dann werden sie hintereinander gesendet) oder es ist ein Writerequest, der nach dem Checksummenbyte dann die zu schreibenden Octets anhängt. Die Angabe des Frametypes im Startup scheint sich wohl dann ausschließlich nur auf die Prozessdaten (Channel 00h) zu beziehen. Jedenfalls müsste man den UART Teil des Treiber dann wohl so konfigurieren, dass erstmal weitere Octets bis Time_out (wie lange eigentlich ?) abgewartet werden, bevor diese dann einer Auswertung zugeführt werden können. Man weiß wohl nie so genau, wie viele Octets der Master nun diesmal senden wird. Ein erster Hinweis könnten allerdings die zwei Framebits /M-sequence bits vor der Master- Checksumme sein. Jedenfalls sieht die Anfrage des Masters nach PDU Adressen irgendwie so nach Preoperate -Mode aus (also Spec 1.1). >Der wird aber niemals benutzt. Prozessdaten sind doch die eigentlichen Daten, die der Device-Sensor zum Master schicken soll(te) (Spec1.0 Seite 77)- oder nicht ? Jedenfalls deuten die ausbleibenden Anfragen des Masters nach Prozessdaten auch auf einen nicht abgeschlossenen Preoperate - Mode hin. Vielleicht kann man ja die Anfragen einfach mit Daten beantworten (Spec 1.1 S 93/94)
42 schrieb: > Demnach scheint sich der Frametype Master -seitig entweder aus dem Read > - Request zu ergeben (wenn eben zwei Octets zu den geforderten Daten > gehören, dann werden sie hintereinander gesendet) oder es ist ein > Writerequest, der nach dem Checksummenbyte dann die zu schreibenden > Octets anhängt. Ja, das ist soweit klar. Jeder Frametyp existiert in zwei Ausprägungen, einmal als write und einmal als read, die OnRequest Daten sind dann einmal bei den masterseitigen dabei oder bei den deviceseitigen. > Die Angabe des Frametypes im Startup scheint sich wohl > dann ausschließlich nur auf die Prozessdaten (Channel 00h) zu beziehen. > Jedenfalls müsste man den UART Teil des Treiber dann wohl so > konfigurieren, dass erstmal weitere Octets bis Time_out (wie lange > eigentlich ?) abgewartet werden, bevor diese dann einer Auswertung > zugeführt werden können. Man weiß wohl nie so genau, wie viele Octets > der Master nun diesmal senden wird. Der verwendete Transceiver (von HMT in meinem Falle) hat ein Register in dem man den für Typ 1 und 2 jeweils die Anzahl der OnRequest-Bytes und die Anzahl der restlichen Bytes angeben kann, so weiß es nach den ersten 2 Byte wieviele noch kommen werden. > Ein erster Hinweis könnten > allerdings die zwei Framebits /M-sequence bits vor der Master- > Checksumme sein. Ja, das hab ich mittlerweile verstanden, ich hab das alles mal etwas setzen lassen und dabei hat es sich in meinem Kopf langsam in der richtigen Reihenfolge angeordnet und aneinandergefügt, jetzt kann ich das Gesamtbild sehen. Ich fasse mal in eigenen Worten zusammen wie das nach meinem Verständnis funktioniert: * Während des Startup gibt es nur Typ-0 Frames. Hierüber werden die Device-Parameter abgefragt, hierüber wird auch das Master-Command gesendet zum Übergang nach "DeviceOperate". * Während DeviceOperate gibt es ebenfalls nur einen einzigen Frametyp, welcher das ist bestimmt sich aus einer Tabelle in der Spec (hab sie gefunden) und ändert sich niemals während der Laufzeit, es leitet sich aus der Größe der Prozessdaten ab die das Device liefern oder oder konsumieren kann, das ist eine Konstante. Mein spezielles Device braucht also nur insgesamt genau 2 verschiedene Framehandler zu implementieren, einen für Frame 0 und einen für Frame 2.1. > Jedenfalls sieht die Anfrage des Masters nach PDU Adressen irgendwie so > nach Preoperate -Mode aus (also Spec 1.1). > >>Der wird aber niemals benutzt. > > Prozessdaten sind doch die eigentlichen Daten, die der Device-Sensor zum > Master schicken soll(te) (Spec1.0 Seite 77)- oder nicht ? > Jedenfalls deuten die ausbleibenden Anfragen des Masters nach > Prozessdaten auch auf einen nicht abgeschlossenen Preoperate - Mode hin. Doch, ich komme problemlos in den DeviceOperate-Zustand. Bis dahin geht alles wie im Bilderbuch: Der Master fragt die Parameter ab, dann schreibt er seine MastrerCycleTime und dann schreibt er das Kommando DeviceOperate. Bis dahin hat er nur Typ-0 Frames verwendet. Ab jetzt kommen nur noch Typ 2.1 Frames (wie erwartet und zyklisch mit der korrekten Zykluszeit) und die [die Antwort-Hälften dieser Frames] transportieren meine Prozessdaten zum Master und zwischendurch ein paar OnRequest-Daten. Auch das läuft wie erwartet. > Vielleicht kann man ja die Anfragen einfach mit Daten beantworten (Spec > 1.1 S 93/94) Das tue ich ja. Ich beantworte jeden OnRequest-Read wahrheitsgemäß, egal ob er über Frame0 beim Startup kommt oder später über einen 2.1 während Operate (übrigens ich implementiere 1.0 und nicht 1.1). Was ich jedoch nicht beantworten kann sind SPDU-Anfragen. Laut Spec muss ich SPDU-Read-IDLE mit "no service" beantworten. Dies ist auch offenbar auch gleichzeitig die zyklische Anfrage nach Prozessdaten, es ist der Frame 2.1 der alle 3ms (meine Zykluszeit) kommt, es ist ein Read ich habe ein Byte OnRequest und ein Byte Prozessdaten zum Master: * Das OnRequest-Byte fülle ich mit 0 (no service, die Antwort auf das IDLE) * Das Prozessdaten-Byte befülle ich mit meinen Prozessdaten. Und das schluckt der Master, die Prozessdaten kommen dort an und wenn er anstelle von SPDU-Read-IDLE ein Parameter-Read oder Parameter-Write macht dann kommt das ebenfalls an. Das einzige was jetzt noch nicht geht ist das automatische Erkennen des Devices durch diese komische PC-Software ("Es ist ein Fehler aufgetreten") wie gestern beschrieben und was mich ebenfalls verwundert sind diese seltsamen SPDU-Frames (nicht das zyklische SPDU-IDLE sondern die anderen) zwischendurch beim Parameter-Lesen. Ich warte noch auf ein anderes Stück Hardware/Software mit dem ich angeblich meine Implementation hochoffiziell auf Konformität testen kann und wenn mir das bescheinigt daß mein Device-Stack jetzt konform ist dann hab ich was ums den Leuten von ifm um die Ohren hauen zu können. Mal schauen was das andere Teil sagt, zumindest wird es wohl vernünftige Fehlermeldungen ausgeben können.
...Nachdem Du es nun nochmal gepostet hast: >es leitet sich >aus der Größe der Prozessdaten ab die das Device liefern oder oder >konsumieren kann, das ist eine Konstante. ...ist es jetzt bei mir auch angekommen. Was mich nun auch interessieren würde, ist die Checksumme bei einem hypothetischen Aktor- Device, das Type_1 Frames beim Startup vereinbart hat. Die zyklischen Daten sehen dann ja in etwa wie folgt aus pCMP: CMD im Prozesschannel pCMD|CHK| Prozess| Prozess| M------S |CHK* pCMD|CHK| Prozess| Prozess| M------S |CHK* pCMD|CHK| Prozess| Prozess| M------S |CHK* pCMD|CHK| Prozess| Prozess| M------S |CHK* Jetzt kommt ein onRequest – z.B. oRqCMD == PDU_REQUEST. Das Device wird dann vermutlich mit einer Sequenz antworten, die über FlowControl geregelt ist und die in etwa so anfängt: pCMD |CHK| Prozess| Prozess| M------S |CHK* oRqCMD |CHK| Prozess| Prozess| M------S PDUdata|CHK** Mich interessiert nun die Berechnung der Checksummen, die doch recht knapp auf der Spec 1.0 Seite 79 bzw. auf den Spec 1.1 Seiten 195/207 irgendwie beschrieben ist (bei der "Kompression" hat man sich wohl mehr Mühe gegeben) Masterchecksumme: CHK == h52^pCMD^xx000000 Devicechecksumme: CHK* == h52^Prozess^Prozess^xx000000 OnRequestDevicechecksumme: CHK** == h52^Prozess^Prozess^onRequestData^xx000000 Kann man das so stehen lassen ? Ich kann leider nicht auf das HMT...PHY mit eingebauter CHK Berechnung zurückgreifen.
42 schrieb: > Jetzt kommt ein onRequest Es gibt zweierlei Arten von Requests: Die simplen direkten on-Request Parameter, die brauchen nur einen einzigen Frame (entweder ein read-frame oder ein write-frame), dafür existieren aber nur 32 Adressen a 1 Byte und über die Hälfte davon ist schon reserviert für protokollinternes Zeug wie DeviceID und VendorID, CycleTime und dergleichen und nur von 0x10 bis 0x1d hat man noch etwas Platz für eigene gerätespezifische Parameter. Die Prüfsumme ist ein simples xor und dann das Ergebnis nochmal von 8 auf 6 Bit komprimiert, wie steht in der Spec erklärt, ist nicht viel dran, jedes einzelne Bit des 6bit-Ergebnisses ist das xor einiger bits der 8bit-summe. Wenn man damit allein schon auskommt muss man eigentlich nicht weiterlesen, zumindest nicht laut Spec. > Das Device wird > dann vermutlich mit einer Sequenz antworten, die über FlowControl > geregelt ist und die in etwa so anfängt: Der andere Typ von Request (der mit dem FlowCTRL, bei Version 1.0 hießen die noch SPDU, bei 1.1 haben sie sich 4 neue Buchstaben dafür ausgewürfelt (damit es nicht langweilig wird) das ist ein Protokoll im Protokoll. Da wird ein komplettes Telegramm mit etlichen Bytes an das Device geschrieben und das Device antwortet dann mit einem ähnlichen Telegramm. Dieses Telegramm wird Byte für Byte über einen der oben erwähnten 1-Byte-OnRequest-Zugriffe getunnelt. Pro Zyklus 1 Byte, und zwar so: * Zuerst wird das komplette Telegramm des Masters geschrieben (das geschieht mit write frames), in jedem Zyklus schreibt er ein Byte des Telegramms über Kanal 3 (und die Adressbits werden umfunktioniert zu FlowCTRL). Die Prüfsumme ist das letzte Byte, das ist ein simples xor übe alle Bytes des Telegramms. * Jetzt fängt der Master an zu lesen (mit read frames), ebenfalls auf Kanal 3 und bei jedem Lesezugriff des Masters schickt das Device das nächste Byte seines Antworttelegramms. Wie die Telegramme genau aufgebaut sind steht in der Spec. Es gibt verschiedene Formate für diese Telegramme, entweder mit 8bit Index oder mit 16bit Index oder sogar mit zusätzlichem Subindex und wenn das Telegramm länger als 15 Byte ist dann wird die Länge anders kodiert und es gibt nochmal ein extra Byte. Allein der Parser dafür mit seinen ganzen Zuständen ist so groß wie der Code für alle Frame Handler und den OnRequest-Handler zusammen. Wenn das Device das Telegramm geparst hat (das kann entweder ein Read sein, dann will der Master irgendwelche Daten sehen oder ein Write, dann wird das Antworttelegramm nur aus 2 Byte bestehen) stellt das Device ein Antworttelegramm zusammen und wenn der Master dann anfängt auf Kanal 3 einzelne Bytes zu lesen dann schickt es das Antworttelegramm Byte für Byte zurück. Die Prüfsumme für das Antworttelegramm ist ebenfalls ein simples xor über alle Bytes. --- Zu meinem eigentlichen Problem: Es ist wie ich zunächst nicht für möglich gehalten habe: Ich habe zunächst kategorisch ausgeschlossen daß eine so tief in IO-Link involvierte und den Standard mit geprägt habende Firma wie ifm jemals einen in so krasser Weise den Standard verletzenden Master verkaufen könnte und daß ich unbedeutender kleiner Wicht binnen nur 3 Tagen drüber stolpere, das habe ich lange ausgeschlossen und stattdessen eine ganze Woche lang den Fehler bei mir selbst gesucht. Nun habe ich aber auf der Messe ein bisschen mit ifm gesprochen (und auch mit anderen Herstellern) und den Master bei mir auch einigen weiteren gezielten Tests unterzogen mit kurzerhand eigens dafür gebautem behelfsmäßigem Protocol-Analyzer und es stellt sich heraus daß dieses Gerät schlicht und ergreifend eine fehlerhafte Firmware besitzt und den heiligen Standard von IO-Link grob verletzt. Wer hätte das gedacht. Ich kann wieder ruhig schlafen. Mein Stack funktioniert :-)
:
Bearbeitet durch User
Also wenn ich es jetzt richtig verstehe, sendet der Master in etwa folgende Sequenz an ein Aktuator (Output) Device, um SPDU Daten abzufragen (oRqCMD == PDU_REQUEST): pCMD |CHK| Prozess| Prozess| M------S |CHK* pCMD |CHK| Prozess| Prozess| M------S |CHK* oRqCMD |CHK| Prozess| Prozess| M------S PDUdata(1)|CHK* pCMD |CHK| Prozess| Prozess| M------S PDUdata(2)|CHK* * * * pCMD |CHK| Prozess| Prozess| M------S PDUdata(n-1)|CHK* pCMD |CHK| Prozess| Prozess| M------S PDUdata(n)|CHK* pCMD |CHK| Prozess| Prozess| M------S CHK**|CHK* wobei, CHK = comp(h52^pCMD^bXX000000) CHK* = comp(h52^bXX000000) CHK** =comp(h52^PDUdata(1)^PDUdata(2)^...PDUdata(n-1)^PDUdata(n)^bXX000000) comp == Kompression Kann man das jetzt so stehen lassen? >Ich habe zunächst kategorisch ausgeschlossen daß >eine so tief in IO-Link involvierte und den Standard mit geprägt habende >Firma wie ifm jemals einen in so krasser Weise den Standard verletzenden >Master verkaufen könnte und daß ich unbedeutender kleiner Wicht binnen >nur 3 Tagen drüber stolpere, > anderes Stück Hardware/Software mit dem ich >angeblich meine Implementation hochoffiziell auf Konformität testen kann >und wenn mir das bescheinigt daß mein Device-Stack jetzt konform ist < Welches Gerät eignet sich denn besser, als der von IFM favorisierte (http://www.ifm.com/products/de/ds/E30396.htm) Master? Kannst Du etwas empfehlen ?
Liebe IO-Link Freunde ich verwende den USB Master von TMG. Funktioniert prima und scheint die Spezifikation zu erfüllen. Kostet allerdings 500€. Gruß Bernd
42 schrieb: > Kann man das jetzt so stehen lassen? Ich bin mir nicht sicher bei Deiner Notation bzgl der SPDU Anfgrage. Ich sehe in dem was Du gepostet hast keine Anfrage. Der Master würde OnReqest schreiben um sein Anfrage-Telegramm zum Device zu schreiben, da wären also neben den Prozessdaten noch zusätzlich OnRequest-Bytes vom Master zum Device, so lange bis das Telegramm beim Device ist, dieser OnRequest findet auf Channel 3 statt. Danach fängt er auf Channel 3 an zu lesen solange bis er das Antworttelegramm vom Device zum Master gelesen hat. In der Spec ist ein kompletter Mitschnitt eines SPDU (oder ISDU wie das neuerdings heißt) abgedruckt. > Welches Gerät eignet sich denn besser, als der von IFM favorisierte > (http://www.ifm.com/products/de/ds/E30396.htm) Master? Kannst Du etwas > empfehlen ? Das ist der den ich habe, der wird aber nicht von ifm "favorisiert", der wird noch solange stillschweigend (wohl wissend um die Bugs) verhökert bis keine mehr da sind oder bis es keiner mehr kauft. Der von ifm favorisierte ist wohl anscheinend der E30390 (250€). Einem der ifm-Vertriebler ist die Bemerkung rausgerutscht sie [ifm Vertrieb] "sollen das alte Kabel [E30396] nicht mehr verwenden, das geht nicht gescheit [sinngemäß], nur noch das neue [E30390]". Ein anderer meinte: "Scannen wird nur vom E30390 unterstützt, nicht vom E30396" <-- Bullshit! Natürlich wird Scannen "unterstützt" (in dem Sinne daß es der Wizard beim Start anbietet und es nicht ausgegraut ist und auch keine dementsprechende Meldung kommt), es versucht ja auch zu scannen, sogar richtig hart und richtig lange, nur endet das dann irgendwann mit ner irreführenden Fehlermeldung weil das Teil nicht gescheit funktioniert!
:
Bearbeitet durch User
>In der Spec ist ein kompletter Mitschnitt eines SPDU (oder ISDU wie das >neuerdings heißt) abgedruckt. Ja den habe ich auch gesehen (Spec1.0 Page 123 of 134). Da mir das Ganze etwas unklar ist, werde ich es mal in die von mir gewählte Notation für ein hypothetisches Aktordevice übertragen: pCMD |CHK| Prozess| Prozess| M------S |CHK* pCMD |CHK| Prozess| Prozess| M------S |CHK* //SPEC1.0 Page 100 ++ WoRqCMD_FlCtrl_h10 |CHK| Prozess| Prozess| SERVICE | M------S |CHK* WoRqCMD_FlCtrl_h01 |CHK| Prozess| Prozess| LENGHT | M------S |CHK* WoRqCMD_FlCtrl_h02 |CHK| Prozess| Prozess| INDEX | M------S |CHK* WoRqCMD_FlCtrl_h03 |CHK| Prozess| Prozess| SUBINDEX | M------S |CHK* (WoRqCMD_FlCtrl_h03 |CHK| Prozess| Prozess| DATA | M------S |CHK*) WoRqCMD_FlCtrl_h04 |CHK| Prozess| Prozess| CHK** | M------S |CHK* RoRqCMD_FlCtrl_R |CHK| Prozess| Prozess| M------S | BUSY |CHK* * * RoRqCMD_FlCtrl_ |CHK| Prozess| Prozess| M------S | BUSY |CHK* RoRqCMD_FlCtrl_h10 |CHK| Prozess| Prozess| M------S | SERVICE |CHK* RoRqCMD_FlCtrl_h01 |CHK| Prozess| Prozess| M------S | ????? |CHK* RoRqCMD_FlCtrl_h02 |CHK| Prozess| Prozess| M------S | PDUdata(1) |CHK* RoRqCMD_FlCtrl_h03 |CHK| Prozess| Prozess| M------S | PDUdata(2) |CHK* * //other requests may interrupt this transfer * RoRqCMD_FlCtrl_h0X-1|CHK| Prozess| Prozess| M------S| PDUdata(n-1) |CHK* RoRqCMD_FlCtrl_h0X |CHK| Prozess| Prozess| M------S| PDUdata(n) |CHK* RoRqCMD_FlCtrl_h0X |CHK| Prozess| Prozess| M------S| CHK*** |CHK* pCMD |CHK| Prozess| Prozess| M------S| CHK* pCMD |CHK| Prozess| Prozess| M------S| CHK* wobei, pCMD -> command prozess channel WoRqCMD_FlCtrl_hXX -> Write on request command with flowcontrol _hXX RoRqCMD_FlCtrl_hXX -> Read on request command with flowcontrol _hXX CHK = comp(h52^pCMD^bXX000000) or CHK = comp(h52^ XoRqCMD_FlCtrl_hXX ^bXX000000) CHK* = comp(h52^bXX000000) CHK** = comp(h52^SERVICE^LENGTH^INDEX^SUBINDEX^(DATA^)^bXX000000) CHK*** =comp(h52^ SERVICE ^?????^ PDUdata(1)^PDUdata(2)^...PDUdata(n-1)^PDUdata(n)^bXX000000) comp == Kompression Kann man das so stehen lassen ? In der Spec 1.0 Page 123 of 134 ist bei cycle 12 ein gelb hinterlegtes 00010110 zu finden – soll das die LENGTH sein ? (SPEC1.0 page 104)
42 schrieb: > In der Spec 1.0 Page 123 of 134 ist bei cycle 12 ein gelb hinterlegtes > 00010110 zu finden – soll das die LENGTH sein ? (SPEC1.0 page 104) In dem von Dir erwähnten Cycle 12 in dem Mitschnitt (das ist das zweite Byte des Telegramms) steht die Länge. Das Erste Feld (Cycle 11, Orange markiert) ist "Service" und das ist kodiert wie auf Seite 102 + 103 beschrieben: Die oberen 4 bit stehen in Tabelle 78 und die unteren 4 bit sind die Länge. Also bedeutet 0b11010001 den service 1101 und die Länge 0001 1101 ist "Read Response (+) lasut Tabelle 78 0001 ist Länge 1. [edit] STOP ZURÜCK da steht 0xD und das ist "Read Response (-)", also ein Fehler, jedoch sollte er dann nicht mit Daten antworten. Da soll wahrscheinlich 0xC stehen, also 0b11000001. Diese bedauernswerten Geschöpfe sitzen den ganzen Tag (Vollzeit!) da auf ihrem Abstellgleis (wahrscheinlich noch bis zu ihrer Rente) und werden in ihrem Leben nichts anderes mehr machen als immer neue barocke Schnörkel und Ein- und Ausbuchtungen anzufügen mit jeder neuen Revision weil sich immer noch irgendwo 2 unbenutzte Bits finden über die sich noch eine neue Monstrosität (in 42 verschiedenen Variationen) durchtunneln lässt für irgendein absurdes Feature nach dem keiner gefragt hat, nur um der Spec nochmal weitere 200 Seiten hinzufügen zu können aber einen simplen Analyzer-Mitschnitt fehlerfrei in das PDF rüberzukopieren das schaffen sie nicht! [/edit] Länge 1 hat jedoch eine Sonderbedeutung (sonst wärs ja langweilig), sie bedeutet daß die Länge nicht in 4 bit passen würde und deshalb ein zusätzliches Längenbyte eingeschoben wird, das ist dann das von Dir erwähnte im Cycle 12, das gelbe 0b00010110 welches bedeutet die eigentliche Länge ist 22 Bytes also verbleiben ab hier noch 20 Bytes zu lesen, also in dem Beispiel Data1 bis Data19 und CHKPDU. Das mit der Extra-Länge bei Längen>15 funktioniert identisch für Masterseitige als auch Deviceseitige Telegramme. Ebenfalls die Prüfsumme CHKPDU die ist einfach ein simples xor über alle Bytes, also in diesem Beispiel über alle Bytes von Service bis Data19. > CHK = comp(h52^pCMD^bXX000000) or > CHK = comp(h52^ XoRqCMD_FlCtrl_hXX ^bXX000000) > CHK* = comp(h52^bXX000000) > CHK** = comp(h52^SERVICE^LENGTH^INDEX^SUBINDEX^(DATA^)^bXX000000) > CHK*** =comp(h52^ SERVICE ^?????^ > PDUdata(1)^PDUdata(2)^...PDUdata(n-1)^PDUdata(n)^bXX000000) Könnte hinkommen, habs nicht nachgerechnet, probiers doch einfach mal aus. Ich weiß nicht ob die 2 anderen Bits des CHKTYPE oder CHKSTAT auch noch mit eingehen, in der Spec steht einfach nur "all UART characters", also evtl schon. Ist halt wie schon gesagt ein grottig schlecht beschriebenes vollkommen chaotisches Dokument das versucht ein ebenso chaotisches planloses Protokoll zu beschreiben. Da ist viel Ausprobieren angesagt.
:
Bearbeitet durch User
>...aber einen simplen Analyzer-Mitschnitt fehlerfrei in das PDF >rüberzukopieren das schaffen sie nicht! So ein >simpler Analyzer-Mitschnitt wäre sicher sehr informativ.
42 schrieb: > So ein >>simpler Analyzer-Mitschnitt > wäre sicher sehr informativ. Hier will der Master einen Parameter per ISDU auslesen. Es ist der index 64 (0x40), kein Subindex. Das Gerät antwortet mit einem ISDU-Telegramm das den uint16_t Wert 42 beinhaltet (immer big endian).
1 | WRITE 70 A1 93 00 2D Typ:2 CHAN:03 ADDR:10 OREQ:93 "?" |
2 | WRITE 61 B0 40 00 2D Typ:2 CHAN:03 ADDR:01 OREQ:40 "@" |
3 | WRITE 62 8C D3 00 2D Typ:2 CHAN:03 ADDR:02 OREQ:D3 "?" |
4 | READ F0 85 D4 00 1B Typ:2 CHAN:03 ADDR:10 OREQ:D4 "?" |
5 | READ E1 80 00 00 2D Typ:2 CHAN:03 ADDR:01 OREQ:00 "?" |
6 | READ E2 B0 2A 00 0A Typ:2 CHAN:03 ADDR:02 OREQ:2A "*" |
7 | READ E3 A1 FE 00 3C Typ:2 CHAN:03 ADDR:03 OREQ:FE "?" |
Mein Frametyp während OPERATE ist typ2.1, ich habe 1 Byte PD vom Device zum Master, null Byte vom Master zum Device. PD ist hier in diesem beispiel immer 0x00. Im nächsten beispiel der selbe Parameter (index 64, uint16_t) vom Master auf das Device geschrieben. Der geschriebene Wert ist 23. Das Device antwortet 0x52 was soviel bedeutet wie (WriteResponsePositive << 8) | 2 Die Länge der Antwort ist 2 und man sieht schön wie das Prüfsummenbyte den selben Wert hat wie das eintige andere Byte da ja simples xor.
1 | WRITE 70 BA 15 00 2D Typ:2 CHAN:03 ADDR:10 OREQ:15 "?" |
2 | WRITE 61 B0 40 00 2D Typ:2 CHAN:03 ADDR:01 OREQ:40 "@" |
3 | WRITE 62 98 00 00 2D Typ:2 CHAN:03 ADDR:02 OREQ:00 "?" |
4 | WRITE 63 BF 17 00 2D Typ:2 CHAN:03 ADDR:03 OREQ:17 "?" |
5 | WRITE 64 92 42 00 2D Typ:2 CHAN:03 ADDR:04 OREQ:42 "B" |
6 | READ F0 85 52 00 00 Typ:2 CHAN:03 ADDR:10 OREQ:52 "R" |
7 | READ E1 80 52 00 00 Typ:2 CHAN:03 ADDR:01 OREQ:52 "R" |
Übrigens hab ich noch mal in die Spec geschaut und mit der 1.1 verglichen, es sieht so aus als ob der Mitschnitt richtig ist aber dafür ist die Tabelle auf Seite 103 falsch jedoch die Tabelle auf Seite 101 ist richtig.
:
Bearbeitet durch User
@NichtSoSchnell Du kennst ja IO-Link auswendig, immerhin hast Du ja schon Slave und sogar Master² implementiert, könntest Du bitte so nett sein und mir kurz erklären was eigentlich passieren soll wenn das Device ein ISDU-Telegramm mit ungültiger CHKPDU erhält? Bitte die Antwort auch begründen mit einem Zitat aus der Spezifikation. Danke! _____________ ²) Master impliziert ja bekanntlich 100% mandatory, also alles von Seite 1 bis 261 plus 100% Rückwärtskompatibel zu ALLEM von v1.0, also kennst Du beide Dokumente wie Deine Jackentasche von der ersten bis zur letzten Seite und hast alle Unklarheiten aufgelöst, keine Fragen mehr offen, deshalb wende ich mich mit meiner Frage an Dich als den hiesigen IO-Link Experten.
Bernd K. schrieb: > (WriteResponsePositive << 8) | 2 (WriteResponsePositive << 4) | 2 muss das heißen, sorry.
@Bernd: Danke fürs posten der Readouts. Ich bin auch schon sehr gespannt, was @NichtSoSchnell denn antworten wird.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.