Gerät via LIN ansteuern

Hallo allerseits!

Ich möchte mich an BUS-Kommunikation versuchen und habe hierfür (erst einmal) ein Heizgerät das ich über einen LIN-Eingang ansteuern möchte (erstmal einfach: "HEIZEN AN / HEIZEN AUS"). Ein 8476-Modul ist schon bestellt!

Die Beispiel-vi "LIN Master Send Full Frame and Receive" vom NI-CAN habe ich bereits gesehen. Wozu ich bisher keine Antwort finden konnte, wäre ob LIN-Geräte (i.d.F der Heizer) bereits eine ID haben, oder ob diese zuerst vergeben werden müssen. Wenn ersteres: kann ich die auslesen oder muss man da beim Hersteller nachhaken? Wenn zweiteres: wie?

Habe ich ausserdem richtig verstanden, dass die Befehle (wie zB "Heizen") vom Slave Task des Masters an den Bus gegeben werden?

Viele Grüße und einen schönen Abend
falk87

Anzeige

Anscheinend habe ich mir nicht die einfachste Labview Aufgabe gestellt und meine Frage war zu wage/planlos als dass sie Interesse an Unterstützung hervor gerufen hätte. Vielleicht hat ja nun jemand einen Tipp, nachdem ich mein Problem konkretisieren konnte. :-)

