Läsa Modbus med arduino

[ojz0r]

Vad exakt är det du vill göra?

Det låter som att du vill ha CANopen för dess komplexitet men samtidigt vill du ha Modbus för dess enkelhet.

[sodjan]

Och vilken sorts "säkerhet" handlar det om?

[DanielM]

Förberendande och jag tänker använda privat också.

Det stämmer att jag söker ett enkelt protokoll. Allt är enkelt om man redan kan. Men med tanke på att de utrustningarna jag använder har sällan Modbus, så undrar jag om det är ens värt om jag lägger tid på det, än fast Modbus är enkelt.

De protokoll jag har mest kommit i kontakt med är EtherCAT. Jag har även kommit i kontakt med IO-Link, vilket verkar vara ett mycket förenklat protokoll för att skicka data mellan två enheter.
SAE J1939 har jag kommit i kontakt med mycket. Modbus också. Men skillnaden är att när det är enheter som talar Modbus så är det ofta äldre saker. Det kan vara till exempelvis CS 1000 partikelräknare och NA 9289 nätverksadapter.

https://www.hydac.com/de-en/products/se ... -1000.html
https://www.beijerelectronics.se/sv-SE/ ... uct___Page

Dessutom så tycker jag det är dåligt om man låter användarna definiera egna I/O på en standard. Sådant förekommer inte på J1939 och inte heller på CANopen. Där har man inte ens rätt att själv bestämma hur felkoderna ska formas eller vad dom ska heta. Detta tycker jag är bra.

Låt oss säga att jag har två enheter av olika fabrikat. Jag kopplar ihop dessa och då ska dom tala med varandra. För J1939 så kan jag blunda och koppla ihop dom. Det fungerar. Men hur blir det för Modbus då?

Och vilken sorts "säkerhet" handlar det om?

Internet?
Se till så paket hamnar rätt?

De flesta protokoll idag har en server som nekar andra icke-godkända enheter att kunna tala med övriga slavar. Alltså det är mastern som styr detta.

[AndLi]

Då kan du väl bara tunnla ModBus genom SSL och kalla det för ModBusSecure.... Det är så alla andra gör när de ska säkra upp något gammalt

Och då kan du ju få all "se till att paketet hamnar rätt" som du möjligen kan önska och mastern kan ju också vara "säker" på att det är din enhet som sänder

[DanielM]

Ja. Jag tvivlar inte på att man måste lägga till något annat för att säkra så inte busar hittar sig in i nätverket och stänger ned.

Men i Modbus, är allt definierat då?
Vi säger att ni har två modbusmoduler. En master och en klient som ska tala med varandra. Om mastern skickar ut ett meddelande. Kan man då läsa den direkt eller måste man behöva avkoda meddelandet?

För i J1939 så behöver man inte avkoda något. Jag uppfattar CANopen likadant. Här finns det färdiga definitioner på vilket hex som ska tolkas på ett och annat sätt. Detta gör så att man kan ta godtyckliga enheter från olika fabrikat och koppla ihop med varandra. Detta är mycket viktigt för mig.

[nibl]

I modbus är ingenting definerat utom själva protokollet
Man läser bara ett "rå" värde från ett eller flera 16bitars register, och sen är det upp till användaren att tolka det.

[DanielM]

Alltså behöver jag protokollet på enheten för att förstå vad den skickar för förfrågan och vad den vill ha för respons tillbaka?
Vissa tillverkare lämnar inte ut sitt protokoll. CS 1000 lämnar inte ut sitt protokoll för att valfria individer ska kunna tolka dessa signaler. Man måste köpa mjukvaran för att kunna tolka vad det är för något som skickas mellan enheterna. Det tycker jag är dåligt.

[TomasL]

Du behöver tag-listan för enheten, alla tillverkare lämnar ut den, ofta är dessutom publicerad på tillverkarens hemsida eller i manualerna.
Tag-lista är samma sak som en lista över registren.
I dessa listor får du registernummer, datalängd, data-typ, giltiga områden, divisor mm.
Det finns också beskrivningar på hur man skall göra för att accessa 16/32-bitars data om det är aktuellt för enheten i fråga.
Till exempel som denna:

[TomasL]

