Läsa Modbus med arduino

[TomasL]

Tänk om man skulle ha haft UDP/IP som fysiska lagret för CANOpen då UDP så kan man köra Peer to Peer och broadcast, alltså man skickar till alla.

UDP/IP är inte fysiska lager det är dataprotokoll och inget annat. UDP och TCP är snarlika med den skillnaden att en TCP klient skickar en ACK för varje mottaget paket.
Får inte servern ett ACK skickas paketet om igen, i princip tills dess att den får ett ACK.
Med UDP skickas inga ACK.
Servern har inte en aning om klienten får data över huvudtaget.
Dock är UDP betydligt snabbare eftersom inga ACK skickas.

[DanielM]

Det där med att Modbus är öppet tycker jag är bra. Jag skrev ett protokoll för J1939 och detta protokoll är stängt. Det finns att få tag på, men då måste man köpa dessa dokument. Jag fick dessa dokument tillgängligt från en tillverkare som lämnade ut protokollet när man köpte deras produkt. Men dom är väldigt skeptiska om man frågar dom något om J1939. "What are going going to use that for?" frågar dom alltid när man ställer en fråga om deras produkt. Jag vet inte hur öppet CANopen är, eller hur svårt det är.

Självklart är det IT avdelningen som följer en viss företagsstandard att inte släppa in folk på nätverket, eller ens att sätta upp lokala nätverk som inte är anslutna till nätverket. Har varit på företag dom nekar folk att ens ta med en DHCP server för att sätta upp ett lokalt nätverk. Orsaken är att finns det okänd utrustning som kan kopplas upp på nätverket, så ska dom slängas. Får inte finnas några risker.

[DanielM]

Tänk om man skulle ha haft UDP/IP som fysiska lagret för CANOpen då UDP så kan man köra Peer to Peer och broadcast, alltså man skickar till alla.

UDP/IP är inte fysiska lager det är dataprotokoll och inget annat. UDP och TCP är snarlika med den skillnaden att en TCP klient skickar en ACK för varje mottaget paket.
Får inte servern ett ACK skickas paketet om igen, i princip tills dess att den får ett ACK.
Med UDP skickas inga ACK.
Servern har inte en aning om klienten får data över huvudtaget.
Dock är UDP betydligt snabbare eftersom inga ACK skickas.

Du verkar kunnig inom detta. Vad är dina rekommendationer om jag vill ha kommunikation över internet där jag kommer använda TCP/IP sockets eller UDP sockets?
Målet är överföring av data snabbt.

Jag kan använda J1939 protokollet då den har DM16 som är Binary Data Transfer. Men enligt standarden kan man bara skicka max 1785 bytes, uppdelat i 224 meddelanden. 1785/8 = 223.125 paket.
Det är lite för dåligt för mig. Jag måste kunna skicka megabyte.

Häftigaste måste väll vara CANOpen, men jag är fortfarande lite kluven på detta då jag uppfattar protokollet som väldigt komplext samt processorkrävande och dessutom ändras protokollet rätt ofta. J1939 ändras typ aldrig. Det bara läggs till med nya kommandon. Är Modbus likadant?

[TomasL]

Föreslår att du köper den här boken

Och lär dig lite om TCP/IP mm.

[DanielM]

Vad har det med Modbus och CANopen att göra?
Jag har tänkt köra detta tillämpat då jag har åsikten att läsa sig till något är sällan bra. Då är det mer intressant att laborera sig till något igenom att testa. Det var så jag lärde mig J1939. Började med att skicka CAN-bus data och sedan formade jag CAN-bus datat efter en J1939 standard. Vipps så blev det ett protokoll som några på teknikavdelningen hos John Deere frågade mig om.

[AndLi]

Varför inte använda något av alla protokoll som är utvecklat för att överföra data snabbt istället för protokoll för styrsystem?

[DanielM]

Jag har ingen aning vad det finns för protokoll för att överföra data. Jag har nämligen sökt efter detta, men inte hittat något.
Går det inte använda Modbus för att överföra data?

[AndLi]

Självklart gör det det, frågan är, är det ett bra val för det du vill göra?

Hur gör andra som vill göra samma sak som dig?

( sannolikt kör de ett rest api över https...)

[DanielM]

Jo. Men med REST API så måste man omvandla datan till objekt till exempelvis en struct.
Men REST API är väll ett protokoll där man själv får bestämma hur dataramen ska se ut?

[Icecap]

Data måste inte passa med en struct - men i många fall (speciellt med fast storlek datablock) kan det bli enklare att jobba med.

Du bör lära dig att skilja mellan data som överförs och sättet de överförs på.

Samma data kan överföras med en uppsjö olika protokoll och med en massa olika hårdvara.

Såklart ska hårdvaran hos sändare och mottagaren passa ihop, resten är enkelt

[TomasL]

Vad har det med Modbus och CANopen att göra?

Du har framfört att du vill använda TCP/IP eller liknande, då kan det vara bra att veta vad det är, då du verkar ha svårt att skilja på de olika transportprotokollen.

