Svenska ElektronikForumet

Modbus RTU hittar jag inte på moderna saker som produceras och uppfinns idag.

Modbus/RTU över RS485 är väldigt vanligt och alla PLCer även nya stöder naturligtvis detta.
MODBUS RTU är ett av de grundläggande protokollen, som används överallt
Inom byggnadsautomation, är det i princip ett krav.
Och byggnadsautomation är en betydligt större marknad än nånting annat.

Självklart finns det och är väl använt. Men nackdelen med RS485 är just krocken av meddelanden. Det är därför Modbus endast kan fungera som master som skickar förfrågan till slavarna. Skulle meddelanden skickas slumpmässigt på RS485 så skulle många meddelanden ej kunna tolkas.

Tänk dig som Klas Kenny sade angående om polling. Jag hade inte tänkt på detta, men det låter smart att slavarna får berätta vad dom har för mätvärden och liknande, istället för att en master ska ständigt fråga. Då behöver bara mastern fånga upp meddelanden.

Men nackdelen med RS485 är just krocken av meddelanden. Det är därför Modbus endast kan fungera som master som skickar förfrågan till slavarna. Skulle meddelanden skickas slumpmässigt på RS485 så skulle många meddelanden ej kunna tolkas.

Det är ingen nackdel alls, det är ju så det är designat, dessutom finns det överhuvudtaget ingen buss där flera kan sända samtidigt, så det du kallar "nackdel" gäller samtliga i dag existerande busar.
Att man sedan kan hantera busskollisioner i olika protokoll är en annan sak, men eftersom Modbus är ett ren Master/Slave protokoll, så finns inte behovet att hantera busskollisioner, eftersom de inte existerar.

Du har missuppfattat vad Klas-Kenny skrev.
Polling betyder att mastern frågar slav efter slav,.
Polling betyder INTE att slavarna skickar efter eget behag.
Polling betyder att slaven bara svarar på det den efterfrågas om.
Så polling är följande':
Mastern begär ett register från slav 1, får det.
Mastern begär ett register från slav 2, får det.
Mastern begär ett register från slav 3, får det.
Mastern begär ett register från slav 4, får det.

osv

Ja, Modbus är förhållandevis enkelt, dock glöm idéerna om funktion 20, 21 osv, det finns inga kommersiella enheter som stöder dessa obskyra koder.

Det är ju definitivt inte den funktion man använder mest/oftast om man säger så men att påsta att det inte finns några kommersiella enheter som använder 0x14 är ju att ta i. Några exempel från namnkunniga tillverkare:

SICK ZIKOR 200 är en gasanalysator, den har stöd för 0x14.
Siemens Masterpact är effektbrytare modell större, de har stöd för 0x14.
Bender PEM735 är en elnätsanalysator, den har stöd för 0x14.
Siemens 7KM PAC2200 är en 3-fas energimätare, den har stöd för 0x14.

TomasL skrev: ↑7 oktober 2021, 00:12:29

Men nackdelen med RS485 är just krocken av meddelanden. Det är därför Modbus endast kan fungera som master som skickar förfrågan till slavarna. Skulle meddelanden skickas slumpmässigt på RS485 så skulle många meddelanden ej kunna tolkas.

Det är ingen nackdel alls, det är ju så det är designat, dessutom finns det överhuvudtaget ingen buss där flera kan sända samtidigt, så det du kallar "nackdel" gäller samtliga i dag existerande busar.
Att man sedan kan hantera busskollisioner i olika protokoll är en annan sak, men eftersom Modbus är ett ren Master/Slave protokoll, så finns inte behovet att hantera busskollisioner, eftersom de inte existerar.

Du har missuppfattat vad Klas-Kenny skrev.
Polling betyder att mastern frågar slav efter slav,.
Polling betyder INTE att slavarna skickar efter eget behag.
Polling betyder att slaven bara svarar på det den efterfrågas om.
Så polling är följande':
Mastern begär ett register från slav 1, får det.
Mastern begär ett register från slav 2, får det.
Mastern begär ett register från slav 3, får det.
Mastern begär ett register från slav 4, får det.

osv

Jag förstår vad du menar. Men ett fysiskt lager som både kan skicka ut kors och tvärs och skick ut data på förfrågan, anser jag mer som mer välkonstruerat än ett fysiskt lager som endast kan skicka ut dat på förfrågan, annars riskerar kollision.

Jag skrev inte att polling betyder att slavarna själva skickar ut data på egen begäran. Jag skrev att jag tänkte på det Klas-Kenny sa om polling och Klas-Kenny argumenterade att det är bra om slavarna själv skickar ut data och Klas-Kenny menade inte att polling betyder att slavarna själv skickar ut data. Klas-Kenny menar att polling(det vi alla har i samma uppfattning) är att mastern frågar slaven och slaven skickar data.

Tänk dig som Klas Kenny sade angående om polling. Jag hade inte tänkt på detta, men det låter smart att slavarna får berätta vad dom har för mätvärden och liknande, istället för att en master ska ständigt fråga. Då behöver bara mastern fånga upp meddelanden.

Du som har koll på Modbus TCP/IP. Måste man använda trådar om man ska använda TCP/IP?
Jag menar, man starta alltid en server som väntar på en klient. När det blir en anslutning och man vill ansluta en till klient, då måste man starta en ytterligare server som väntar på en anslutning. Eller hur?

Så om man har 10 anslutningar så innebär det 10 trådar?

