Vilket MODBUS bibliotek använder du?

[Shimonu]

Varför skriver du inte varför fördröjningen är viktig i din kommentar? Du skapar bara frustration genom att inte dokumentera vad som är så viktigt med den. Det får mig att tro att du bara lagt in det utan att förstå varför men det råkade lösa problemet.

[pfyra]

Håller med om kommentaren. Det blir egentligen än mer viktigt när man inte vet varför, för då finns det heller ingen förklaring att hitta i nån annan dokumentation heller (t.ex modbus-spec eller nåt sånt).

Hur anropas uart_read? Det är inte i från en isr väl? Och inte pollar du väl när du har dma uppsatt?
hur som helst så känns det rimligare att se till att funktionen inte anropas för ofta snarare än att låta funktionen fördröja sig själv.

Det kan väl också tänkas att du har ett OS inblandat, då är det lämpligare att använda osDelay(), för HAL_Delay är en busy-loop och kan hindra andra taskar från att köras.

[TomasL]

Förstår inte vad som pollas, i Modbus pollar man ingenting, då allting händer i realtid.
Slaven måste reagera på RX-interrupt vilket måste ha en hög prioritet.
Mastern sätter samman meddelandet i en lämplig struktur, och skickar iväg detta, sedan reagerar mastern på RX-interrupt med hög prioritet.
När slaven svarat, defaultar mastern alltid till avstängd TX och RX.

När jag har både Master och TCP-server i samma processor, så är TCP-Servern av lägre prioritet, då har jag en DMA kanal uppsatt, som vid RX-interrupt fyller upp en TCP-RX struktur, så jag kan hantera den när RTU-Interrupten är hanterade.

Det finns ingen som helst anledning att krångla till saker med polling, snarare verkar detta vara implementerat av någon som inte förstår hur Modbus fungerar.

[hawkan]

Det är väl början på något.
Jag förstod att DanielM önskade något asynkront och där är inte koden alls.

[DanielM]

Varför skriver du inte varför fördröjningen är viktig i din kommentar? Du skapar bara frustration genom att inte dokumentera vad som är så viktigt med den. Det får mig att tro att du bara lagt in det utan att förstå varför men det råkade lösa problemet.

Jag har lagt in en kommentar nu.
Jag är inte 100% säker på vad felet kunde vara. Men tydligen så verkar det som att min DATA_RX array fylls på långsammare än vad DMA kan räkna.

Håller med om kommentaren. Det blir egentligen än mer viktigt när man inte vet varför, för då finns det heller ingen förklaring att hitta i nån annan dokumentation heller (t.ex modbus-spec eller nåt sånt).

Hur anropas uart_read? Det är inte i från en isr väl? Och inte pollar du väl när du har dma uppsatt?
hur som helst så känns det rimligare att se till att funktionen inte anropas för ofta snarare än att låta funktionen fördröja sig själv.

Det kan väl också tänkas att du har ett OS inblandat, då är det lämpligare att använda osDelay(), för HAL_Delay är en busy-loop och kan hindra andra taskar från att köras.

Du ska hålla med mig. Jag som har skrivit koden och gett ut den gratis

UART read anropas igenom DMA. Så fort min ST processor får ett meddelande via DMA så fylls en array DATA_RX på helt automatiskt. Jag behöver inte anropa någon kod eller liknande. Detta är en grafisk konfiguration i STM32CubeIDE. Jag "pollar" när jag vill läsa om det har kommit in något nytt meddelande. Detta gör jag i min oändliga while-loop.

Om du testar att ladda ned min kod som jag laddade upp på föregående sida. Då kan du enkelt sätta upp nanoMODBUS.

Förstår inte vad som pollas, i Modbus pollar man ingenting, då allting händer i realtid.
Slaven måste reagera på RX-interrupt vilket måste ha en hög prioritet.
Mastern sätter samman meddelandet i en lämplig struktur, och skickar iväg detta, sedan reagerar mastern på RX-interrupt med hög prioritet.
När slaven svarat, defaultar mastern alltid till avstängd TX och RX.

När jag har både Master och TCP-server i samma processor, så är TCP-Servern av lägre prioritet, då har jag en DMA kanal uppsatt, som vid RX-interrupt fyller upp en TCP-RX struktur, så jag kan hantera den när RTU-Interrupten är hanterade.

Det finns ingen som helst anledning att krångla till saker med polling, snarare verkar detta vara implementerat av någon som inte förstår hur Modbus fungerar.

I nanoMODBUS så pollar man för att läsa "har det kommit in något nytt?". Om fallet är JA, så läser den meddelandet och tar ett beslut vad den ska göra.
Ett RX-interrupt innebär att man måste veta exakt hur mycket som skickas. Detta betyder att jag sätter en gräns t.ex. "När det har kommit in 4 bytes, då ska min interrupt aktiveras".
Visst, jag kan ha en RX-interrupt som reagerar vid 1 byte. Jag har dock inte testat. Jag är mera van vid DMA.

Mitt DMA triggar två callbacks faktiskt. När bufferten är full eller halvfull. Men detta har jag inget behov utav.

Det är väl början på något.
Jag förstod att DanielM önskade något asynkront och där är inte koden alls.

Det enda jag vill göra är att läsa ett meddelande när den finns tillgänglig. Utan några krångel

[DanielM]

Om ni undrar vad jag pysslar med så håller jag på att implementera ett linjärt kalmanfilter och en linjär MPC på en mikrokontroller.
För att ha en proper kommunikation för att sätta parametrarna och även mäta lite data för att kunna göra systemidentifiering av modellen, så använder jag modbus som kommunikationsprotokoll.

