Warning aus erhaltenen UDP Bytes korrekt interpretieren
-
@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äreHauptnummer = 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.