www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Mal was neues: IO-Link


Autor: Delta (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Delta (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
... wow, das ist Weltpremiere! Niemand der ne Ahnung zu einem Thema hat 
das ich poste.. irgendwie cool, aber sehr schade

Autor: Bastler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
die Spezifikationn ist noch gar nicht so lange draußen!

Schau mal wieviel Geräte es mit dieser Schnittstelle schon gibt!

Autor: Delta (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was nicht ist...

Autor: Hans Josef (hjm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Patrick B. (p51d)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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...

Autor: Bastler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: NichtSoSchnell (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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?

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: 7x7-7=42 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ?

Autor: NichtSoSchnell (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. ...

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
    param_page_1[PARAM_ADDR_FRAME_CAPABILITY] = (1 << 1);   // type 1 supported, spdu not supported
    param_page_1[PARAM_ADDR_VENDOR_ID_1] = (uint8_t)(IOLINK_VENDOR >> 8);
    param_page_1[PARAM_ADDR_VENDOR_ID_2] = (uint8_t)(IOLINK_VENDOR);
    param_page_1[PARAM_ADDR_DEVICE_ID_1] = (uint8_t)(IOLINK_DEVICE >> 16);
    param_page_1[PARAM_ADDR_DEVICE_ID_2] = (uint8_t)(IOLINK_DEVICE >> 8);
    param_page_1[PARAM_ADDR_DEVICE_ID_3] = (uint8_t)(IOLINK_DEVICE);
    param_page_1[PARAM_ADDR_FUNCTION_ID_1] = (uint8_t)(IOLINK_FUNCTION >> 8);
    param_page_1[PARAM_ADDR_FUNCTION_ID_2] = (uint8_t)(IOLINK_FUNCTION);
    param_page_1[PARAM_ADDR_IOLINK_REV_ID] = (1 << 4);
    param_page_1[PARAM_ADDR_PROCESS_DATA_IN] = (1 << 6) | 1;    // 1 bit process data from device
    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?

Autor: 42 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Wolfgang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;-)

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.
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)

Autor: 42 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
7.2.2.3.5 IO-Link Revision ID
The IO-Link Revision ID parameter is the two-digit version number of the IO-Link specification in
accordance with which the device has been implemented. Its structure is illustrated in Figure 36.


                               |MajorRev      |      MinorRev|
                               [_] [_] [_] [_] [_] [_] [_] [_]
                              Figure 36 — IO-Link Revision ID

Bits 0 to 3: MinorRev
These bits contain the minor digit of the version number, e.g., 0 for IO-Link Version 1.0.
Permissible values for MinorRev are 0 to 9.
Bits 4 to 7: MajorRev
These bits contain the major digit of the version number, e.g., 1 for IO-Link Version 1.0.
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:
uint8_t param_page_1[32] = {0};

[...]

    param_page_1[PARAM_ADDR_FRAME_CAPABILITY] = (1 << 1);   // type 1 supported, spdu not supported
    param_page_1[PARAM_ADDR_VENDOR_ID_1] = (uint8_t)(IOLINK_VENDOR >> 8);
    param_page_1[PARAM_ADDR_VENDOR_ID_2] = (uint8_t)(IOLINK_VENDOR);
    param_page_1[PARAM_ADDR_DEVICE_ID_1] = (uint8_t)(IOLINK_DEVICE >> 16);
    param_page_1[PARAM_ADDR_DEVICE_ID_2] = (uint8_t)(IOLINK_DEVICE >> 8);
    param_page_1[PARAM_ADDR_DEVICE_ID_3] = (uint8_t)(IOLINK_DEVICE);
    param_page_1[PARAM_ADDR_FUNCTION_ID_1] = (uint8_t)(IOLINK_FUNCTION >> 8);
    param_page_1[PARAM_ADDR_FUNCTION_ID_2] = (uint8_t)(IOLINK_FUNCTION);
    param_page_1[PARAM_ADDR_IOLINK_REV_ID] = (1 << 4);
    param_page_1[PARAM_ADDR_PROCESS_DATA_IN] = (1 << 6) | 1;    // 1 bit process data from device
    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.

Autor: 42 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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". :-/

Autor: 42 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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)

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: 42 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...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.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: 42 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ?

Autor: Bernd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: 42 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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)

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: 42 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>...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.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).
WRITE   70 A1 93    00 2D       Typ:2 CHAN:03 ADDR:10 OREQ:93 "?"
WRITE   61 B0 40    00 2D       Typ:2 CHAN:03 ADDR:01 OREQ:40 "@"
WRITE   62 8C D3    00 2D       Typ:2 CHAN:03 ADDR:02 OREQ:D3 "?"
READ    F0 85    D4 00 1B       Typ:2 CHAN:03 ADDR:10 OREQ:D4 "?"
READ    E1 80    00 00 2D       Typ:2 CHAN:03 ADDR:01 OREQ:00 "?"
READ    E2 B0    2A 00 0A       Typ:2 CHAN:03 ADDR:02 OREQ:2A "*"
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.
WRITE   70 BA 15    00 2D       Typ:2 CHAN:03 ADDR:10 OREQ:15 "?"
WRITE   61 B0 40    00 2D       Typ:2 CHAN:03 ADDR:01 OREQ:40 "@"
WRITE   62 98 00    00 2D       Typ:2 CHAN:03 ADDR:02 OREQ:00 "?"
WRITE   63 BF 17    00 2D       Typ:2 CHAN:03 ADDR:03 OREQ:17 "?"
WRITE   64 92 42    00 2D       Typ:2 CHAN:03 ADDR:04 OREQ:42 "B"
READ    F0 85    52 00 00       Typ:2 CHAN:03 ADDR:10 OREQ:52 "R"
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
Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernd K. schrieb:
> (WriteResponsePositive << 8) | 2

(WriteResponsePositive << 4) | 2

muss das heißen, sorry.

Autor: 42 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Bernd: Danke fürs posten der Readouts.

Ich bin auch schon sehr gespannt, was @NichtSoSchnell denn antworten 
wird.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.