Warning aus erhaltenen UDP Bytes korrekt interpretieren



  • Hallo,

    ich habe aktuell folgendes Problem: Ich frage aktuell per UDP einen Regler nach den letzten Warnungen ab und erhalte eine Folge von Bytes die leider nicht in ganz in das Antwortschema passen, aber richtig sind (in der hauseigenen Software wird die Warnung entsprechend angezeigt). Der Fehler bzw. die Warnung ist 52-2. Ich erhalte folgenden Bytestream mittels UdpClient.Receive(...):

    Relevante Bytes:
    ... 30 35 34 30 0D (0D = carriage return)
    

    Übersetzt in einen String (Encoding.ASCII.GetString()) wäre das folgendes:

    0540(CR)
    

    Das Handbuch sieht ein UINT16 vor welches wie folgt interpretiert wird:
    Bit Wert Bedeutung
    0...3 000Fh Unternummer
    4...11 0FF0h Hauptnummer
    15 8000h Warnung aktiv

    Gefühlt wird hier 52 + 2 addiert und mir ausgegeben. Ich habe mir entsprechend die Bytes als Bits mal herausgeschrieben, komme aber nicht wirklich auf eine korrekte Lösung. Lese ich die Bytes falsch oder muss ich diese erst "beschneiden"?



  • @Spacemuck sagte in Warning aus erhaltenen UDP Bytes korrekt interpretieren:

    Relevante Bytes

    = 5 Bytes

    Handbuch sieht ein UINT16

    = 2 Bytes

    Lese ich die Bytes falsch

    Tja

    Woher kommt die Erkenntnis über die relevanten Bytes?



  • @manni66
    Damit meinte ich aus dem Antwortstring erhalte ich mehrere Bytes, die aber insgesamt nur interne Zusatzinformationen des Gerätes sind. Ich erhalte normalerweise so etwas wie MsgNr.,Teilnehmer.Kommando,.... : [Antwort]. Genau diese Antwort am Schluss sind die relevanten Bytes. Sicherheitshalber, aber wahrscheinlich irrelevant, habe ich ebenfalls das Carriage Return (0D) mit angehängt.



  • @Spacemuck sagte in Warning aus erhaltenen UDP Bytes korrekt interpretieren:

    Übersetzt in einen String (Encoding.ASCII.GetString()) wäre das folgendes:

    Wozu? Du willst doch die Bits untersuchen.

    Ich sehe aber nicht, wie 30 34h (oder 34 30h) da irgendwie passen sollte.

    34h ist jetzt zufällig gleich 52d aber das passt mit den von dir angegebenen Positionen nicht überein.



  • @Spacemuck sagte in Warning aus erhaltenen UDP Bytes korrekt interpretieren:

    Gefühlt wird hier 52 + 2 addiert und mir ausgegeben. Ich habe mir entsprechend die Bytes als Bits mal herausgeschrieben, komme aber nicht wirklich auf eine korrekte Lösung. Lese ich die Bytes falsch oder muss ich diese erst "beschneiden"?

    du musst wissen in welchen format der regler den wert ausgibt. muss im programmer's manual stehen. ist das 0d wirklich ein return und der rest ascii-zeichen?

    manche regler geben werte immer als 4-byte floats aus. kein witz.
    daher: RTFM! 🙂



  • @Bushmaster sagte in Warning aus erhaltenen UDP Bytes korrekt interpretieren:

    du musst wissen in welchen format der regler den wert ausgibt. muss im programmer's manual stehen. ist das 0d wirklich ein return und der rest ascii-zeichen?

    manche regler geben werte immer als 4-byte floats aus. kein witz.
    daher: RTFM! 🙂

    Meinst du bspw. Positioniergeschichten? Dieses Vergnügen hatte ich in der Tat mit diesem Regler schon ;).
    Das Carriage Return wird immer als Abschlußzeichen mitgeliefert, so sieht es die Spezifikation vor.
    Die Befehlsabfrage selbst kann für Befehle dieser Art eine Antwort erhalten welche 8 / 16 / 32 Bit groß ist.
    Die Message selbst besteht laut Manual aus n-Zeichen (ASCII). Für diesen Fall soll die Antwort ein UINT16 sein.

    Ich hatte ja mit den anderen Befehlen soweit auch keine großen Probleme. Ich lese morgen nochmal den Regler aus bzw. provoziere diesen und einen anderen Fehler und schau mal was mir sonst so zurückgeliefert wird; evtl. gibt das mir weiteren Aufschluss. Eigene Dummheit beim Lesen der Bytes wird natürlich nicht ausgeschlossen.

    Weitere Informationen erfolgen im Laufe der Tage.



  • kurzes Update: Die Bytefolge kommt tatsächlich so an. Leider konnte ich keinen anderen Fehler gerade provozieren welcher mir als Fehler (statt warning) angezeigt wird. Das Bit für "Fehler/Warnung aktiv" wird dem Anschein nach auch nicht gesendet (oder eben mit in der 54/540).



  • @Spacemuck ich weiß ja nicht.

    #include <cctype>
    #include <cstdint>
    #include <iostream>
    
    int adigit2int(char adigit)
    {
    	if (!std::isdigit((unsigned) adigit))
    		return -1;
    	return adigit - '0';	
    }
    
    int main()
    {
    	char const msg[]{ 0x30, 0x35, 0x34, 0x30 };
    	std::uint16_t value = 1000 * adigit2int(msg[0]) + 100 * adigit2int(msg[1]) + 10 * adigit2int(msg[2]) + adigit2int(msg[3]);
    	std::cout << value << '\n';
    	std::cout << "Unternummer: " << (value & 0x000f) << '\n';
    	std::cout << "Hauptnummer: " << ((value & 0x0ff0) >> 4) << '\n';
    }
    
    540
    Unternummer: 12
    Hauptnummer: 33
    

    Ich habe das Gefühl daß Du von falschen Voraussetzungen ausgehst.



  • @Swordfish sagte in Warning aus erhaltenen UDP Bytes korrekt interpretieren:

    ((value & 0x0ff0) >> 8)

    passt scheinbar zur beschreibung des fragestellers. ist aber letztlich bloß value>>8 & 0xf



  • Ich denke, daß der Wert als hex zu interpretieren ist (bei einer Dezimalzahl würde man keine 0 voranstellen), d.h. es wäre
    0x0540 = 1344.
    Und dann wäre

    Hauptnummer = 84 (0x54)
    Unternummer = 0
    

    @Swordfish und @Bushmaster: Die Unternummer besteht nur aus 4 Bits, d.h. zur Berechnung der Hauptnummer den Wert nur um 4 (nicht 8 ) nach rechts verschieben.





  • @Spacemuck sagte in Warning aus erhaltenen UDP Bytes korrekt interpretieren:

    52-2.

    wie das zustande kommt weiß aber immer noch keiner. 😞



  • Erst einmal: Vielen Dank für die zahlreichen Antworten eurerseits und Entschuldigung für die verspätete meinerseits.

    Ja, wie das zustande kommt weiß ich auch nicht so wirklich. Das ist nur das was ich aus dem Handbuch lese.

    @Swordfish : Was meinst du mit falschen Voraussetzungen?

    EDIT: Der betroffene Regler wäre der Metronix ARS 2000, CANopen Handbuch Objekt 200F (S. 149).
    Der Zugriff erfolgt allerdings nicht in Echtzeit über UDP (ARS 2000 => Produkthandbuch Technologiemodul Ethernet, Abschnitt "Lesen eines CANopen Objekts, Seite 24f)

    EDIT2: Metronix homepage, Downloads, Handbücher, ARS2000



  • @Spacemuck sagte in Warning aus erhaltenen UDP Bytes korrekt interpretieren:

    Was meinst du mit falschen Voraussetzungen?

    Naja, Du glaubst etwas zu Senden auf das eben diese Antwort kommen muss.
    Vielleicht läuft bei der Abfrage schon was falsch.



  • @Swordfish Das schließe ich natürlich nicht aus, wäre aber trotzdem etwas verwunderlich, da die restlichen benötigten Kommandos ohne Probleme funktionieren.


Log in to reply