Här är ett exempel på kalman filter.
En stark motivering att använda ett Kalman Filter, är att med ett KF så blir det ingen eftersläpning på signalen, vilket det kan bli för ett vanligt lågpassfilter. KF används ofta inom reglersystem där fördröjning kan skapa en sorts olinjäritet, vilket skapar ostabilitet hos reglersystemet. KF finns både i linjär form och olinjär form. Vilken man ska använda beror på problemet. Vanligaste är linjärt då dom är numeriskt stabila för alla tillstånd(position, hastighet, temperatur och övriga mätsignaler), vilket inte kan garanteras med ett olinjärt KF. Nackdelen är att linjärt KF fungerar bara under vissa tillstånd. En stark rekommendation är att använda flera olika linjära modeller beroende på situation, eller linjärisera sin olinjära modell innan linjär KF tillämpas. Linjäriseringen brukar tillämpas via jacobianer.

Ett kalman filter kan användas för två situationer:

• Filtrera bort brus
• Estimera ett tillstånd som ej kan mätas t.ex. där givare ej kan monteras på en viss position, men positionen måste mätas oavsett. Solen är ett bra exempel på extrema miljöer.

Ett KF fungerar som att det finns en dynamisk beskrivning(model) som kan simulera nästa mätvärde. Men vi vet inte om den dynamiska beskrivningen är den korrekta jämfört med det verkliga mätvärdet. Ett förstärkningsfaktor räknas då ut statistiskt av KF som kombinerar det faktiskta mätvärdet och det simulerade mätvärdet. Denna förstärkningsfaktor avgör hur mycket avvikelser från verkliga mätbruset som ska tas hänsyn till, jämfört med simulerade.

KF_Result.png

Denna modell är på formen
\(x(k+1) = Ax(k) + Bu(k)\\ y(k) = Cx(k)\)
\(x(k+1) = 9.9154*10^{-1}*x(k) + 4.8969*10^{-3}*u(k)\\ y(k) = 1*x(k)\)

Här är observationsmatrisen C = 1 vilket betyder att jag vill bara filtera bort brus.

[TomasL]

I nanoMODBUS så pollar man för att läsa "har det kommit in något nytt?". Om fallet är JA, så läser den meddelandet och tar ett beslut vad den ska göra.
Ett RX-interrupt innebär att man måste veta exakt hur mycket som skickas. Detta betyder att jag sätter en gräns t.ex. "När det har kommit in 4 bytes, då ska min interrupt aktiveras".
Visst, jag kan ha en RX-interrupt som reagerar vid 1 byte. Jag har dock inte testat. Jag är mera van vid DMA.

Det måste vara en av de sämsta implementationerna jag någonsin hört talas om.

Naturligtvis behöver man inte veta hur mycket som skall tas emot i ett RX-interrupt, det är fullständigt felaktigt.
Du kan problemfritt ta emot ett oändligt antal bytes i ett enda RX-interrupt.

Dessutom kan en PDU aldrig vara längre än 256 bytes, det är maxlängden på ett meddelande.

De visar bara att den som skrivit rutinen inte har en blekaste aning om hur saker och ting fungerar, varken hårdvarumässigt eller mjukvarumässigt.

[DanielM]

Notera att nanoMODBUS fungerar för all hårdvara.
Man kan köra detta på någon sliten gammal 8-bitare.

[hawkan]

Låter som det vore bättre med ett simpelt serie-interface för att sätta parametrarna.
Eller varför inte byta till esp32 och göra en websida för att ställa in.
Kanske ett rest api om du behöver automatisera.
Då slipper du mycket av Modbus begränsningar.

[TomasL]

Notera att nanoMODBUS fungerar för all hårdvara.
Man kan köra detta på någon sliten gammal 8-bitare.

Även gamla slitna 8-bitare har RX-buffert.
Dessutom gamla slitna 8-bitare har inte tillräckligt med programminne och ram för att rymma koden eller applikationen oavsett.

Så nej, det finns inget försvar för att skriva en så dålig implementation.

[DanielM]

Detta är en utmärkt applicering. Jag tar emot data och varje iteration så kollar jag om data har kommit in. Vad kan bli fel?

[TomasL]

Troligen allt.
Och nej, det är en urusel kod.

[DanielM]

nanoMODBUS är ingen usel kod.
Däremot kan jag säga att det där biblioteket som du hänvisade till, var riktigt dåligt skrivet.
Det var dåligt för att för mycket structs används och det var för mycket konfigureringar för att få samma funktionalitet som nanoMODBUS.
Det märks att biblioteket är skrivet av tyskar. Väldigt onödigt avancerat.

[TomasL]

Dumheter, det bibliotek jag hänvisade till är industristandard i dag, dessutom är det kvalitetssäkrat, och godkänt för säkerhetskritiska applikationer.

Det finns en förklaring till att man använder strukturer, men det lär du dig nog framöver.
Mycket konfigureringar, tja det är 100% portabelt, oavsett vilket system och OS du använder.
Det är dessutom tråd-säkert, vilket gör att det problemfritt fungerar i såväl RTOS av olika slag, även så Win, Linux, BSD osv.

[DanielM]

Du har åter igen fel och bevisar din okunskap.
nanoMODBUS använder inte ens trådar, därmed "trådsäkert" också.

Du får gärna visa några kodexempel på implementeringen av det där biblioteket.