Även jag beundrar TS och hans sökande efter den helige Gral!
Men CD var väl på något protokoll, så att man slumpvis satte ett fördröjnings ms för att undvika att det krockade igen!

Jag förstår vad du menar. Men ett fysiskt lager som både kan skicka ut kors och tvärs och skick ut data på förfrågan, anser jag mer som mer välkonstruerat än ett fysiskt lager som endast kan skicka ut dat på förfrågan, annars riskerar kollision.

Det existerar inga fysiska lager som kan hantera flera anslutningar samtidigt.
Kollisionshantering sker på en högre nivå.
Oavsett vilket fysiskt gränssnitt du har, kan det bara finnas en sändare i taget.

Skall du kunna acceptera flera anslutningar med TCP/IP, så måste du nog köra flera trådar.

Lasp skrev: ↑7 oktober 2021, 10:41:33 Även jag beundrar TS och hans sökande efter den helige Gral!
Men CD var väl på något protokoll, så att man slumpvis satte ett fördröjnings ms för att undvika att det krockade igen!

Låter som att det är Ethernets kollisionsdetektering (eller snarare collision avoidance efter att en kollision detekterats) du tänker på.

Nu har jag inte programmerat för den aktuella arkitekturen, men inte ska det krävas några trådar för att hantera flera anslutningar? En select()-loop är standardsvaret, för det anropet måste väl finnas tillgängligt?

Hur trådarna i mjukvaran hanteras hänger väl snarare ihop med hur protokollen implementeras än vilket det faktiska protokollet än. Har man möjlighet till trådar kan de ju vara smidiga att använda, har man ingen möjlighet så får man lösa det utan trådar helt enkelt (t.ex med select och poll som nämnts).

Lasp skrev: ↑7 oktober 2021, 10:41:33 Även jag beundrar TS och hans sökande efter den helige Gral!
Men CD var väl på något protokoll, så att man slumpvis satte ett fördröjnings ms för att undvika att det krockade igen!

Inte bara en helig Gral. Ännu bättre!

Föreställd dig att kombinera CANopen med TCP/IP?
Du har en hög med molijoxer och mojänger (även kallat produkter från ABB, Siemens, Bosch, Schneider med mera) som talar CANopen och du vill läsa utav CANopen protokollet över nätet.

Hur gör man då? Jo, man bygger ett kretskort som har USB <--> CAN-bus. Sedan bygger man en PC-mjukvara som kan tala med USB och mjukvaran kan även ha en TCP/IP server. Där efter bygger man ett protokoll i C som talar CANopen, som dessutom fungerar utmärkt med PC mjukvaran.

Sammanfattning:
1. Kretskort som har USB och CAN-bus
2. Kretskortet har CANopen som protokoll
3. Kretskortet talar med PC via USB
4. Hos PC finns det mjukvara som läser CANopen kommandon via USB
5. Mjukvaran har en TCP/IP server
6. Användare kan ansluta TCP/IP servern och komma in på CANbus nätverket via USB

TomasL skrev: ↑7 oktober 2021, 10:56:14 Det existerar inga fysiska lager som kan hantera flera anslutningar samtidigt.
Kollisionshantering sker på en högre nivå.
Oavsett vilket fysiskt gränssnitt du har, kan det bara finnas en sändare i taget.

Du vet inte hur det fungerar? Vore intressant. Var korrekt nu, du har haft mycket fel i denna tråd angående diverse saker nu

TomasL skrev: ↑7 oktober 2021, 11:07:15 Skall du kunna acceptera flera anslutningar med TCP/IP, så måste du nog köra flera trådar.

Då vet jag exakt vilket ramverk och språk jag ska köra. C++.

davidi skrev: ↑7 oktober 2021, 12:02:15 Nu har jag inte programmerat för den aktuella arkitekturen, men inte ska det krävas några trådar för att hantera flera anslutningar? En select()-loop är standardsvaret, för det anropet måste väl finnas tillgängligt?

Jag har kört Sockets förut och då fick man alltid vänta på anslutning. Du kan ju köra med icke-blockering, men det blir svårt att pricka anslutningen då med klienten.

Eller så köper man en sådan här och ser glad ut, behövs varken USB eller PC
https://www.amazon.com/Ethernet-Interfa ... B07Y8SS25C

Det finns ingen anledning att gå via USB, dessutom finns redan många gateways på marknaden som omvandlar J1939 och CANopen till olika varianter av TCP. Exempelvis från Coperhill, Moxa, ICP-DAS (och olika kineser som Ajje länkade).

https://www.icpdas-usa.com/canbus_gateways.html

ajje skrev: ↑7 oktober 2021, 12:50:46 Eller så köper man en sådan här och ser glad ut, behövs varken USB eller PC
https://www.amazon.com/Ethernet-Interfa ... B07Y8SS25C

Hur fungerar en sådan liten apparat?
Det måste väll vara någon TCP server på den som man ansluter och sedan så kan man skicka ID, DLC och DATA ut på CAN-busnätet?

mrfrenzy skrev: ↑7 oktober 2021, 12:56:19 Det finns ingen anledning att gå via USB, dessutom finns redan många gateways på marknaden som omvandlar J1939 och CANopen till olika varianter av TCP. Exempelvis från Coperhill, Moxa, ICP-DAS (och olika kineser som Ajje länkade).

https://www.icpdas-usa.com/canbus_gateways.html

Häftiga saker! CAN över nätet måste vara revolutionerande med tanke på att nästan alla inbyggda system idag har CAN.