Skall du sända mycket data över ethernet eller liknande så är UDP/IP att föredra, eftersom det är rätt snabbt, dock är det mindre säkert, då den som skickar data inte har en blekaste aning om det kommer fram korrekt.

Skall du skicka mycket data över RS485/RS232 då skall du använda något annat. Till exempel rådata, i lämpliga chunks, eventuellt då även med checksumma för varje del, och kanske även ordningsnummer för delarna,

MODBUS-RTU till exempel är ett protokoll avsett för en ren Master/Slave-miljö, det är helt registerbaserat, dvs Mastern frågar efter N antal register, slaven svarar med att skicka dessa register, där varje register är 16 bitar (och inget annat)
Sedan har diverse tillverkare implementerat både 32 och 64 bitars register samt även flyttal, men det ingår inte i standarden, ofta har då varje tillverkare ett eget unikt sätt att hantera 16/32/64-bitars register, vilket inte alltid är kompatibelt mellan olika tillverkare.

MODBUS-TCP/IP är i princip Modbus-RTU inkapslat i en TCP-ram (med några få skillnader).
Oavsett om du kör MODBus-RTU över seriell lina eller över TCP/IP så är det alltid ett strikt Master/slav-protokoll.

[DanielM]

Data måste inte passa med en struct - men i många fall (speciellt med fast storlek datablock) kan det bli enklare att jobba med.

Du bör lära dig att skilja mellan data som överförs och sättet de överförs på.

Samma data kan överföras med en uppsjö olika protokoll och med en massa olika hårdvara.

Såklart ska hårdvaran hos sändare och mottagaren passa ihop, resten är enkelt

Jag brukar alltid passera data till en struct igenom att kasta den och använda memcpy.

Vad har det med Modbus och CANopen att göra?

Du har framfört att du vill använda TCP/IP eller liknande, då kan det vara bra att veta vad det är, då du verkar ha svårt att skilja på de olika transportprotokollen.

Skall du sända mycket data över ethernet eller liknande så är UDP/IP att föredra, eftersom det är rätt snabbt, dock är det mindre säkert, då den som skickar data inte har en blekaste aning om det kommer fram korrekt.

Skall du skicka mycket data över RS485/RS232 då skall du använda något annat. Till exempel rådata, i lämpliga chunks, eventuellt då även med checksumma för varje del, och kanske även ordningsnummer för delarna,

MODBUS-RTU till exempel är ett protokoll avsett för en ren Master/Slave-miljö, det är helt registerbaserat, dvs Mastern frågar efter N antal register, slaven svarar med att skicka dessa register, där varje register är 16 bitar (och inget annat)
Sedan har diverse tillverkare implementerat både 32 och 64 bitars register samt även flyttal, men det ingår inte i standarden, ofta har då varje tillverkare ett eget unikt sätt att hantera 16/32/64-bitars register, vilket inte alltid är kompatibelt mellan olika tillverkare.

MODBUS-TCP/IP är i princip Modbus-RTU inkapslat i en TCP-ram (med några få skillnader).
Oavsett om du kör MODBus-RTU över seriell lina eller över TCP/IP så är det alltid ett strikt Master/slav-protokoll.

Du kan inte CANopen heller.

Du menar att jag behöver inte ansluta någon UPD server för att ta emot data. Bara lyssna efter kommande trafik från UDP servern?

Jag vill mest bara ha en bra standard att kunna kommunicera med diverse industriella enheter. Modbus och CANopen verkar vara riktigt populärt. Jag träffar på mycket om CANopen, men inte så mycket Modbus. Det enda Modbus liknande enheterna jag har träffat på är för PLC miljöer.

Om det är låg sannolikhet att det är svårt att avläsa enheter via Modbus då tillverkaren har eget modbus-liknande protokoll. Då tycker jag det är rätt värdelöst med Modbus om fabrikaterna följer inte standarden.

[TomasL]

Du kan alltid läsa data från en MODBus-slav, frågan är bara i vilket format du får data, läser du ett 32-bitars register, måste din master vara medveten om att den får dubbelt så många byte från slaven, osv.

CAN-bus, nä har aldrig behövt blanda mig i det.
Eftersom all kommunikation jag kör är antingen MODBus, eller ett eget protokoll.

[DanielM]

Jag ska försöka skriva lite C kod för Modbus och testa det. Jag siktar på att man inte ska behöva använda trådar om man kör TCP/IP samt dynamisk allokering ska inte vara med.

Men målet är att överföra data mellan två enheter och även data för styrning. Jag har tittat på REST API och det känns som ett väldigt inviduellt protokoll som saknar dataram.

[Icecap]

Jag har kört MODBUS via RS485 och det fungerar perfekt.

Det är bokstavligen att packa frågadata in med CRC osv. och trycka ut det på serieporten.

Sedan tar den emot en block data, jag minns inte exakt hur jag kände av slut av block.

Dessa data är i ett format jag känner igen och tar de data jag behöver.

Det behövs ingen framework, paketer eller liknande, bara seriell kommunikation.