modbus v.s. canbus

[FormerMazda]

Använd en flerkärnig uC, typ ESP32, och kör kommunikation på en kärna och övrigt på en annan kärna.
https://randomnerdtutorials.com/esp32-d ... duino-ide/

Valet mellan modbus och canbus så känner jag spontant att för säkrare och snabbare saker så hade jag föredragit canbus, men modbus i 19200baud kan hantera rätt mycket data rätt snabbt det med.

[TomasL]

Modbus, du måste polla slaven konstant.
CAN om det är rätt gjort, ligger du och lyssnar på meddelanden, dvs du behöver inte polla

Fast jag ser inte någon skillnad rent funktionsmässigt. 4 st drivrar kommer att sända data hela tiden. varvtal pulser, vinkelfel m.m så jag måste i alla fall kolla inkommande data från alla hela tiden för att se om för stort vinkelfel inträffat på någon av dem.

Jo, det är stor skillnad, med MODBUS kan dina driver inte sända, enbart svara på Masterns förfrågningar, vilket gör att man alltid vet när data från en specifik slav kommer, samt hur mycket data som kommer.

Med CAN kan de sända själva, men då måste man hantera slumpvisa meddelanden samt meddelanden av okänd längd., vilket kan vara komplicerat.

[mrfrenzy]

I detta fall när du ska ha kontinuerlig data från flera enheter hade jag definitivt valt CAN, det blir mycket effektivare än att polla och vänta på svar från en enhet i taget. Vid boot eller konstruktionsfasen så ställer man in vilka signaler varje "slav" ska skicka och sedan bara strömmar det in data.
Dessutom är det ju mycket högre hastigheter att välja på. Ofta i små nät kör man 256 kbps eller högre om det behövs.

[H.O]

Fast om man gör sig besväret att RTFM så ser det ju ut se att de implementerat CAN på exakt samma sätt som MODBUS, dvs fråga/svar.
Så vitt jag kan se "streamar" korten ingenting av sig själva, CAN ID använder de som "slav ID" och varje slav måste "pollas", precis som med MODBUS. Skum implementering.

Länk till manualen jag tittade i.

[SeniorLemuren]

Det är precis så jag fattade det också. Grejen här är att denna övervakning sker i en egen Arduino som inte skall göra något annat än att just övervaka. Fräsen styrs av ett anat system.

[MiaM]

Googlade lite, tog första bästa resultat utan att läsa särdeles noga så dubbelkolla allt detta före det används som faktisk beslutsgrund:

Modbus verkar ofta köra 9600bps.

Arduino (utan närmare specifikation) verkar ha UART-buffert på 63/64 bytes.

Det betyder att man kan ha interruptdriven kod som t.ex. körs på timerinterrupt som pollar UART minst 16 gånger per sekund, eller minst var 65:e millisekund. Det är väldigt sällan sett ur prestandaperspektiv, så det bör gå utmärkt att ha diverse annan kod körandes samtidigt som interrupter sköter om modbus-kommunikation.

OBS att i det jag föreslår ovan så har man UART-interrupt avslagen och använder timer för att polla den. På så vis får man en känd responstid (mellan drygt noll och upp till 65 ms beroende på hur indata råkar synka med timern) men framförallt 100% förutsägbar processorbelastning oavsett hur mycket/lite data som ska skyfflas, minus tiden det går att att faktiskt flytta data mellan ram och uartbuffert samt eventuell processning.

Antar att just alarmhantering ska skötas av interruptrutinen. Vet inte hur bra/dåligt det går att låta en Arduino använda interrupt på så vis att man inte återvänder till vad man gjorde innan, utan avbryter det. Fast för typ nödstoppscenarior så kan man väl kanske bara starta om hela Arduinon i värsta fall - jag utgår från att den bara kommer användas som slav till en "vanlig dator" och därmed finns det väl inga tillstånd som behöver sparas osv.

[Icecap]

Att i detta köra utan RX-interrupt ville vara dumt.

Ett MODBUS-meddelande med typ fråga på ett register blir typ 8-9 bytes, svaret ung. det samma.

Så med 9600 baud blir en total sekvens 18 bytes o tar 19 ms totalt.
Dekodningen av svar lär gå riktigt snabbt så med interruptstyring tar en komplett sekvens ung. 20 ms.

Sändning bör såklart också ske vid att skriva till en buffer som sedan töms medelst tx-empty-interrupt.

Störstadelen av tiden är ju överföringshastighet så "dubbla" den o det hela sker mycket snabbare.

[TomasL]

