Raspberry pi en Linuxcnc

[hugo stoutjesdijk]

http://wiki.linuxcnc.org/cgi-bin/wiki.pl?RealTime
https://github.com/jeroenvdwaal/real-time-kernel

Volgens mij geen schokkende nieuwe ontwikkelingen.

En dat dos ‘gewoon’ realtime is blijkt toch uit bovenstaande link niet echt.
Dat er een dos versie was 40 jaar geleden die dat wel was zal ook wel. Die werd o.a. gebruikt door Philips op de 432 besturing van maho. Maar dat was geen ms-dos.
Waarom noem ik die, dat was een hardware op intel 80x86 gebaseerd, de andere besturingen die ik ken uit die tijd hadden sowieso andere hardware, motorola en texas-instruments.

(Dabit is wat sneller, ik had me de moeite kunnen sparen)

[Markus]

Dat is niet waar....
Voorbeeld: als ik in DOS met een int 21h oproep iets met mijn floppy doe dan moet ik maar afwachten wanneer dat klaar is. Gegarandeerd niet binnen de milliseconde die ik kan missen voor ik de motoren van de machine weer aandacht moet geven. En timerinterrupts heb ik dan ook niks aan, want die worden vrolijk geblokkeerd omdat anders het lezen van de floppy niet lukt.

Hahaha das flauw Dabit, je maakt een grapje, je weet wat ik bedoel, ik heb ooit de data acquisitie en real-time weergave software geschreven voor een PC-Radar interface geschreven dat het analoge radar signaal met max 50Mhz samplede. Zonder uitstekende responsetijden op interupts was dat nooit gelukt zeker niet in 1993 ook al heb ik het hele ding in Assembler geschreven. Tegenwoordig zou je een flinke Fifo chip er tegenaan gooien maar die hadden we niet echt toen in de prehistorie.

En dat dos ‘gewoon’ realtime is blijkt toch uit bovenstaande link niet echt.

Alle besturing systemen (en systemen zonder OS zoals Arduino/ Raspberry Pi Pico) die geen gebruik maken van time-sliced multitasking/threading zijn in theorie "real-time". Wat niet betekent dat ze onmiddelijk reageren op externe of interne interrupts maar dat de vertraging tussen interrupt en afhandeling daarvan een vaste (bekende) tijd bedraagt. Meestal gaat het dan op milliseconden. Het probleem bij CNC systemen is dat de puls reeksen naar de As motoren on-onderbroken en perfect synchroon (tussen de assen) moeten zijn want anders wordt je cirkel geen cirkel en je schuine lijn enorm wiebelig.

Ik liep tegen dat probleem aan ergens in 2004 tegen toen ik een bescheiden cnc besturing heb geschreven voor een printplaat frees machine die ik had gebouwd (mijn aller eerste cnc bouw). Ik heb de code geschreven die de tekentaal HP-GL (dus geen Gcode) omzette naar pulsreeksen (step/Dir) voor de 3 stappen motoren en heb uiteindelijk een 8bit Atmel gebruikt om als een soort van output sync fifo zodat er vanuit windows geen multitasking onderbrekingen waren. Ik had natuurlijk gewoon mach3 moeten gebruiken maar daar kwam ik pas een hele poos later achter toen ik meer machines had gebouwd.

En met Dos cnc besturingen bedoelde ik dat in de context van hobby-cnc dus programmas zoals Zeus CNC en Turbo CNC

Wellicht is deze DOS CNC besturings software nu nog steeds goed aan de gang te krijgen met x86 bordjes zoals de 86Duino of de Radxa X2L of een van de vele supergoedkope Thin Client mini PC's die je op ebay kunt kopen die draaien DOS maar natuurlijk ook Linux, de Fujitsu Futro S920 heeft een printer poort via een standaard header op de printplaat.

Voor diegene die een Thin Client pctje zoekt, deze meneer heeft heel veel info en via deze Processor snelheidsdatabase site kun je een idee krijgen van de prestaties. Je kunt daar ook vergelijken met bijvoorbeeld de Raspberry Pi 4 (processor = BCM2711) en dan valt het op dat de prestaties niet super zijn 40% lager dan die van de 2de hands goedkopere Fujitsu Futro S920 met AMD GX-415GA procesoor.

Greezt,

Markus

[DaBit]

Hahaha das flauw Dabit, je maakt een grapje, je weet wat ik bedoel

