Hile mit CAN & Bytes & K-Type Sensor

[Pat P. (tsag)]

Moin,

ich habe ein MGL RDAC Steuergerät. Es liest analog Sensoren aus und gibt 
diese dann über CAN weiter.

Manual gibt es hier:
https://www.mglavionics.co.za/Docs/RDAC%20XG%20INSTALLATION%20MANUAL.pdf

CAN Protokoll gibt es hier:
https://www.mglavionics.co.za/Docs/MGL%20CAN%20Protocol.pdf

Nun versuche ich gerade, dieses Gerät über einen Arduino auszulesen, was 
auch (mehr oder weniger) erfolgreich ist.

Mit meinem Sketch (Standard Arduino CAN Receiver Beispiel), erhalte ich 
Messages in der Konsole. Das erste was mich etwas irritierte war, dass 
die IDs a nstatt wie im CAN Manual 1, 2, 3 etc. waren, 0x212, 0x215 
etc.sind. Jedoch stimmt es mit dem Schema im Manual überein (0x212 
ändert sich beim Anschluss des Thermocouples und 0x217 ist nur 4 Bytes 
groß).

Daher habe ich dies erst einmal auf mein rudimentäres Verständnis für 
CAN geschoben.

Nun habe ich an den TC1 eingang eine Spannungsquelle mit 24,9mV 
angeschlossen. Laut Manual soll dies ~600°C ergeben.

So wie ich gesehen habe, setzt sich die Temperatur aus Byte 0 und Byte 1 
von ID2 zusammen (Seite 12 im Manual).

Ich habe also im Sketch einen Filter für ID 0x212 eingefügt, was auch 
funktioniert hat.

Als nächstes habe ich den Sketch etwas modifiziert und die ersten beiden 
Bytes zusammen geshiftet. Allerdings klappt das nicht so ganz wie ich es 
mir vorgestellt habe (Wert stimmt nicht). Kann mir jemand sagen, wo ich 
den Fehler gemacht habe?

Ausschnitt aus "Loop"

  Serial.print("packet with id 0x");
    Serial.print(CAN.packetId(), HEX);

    if (CAN.packetRtr()) {
      Serial.print(" and requested length ");
      Serial.println(CAN.packetDlc());
    } else {
      Serial.print(" and length ");
      Serial.println(packetSize);

      // only print packet data for non-RTR packets
       //CAN.readBytes(CanB, 8);
      while (CAN.available()) {
       for (int i = 0; i < packetSize; i++) {
    CanB[i] = CAN.read();
    Serial.print(CanB[i]);
    Serial.print(" ");
  }
       
      }
      Serial.print("First complete Val: ");
      int16_t r = (CanB[1]<<8) | CanB[0];
      Serial.println(r);
    }

    Serial.println();
  }

Dies ergibt dann jedoch folgendes:

 Received packet with id 0x212 and length 8
16 255 0 0 0 0 0 0 First complete Val: -240

Received packet with id 0x212 and length 8
15 255 0 0 0 0 0 0 First complete Val: -241

Received packet with id 0x212 and length 8
15 255 0 0 0 0 0 0 First complete Val: -241

Grüße

Patrick

[Wolfgang (Gast)]

Pat P. schrieb:
> Allerdings klappt das nicht so ganz wie ich es
> mir vorgestellt habe (Wert stimmt nicht). Kann mir jemand sagen, wo ich
> den Fehler gemacht habe?

Was bekommst du in CanB[1] und CanB[0] für Werte und was für Werte 
stellst du die als Ergebnis vor?

[Wolfgang (Gast)]

p.s.
Was kommt unter Id7 und wie hast du die Kaltstellenkompensation gemacht?

[Pat P. (tsag)]

Hi,

oben habe ich die Ausgabe angehangen. Also Byte 0 erhalte ich 15 und 
Byte 1 ist 255. Eine Kaltstellenkompensation habe ich noch nicht 
gemacht, da ich momentan ja nur eine 24,9mV Spannungsquelle 
angeschlossen habe.

ID7 werde ich heute Mittag einmal nachschauen.

[Irgend W. (Firma: egal) (irgendwer)]

Pat P. schrieb:
> Also Byte 0 erhalte ich 15 und
> Byte 1 ist 255.

Die Frage ist "big-endian" oder "little-endian"?
Ich würde das eher als 0x0FFF und somit 4095 interpretieren was 
anscheinend bei denen öfters mal der Wert für den Endausschlag ist?

Ändere die Spannung doch mal gerinfügig damit du sieht welche Stelle 
sich verändert, dann weißt du recht schnell welches das hoherwertige 
Byte ist und welches das niederwertige. Und wenn sich garnichts ändert 
stimmt was anderes  nicht:-)

[Rolf M. (rmagnus)]

Pat P. schrieb:
> Das erste was mich etwas irritierte war, dass
> die IDs a nstatt wie im CAN Manual 1, 2, 3 etc. waren, 0x212, 0x215
> etc.sind.

Also ich lese dort:

"MGL CAN Addressing
Addresses are 11 bits and identify the message source. Lower 4 bits are 
used as message type ID, upper 7 bits are device address where a single 
node may have more than one device address to identify logical function 
blocks.
In this document, “CAN address” of a device refers to the upper 7 bits 
of the native CAN address. The lower 4 bits is the “ID”"

0x212 ist also Botschaftstyp 0x2 ("ID") des Geräts 0x21 ("CAN address").

Weiterhin:

"RDAC: 32 – 35 (max 4 RDAC units per bus – selected by dipswitch)"

Gerät 0x21 (33 dez) ist also ein "RDAC".

[Pat P. (tsag)]

Rolf M. schrieb:
> Also ich lese dort:

Ah, top Danke! Das habe ich überlesen. Dann werde ich die Adresse so 
implementieren:)


Zum Sensor Readout:

So wie ich im Can Manual gelesen habe, werden direkt die Temperaturen 
ausgegeben. Was mir jedoch zeigt, das ich irgendwo einen Fehler drin 
habe ist folgendes. Lege ich eine Negative Spannung von -4mV an, erhalte 
ich
Byte0: 79 Byte1: 0
Laut meiner Berechnung ist dies 80

Wenn ich die Spannung auf +1mV erhöhe:
Byte0: 225 Byte1: 255
Laut meiner Berechnung ist dies -31

Wenn ich die Spannung auf +2mV erhöhe:
Byte0: 203 Byte1: 255
Laut meiner Berechnung ist dies -54

Wenn ich die Spannung auf +4mV erhöhe:
Byte0: 159 Byte1: 255
Laut meiner Berechnung ist dies -98

Also habe ich wohl irgendwo einen Wurm drin. Byte 0 ist also das least 
significant Byte (?).

Mein Code um beide Bytes zu verbinden ist der folgende, sollte das nicht 
klappen? CANB  ist vom Typ uint8_t und wird von der library funktion 
CAN.read() gefüllt (die auch uint8_t ist).

      int r = (CanB[1]<<8) | CanB[0];
      Serial.println(r);

[Rolf M. (rmagnus)]

Pat P. schrieb:
> Nun habe ich an den TC1 eingang eine Spannungsquelle mit 24,9mV
> angeschlossen.

Im Manual gibt's kein TC1, sondern TC1+ und TC1-. Die beiden Anschlüsse 
sind wohl dafür gedacht, einfach den Temperatursensor dazwischen zu 
schalten und gar keine externe Spannung anzulegen. Wie hast du deine 
Spannungsquelle denn angeschlossen?