modbus v.s. canbus

[TomasL]

Du skall alltså hämta in data från 3-4 servon och hantera dessa på 3,3 ms, nåväl hur mycket data skall du hämta, och hur är de organiserade?
Ponera att du skall hämta 2 byte per servo, det blir vid 8N2:
TX:7 ord ink checksumma
RX: 7 ord ink checksumma
Minsta tid mellan två meddelanden 1,75 ms
Så du skall skicka 2x7 ord med 1,75ms mellan orden, varje ord är 11 bitar långt, det innebär att även vit extremt höga busshastigheter så klarar du det inte, då det tar minst 14 ms att prata med 4 servon
så vid säg 230kbps så tar det lite över 4 ms för att få hem data från en driver, för 4 st tar det då strax under 16 ms, så nej det kommer knappast att fungera.
Tror nog att du får leta efter en annan lösning.

Du behöver en driver som själv upptäcker felet och gör rätt sak, när felet uppträder, samt sätter en larmpinne.

[hawkan]

Såg att Modbus-varianten kunde 256000 bit/sec, så det kanske hinns med?

[TomasL]

Fortfarande oavsett bit-hastighet, så är det 1,75 ms mellan varje meddelande, så nej det hinns knappast med,
Det tar 4+ ms att göra en komplett transaktion med en slav. Det går inte göra det fortare.

Med en ordentligt välskriven och optimerad TCP-IP stack och inget annat på linan går det kanske att få saker snabbare med MODBUS-TCP, men då är det lämpligt att köra DMA på porten.

[MiaM]

Säkert att denna Arduino inte ska göra något mer? T.ex. tala om för användaren att något gått snett, eller ta emot kommandon från en dator?

Frågar detta eftersom dessa saker, speciellt kommunicera med ansluten dator, tar upp viss prestanda, och det verkar extremt märkligt om den inte skulle göra detta.


Om den enbart har en byte buffer i hårdvara så kanske det är enklast att skriva allt som en busy-wait-loop och låta den prata med dator eller liknande via något protokoll där varje överförd datamängd handskakas, typ ack-puls för varje datamängd. Om pinnarna räcker så ta minst åtta bitar i taget, kanske än mer.

Jag hade nog personligen använt en PC med DOS (d.v.s. utan "riktigt" operativsystem) för att göra denna typ av jobb, men det är ju förstås otympligt när datorer som duger till detta blir allt ovanligare. Annars framstår två 16550 UART eller liknande som förträffligt för detta jobb.

Finns det annars inte nån mikrokontroller som är typ fokuserad på uart-mässiga sysslor?

Det känns allmänt som att ifall du ska använda Arduino så är det nog läge att skriva preliminär mjukvara (och ev provköra mot andra Arduino som simulerar servomotorerna) för att testa att det verkligen är rimligt.

[FormerMazda]

https://www.amazon.se/-/en/AZDelivery-D ... LQHGZ?th=1

5st ESP32 för 360kr.
Varje CPU har två kärnor och klockfrekvens 240MHz.
Sätt en per axel, braka loss med så snabb modbus du bara kan.
Sen finns inga frågetecken kvar kring om det hinns med eller inte, allt löst för 360kr.

[TomasL]

Oavsett vilken prolle/system man använder är Modbus och CAN fel val, då protokollen inte är avsedda för detta, de är för långsamma,helt enkelt.

Former, inte ens en prolle per axel hinner med, läs ovanstående.

[SeniorLemuren]

Säkert att denna Arduino inte ska göra något mer? T.ex. tala om för användaren att något gått snett, eller ta emot kommandon från en dator?

Det enda den skall göra är att släppa ett draget relä när något går snett.
The Arduino Due is a microcontroller board based on the Atmel SAM3X8E ARM Cortex-M3 CPU. It is the first Arduino board based on a 32-bit ARM core microcontroller. It has 54 digital input/output pins (of which 12 can be used as PWM outputs), 12 analog inputs, 4 UARTs (hardware serial ports), a 84 MHz clock, an USB OTG capable connection, 2 DAC (digital to analog), 2 TWI, a power jack, an SPI header, a JTAG header, a reset button and an erase button.

CNC-fräsen körs helt separat av ett annat system.

[Icecap]

Som Thomas säger är det inte bara kommunikationshastigheten som är viktig vid MODBUS.
1.75 ms EFTER sista byte i frågan kan svaret starta skickas.