Nee, sorry, dat is niet flauw. DOS heeft geen bovengrens aan de responstijd op een event en is daarmee per definitie niet realtime.
Jouw applicatie had een gegarandeerde responstijd omdat je het OS, namelijk DOS, niet meer gebruikte als het eenmaal draaide. Maar nogmaals, dat maakt DOS niet realtime. Als ik een kerneldriver schrijf voor Windows die ik op commando de CPU laat blokkeren met de eigen code en nooit meer de controle teruggeef aan Windows dan zou je kunnen ook stellen dat 'Windows een realtime OS is'. Nee dus.

Dat is ook waarom die PREEMPT_RT patch op de kernel zo'n monsterklus was/is. Je moet van elke regel code in de kernel kunnen garanderen dat die een gedefinieerde respons op een event niet in de weg zit. En die regels code zijn er nogal wat.
(overigens geven ze toe dat ze niet alle drivers gecontroleerd hebben)

Maar zoals het er nu bij staat is het wel een hele goede oplossing als het je niet om de laatste microseconde gaat, want je kunt en je realtime taken schedulen, en gebruik maken van de volle functionaliteit van je besturingssysteem. Die combinatie is toch best zeldzaam.

[Markus]

Nee, sorry, dat is niet flauw. DOS heeft geen bovengrens aan de responstijd op een event en is daarmee per definitie niet realtime.

Je begrijpt me verkeerd, jij hanteert een formele definitie van real-time, ik hanteer een praktische. Vanuit het perceptief van iemand die een realtime applicatie schrijft is het niet moeilijk zeer voorspelbare responstijden te realiseren onder DOS. In het voorbeeld van de radar applicatie was die voorspelbaarheid in het bereik van een aantal clock cyclussen van de CPU (bij 16Mhz is dat n x 62.5 ns) wenselijk beter dan een aantal milliseconden. DOS is een single tasking OS, en daarmee is het jouw applicatie die alleen runt en gebruik kan maken van de software interrupts die het systeem bied. Natuurlijk is de responstijd van een schrijf opdracht (DOS software Interrupt 21H 40) niet real time zoals jij juist aangeeft. Maar als je dat weet kun je vaak om zulke asynchrone problemen heen werken zonder al te veel problemen en dus een real-time applicatie realiseren. Ik zeg niet dat het makkelijk is, maar als je in machinetaal programmeert ben je dusdanig dicht bij wat er werkelijk gebeurt op de toen nog single core processor dat je staat bent heel precies te weten wat er allemaal gebeurt en precies hoe lang het gaat duren.

Greezt,

Markus

[andrefc101]

oh..... wat spannend...... wie oh wie zal er nu de langste hebben.....

[Markus]

oh..... wat spannend...... wie oh wie zal er nu de langste hebben.....

:) ,als het een pissing contest gaat worden (en dat valt nog te bezien) dan haak ik af, ik zie dat regelmatig op het forum gebeuren en vind het waardeloos, ik ga daar niet aan meedoen

Een ieder mag van mij best de langste hebben, mocht het hem/haar daarom gaan, ik hoop echter dat het om de inhoud gaat, we zullen zien.....

Greezt,

Markus

[andrefc101]

Een ieder mag van mij best de langste hebben, mocht het hem/haar daarom gaan, ik hoop echter dat het om de inhoud gaat, we zullen zien.....

Ik dacht juist dat jou hele verhaal wat betreft de inhoud niet echt met de vraag van de ts te maken had!

[FreesKever]

oh..... wat spannend...... wie oh wie zal er nu de langste hebben.....

't is heel simpel. Dabit heeft hier gewoon gelijk, terwijl Markus aan het zaniken is omdat hij het in zijn speciale geval toch voor elkaar heeft gekregen om de hele zooi werkend te krijgen. En hoewel je redelijk "real time" kunt werken op een PC tegenwoordig (vele GHz, meerdere processor kernen) wordt het vaak nog steeds als een "betere oplossing" gezien om het "real time" gedeelte over te hevelen naar "dedicated hardware" zoals een microcontroller of FPGA.

Voor "echt serieus werk" lijkt EtherCAT steeds populairder te worden. De "real time PC" draait dan de servo loops op een paar kHz, terwijl de (sub) micro seconde timing wordt gedaan buiten de PC. EtherCAT heeft ook ingebouwde methoden om timing tussen verschillende apparaten te synchroniseren, en het is een open protocol.

Maar om terug te komen bij de Raspi. Een paar weken terug gelezen dat de RP4 (en eerder?) de hardware ziet als een soort paralelle poort, terwijl in de RP5 de I/O meer als "native" wordt gezien. Om LinuxCNC daarmee werkend te krijgen moeten de configuratie files andere namen voor de I/O gebruiken.