Alltså behöver jag protokollet på enheten för att förstå vad den skickar för förfrågan och vad den vill ha för respons tillbaka?

En modbus-slav skickar aldrig någon förfrågan på någonting, den svarar på det som mastern vill veta.
EN modbus-slav kan aldrig någonsin starta en sändning av sig själv.
Helt enkelt, den håller käft tills dess att mastern har sagt till den att prata, och då svarar den enbart på kommandot som skickats från mastern, inget annat.

Dock måste du sätta upp din master med korrekta registeradresser. för varje typ av slav som din master skall prata med.

Bygger du en slav, tja, då är det ju fritt fram för dig att skapa din egen registerlista.

[DanielM]

En modbus måste både ha slav och master? Det går inte ha klient till klient?

[TomasL]

Det måste finnas en, och endast en Master, och sedan teoretiskt upp till 247 slavar adresserade 1-247, med unika adresser, dvs 2 slavar för ej ha samma adress, dock rent praktiskt på en RS485-lina max 16 enheter för varje förstärkare/repeater.
Det går inte att köra Slav-Slav, ej heller Master-Master.

[DanielM]

Varför är just RS485 ofta tillämpat med Modbus? RS485 är också differentiella signaler som canbus.

[H.O]

För i J1939 så behöver man inte avkoda något.

Är inte det en definitionsfråga?
J1939 är är väl just precis en beskrivning/specifikation på hur data överförd i form av CAN-meddelande skall tolkas/översättas/avkodas?
Dvs J1939 specificerar vilka värden som överförs i ett paketet med ett visst ID och hur dessa värden skall representeras (skalfaktor och offset).

CAN är ett sätt överföra data.
VAD som överförs "bestäms" inte på något sätt av CAN-standarden.
J1939 bestämmer/beskriver/specificerar exakt VAD och HUR specifik data överförs i form av CAN-meddelande.
OBD-2 är ett exempel på ett ANNAT protokoll som också överförs i form av CAN-meddelande.

MODBUS är ett sätt att överföra data.
VAD som överförs "bestäms" inte på något sätt av MODBUS-standarden.

[TomasL]

RS485 och liknande används ihop med i princip alla fältbussar, av den enkla anledningen att de är väldigt stör-säkra.

[DanielM]

För i J1939 så behöver man inte avkoda något.

Är inte det en definitionsfråga?
J1939 är är väl just precis en beskrivning/specifikation på hur data överförd i form av CAN-meddelande skall tolkas/översättas/avkodas?
Dvs J1939 specificerar vilka värden som överförs i ett paketet med ett visst ID och hur dessa värden skall representeras (skalfaktor och offset).

CAN är ett sätt överföra data.
VAD som överförs "bestäms" inte på något sätt av CAN-standarden.
J1939 bestämmer/beskriver/specificerar exakt VAD och HUR specifik data överförs i form av CAN-meddelande.
OBD-2 är ett exempel på ett ANNAT protokoll som också överförs i form av CAN-meddelande.

MODBUS är ett sätt att överföra data.
VAD som överförs "bestäms" inte på något sätt av MODBUS-standarden.

Nej. Det fungerar så att när man skickar en förfrågan så skickar man ett PGN nummer. Detta nummer representerar en funktion. Vi säger att jag skickar ID = 200, vilket betyder förfrågan. Sedan skickar jag mitt PGN nummer. Vi säger att PGN numret är 300 och betyder att jag vill ha felkoderna för DM1 av dig. Då skickar du DM1 felkoder. DM1 felkoder i sin tur innehåller FMI och SPN nummer där FMI beskriver vad det är för fel och SPI beskriver lokaliseringen av felet. SPI numrera är enorma medan FMI numren går upp till 30 stycken. Det kan vara till exempelvis FMI = låg strömstyrka och SPI = Tändstift.

J1939 är som du säger, ett sätt att forma CAN meddelanden och tolka dessa på ett likasinnat sätt för alla enheter. Det unika med J1939 är att du behöver aldrig definiera registerna själv. Allt finns dokumenterat att ett visst ID nummer och visst data är en speciell funktion och ingenting annat.

Jag kan J1939.
ODB2 fixar Biltema.