Ich habe inzwischen eine ldf-Datei erhalten, in der der Befehl "Heizer AN" (idF: "Geraet_ein) zu finden ist.
Meine Hoffnung war, dass es ab jetzt nur noch plug&play ist mit der Beispiel-VI "LIN Master Send Full Frame and Receive". Den Receive-Teil habe ich erstmal gelöscht; somit sieht die VI jetzt aus wie im Anhang.

So wie ich die Beispiel-VI interpretiere, wird hier anhand der Eingaben "Arbitration ID" und "Data" der Frame erstellt und mit "Send Full Frame" verschickt.

Die "Arbitration ID" sollte dann doch "28" sein, wie in "Frames {..." definiert.
Als Eingabe für "Data" hätte ich dann "Geraet_ein" vermutet, aber hier kann ich ja keinen String eingeben, sondern nur zwischen 0 und 8 Hex-Werten. Und eine Id, für welche "Geraet_ein" steht habe ich auch nicht gefunden.

Ich wäre sehr dankbar, wenn mir hier jemand auf die Sprünge helfen könnte.

Code:

Nodes {
    Master: PC, 5 ms, 0.2 ms;
    Slaves: ..., HEIZER;
}
Signals {
...
    Geraet_ein: 1, 0, PC, HEIZER;
...
}
Diagnostic_signals {
...
}
Frames {
...
    Heiz_01: 28, PC, 4 {
...
        Geraet_ein, 8;
}

Hallo falk,

ich hatte mal mit einem LIN-Gerät zu tun, allerdings nur indirekt über einen CAN-2-LIN-Umsetzer…

In deiner ldf-Datei sollte die komplette Botschaft definiert sein! Dies sieht dann z.B. so aus:

Code:

Frames {
    RSGe_01 : 38, MB_LINMaster, 4 {
        Reg_Set_Voltage, 0;
        Ramp_Time, 8;
        Cut_Off_Speed, 12;
        Exc_Limitation, 16;
        TA_Exc_Set_Level, 24;
        MM_Request, 27;
        Reg_Blind, 30;
    }

Im Beispiel ist eine Botschaft mit der ID 38 definiert, sie enthält die Signale Reg_Set_Voltage usw. Diese Signale sind in einem U32-Wort enthalten, die Zahl nach dem Signalnamen definiert die Bitposition in der Botschaft.

Weiter im Beispiel: Die Cut_Off_Speed ist so als Signal definiert:

Code:

Signals {
    Cut_Off_Speed : 4, 0, MB_LINMaster, iStars_LINSlave;

Hier bedeutet die "4", dass das Signal mit 4 Bit Breite definiert ist.
Da eine Wertetabelle für dieses Signal existiert, steht diese auch in der ldf-Datei:

Code:

Signal_encoding_types {
    Cut_Off_Speed_Sig_Type {
        logical_value, 0, "2400 rpm";
        logical_value, 1, "2530 rpm";
        logical_value, 2, "2670 rpm";
        logical_value, 3, "2820 rpm";
        logical_value, 4, "3000 rpm";
        logical_value, 5, "3200 rpm";
        logical_value, 6, "3430 rpm";
        logical_value, 7, "3690 rpm";
        logical_value, 8, "4000 rpm";
        logical_value, 9, "4360 rpm";
        logical_value, 10, "4800 rpm";
        logical_value, 11, "5330 rpm";
        logical_value, 12, "6000 rpm";
        logical_value, 13, "6860 rpm";
        logical_value, 14, "8000 rpm";
        logical_value, 15, "Always active";
    }

Wenn du jetzt also eine CutOffSpeed von 4000rpm setzen willst, musst du den Wert "8" in 4 Bit Breite kodieren und an Bitposition 12 in der Botschaft unterbringen…

Die LIN-Botschaften selbst werden nach einem festen Zeitschema versendet, auch dieses wird in der LDF-Datei definiert:

Code:

Schedule_tables {
    ST1 {
        RSGe_01 delay 20 ms;
        RSGs_02 delay 40 ms;
        RSGe_01 delay 20 ms;
        RSGs_02 delay 20 ms;
        RSGe_01 delay 20 ms;
        RSGs_01 delay 60 ms;
    }

Es gibt also 3 verschiedene Botschaften (RSGe_01, RSGe_02, RSGs_01), die in gewissen Zeitabständen vom MASTER verschickt werden.

Was steht also alles in deiner LDF-Datei?

Hallo Gerd

vielen Dank für deine Antwort! Ich denke ich verstehe die ldf jetzt schon etwas besser und hoffe es ist ok, dass ich sie leicht gekürzt einstelle.

Mir ist aufgefallen, dass es eventuell weniger umständlich ist die Kommunikation zu überprüfen, wenn ich erstmal nur einen Temperatursensor abfrage.

Dafür dachte ich müsste mit der Beispiel-VI "LIN Master Send Header Frame and Receive" die Arbitration-ID "48" versenden werden. Da erhalte ich aber den gescreenshotteten Fehler, der wohl bedeutet, dass der Slave noch eine Response erwartet. Die soll aber doch der Slave verschicken?

Code:

LIN_description_file;
LIN_protocol_version = "2.0";
LIN_language_version = "2.0";
LIN_speed = 19.2 kbps;
Nodes {
    Master: PC, 5 ms, 0.2 ms;
    Slaves: ..., HEIZER;
}
Signals {
...
    Geraet_ein: 1, 0, PC, HEIZER;
...
    Temp_Sensor: 8, 254, HEIZER, PC;
...
}
Diagnostic_signals {
...
}
Frames {
...
    Heiz_01: 28, PC, 4 {
...
        Geraet_ein, 8;

    Heiz_02: 48, HEIZER, 8 {
...
        Temp_Sensor, 48;
...
}
...
}
}
Diagnostic_frames {
    MasterReq: 60 {
        MasterReqB0, 0;
        MasterReqB1, 8;
        MasterReqB2, 16;
        MasterReqB3, 24;
        MasterReqB4, 32;
        MasterReqB5, 40;
        MasterReqB6, 48;
        MasterReqB7, 56;
    }
    SlaveResp: 61    {
        SlaveRespB0, 0;
        SlaveRespB1, 8;
        SlaveRespB2, 16;
        SlaveRespB3, 24;
        SlaveRespB4, 32;
        SlaveRespB5, 40;
        SlaveRespB6, 48;
        SlaveRespB7, 56;
    }
}
Node_attributes {
...
    HEIZER {
        LIN_protocol = 2.0;
        configured_NAD=0x5F;
        product_id=0x0006, 0x0000, 0x00;
        response_error =Geraet_ResponseError;
        P2_min = 10 ms;
        ST_min = 10 ms;
        configurable_frames {
            Heiz_01 = 0x401C;
            Heiz_02 = 0x4030;
        }
    }
}
Schedule_tables {
    main {
        Heiz_01 delay 10 ms;
...
        Heiz_02 delay 10 ms;
...
    }
}
Signal_encoding_types {
...
    Temp_Sensor_encoding {
        logical_value, 254, "Init";
        logical_value, 255, "Fehler";
        physical_value, 0, 220, 1, -50, "Unit_DegreCelsi";
    }
...    
        HZ_Off_On {
        logical_value, 0, "Aus";
        logical_value, 1, "Ein";
    }
}
Signal_representation {
...
    Temp_Sensor_encoding: Temp_Sensor
...
    HZ_Off_On: Geraet_ein
...
}

Hallo falk,

Zitat:Dafür dachte ich müsste mit der Beispiel-VI "LIN Master Send Header Frame and Receive" die Arbitration-ID "48" versenden werden. Da erhalte ich aber den gescreenshotteten Fehler, der wohl bedeutet, dass der Slave noch eine Response erwartet.

Ich selbst habe nicht mit den Low-Level-CAN-Funktionen direkt mit LIN gearbeitet, von daher nur wenig Erfahrung mit diesem Beispiel-VI.

Aber:
Im Screenshot sendest du keinen "Write Header Frame". Der Slave wartet aber auf die Aufforderung des Masters, eben diesen Frame 48 zu senden!
LIN funktioniert MASTER-gesteuert: Der Master hat die Oberhoheit und teilt den Slaves am Bus mit, welche Botschaft er jetzt gerne abfragen will. Der Slave hat dann auf genau die IDs zu antworten, die ihn betreffen. Genau deshalb gibt es die ScheduleTable im Master, die festlegt, welche ID wann (bzw. in welchem Abstand) gesendet wird!

Wenn ich das richtig verstehe, ist der automatische Ablauf nach "ldf" normalerweise der Fall, jedoch nicht wenn die Steuerung über Labview laufen soll:

"Allgemein ausgedrückt wird der LDF genutzt, um das Planungsverhalten des LIN-Clusters zu konfigurieren und festzulegen. So definiert er z. B. die Baudrate, die Reihenfolge und die Zeitverzögerungen bei der Übertragung der Header durch den Master-Task sowie das Verhalten jedes Slave-Tasks als Antwort darauf. Die Frame-API NI-CAN für LIN und LIN-Hardware von NI bieten keine volle native Unterstützung für LDFs, so dass das geplante Verhalten nicht auf die Hardware geladen werden kann. Jedoch steht eine Low-Level-Unterstützung für den Buszugriff (Schreiben der Header und Veröffentlichung oder Abfragen der Antworten) so zur Verfügung, dass der Nutzer das geplante Verhalten auf der Anwendungsebene erstellen kann"
[ni-Seite]

Dem entnehme ich, dass ich meinen Slave direkt mit den Low-Level Funktionen ansprechen kann/soll. Klappt nur leider nicht....

Anzeige

Hallo falk,

da ich selbst nur mit CAN und einem CAN2LIN-Umsetzer gearbeitet habe, kann ich zur direkten LIN-Unterstützung nichts beitragen.
Was sagt denn der NI-Support in München?