[Sven]

Een woord als 'zaniken' hoort wat mij mij betreft niet op een forum thuis en draagt niet bij aan een fijne sfeer.

[Kars-cnc]

Een woord als 'zaniken' hoort wat mij mij betreft niet op een forum thuis en draagt niet bij aan een fijne sfeer.

+1 (een "meningsverschil" is waar het hier om gaat)

[DaBit]

Markus en ik hanteren een ietswat verschillende definitie van 'hard-realtime OS'. We weten allebei precies wat de ander bedoelt en waar het verschil in nuance zit, dus da's allemaal niet echt een wedstrijd en zelfs amper meningsverschil.

Hard-realtime taken overhevelen naar hardware die enkel die taken hoeft te doen is meestal gewoonweg het minst slechte compromis op systeemniveau

[hainjedaf]

Hard-realtime taken overhevelen naar hardware die enkel die taken hoeft te doen is meestal gewoonweg het minst slechte compromis op systeemniveau

Hebben jij en ik daar niet eens mee geëxperimenteerd en jij daar je 3D printer oorspronkelijk op gebouwd?!

Ik kwam laatst de images nog tegen van de zelf gepatchte en gecompileerd realtime kernel...

Was nog op een Pi3 geloof ik.

[DaBit]

Dat was PREEMPT-RT op een Pi3, en ja, daar draaide ik mijn 3D printer op met ST Microelectronics dSpin stepperdrives op SPI.
Draaide prima; ik stapte over op zo'n Duet bordje omdat ik een 'echte' 3D-printercontroller uit het betere segment wilde ervaren en niet omdat die Pi+LinuxCNC+wat uitbreidingen op LinuxCNC tbv printen+dSpin drives voor motoren+BluePill bordje voor analoge I/O niet voldeed.

Net zoals ik nu eens Klipper op de printer heb draaien; da's ook niet omdat RepRapFirmware niet voldoet, maar omdat ik wel eens wilde weten wat het nou precies is. Heb ik toch weer die Pi in het systeem zitten

[Markus]

terwijl Markus aan het zaniken is omdat hij het in zijn speciale geval toch voor elkaar heeft gekregen om de hele zooi werkend te krijgen

gezien het bestaan van al die vele CNC besturingen van 30 jaar en ouder lijkt me dat heel veel programmeurs al heel lang "real-time" voor elkaar hebben gekregen , en dat met single core CPU clock snelheden gemeten in tientallen MHz. Velen doen daarbij ook nog eens real-time positie feedback via glaslinialen.

Niet heel bijzonder dus (ook mijn code van toen niet), en daarmee lijkt me de noodzakelijkheid van het gebruik van een FPGA flink overdreven

Bovendien wat Dabit zegt:

Hard-realtime taken overhevelen naar hardware die enkel die taken hoeft te doen is meestal gewoonweg het minst slechte compromis op systeemniveau

is ook volgens mij het beste antwoord. Als je een simpele 18 euro microcontorollertje via USB of ethernet aan je windows PC of Raspberry plakt die servo's of stappenmotoren pulst, dan is het "verstoorde puls trein output door multitasking OS" heel makkelijk en goedkoop opgelost bij openloop systemen zoals 99% van de hobby cnc's en 100% van de 3D printers openloop zijn (geen glaslinialen).

Het opwekken van de pulstreinen voor de servo/stappenmotoren vanuit G-Code kan dan lekker langzaam en met horten en stoten voor het begin van de frees/print Job gedaan worden, om daarna in losse datapakketten gedumpt te worden naar de externe microcontroller die voor syncroniteit en stabiele pulsfrequentie zorgt.

Realtime Raspberry PI OS is juist erg interessant als het gaat om real-time positie feedback via bijvoorbeeld glaslinialen. Closed loop op de assen dus. Daarmee zou je een heleboel bestaande hobby CNC machines met matige nauwkeurigheid (door goedkope kogelomloop spindels) kunnen upgraden naar een veel betere nauwkeurigheid.

Een woord als 'zaniken' hoort wat mij mij betreft niet op een forum thuis en draagt niet bij aan een fijne sfeer.

Ach beetje drama vind ik best leuk. ik waardeer op zich authentiek woordgebruik, geeft meer inzicht in de emoties die loskomen.
Maar anderzijds als het om het forum gaat mag ik natuurlijk niet alleen vanuit mezelf beredeneren en dan is een beetje beschaaft doen misschien de beste koers als je rekening wilt houden met iedereen.

Greezt,

Markus