modbus v.s. canbus

[SeniorLemuren]

Jag såg att AI hade hade missat detta så jag påpekade detta.

AI ChatGPT fellhantering-2.png

[SeniorLemuren]

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.

Ja, du har helt rätt. Jag missade det helt. Problemet är löst.

[TomasL]

chatgtp har nog fel i detta.
Föreslår att du läser standarden, så förstår du vad det handlar om.
tyst->Master sänder>1,75ms->Slav1 svarar->1,75ms->master sänder->1,75ms->slav2 svarar->1,75ms->master sänder->1,75ms->slav svarar->1,75ms
Det tar minst 8,75 mms att få runt meddelandena, nu har jag inte räknat med tiden det tar att sända och ta emot, samt hantera, 8,75ms är väntetiden.
så lägger vi på 3x350us, så blir det 1,05 ms, det är ju så att vi skickar ju inte 16 bitar, vi skickar också slavadress, kommando och CRC, dvs 7-8 byte per meddelande.
Så för förfrågan och svar är det 2x250 us, dvs 0,5 ms, sedan får vi lägga på lite, som du själv påpekat 100 us för behandling, dvs 0,6 us/driver, så dataöverföringen tar 1,8 ms plus väntetiden om 8,75ms totalt blir det då 10,55 ms för att få hem och hantera data från tre drivers.

[SeniorLemuren]

Ja men du har säkert mer rätt än AI. Men så finns det ju en medlem som har mest rätt och det är ju H.O som gjorde det enda rätta, nämligen kollade i manualen och hittade detta: OUT_1 port output stall indication. Vilket ju är exakt det jag vill komma åt.

[TomasL]

Och det skrev jag för ett par inlägg sedan, att du behövde titta på en hårdvarulösning.
Kanske kommer som en överaskning, men jag har jobbat rätt mycket med modbus (i typ 20 år), och implementerat egna masters och slavar, så jag har hyffsat bra koll på hur MODBUS funkar.

[bobobo]

Mycket snack om ms hit och dit i kommunikationen.

Hur lång tid tar det för reläet att släppa efter att du bryter spolspänningen? (Jag kollade hastigt på ett weidmuller interfacerelä som hade 16ms reaktionstid)

Och ännu viktigare, hur lång tid tar det för din maskin att accelerera till max hastighet, eller stanna?
Hur stora krafter blir det på mekaniken om du ska stanna från full fart till stillastående på 0,2mm?!

[TomasL]

Jag tror att det Senioren vill uppnå är omöjligt.
Stegmotorer är nog helt fel i detta läge, servon med enkoder och bra drivers, vilka hanterar sådana här fel helt internt är sannolikt lösningen.
Alternativt är ju att sänka matningshastigheten markant.

[hawkan]

Motortypen är inte det viktiga, det viktiga är att få en tillförlitlig signal om verklig position.
I ett cnc-system vill man ha det med mindre än nån millisekund fördröjning.
Servo-system har detta naturligt, closed-loop stegmotorer också.
Det går att sätta på i efterhand, t ex linjärskala.
När de används för detta syften är det vanligaste att en enkoder ger kvadratursignal.
Har man ett cnc-system bör man kunna leda in den signalen i cnc-systemet och varje millisekund eller så
kunna se hur stort positioneringsfelet är.
Man får testa sej fram till vad som är ett oacceptabelt stort positioneringsfel, för både servo-system
och stegmotorer har en viss eftersläpning, skärkrafter varierar i maskinen, acceleration osv, flexibilitet i alla delar,
hur vältunat servosystemet är.
Så man måste acceptera ett visst positioneringsfel, frågan är hur stort det ska vara för att dra i nödbromsen.
Allt sånt går att testa fram, man måste starta med en positionssignal och det bästa är att ta den direkt från motorns enkoder.
Jag har inte sett att det finns en rå positionssignal från en magnetisk enkoder. Här är det via Modbus eller CAN.
Den jag testade hade i2c.
Det här handlar väl om en fräs med dubbla X-axlar (eller Y). Då är det bättre att gå på closed-loop stegmotorer.
I första läget kan man låta bli att göra något, drivarna stannar själv om felet blir för stort. Utan att veta hur stort felet är. Men det stannar.
Sedan kan man leda in enkodersignalen i cnc-system och använda det för fintuning av felgränsen.
Closed-loop stetgmotor-kit kostar en del.

Tittade på magnetiska enkoder icn, det är https://www.allegromicro.com/~/media/Fi ... sheet.ashx
Den har faktiskt möjlighet att få kvadratur-signal. Alternativt kan man läsa läget via SPI och det är tillräckligt snabbt säger jag utan att ha kollat.
Så, ett enkoder-projekt? Obs att det är speciella magneter, med halva pajen N och andra pajen S, inte som vanligt att övre sidan är N och under S (annars vänd på den).

Suck, det blev alldeles för långt.

[hawkan]

Och för att allt ska vara vettigt behöver man både avsedd position och verklig position, eller snarare differensen mellan dessa.
Avsedd position finns i cnc-systemet.

[Jan Almqvist]

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.

Jag har funderat på nyttan av denna paus och kommit fram till att det faktiskt finns, eller åtminstone fanns, en liten poäng med pausen. Direkt när en Modbus RTU enhet läst första tecknet, som är Device ID (eller adress) så kan den, om Device ID inte stämmer med adress för den aktuella enheten, ignorera alla tecken fram till nästa paus. Detta kunde absolut vara en fördel på 70-talet när CPU:erna inte särskilt snabba och det är kanske därför denna pausen finns i specifikationen. Idag finns ingen anledning att göra så, alla telegrammottagare oavett om det är server eller klient kan enkelt behandla alla telegram (Request och Response) och därför veta var varje nytt telegram börjar. Jag kan inte minnas att jag sett någon paus i en specifikation för något annat protokoll och under förutsättning att man gör telegrammottagaren på "rätt" sätt finns det inget behov. Jag har stött på andra liknande protokoll som körs utan paus, Response kommer direkt efter Request. Jag minns att för ett visst protokoll så var det ett till och med ett krav att Response skulle komma direkt. Vi labbade för 40+ år sedan med en optisk länk som jag tror gav en fördröjning mostvarande tiden för ett tecken och då accepterades inte svaret.

[TomasL]

Dessutom var det nog så att adressen rätt ofta avkodades i hårdvara.