Hallo, ich muss ein kleines Subset von IO-Link Masterseitig implementieren, im Wesentlichen benötige ich folgendes: * einen Brocken Hardware der die physikalische Schicht halbwegs funktionsfähig implementiert * ich muss ein Wakeup erzeugen können um den Transceiver auf der anderen Seite in den IO-Link Mode zu versetzen * Dann muss ich nachdem ich dem Gerät mitgeteilt habe daß jetzt mein proprietärer Werksjustagespezialmodus beginnt beliebige Daten relativ direkt (halbwegs transparent) halbduplex unter Umgehung aller IO-Link Protokolle austauschen können. Und das wars auch schon, mehr muss das PC-seitig nicht können. Geräteseitig macht mir das keine Sorgen, der oben angesprochene Spezialmodus der sich als komplett eigenständiges Programm im Gerät befindet kann mit seinem IO-Link Transceiver machen was ich will, das hab ich im Griff. Was mir fehlt ist obige Masterseitige Hardware die ich halbwegs low-level (oder halbwegs direkt genug) ansteuern kann und ich habe eigentlich keine Lust erst noch welche zu bauen, sowas muss es doch fertig geben (also links USB und rechts IO-Link und ein schönes Gehäuse drum rum)? Ich habe da zum Beispiel so einen USB-IO-Link Adapter der Firma ifm herumliegen, für den scheint aber null Dokumentation zu existieren, der funktioniert nur mit seiner eigenen proprietären ifm Software und als Briefbeschwerer taugt er auch nicht, dazu wiegt er leider nicht genug. Er stellt zwar einen virtuellen Com-Port zur Verfügung aber das undokumentierte Protokoll das er darüber spricht ist binär und sehr obskur und bis ich das reverse-engineered habe bin ich in Rente. Das ist mir dann doch zu blöd. Also welche käuflich erwerblichen IO-Link Master gibt es die sich auch von eigener Software relativ unkompliziert ansprechen lassen und die erlauben einerseits normales IO-Link und andererseits bei Bedarf auch eine transparente Kommunikation am IO-Link-Stack vorbei durchzuführen? Notfalls bin ich sogar bereit meine Daten häppchenweise durch protokollgerechte IO-Link Frames zu tunneln wenns nicht anders geht aber ich muss zumindest in der Lage sein den Adapter mit eigener Software ansprechen und ausreichend kontrollieren zu können. Wäre sehr dankbar wenn mir jemand nen Fingerzeig in die richtige Richtung geben könnte.
Ich würde hier mal anrufen: http://www.tmgte.de/ Die können Dir sicher gegen den richtigen Geldbetrag weiterhelfen. Die haben einen Master-Stack und sicher auch gleich noch Hardware dazu. Die meisten Parametirergeräte am Markt sind von denen. Ih kenne kein Gerät, dass deine Anforderungen direkt erfüllt. Ist aber auch schon 2 Jahre her, dass ich mich mit der Materie beschäftigt habe. Aber auf Anhieb hab ich grad nichts gefunden. Grüße Oliver
Ich hab noch das hier gefunden: http://www.iq2-development.de/iqinterface-das-io-link-interface-am-markt/ kostet vierstellig :-/ Ich glaub ich bau mir selber was zusammen. Da muss nicht viel mehr rein als ein durchschnittlicher µC mit USB, ein IO-Link Transceiver und ein ein paar Zeilen Code und fertig ist das Teil.
Bernd K. schrieb: > Ich glaub ich bau mir selber was zusammen. Da muss nicht viel mehr rein > als ein durchschnittlicher µC mit USB, ein IO-Link Transceiver und ein > ein paar Zeilen Code und fertig ist das Teil. Wollte ich Dir auch vorschlagen, aber Basteln hattetst Du ja halbwegs ausgeschlossen. Ich hab damals den MAX14824 benutzt, weil es der einzig frei am Markt verfügbare MasterIC war. Das gibts auch ein Dev-Kit. Hab ganz gute Erfahrungen damit gemacht. Grüße Oliver
Oliver Ju. schrieb: > aber Basteln hattetst Du ja halbwegs > ausgeschlossen. Naja, wenns für 100€ was gegeben hätte hätt ich nichts gesagt, von mir aus auch noch 200€ wenn ordentliche Doku dabei ist, ne ordentliche API und ein bisschen Beispiel-Code, Kabel und Stecker, das kann man noch rechtfertigen bei der gesparten Zeit fürs selber Bauen aber Programmieraufwand fällt so oder so an und auch Einarbeitung in deren API und da kommt schon der Bereich wo man genauso schnell oder schneller selber was zusammengebaut hat. Ich hätt zwar gern was gekauft, aber nicht zu jedem Preis, und auch nichts wovon 95% wahrscheinlich eh unnütz¹² sind. _______ ² ich brauch nur eine Schnittstelle zum PC, keine 3 verschiedenen gleichzeitig. ¹ mit irgendwelchen klicki-bunti GUI-Apps kann ich nix anfangen das braucht kein Mensch und treibt nur die Kosten in die Höhe, ich brauch nur ein API, da wird programmiert und nicht geklickt.
http://www.mouser.de/ProductDetail/Maxim-Integrated/MAX14824EVKIT/?qs=sGAEpiMZZMtKiEBa%2fXu9%252bHfqDlP1Behm sowas? die software dazu wäre auch aus deutschem hause... oder die software [1] von IFM direkt, ob da jeweils apis bei sind, bzw darunter liegen... wer weiß ^^, aber anfragen kostet ja nix. das "kleine" kabel [2] ist mit 122€ auch noch relativ erschwinglich... (im gegensatz zu dem usb-master [3] mit 250€) letzteres gibts auch im gleichen referenzdesign von den mitbewerbern (P+F, Balluff usw...) preise sind netto vermutlich ^^ [1] http://www.ifm.com/products/de/ds/E30110.htm [2] http://www.ifm.com/products/de/ds/E30396.htm [3] http://www.ifm.com/products/de/ds/E30390.htm
Steven M. schrieb: > http://www.mouser.de/ProductDetail/Maxim-Integrate... > sowas? Ja, den hab ich auch schon ins Auge gefasst. Seit meinem ursprünglichen Posting ist viel Zeit ins Land gegangen, ich bin bereits 2 Schritte weiter. Mittlerweile kenne ich die IO-Link Spezifikation in und auswendig und kann die notwendigen Abläufe und Zusammenhänge auf Layer 1 und 2 bis ins letzte Detail vorwärts und rückwärts runterbeten (bin gerade dabei ein Buch drüber zu schreiben damit es nicht wieder verloren geht), ich habe nun einen vollständigen Device-Stack incl. Hardware, einen funktionsfähigen Master, der Master ist noch etwas frickelig und nicht mit der endgültigen Hardware, ich benutze dort (noch) einen Transceiver von CreativeChips ("könnten Sie mir bitte sagen wo ich das Datenblatt finden kann?" - "wozu brauchen Sie das?"). Bei näherer Betrachtung brauch ich deren Chip tatsächlich nicht. Ich brauch eigentlich nur nen kurzschlussicheren und schnellen Level-Shifter auf 24V und nen billigen Microcontroller. Ich habe nebenher mit diesem improvisierten Master mittlerweile auch einen Device-Tester gebaut der alle vorgeschriebenen Testcases von Layer 2 aufwärts abfahren kann, so weiß ich nun daß mein Device-Stack tatsächlich funktioniert. Da ich dort auch korrupte M-Sequenzen erzeugen können muss wird masterseitig alles bis kurz vor dem UART eh in Software gemacht, ich brauch also eigentlich kein fertiges ASIC für Framing und Prüfsumme, das muss ich eh in Software machen, ist aber auch trivial. Der oben genannte MAX14824 (natürlich ohne das Demo-Board drumherum) ist schon in der engeren Wahl. > oder die software [1] von IFM direkt, ob da jeweils apis bei sind, bzw > darunter liegen... wer weiß ^^, aber anfragen kostet ja nix. > das "kleine" kabel [2] ist mit 122€ auch noch relativ erschwinglich... > (im gegensatz zu dem usb-master [3] mit 250€) > letzteres gibts auch im gleichen referenzdesign von den mitbewerbern > (P+F, Balluff usw...) > preise sind netto vermutlich ^^ > > [1] http://www.ifm.com/products/de/ds/E30110.htm > [2] http://www.ifm.com/products/de/ds/E30396.htm > [3] http://www.ifm.com/products/de/ds/E30390.htm [2] hab ich hier, das Gerät ist Schrott, ein API dafür gibt es auch nicht, nur ne fertige Parametriersoftware die leidlich funktioniert und vollgestopft ist mit Werbung(!) und Firmenlogos für zwei Dutzend Hersteller aus dem Konsortium. Dieser Master ist entgegen der irreführenden Bezeichnung "IO-Link" nicht IO-Link konform, Events kann er gar nicht, ISDU ist fehlerhaft implementiert und ab und zu haut er Frames mit falschen Prüfsummen raus. IFM weiß davon daß das Gerät ihre eigenen [des Konsortiums] Test-Cases nicht besteht, trotzdem verkaufen sie ihn munter weiter. FINGER WEG von diesem Schrott, das ist keine Hilfe beim Entwickeln oder Test eigener Geräte und dafür ist es auch nicht gedacht, es soll wohl nur zu IFM-Geräten kompatibel sein, damit deren Vertriebler den Sensor mal kurz vorführen kann wenn er grad keine ausgewachsene SPS in seinem Köfferchen dabei hat. Über [3] kann ich nichts sagen, laut IFM soll er angeblich besser sein aber auch dafür gibt es laut Auskunft von denen kein API, das einzige wären tatsächlich die Geräte von TMG oder IQ² und noch einen dessen Name mir gerade entfallen ist. Jedoch sind diese 4-stellig kostenden Teile eher für die Entwicklung und den Compliance test gedacht, nicht für den rauen Einsatz in der Produktion (Werkskalibrierung, Funktionstests, Firmwareupdates). IO-Link konforme Devices zu entwickeln ist wahrhaftig nichts für schwache Nerven oder kleine Garagen-Startups und selbst wenn man Zeit im Überfluss hat und 52 Wochenenden reinsteckt kann man trotzdem locker mal einen fünfstelligen Betrag einplanen den das Konsortium als Mindesthürde davor gesetzt hat NUR für das Protokoll-Compliance-Geraffel mit obszön überteuerte Test-Devices und anscheinend soll in Zukunft die Schraube eher noch fester angezogen werden damit ja nicht noch mehr kleine Hersteller auf die Idee kommen "mal eben" IO-Link fähige Devices zu bauen. Naja, immerhin bin ich nun einer der weltweit geschätzt maximal zwei dutzend Personen die die Spec tatsächlich vollständig gelesen und den IO-Link Protokollstack vollständig verstanden und mindestens einmal komplett mit allen Features selbst implementiert haben, immerhin etwas.
Bernd K. schrieb: > Seit meinem ursprünglichen > Posting ist viel Zeit ins Land gegangen, ich bin bereits 2 Schritte > weiter. hmm, seh ich jetzt auch... naja, war spät... > "könnten Sie mir bitte sagen wo ich das > Datenblatt finden kann?" - "wozu brauchen Sie das?" (^^,) > [2] hab ich hier, das Gerät ist Schrott, ein API dafür gibt es auch > nicht, nur ne fertige Parametriersoftware die leidlich funktioniert und > vollgestopft ist mit Werbung(!) und Firmenlogos für zwei Dutzend > Hersteller aus dem Konsortium. ich glaube, für mehr ist beides auch nicht gedacht... sensor vorbereiten, rausgehen, einbauen... > Über [3] kann ich nichts sagen, laut IFM soll er angeblich besser sein > aber auch dafür gibt es laut Auskunft von denen kein API, das einzige > wären tatsächlich die Geräte von TMG oder IQ² und noch einen dessen Name > mir gerade entfallen ist. Jedoch sind diese 4-stellig kostenden Teile > eher für die Entwicklung und den Compliance test gedacht, nicht für den > rauen Einsatz in der Produktion (Werkskalibrierung, Funktionstests, > Firmwareupdates). > > IO-Link konforme Devices zu entwickeln ist wahrhaftig nichts für > schwache Nerven oder kleine Garagen-Startups und selbst wenn man Zeit im > Überfluss hat und 52 Wochenenden reinsteckt kann man trotzdem locker mal > einen fünfstelligen Betrag einplanen den das Konsortium als Mindesthürde > davor gesetzt hat NUR für das Protokoll-Compliance-Geraffel mit obszön > überteuerte Test-Devices und anscheinend soll in Zukunft die Schraube > eher noch fester angezogen werden damit ja nicht noch mehr kleine > Hersteller auf die Idee kommen "mal eben" IO-Link fähige Devices zu > bauen. tja wenn man sensoren im mittleren 3stelligen bereich verkaufen will, muss man den markt irgendwie schützen ;) ich hatte naiver weise mal auf eine bibliothek gehofft, aber das wird wohl eher nix werden... > Naja, immerhin bin ich nun einer der weltweit geschätzt maximal zwei > dutzend Personen die die Spec tatsächlich vollständig gelesen und den > IO-Link Protokollstack vollständig verstanden und mindestens einmal > komplett mit allen Features selbst implementiert haben, immerhin etwas. ^^
Hallo nur mal so da der thread schon ziemlich alt ist. Ich habe mich vor ca.1Jahr mit IO-LINK beschäftigt. Da ich viel mit den Devices aus Esslingen-Berkheim zu tun habe brauchte ich eine Lösung um die Dinger einfach zu Testen (ohne Parameter einstellung).Auf dem Markt gab es nichts was ich brauchen konnte. Ich habe deswegen einen Master mit mit Software gebaut. Als Transceiver habe ich einen MAX14824 der func ganz gut. Dieser wird über einen FTDI2232 mit Daten gefüttert. Der Master-Stack läuft auf WIN,Linux und Android. Android deswegen da ich bei der Prüfung frei beweglich sein muss. Mein Ziel ist es einen Adapter zu bauen der per Bluetooth(LE) oder Wifi(ESP8266 als AP)ohne MCU die Kommunikation übernimmt. Wie seht ihr die chance dass das funktioniert. ms
ms schrieb: > um die Dinger einfach zu Testen (ohne Parameter > einstellung).Auf dem Markt gab es nichts was ich brauchen konnte. > Ich habe deswegen einen Master mit mit Software gebaut. Genau das habe ich nun auch gemacht. Im Wesentlichen muss man eigentlich nur einen 24V (Mark=0 und Space=24V) Halbduplex UART bauen, den Rest kann man komplett in Software implementieren. Ich hab mir dann in Object Pascal (für Lazarus/FPC weil damit alle unsere PC-Tools und Software gebaut werden) eine Unit gebaut die den masterseitigen Protokollstack inclusive ISDU und Events vollständig implementiert und darauf aufbauend sowas wie einen Device-Tester "light" um die wichtigsten Tests aus der Test-Spec abzutesten. Darüber hinaus kann ich das jetzt auch verwenden um meine eigenen Devices zu parametrieren und auch meine eigenen undokumentierten (nicht in der IODD aufgeführten) Werks-Parameter zu lesen oder zu schreiben. Das einzige wirklich zeitkritische Element bei IO-Link ist die Antwortzeit des Device die binnen maximal 10 Bitzeiten erfolgen muss, aber das muss mich ja auf PC-Seite nicht kümmern, wenn ich am PC die Antwort erst 50ms später (wegen USB Roundtrip etc.) bekomme kann mir das Schnuppe sein, an das Timing des Masters werden keine so strengen Anforderungen gestellt (zumindest nicht von meinen eigenen Devices). Die nächste Version des Masters die ich bauen will wird einen µC mit USB beinhalten (dann fällt der FTDI weg) und dann werde ich weite Teile des Masterstacks in den µC verlagern (Wakeup-Prozedur, Prozessdatenzyklus), dann werde ich auch mit dem Master das Timing auf die Millisekunde genau einhalten können und muss nicht mehr so viel über USB hin und her schaufeln. Wenns fertig ist kann ichs dann wohl auch für nen hohen dreistelligen Betrag anbieten, denn es gibt ja bislang weltweit nur zwei Mitbewerber und die rufen beide gesalzene vierstellige Beträge auf für ein kleines Kästchen mit einem µC, einem 3.3V/24V Levelshifter und einer API um das Ding anzusteuern. Ich muss halt ne halbe Größenordnung unter dem Preis bleiben weil es kein Zertifikat vom Konsortium hat und nur als Mess- und Prüf-Hilfsmittel dienen kann (und soll).
oh der Beitrag wird doch noch gelesen.. Ich habe RadStudio Seattel zu verfügung um meinen Master zu schreiben. Ich denke ich werden jetzt doch die Masterplatine mit einem XMega und BT900 oder ESP8266 bauen. Das Backend bekommt noch einen XML-Parser damit ich die IODD einlesen und die richtige Form anzeigen kann. Bilder von der IODD ist schön brauch ich aber nicht. ISDU habe ich bis jetzt noch nie gebraucht wichtig sind für mich nur die ProzessDaten. Anbieten werde ich meinen Master nicht bin aber gerne bereit meine Erfahrung auszutauschen. Ich habe auch noch das Maintenance-Tool von FESTO auf Android portiert und mit einem BL900 versehen. Auch da gab es nichts auf dem Markt um eine CPX-Insel schnell und unkompliziert zu prüfen.Auch da bin ich bereit infos auszutauschen. ms
Ich möchte in meinem aktuellen Projekt ein RGB-Sensor mit IO-Link-Schnittstelle einsetzen. Die Steuerungssoftware läuft aktuell auf einem ATmega128 (soll zukünftig ggf. auf einem STM32 laufen). Nachdem man das Rad nicht nochmal erfinden muss, würde ich gerne für dieses Projekt deine IO-Link Mastersoftware einsetzen. Hast du die SW-Implementierung auf einen uC mit USB-Schnittstelle schon abgeschlossen? Eine Zertifizierung benötige ich nicht. Hast du schon einen Preis für deine HW/SW festgelegt?
Meinrad H. schrieb: > würde ich gerne für > dieses Projekt deine IO-Link Mastersoftware einsetzen Es existiert noch keine dedizierte Hardware/Firmware, es ist immer noch mehr oder weniger ein Provisorium das genau auf meine Zwecke zugeschnitten ist. Daher hat es auch noch keinen Preis (wenn überhaupt jemals). Einen vollständigen Master zu implementieren (der auch die entsprechende Test-Spec bestehen würde, der jeden kleinen schrägen Winkel und Erker der Protokollspezifikation beherrscht) wäre eine Lebensaufgabe für jemanden der sonst keinen anderen Aufgaben mehr zusätzlich erledigen muß und der gleichzeitig so schmerzbefreit ist daß er den intensiven Kontakt mit dieser Technologie ohne Antidepressiva und Agressionsblocker durchstehen kann. So weit haben die das mittlerweile aufgebloatet. Deshalb kann man die Hersteller von zertifizierten Mastern auch an einer Hand abzählen, und das war wahrscheinlich auch die Intention. Auch an mir ist die intensive Beschäftigung mit diesem Protokollstapel nicht ohne Risse und tiefe Krater in meiner Seele zu hinterlassen vorbeigegangen. Ich bin nicht mehr der selbe wie vorher. Wer IO-Link benutzen will ohne durch diese sieben Kreise der Hölle zu gehen kauft sich am besten irgendwas fertiges von Siemens oder Konsorten und bezahlt jemanden der das zusammenstöpselt und konfiguriert. So haben die das vorgesehen, so muss man das wohl machen. Für ein einzelnes (hoffentlich simples) Gerät kann man sich (nachdem man obige Erfahrungen bereits hinter sich hat) auch mit dem ATmega mit überschaubarem Aufwand was zusammenhacken was dann halt genau mit diesem einen aber sonst keinem anderen Gerät sprechen kann. Es gibt zwei Abstufungen von Einfachheit: ohne ISDU: einfach mit ISDU: etwa doppelter Aufwand Häng mal die IODD-Datei von dem Ding hier an daß man einen Blick drauf werfen kann.
:
Bearbeitet durch User
In meinem Fall geht es um den gleichen Sensor, welcher über IO-Link mit dem ATmega kommunizieren soll. Die IODD-Datei, sowie das IO-Link Datenblatt für diesen Sensor habe ich angehängt. Es besteht kein Bedarf einen vollständigen Master zu implementieren. Ich sollte vielleicht noch sagen, dass ich bzgl. IO-Link keinerlei SW-Erfahrung bis jetzt gemacht habe. Da auch meine Zeit beschränkt ist, und ich nicht vorhabe, durch die die Hölle zu gehen, versuche ich auf diesem Weg die Erfahrung/Hilfestellung/... anderer zu nutzen. DANKE!!!!
Angehängte Dateien:
-
Type-0-Sequence.png
57 KB
OK. Wir brauchen also ISDU. Das verdoppelt den Aufwand aber geht trotzdem noch. Wie gesagt, ich hab nichts fertiges das ich verkaufen könnte und ich müsste mich mit dem Sensor mehrere Wochen hinsetzen (Vollzeit) um dafür eine Lib mit einem API für den Atmega (oder für einen beliebigen µC) zu schreiben. Dafür hab ich aber im Moment absolut keine Ressourcen mehr frei. Wieviel Zeit hast Du? Wieviel Geld hast Du? Als erstes brauchen wir die IO-Link spec, V1.1.2: https://io-link.com/de/Download/Download.php https://io-link.com/share/Downloads/Spec-Interface/IOL-Interface-Spec_10002_V112_Jul13.pdf Als nächstes brauchst Du Hardware mit der Du eine halbduplex UART-Verbindung mit 24V-Pegel (und zwar invertiert: Ruhepegel=0V und Startbit=24V) durchführen kannst und schnell genug für 38400 Baud. Entweder diskret aufbauen oder fertige nehmen, zum Beispiel MAX14824. Der Max hat eine SPI-Schnittstelle mit der er konfiguriert werden kann (Pulldown einschalten, verschiedene Einstellungen, Pegel und Modi) und eine UART-Schnittstelle die direkt an den Pegelwandler durchgereicht wird der die C/Q-Leitung treibt. Beim Start wird der Max also einmalig konfiguriert, danach läuft alles über RX/TX, TXEN, WUEN. Ich bin mir nicht hundertprozentig sicher ob die Defaultkonfiguration schon ausreicht so daß man sich das SPI sparen kann. Ich würds sicherheitshalber anschließen. Softwareseitig musst Du es zunächst schaffen die Wakeup-Prozedur durchzuführen und danach erfolgreich Typ-0 Sequenzen lesend und schreibend zu übertragen. Wenn Du das geschafft hast kannst Du schonmal ein Faß aufmachen denn ein wichtiges Zwischenziel ist erreicht, Du weißt dass die Hardware funktioniert und von nun an ist es nur noch Software. Typ-0 Frame: Anhang A, A.2.2, Bild A.5 Wakeup: Kapitel 5.3.3.3 Die Spec ist ein bisschen zäh zu lesen und maximal chaotisch organisiert. Ich weiß nicht was die sich dabei gedacht haben so einen chaotischen verklausulierten Scheiß hinzurotzen anstatt es einfach und prägnant hinzuschreiben und ein bisschen zu strukturieren, denn an sich ist das Protokoll recht simpel aber die Dokumentation ist gequirlte Hühnerkacke hoch 3! Falls einer mitliest vom Konsortium: Stellt endlich einen ein der ordentlich strukturierte Protokolldokumentationen schreiben kann und nicht so einen unsagbar verkorksten Scheiß abliefert! Der Wakeup ist letztendlich ein Kurzschluss definierter kurzer Dauer auf der C/Q-Leitung während das Gerät im SIO-Zustand ist, gefolgt von einer Pause, gefolgt von einer Typ-0 Leseoperation, wenn das Gerät antwortet befindest Du Dich erfolgreich im Protokollzustand STARTUP. Du kannst in diesem Zustand ohne Zeitdruck beliebige weitere Typ-0 Lese- oder Schreiboperationen ausführen, sogar ISDU kannst Du da schon machen (ISDU ist ein Protokoll im Protokoll, es werden längere Telegramme über wiederholtes Schreiben oder Lesen des OD-Bytes getunnelt, die ganzen Parameter die man einstellen kann die in dem obigen PDF aufgezählt sind werden alle per ISDU gesetzt oder gelesen). Das Bild im Anhang zeigt wie Typ-0 Sequenzen aussehen. Jede Sequenz gibt es in zwei Varianten, einmal lesend und einmal schreibend, der Unterschied ist ein Bit im CKT-Byte. Der Master sendet 2 oder 3 Bytes und das Device antwortet 2 oder 1 Byte. Das weiße OD ist das zu lesende oder zu schreibende Byte. Für die einzelnen Bits in den farbigen Bytes und die Prüfsumme bitte die Spec konsultieren. Das Device weiß in welchem Zustand es sich befindet (STARTUP, PREOPERATE, OPERATE) und welcher Sequenztyp da jeweils nur zum Einsatz kommt, weiß also nach den ersten zwei Bytes wieviele noch kommen werden, deshalb ist da keine Länge mit einkodiert. Danach schickt es binnen maximal 10 Bitzeiten die Antwort, je nachdem ob es lesen oder Schreiben war mehr oder weniger viele Bytes. Bei Typ-1 oder Typ-2 Sequenzen ist es ganz genau das selbe, nur können da mehr als 1 OD-byte und auch noch Prozessdaten in die eine und/oder andere Richtung dabei sein (in der Spec sind Bilder davon). Die Länge der Sequenzen in jedem Zustand ist hart kodiert für jedes Gerät und geht aus der IODD-Datei hervor, deshalb haben diese Sequenzen auch kein Längenfeld sondern nur Typ und Read/Write-Bit. Weil es pro Gerätetyp hart kodiert ist kann man sich vieles einfacher machen wenn man nur ein einziges Gerät unterstürzt. Sag Bescheid wenn Du an diesem Punkt (STARTUP, Typ-0) bist, dann gehts weiter mit * Übergang in die Zustände PREOPERATE und OPERATE * Type-2 Sequenzen und zyklischer Prozessdatenaustausch * ISDU
:
Bearbeitet durch User
Angehängte Dateien:
-
sequence-types.png
53 KB -
mc.png
140 KB -
ckt.png
83 KB -
cks.png
300 KB
Im Anhang nochmal ne Übersicht über die möglichen Sequenztypen und die Bedeutung der Bytes und Bits. Anders als ich oben irrtümlich gesagt habe ist das R/W-Flag im MC-Byte und nicht im CKT-Byte. Wenn die Prüfsumme der masterseitigen Hälfte der Sequenz (CKT) nicht korrekt ist darf das Device NICHT antworten, es wird komplett ignoriert. Wenn das Gerät also partout nicht antworten will ist wahrscheinlich Deine Prüfsummenberechnung falsch. Wenn Du in OPERATE bist und eine Type-0 Sequenz sendest darf das Gerät NICHT antworten aber gleichzeitig MUSS es auch nach STARTUP zurückfallen, eine zweite Type-0 Sequenz würde dann also wieder beantwortet (weil es jetzt ja in STARTUP ist und nur in STARTUP gibt es Type-0 Sequenzen)! Aber der korrekte Wechsel zwischen diesen Zuständen erfolgt normalerweise mit den entsprechenden Mastercommands. Mit dem bisher gesagten solltest Du also schonmal in der Lage sein von SIO nach STARTUP zu kommen (Wakeup) und dort beliebige Type-0 Sequenzen zu vollführen, zum Beispiel mal die Parameter page auslesen (Kanal 1 (Page), Adressen 0..15). Die Adressen 16..31 sind gerätespezifisch und können Konfigurationsparameter enthalten, bei Deinem Gerät aber nicht denn Dein Gerät verwendet dafür ISDU und wenn ein Gerät ISDU verwendet soll es NICHT auch noch zusätzlich die zweite Seite (16..31) der Parameterpage benutzen. An diesen Adressen wirst Du also nur Nullen auslesen oder undokumentierten Datenmüll. Kanal 1 (Page): Adressen 0..15 aka "Direct Parameter Page 1" (alle Geräte gleiche Bedeutung, siehe Annex B, Table B.1) Adressen 16..31 aka "Direct Parameter Page 2" (gerätespezifisch) Also versuch mal so weit zu kommen die Page 1 auszulesen. Dann hast Du schon mal ein gewaltiges Zwischenziel, einen ganz fetten Meilenstein erreicht!
:
Bearbeitet durch User
Angehängte Dateien:
So wie im Anhang sieht eine Type-0 Sequenz aus, dann hast Du schon mal
zwei Testvektoren für die Prüfsummenberechnung, das müsste reichen:
8 Bit, Parity-even, 1 Stop, 38400 Baud, Mark ist 0V, Space ist 24V.
Der Master sendet
0xa2 (MC):
* lesen
* Kanal: 1 (Page)
* Adresse: 2 (Minimum Cycle Time)
0x00 (CKT):
* Sequenz-Typ: 0
* Prüfsumme: 0 (ja, tatsächlich!)
Dann wird er hochohmig und das Gerät antwortet sofort (< 10tBit):
0x32 (OD):
* 5 Millisekunden (kodiert als 0x32, siehe Anhang B.1.3)
0x3c (CKS):
* kein Event in der Event-Queue
* Prozessdaten sind gültig
* Prüfsumme: 0x3c
Die beiden Master-Bytes oben kannst Du genau so wie sie sind an jedes
beliebige Device schicken das sich in STARTUP befindet und es wird
antworten.
:
Bearbeitet durch User
Hallo Bernd, gibt es von Ihnen schon ein Buch zu dem Thema IO-Link ? Ich hätte Interesse dran ! Mit freundlichen Grüßen Josef
P.Wienzek / J.R. Uffelmann IO-Link Intelligente Geräte brauchen einfache Schnittstellen Olenbourg Industrieverlag
Bernd K. schrieb: > Die Spec ist ein bisschen zäh zu lesen und maximal chaotisch > organisiert. Ich weiß nicht was die sich dabei gedacht haben so einen > chaotischen verklausulierten Scheiß hinzurotzen anstatt es einfach und > prägnant hinzuschreiben und ein bisschen zu strukturieren, denn an sich > ist das Protokoll recht simpel aber die Dokumentation ist gequirlte > Hühnerkacke hoch 3! > > Falls einer mitliest vom Konsortium: Stellt endlich einen ein der > ordentlich strukturierte Protokolldokumentationen schreiben kann und > nicht so einen unsagbar verkorksten Scheiß abliefert! Hahaha! Ich arbeite in einem Unternehmen, welches IO-Link Devices herstellt. Ich kann dir kopfnickend zustimmen. Die Spezifikation ist wirklich schrott. Ich gehe sogar soweit, dass die meisten Entwickler (und ich) IO-Link gar nicht vollständig verstanden haben. Die Basics sind natürlich klar. Wir haben einen IO-Link Stack und wissen damit umzugehen. Deine Ausführungen haben zumindest bei mir noch einmal ein "Aha, so ist das also" beschert. Danke dafür
Hallo Zusammen, vielen Dank für die informativen Beiträge! Ich implementiere auch gerade eine IO-Link Schnittstelle und bin beim Auslesen von Page1 über M-Sequence TYPE_0 angekommen. Und das war ein harter Weg!!! Jetzt muss ich Parameter per ISDU auslesen und setzen (wie im IODD File beschrieben). Die Doku ist wirklich fürchterlich. Sowas unübersichtliches habe ich noch nicht gesehen. Frage: Habt Ihr ISDU schon umgesetzt? Falls ja: Gibt es eine VERSTÄNDLICHE Erklärung, wie man Parameter über ISDU ausliest und setzt? Es wäre echt super, wenn mir jemand dabei helfen könnte. Bzw. einen Tip geben könnte. Vielen dank und schöne Grüße, Andreas
Hallo Möchtest Du den Stack komplett selber schreiben? Ansonsten sollte doch Doku vom Stack vorhanden sein. Wenn man bedenkt, dass alle Tests für die Herstellererklärung erfüllt werden müssen, scheint mit das selber schreiben des Stacks nicht effektiv. Zumindest sollte ein Testmaster mit Software vorhanden sein.
Hallo Boris, ich möchte nicht den ganzen Stack schreiben. Ich benötige nur einen kleinen Teil davon. Alles was ich tun möchte, ist die Parameter eines Sensors (von BAUMER) auszulesen und zu setzen. M-Sequence-TYPE0 habe ich umgesetzt. Page1 kann ich auslesen und beschreiben. Jetzt muss ich per ISDU die Standard Variablen (wie im IODD-File von BAUMER beschrieben) abholen und beschreiben. Ich habe es mit einer M-Sequence TYPE2 probiert (wie es auch im Beispiel "Example sequence of an ISDU transmission" beschrieben ist). Leider bekomme ich keine Antwort vom Sensor. Vielleicht muss ich den mode irgendwie von STARTUP auf z.B. PREOPERATE umstellen. Ich habe aber keine Ahnung wie. Und wie Bernd K. schon geschrieben hat, ist die Doku dazu eine Katastrophe!!! Ich bräuchte eigentlich nur jemand, der mir sagen kann, welche I-Services ich beschreiben/nutzen muss, um an die ISDU Variablen zu kommen. Über Hilfe wäre ich sehr dankbar!
Andy N. schrieb: > Alles was ich tun möchte, ist die Parameter eines > Sensors (von BAUMER) auszulesen und zu setzen. Dafür gibt es doch USB Master, wo alles implementiert ist.
Boris schrieb: > Dafür gibt es doch USB Master, wo alles implementiert ist. Und genau das will/muss ich umgehen. Weil es für den Kunden nicht sinnvoll ist.
An alle die hier über die IO-Link Spec. meckern. Habt ihr schon mal die PN- oder CIP-Spec. gelesen? Ich denke nicht, sonst würdet ihr nicht sowas vom Stapel lassen. ;-) Die IOL-Spec. ist der reinste Segen dagegen.
Hallo, der Thread ist zwar schon etwas älter, hier der Beitrag zum Thema von meiner Seite: Ich habe ein Erweiterungsboard für den Raspberry Pi entwickelt, mit dem sich IO-Link-Geräte anbinden lassen. Die Hardware verwendet einen MAX14819 IO-Link Master Transceiver, der über SPI angebunden ist. Zusätzlich habe ich den Open-Source I-Link Master Stack von RT-Labs (https://github.com/rtlabs-com/i-link) erweitert, sodass er Standalone arbeitet und über einen TCP-Socket in die Nutzer-Applikation eingebunden werden kann. Die Lösung kommt ohne zusätzlichen Prozessor aus, der Stack läuft direkt auf dem Raspberry. Die API ist recht einfach gehalten (Kommandos: Port ein/aus, Prozessdaten, Parameter-Daten lesen/schreiben, Status), sodass IO-Link Kenntnisse eigentlich gar nicht erforderlich sind. Ich habe dazu ein Demo-Video erstellt: https://youtu.be/7FeneSIWimo Mit dem Projekt habe ich mich bei CrowdSupply beworben und bin akzeptiert worden (und habe aus Haftungsgründen eine UG gegründet). Falls euch das Projekt gefällt, würde es mich freuen, wenn ihr die Kampagne abonniert (dann geht es mit dem Projekt auch weiter): https://www.crowdsupply.com/pinetek-networks/iol-hat Vielleicht hilft der Ansatz dem einen oder anderen weiter, wenn es um die Integration von IO-Link in diverse Projekte geht, ohne einen externen Master zu nutzen.
Andreas L. schrieb: > mit dem sich IO-Link-Geräte anbinden lassen. Hallo Andreas, das hört sich interessant an. Wen Du jetzt noch den Profinet Device stack von RT-Labs ans laufen bekommst, dann Hast Du einen echten IOL-Master mit Profinet Anbindung (Industrie Standard).
Andreas L. schrieb: > Vielleicht hilft der Ansatz dem einen oder anderen weiter, wenn es um > die Integration von IO-Link in diverse Projekte geht, ohne einen > externen Master zu nutzen. Hut ab, alles sehr hübsch, insbesondere auch das Demo-Video! Die Links werde ich mir ablegen, das nächste IO-Link Projekt kommt bestimmt. Das mit dem HAT ist gut, allerdings wollen viele nicht mit dem RPI (aufgrund der SD Card Thematik) sondern mit einem CM4 (mit EMMC) Modul arbeiten. Daher wäre es bestimmt gut, wenn es andere Schnittstellen gäbe, z.B. auch USB.
Hi, vielen Dank für die Rückmeldungen! >Wenn Du jetzt noch den Profinet Device stack von RT-Labs ans laufen bekommst, dann Hast Du einen echten IOL-Master mit Profinet Anbindung Solche Lösungen gibt es von den großen Hersteller ja bereits ausreichend, das war daher nicht wirklich das Ziel >Das mit dem HAT ist gut, allerdings wollen viele nicht mit dem RPI (aufgrund der SD Card Thematik) sondern mit einem CM4 (mit EMMC) Modul arbeiten. Die Lösung funktioniert prinzipiell auch mit dem CM4 (getestet). Hierzu gibt es eine zweite Variante des IOL HAT ohne 40-pin GPIO, dafür mit einer generischen Schnittstelle (SPI, Interrupt und Logikspannung). Infos dazu gibt es hier (PT-1202): https://www.pinetek-networks.de/iol-hat Damit das Projekt umgesetzt wird und die Hardware dann auch verfügbar wird wenn es ans nächste Projekt geht bräuchte ich noch ein paar Subscriber für die Kampagne: https://www.crowdsupply.com/pinetek-networks/iol-hat
Angehängte Dateien:
-
scope_1.png
38 KB -
scope_2.png
42 KB
Hallo, mit großem Interesse habe ich den Thread gelesen. Besonders die Beiträge von Bernd K. haben mir weitergeholfen. Vielen Dank dafür! Ich möchte von einem Durchflussmesser (IODD siehe Anhang) die Messwerte per IO-Link abfragen. Nicht mehr und nicht weniger. Meine Hardware läuft (mit dem MAX14824) und ich kann in der Startup Phase beliebige Werte aus der direct Parameter Page (DPP) abrufen. Die Daten, welche ich zurück bekomme sind sinnvoll bzw. stimmen mit denen aus dem Datenblatt überein. Also gehe ich davon aus, dass meine Kommunikation grundlegend schon einmal funktioniert. Weiterhin kann ich auch in den Operate Modus schalten (der Wechsel zwischen den Modi funktioniert indem man an die Adresse 0 der DPP das entsprechende Kommando schreibt (Master-Command). Das wurde auch in einem vorigen Beitrag von Andy N. gefragt.). Das Device quittiert mir den Wechsel in Operate mit einem 0x2D - also für mich in Ordnung soweit. Wenn ich dann allerdings die Prozessdaten abrufen möchte bekomme ich keine Antwort. Das ist die Stelle an der ich hänge und für den Moment nicht mehr weiter weiß. Könnte mir jemand noch eine Tip geben? Für das Lesen der Prozessdaten sieht meine Anfrage so aus: MC = 0x80 (Read Access, comm. channel Process, Address = 0) CKT = 0xAD (M-sequence Type 2, Checksumme) Passt das so für Frame Type_2_V? Prozessdaten oder OD möchte ich ja nicht senden, sondern nur PD lesen. Oder muss das Device vorher noch einen anderen Befehl bekommen, was evtl. aus dem IODD hervorgeht? Die Master Cycle Time habe ich in die DPP geschrieben mit 10 ms.
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.