Moins, Hat jemand die Spezifikation davon zur Hand und kann bitte weiterhelfen ? Zum Rest der Telegrammstruktur habe ich Infos gefunden, nur zum Starbyte nichts, in dem u.a. auch short oder long address mode festgelegt wird. Danke ;-), tom.
Tomas Kuckenburg schrieb: > Starbyte Starbyte Express? [...](war Käse) mfg mf PS: Achso, HART, die Kommunikation über 4..20mA. Äh, der zweite Gockel-Treffer(http://www.google.com/search?q=hart+message+frame&hl=de) scheint was zu enthalten: http://www.samson.de/pdf_en/l452en.pdf
...danke, da steht alles drin AUSSER startbyte Format :-( glaubst Du ich würde hier posten, wenn es mit gurgel so einfach zu finden wäre ??? aber trotzdem danke, tom.
Beschreibe mal dein Problem genauer! Ich habe in meiner Diplomarbeit einen Transmitter mit HART-Protokoll entwickelt - kann dir also bestimmt helfen, verstehe aber die Frage nicht so genau mit dem "Start-Byte" - so etwas gibt es nämlich nicht. Wenn geht es ja eher um den Delimiter, also das Byte nach den 5 Preamblen. Man findet im Netz schon ne Menge, aber das ersetzt halt nicht die HART-Protocol-Specifications, die aber einen Haufen Kohle kosten. Die durchzuarbeiten macht aber auch keinen Spaß, da sie dicker als ne Bibel sind...
Nabend, LuXXuS 909 schrieb: > Beschreibe mal dein Problem genauer! Ich habe in meiner Diplomarbeit > einen Transmitter mit HART-Protokoll entwickelt - kann dir also bestimmt > helfen, verstehe aber die Frage nicht so genau mit dem "Start-Byte" - so > etwas gibt es nämlich nicht. > > Wenn geht es ja eher um den Delimiter, also das Byte nach den 5 > Preamblen. Genau, je nach Sprachgebrauch Delimiter oder anderswo auch auch start byte genannt. > > Man findet im Netz schon ne Menge, aber das ersetzt halt nicht die > HART-Protocol-Specifications, die aber einen Haufen Kohle kosten. Die > durchzuarbeiten macht aber auch keinen Spaß, da sie dicker als ne Bibel > sind... Na ja, das HART-Protokoll in OSI-Schicht 2 selbst ist ja nicht so komplex zu implementieren, wenn man täglich mit UDS, KWP, CANxxxxx, Flexray, usw. zu tun hat :-), aber das ist ja für jeden auch immer ein anderer Blickwinkel. Wäre supi wenn Du mir in folgenden Punkten bitte weiterhelfen könntest: 1. Kannst Du die Codierung/Struktur vom Delimiter byte mal posten ? 2. Kann das Senden einer Burst-Message vom Master per Telegramm auf einem Slave gestartet und auch wieder gestoppt werden, oder wie läuft das normalerweise ab ? 3. Die checksum ist einfach uint8 aufsummiert ohne preamble bytes mit 8-bit Breite und dann = summe XOR 0xff zum bitweisen invertieren, oder ? wikipedia hat da noch irgendwas mit +1... schnickschnack bei longituxxx checksum parat, sieht mir aber eher nach mumpitz aus in dem Fall. Liege ich da richtig ? 4. Kennst Du eine PC-Software, die ich praktikabel als HART Master zur slave-protokoll Inbetriebnahme nutzen kann ? 5. Oder ein HART-Protokoll log, wo exemplarisch Verbindungsaufbau und paar Abfragen vom Slave drin sind ? Am besten 1x mit short addressing mode und einmal mit long. Herzliche Grüsse, tom.
Morgen Tomas! Also... Tomas Kuckenburg schrieb: > 1. Kannst Du die Codierung/Struktur vom Delimiter byte mal posten ? Ich beziehe mich auf die HART-Revision 7 (die aktuellste)! Das Delimiter-Feld legt ja fest, um welchen Frame-Typ es sich handelt und ist folgendermaßen aufgebaut:
1 | MSB LSB |
2 | --- --- --- --- --- --- --- --- |
3 | | | | | | | | | | |
4 | | | | | | | | | | |
5 | --- --- --- --- --- --- --- --- |
6 | | _______ _______ ___________ |
7 | | | | | |
8 | | | | |___ Frame Typ |
9 | | | | 1: BACK (Burst-Frame) |
10 | | | | 2: STX (Master -> Slave) |
11 | | | | 6: ACK (Slave -> Master) |
12 | | | | |
13 | | | |_____________ Physical Layer |
14 | | | 0: Asynchron (Standard FSK-HART) |
15 | | | 1: Synchron (z.B. PSK Phase-Shift-Keying) |
16 | | | |
17 | | |_____________________ Zahl der Expansions-Bytes (bis dato immer 0) |
18 | |
|
19 | |___________________________ Adress-Typ |
20 | 0: Polling-Adresse (1 Byte) |
21 | 1: Unique-ID (5 Byte) |
Die Adressierung mit nur einem Adress-Byte ist ausschließlich für das Kommando 0 zulässig - alle anderen Komandoanfragen mit 1-Byte-Adressierung müssen vom Slave ignoriert werden. Wird Kommando 0 mit nur einem Byte angefragt, dann wird auch nur mit einem Byte Adresse geantwortet - dieses Kommando ist ja nur zum herausfinden der Long-ID gedacht. Wurde einmal Kommando 0 zu einem Slave gesendet, so wird i.d.R. ab dann nurnoch im Long-Frame-Format gearbeitet. Tomas Kuckenburg schrieb: > 2. Kann das Senden einer Burst-Message vom Master per Telegramm auf > einem Slave gestartet und auch wieder gestoppt werden, oder wie läuft > das normalerweise ab ? Ja, der Master kann den Slave in den Burst-Modus versetzen und auch wieder da raus holen. Aber es kann natürlich keine laufende Übertragung abgebrochen werden, da es sich ja um Halb-Duplex handelt und die Leitung erst wieder frei sein muss, aber ich denke, das ist klar. Tomas Kuckenburg schrieb: > 3. Die checksum ist einfach uint8 aufsummiert ohne preamble bytes mit > 8-bit Breite und dann = summe XOR 0xff zum bitweisen invertieren, oder ? > wikipedia hat da noch irgendwas mit +1... schnickschnack bei longituxxx > checksum parat, sieht mir aber eher nach mumpitz aus in dem Fall. Liege > ich da richtig ? Die Checksumme beeinhaltet alles zwischen Preamblen und Checksumme - sie beginnt also mit dem Delimiter und endet nach dem letzten Datenbyte. Die Checksumme ist einfach ein XOR mit jedem Byte. Diese Checksumme kann am Ende entweder mit der übertragenen verglichen werden, oder du kannst die übertragende mit der selber generierten wieder XORn und es muss 0 rauskommen. Diese Prüfung stellt die longitudinale Parität dar - die vertikale Parität für jedes Datenbyte muss seperat überprüft werden, aber diese Funktion bietet i.d.R. jeder uC in seinem UART. Tomas Kuckenburg schrieb: > 4. Kennst Du eine PC-Software, die ich praktikabel als HART Master zur > slave-protokoll Inbetriebnahme nutzen kann ? Ja, ich kann dir den FrameAlyst von Borst-Automation empfehlen: http://borst-automation.com/products/products.htm Als Testversion kannst du sie 30 oder 50 mal öffnen oder so. Während sie auf ist, kannst du sie benutzen, so lange du willst (Zum Glück, in der vorherigen Version war es anders, da konnte man das Programm öffnen so oft man wollte, musste es aber nach 10 Übertragungen stets neu starten). Das Programm sieht auf den ersten Blick recht unscheinbar aus, du kannst mit ihm aber wirklich alles machen, was du brauchst. Dazu musst du dir mal die Doku durchlesen - gerade die Funktion mit beliebigen Frames ist sehr hilfreich, um deinen Parser auf Fehler zu überprüfen. Klick dich da mal durch die einzelnen Funktionen, das Programm zeigt dir auf jeden Fall alles nötige an, auch die Zeiten, die die Übertragung gedauert hat, was nicht ganz unwichtig ist, da der Slave ja im TimeOut bleiben muss. Ansonsten gibt es auch PACTWare, wo es bei ICS mal eine Testversion von einer Generic-HART-DTM gab: http://www.icsgmbh.de/deutsch/sensorsoft/dtm5.htm Mit der kannst du auch einiges machen, aber generell ist es mit Software rar gesäht, da bei HART halt alles ziemlich teuer ist...:-\ Tomas Kuckenburg schrieb: > 5. Oder ein HART-Protokoll log, wo exemplarisch Verbindungsaufbau und > paar Abfragen vom Slave drin sind ? Am besten 1x mit short addressing > mode und einmal mit long. Den Log wirst du im FrameAlyst selber sehen, wenn deine Übertragung klappt - wenn nicht, dann kann ich dir auch mal ein paar Übertragungen schicken, muss ich mal meinen Transmitter rauskramen. Gruß
Moins, Super + Danke !!! >> 2. Kann das Senden einer Burst-Message vom Master per Telegramm auf >> einem Slave gestartet und auch wieder gestoppt werden, oder wie läuft >> das normalerweise ab ? > Ja, der Master kann den Slave in den Burst-Modus versetzen und auch > wieder da raus holen. Aber es kann natürlich keine laufende Übertragung > abgebrochen werden, da es sich ja um Halb-Duplex handelt und die Leitung > erst wieder frei sein muss, aber ich denke, das ist klar. Läuft das prinzipiell so ? Burst starten: Burst Request vom Master per Burst bit im AD byte und in der message dann das CMD mit gewünschter Device-Variable ? Und der slave sendet ab dann die burst frames mit dem BACK bit im SD gesetzt ? Burst stoppen: Request vom Master ohne Burst bit im AD byte und in der message dann das CMD mit gewünschter Device-Variable ? Und der slave stoppt ab dann die burst frames und antwortet mit normaler response ? Alle infos sind mir willkommen, Danke. Ja, den BorstAlyser habe ich mir gerade angeschaut, als Du die Antwort geschrieben hast ;-), gibt halt wirklich nicht viel in der Richtung. Gibt es noch weitere Besonderheiten wie das packed ASCII format usw. ? Gibt es bei HART etwa auch segmentierte Nachrichten (wenn die 25 data bytes nicht ausreichen) ? btw, HART ist schon witzig, kein konsistentes message format (short vs. long address, master vs. slave mit status bytes), da "freut" sich der Implementierer, aber ist schon gemacht. So ist das manchmal bei den historisch gewachsenen Dingen, hinterher wissen es immer alle besser ;o). Herzliche Grüsse, Tom.
Tomas Kuckenburg schrieb: > Läuft das prinzipiell so ? > Burst starten: > Burst Request vom Master per Burst bit im AD byte und in der message > dann das CMD mit gewünschter Device-Variable ? > Und der slave sendet ab dann die burst frames mit dem BACK bit im SD > gesetzt ? Nein, so geht das nicht. Es gibt spezielle Kommandos zum Starten und Stoppen der Burst-Telegramme. Der Master setzt niemals das Burst-Bit in seiner Anfrage. Tomas Kuckenburg schrieb: > Burst stoppen: > Request vom Master ohne Burst bit im AD byte und in der message dann das > CMD mit gewünschter Device-Variable ? > Und der slave stoppt ab dann die burst frames und antwortet mit normaler > response ? Nein, siehe oben ;-) Tomas Kuckenburg schrieb: > Gibt es noch weitere Besonderheiten wie das packed ASCII format usw. ? > Gibt es bei HART etwa auch segmentierte Nachrichten (wenn die 25 data > bytes nicht ausreichen) ? Das PackedASCI braucht dich garnicht zu interessieren, da du es eigentlich nur speichern und wieder ausgeben musst. Bei einem Slave zumindest. Angezeigt wird das in der Regel eh nicht. Um die Hin- und Herkonvertierung brauchat du dich also nicht zu kümmern. Das brauchst du ja nur für gespeicherte Nachrichten und so. Nachrichten werden nicht geteilt, nein - aber es sind auch nicht nur 25 Datenbytes, da gibt es schon kommandos mit wesentlich mehr Bytes. Man kann sich da ja eh nichts aussuchen, da alles absolut fest von der HCF vorgegeben wird. Lediglich eigene Kommandos kann man im gewissen Rahmen selber implementieren...aber auch da kann man nicht machen, was man will. Tomas Kuckenburg schrieb: > HART ist schon witzig, kein konsistentes message format (short vs. > long address, master vs. slave mit status bytes) Das sehe ich nicht so, da ist schon Verstand drin. Es ist halt erstmal etwas kompliziert. Nichts desto trotz ist alles strikt festgelegt, von reiner Willkür kann man also nicht reden. Das kurze Format kommt ja eher aus den Anfangszeiten von HART und ist halt einfach um neue Geräte einzubinden. Wirklich kommuniziert wird ja nur über das Long-Frame. Tomas Kuckenburg schrieb: > So ist das manchmal bei den historisch gewachsenen Dingen, hinterher > wissen es immer alle besser ;o). Ja, das ist schon ein Urgestein, aber es geht halt immer weiter - sei froh, wenn du kein WirelessHART machst. Trotzdem ist es nach wie vor sehr verbreitet.
Moins, Ich würde gerne noch einmal auf Dein Angebot mit dem Trace zurückkommen. FrameAlyst braucht eine Trail-lizenz, das kann noch dauern falls Walter Borst sich Zeit lässt ;-). Einfach so wie es auf der seriellen Schnittstelle roh rübergeht einmal CMD0 mit Response vom Slave und ein long CMD wie CMD1 oder was Du gerade zur Hand hast wäre gut. Danke + Gruß, Tom.
Tomas Kuckenburg schrieb: > FrameAlyst braucht eine Trail-lizenz Echt? Brauchte ich nie. Tomas Kuckenburg schrieb: > Einfach so wie es auf der seriellen Schnittstelle roh rübergeht einmal > CMD0 mit Response vom Slave und ein long CMD wie CMD1 oder was Du gerade > zur Hand hast wäre gut. Ich guck gleich mal.
Angehängte Dateien:
-
HART_HEX.JPG
79 KB -
HART_dekodiert.JPG
87 KB
So, hier sind mal nacheinander: Kommando 0 (short) Kommando 1 (long) Kommando 2 (long) Kommando 3 (long) Im ersten Bild sind die reinen HEX-Werte, die gesendet werden - im zweiten sind die selben Daten dekodiert.
...falls Du bitte noch den Zusammenbau der long adresse entmystifizieren könntest :-) ? : ad[0] = irgendetwas von der manufacturer id im unteren nibble ? ad[1] = device type ? ad[2] = MSB device Id tag ad[3] = .. ad[4] = LSB device Id tag gruss, tom.
tom schrieb: > ...falls Du bitte noch den Zusammenbau der long adresse entmystifizieren > könntest :-) ? : Sicher:
1 | BYTE 0 | BYTE 1 | ----> |
2 | --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- |
3 | | | | | | | | | | | | | | | | | | 3 Byte |
4 | | | | | | | | | | | | | | | | | | Unique Identifier |
5 | --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- |
6 | | | _______________________________________________________ |
7 | | | | |
8 | | | |___ 14 LSBs vom Expanded-Device-Type |
9 | | | |
10 | | |_________________________________ Burst-Mode-Bit |
11 | |
|
12 | |_____________________________________ Master-Address-Bit |
Gruß
jepp, und woraus setzt sich der expanded device type zusammen ? In einer anderen doku habe ich was von 35bit long address gelesen, das passt ja dann nicht mit dem hier überein, oder ??? ei verbibscht ;-). Du hast bei mir schon mal auf jeden Fall eine Kiste Bier gut ! Gruss, tom.
axso, wg. der trial lizenz für FrameAlyst: war wohl ein bug im installer der 7.11 version den der walter borst im aktuellen trail zum download wieder behoben hat...
tom schrieb: > woraus setzt sich der expanded device type zusammen ? Den Extended Device Type bekommst du bei der Registrierung deines Gerätes bei der HCF. Diese nimmt das Gerät dann in ihre "Common Tables" auf und aktualisiert ihre Datenbank. Wenn jetzt irgendwer mit seinem Programm deinen Transmitter anspricht und die aktuellen Extended Device Type Codes hat, dann sieht er weitere Informationen zu deinem Gerät, wie halt den Hersteller und den Typ des Gerätes. Auf jeden Fall kannst du dir den nicht einfach aussuchen. Bei der Unique ID hast du etwas freiere Wahlmöglichkeiten. Beide zusammen ergeben jedoch eine Kombination von Adresse, die nirgends auf der Welt ein zweites Mal vorkommen wird (oder sollte!). tom schrieb: > In einer anderen doku habe ich was von 35bit long address gelesen Das kenne ich persönlich jetzt nicht. Aber Unterschiede wird es eigentlich nicht geben, da ja alles durch die HCF festgelegt ist. Quelle? tom schrieb: > Du hast bei mir schon mal auf jeden Fall eine Kiste Bier gut ! Kann ich mir die irgendwo runterladen ;-)
Liebe HART - Spezialisten Habe eine Verständnisproblem mit der HART Spec. (v6): Die lange Adresse besteht ja u.a. aus der 24-bit Device-ID. Diese ID wird ja mit Kommando 0 und 11 zurückgegeben. Hat diese ID etwas mit der Final Assembly - Number zu tun, die mit Kommando 16 und 19 gelesen und geschrieben werden kann? Oder muss diese Assembly Number einfach nur gespeichert werden, ohne dass sie irgend einen Einfluss auf die Adressierung hat? Vielen Dank! Gruss Adrian
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.