Den tid är ganska fast, oavsett kommunikationshastighet.

[Jan Almqvist]

Torde inte 1.75 ms gälla vid 19200 Baud?
Specen säger väl 3.5 x teckentiden och denna siffra sattes kanske för över 40-50 år sedan när CPU:er gick på typ 1 MHz?
Jag kan inte se något hinder för att köra fullt blås dvs ingen paus mellan Request och Response och inte heller någon paus mellan Response och nästa Request.

[Mindmapper]

https://www.amazon.se/-/en/AZDelivery-D ... LQHGZ?th=1

5st ESP32 för 360kr.
Varje CPU har två kärnor och klockfrekvens 240MHz.
Sätt en per axel, braka loss med så snabb modbus du bara kan.
Sen finns inga frågetecken kvar kring om det hinns med eller inte, allt löst för 360kr.

Man behöver väl bara en mpu som har 4 st serieportar. Det borde vara möjligt att hinna med att hålla koll på dessa 4. låt säg att du parar ihop rätt kanaler så kan du ge ut en error signal.

Förutsättningen är väl om drivrarna måste vänta eller kan svara på en ny request utan väntan. Som HMI Droid säger.

[SeniorLemuren]

Så här tyckte ChatGPT: Obs. Endast 3 motorer. Jag skippade Z-axeln.

AI ChatGPT fellhantering.png

Jag påpekade att det fattades tidsberäkningar för bearbetning av data och fick detta:

AI ChatGPT fellhantering-1.png

[Jan Almqvist]

ChatGPT tar inte hänsyn till den overhead som finns i Modbus-meddelandena för request och response.
Om man läser ett (1) Holding register med Modbus RTU blir det totalt 8 respektive 7 tecken.
https://www.simplymodbus.ca/FC03.htm

[TomasL]

Torde inte 1.75 ms gälla vid 19200 Baud?
Specen säger väl 3.5 x teckentiden och denna siffra sattes kanske för över 40-50 år sedan när CPU:er gick på typ 1 MHz?
Jag kan inte se något hinder för att köra fullt blås dvs ingen paus mellan Request och Response och inte heller någon paus mellan Response och nästa Request.

Standarden säger ordagrant:

The implementation of RTU reception driver may imply the management of a lot of interruptions due to the t1.5 and t3.5 timers. With
high communication baud rates, this leads to a heavy CPU load. Consequently these two timers must be strictly respected when the
baud rate is equal or lower than 19200 Bps. For baud rates greater than 19200 Bps, fixed values for the 2 timers should be used: it is
recommended to use a value of 750μs for the inter-character time-out (t1.5) and a value of 1.750ms for inter-frame delay (t3.5).

Så, ja, det är 1,75 ms som gäller mellan meddelanden.
Allting annat ligger utanför standarden, och fungerar nödvändigtvis inte alltid.
Pausen används för att slaven (och mastern) skall kunna synkronisera sig, eftersom man normalt sett kör på endast två trådar.

Om man har säg tre slavar anslutna, så kan de andra slavarna, när en slav sänder sitt svar få för sig att detta är för dem, och börja sända samtidigt, med denna synkronisering, dvs pausen på 1,75 ms, så vet alla slavar att det är ett nytt meddelande som kommer på bussen, och eftersom de då kan avkoda det, så vet de också att de inte skall svara på det.
Just därför är det viktigt att hålla koll på pauserna mellan meddelanden.

Detta ger en roundtrip på lite över 4ms per meddelande, det går helt enkelt inte köra fortare, oavsett busshastighet.

[Mindmapper]

Nästa fråga blir hur ofta standarden följs?

Till syvende och sist är det hur tillverkaren implementerar standarden som bestämmer.
Jag har stött på avvikelser från standarden flera ggr. Ändå är jag ingen som håller på så mycket med Modbus.

[TomasL]

Just när det gäller dessa saker så följer alla tillverkare den, att de sedan har tänjt på saker som 32/64-bits register, samt möjligheten att köra 8x1 istället för 8x2 som standarden säger är en annan sak som de ofta har lagt till, men de alternativ som standarden anger, dvs 8x2 stöds alltid.
Timingen är en förutsättning för att kunna köra enheter från olika tillverkare tillsammans, på samma lina, är något som är heligt.