När det gäller Modbus, så kommer alltid svaret några ms efter det man skickat förfrågan, slaven sänder aldrig om den inte blivit ombedd att göra så, man får aldrig mer data än man begärt.
Beträffande hastighet, så kan man köra Modbus precis så fort som uartarna och processorn hinner med, det finns ingen övre gräns.

[Icecap]

Just det, nu minns jag. End-Of-Transmission är 3-4 bytes tid utan data.
Det gör ju såklart att det tar lite extra tid så 19k2 hade varit minimum för mig.

[MiaM]

Det låter som ytterligare ett skäl att använda timer snarare än UART-interrupt, men då kanske sätta önskad timertid varje gång man startar sändning. Tiden det tar att sända och därefter ta emot ett visst antal bytes är ju känd. Med UART-interrupt så måste man istället krångla med att ställa in så att man får interrupt då man tagit emot t.ex. 17 tecken, ifall det ens går att göra så, och ifall man tappat något tecken eller något annat blivit knas så kör man fast på att inget händer och kommunikationen med alla enheterna dör för att man hamnat i ett deadlock i väntan på svar från en enhet som inte svarar korrekt.

[Icecap]

En Arduino har bara 1 byte "FIFO" vid mottagning o sänding.

Arduino-basen tar däremot hand om interrupten o packar de mottagna bytes i en buffer.

Om själva μC'n har en större inbyggd FIFO lär det vara mycket speciellt.
De 32-bitars jag jobbar med har bara 1 byte mottagnings o sändingsbuffer, resten styrs med interrupts.

[SeniorLemuren]

Ok. Jag har inte tänkt så mycket på hur det hela skall byggas programmässigt. Men låt oss säga att jag har en rutin som läser in vinkeln på de 4 drivrarna och hela tiden kontrollerar om någon har en för stor avvikelse,

Om det inte inträffar så gör jag ingenting. Om det blir en avvikelse så enablar jag alla motorer, Jag är inte riktigt med på att man hela tiden talar om interupt. En loop som hela tiden håller koll på vinkelfel och gör något via en if är ju allt som behövs såvitt jag förstår.

[TomasL]

Nu vet jag inte vad din Arduino skall göra, mer än ren övervakning, dock hur man löser programvaran beror ju på hur snabbt saker och ting skall hanteras.
Hur man löser RX/TX beror ju på hur många register som skall läsas och hur långa de registren är.
För TXen så är det rätt enkelt, man talar bara om hur många register man vill ha och startpositionen, dock förutsätter det att registren ligger i en rad.
Om de inte gör det, får man initiera en läsning för varje registeruppsättning, sedan ligger man och väntar tills slaven svarar.
Man behöver använda interrupt, så man kan stoppa undan värdena i en buffert, allteftersom de trillar in, men det beror ju på hur lång FIFO UARTen har.
TX mår bra av interrupt också, återigen beror det på hur lång FIFOn är.
Det är speciellt viktigt när man kör i högre hastigheter.
Timer mm behöver man för att hålla koll på EOT, och om slaven timar ut.

[SeniorLemuren]

Jag har just nu tagit helg. Ja, det är i dag min pension utbetalas. det innebär att detta är den enda dagen i månaden jag tar mig ett par rejäla groggar. Skåål.

Men Ok. tillbaks till tråden. TomasL vet inte vad Arduinon skall göra mer än ren övervakning trots att jag talat om att den bara skall användas till övervakning. Ja det är ju bra. Då vet man ju att man kan räkna ut honom. Men sedan har han ju en poäng. Han frågar sig hur snabbt skall saker hanteras. Det är ju faktiskt själva grundfrågan.

Ok. Min fräsmaskin körs i max 2500 mm/min. Går det fel med 0.2 mm så behöver jag bryta för att undvika problem. 0.2 mm tar alltså 0,0033 sek. Det är den tid som man måste läsa in, räkna ut och bryta. Nu använder jag en Arduinio due på 84 MHz clock. så det borde vara gott om tid för att hantera vad som skall hanteras oavsett Mobus/ CAN.

Så det väl väl inte riktigt tidsaspekten vi talar om. Utan mer vilken lösning som är mest praktisk och enkel, utan att krångla till det så ini bomben som vissa har förmågan att göra.

[H.O]

I den andra tråden länkade du till MKS57C och som vi konstaterade där så verkar den inte ha någon felutgång. I den här tråden länkar du istället till MKS57D som enligt manualen HAR en fel-utgång

OUT_1 port output stall indication

Lösningen på problemet är kanske så enkelt som att köpa rätt version.