driver aangestuurd vanuit 2 controllers

[mauritswoudenberg]

Nu mijn CNC plasmasnijder werkt wil ik er een THC op maken. Ik maak een spanningsdeler over de toorts / massa (feitelijk is de toorts de massa en de klem de + maar goed, het idee is duidelijk), die spanning filter ik wat met een lowpass-filter en lees ik uit met een ADC op een arduino. Daarin wordt berekend of de toorts omlaag of omhoog moet, ofwel met een simpel up/down signaal, of iets slimmer met bijvoorbeeld een PID controller..

Normaal gesproken gaat het up/down signaal naar je CNC controller die het verder regelt, maar ik gebruik GRBL en die ondersteunt geen THC, bij gebrek aan poorten. Nu dacht ik, ik schrijf code die in plaats van een up/down uitgang een step/dir uitgang heeft die ik parallel aan de step/dir uit de GRBL arduino op de Z driver zet. Mijn vraag: is dit mogelijk? Of brengen de de twee signaal bronnen elkaar in de war? Uiteraard laat ik ze niet tegelijk werken.

[hugo stoutjesdijk]

Als die uitgangen open collector zijn, wint degene die laag staat lijkt me, dus als de het dir signaal vanuit GRBL toevallig laag is, krijg je met jouw arduino die Z nooit de andere kant op. Als het een andere signaal vorm is zullen er weer andere uitdagingen zijn.
Ik zou eerder overwegen om die step /dir in die 2e arduino in te lezen, en naar keuze transparant door te sturen of je eigen pulst en dir er naar toe te sturen.
Dan moet je ook nog in de gaten houden dat die GRBL dan niet meer de echte Z-waarde weet, dus zomaar op een limit kan lopen.

[Kjelt]

Twee kapiteins op 1 schip is nooit een goed idee.
Zeker niet als de eerste kapitein geen weet heeft dat er nog een tweede kapitein bezig is.

[mauritswoudenberg]

ah wat een goed idee! Ik dacht iets met een pull-up resistor en een diode te rommelen, maar dit is veel slimmer. De absolute Z hoogte is ook niet zo relevant omdat ie toch voor iedere cut zn probing sequence doet.

[mauritswoudenberg]

Kjelt, ik snap je bericht, maar is dat niet vooral zo bij 2,5D en 3D machines zoals bijvoorbeeld een frees? Veel plasma snijders hebben niet eens een motor op de Z-as en stel je de hoogte met een stelschroef in. Bij dunner materiaal kan het echter door de hitte buigen en dus iets omhoog komen. Daar is die THC voor. Bij de volgende cut probe je eerst weer om een goede pierce hoogte te krijgen en zodra de plasma-arc goed loopt neemt de THC het over. Ik zie er wel iets in.

[Kjelt]

Ik weet alleen dat een goede THC control loop best tricky kan zijn, er zit vaak ruis op het signaal en je wilt redelijk snel kunnen sturen zonder overshoot dus eigenlijk moet je een continue sample-calculate-control loop met iets van demping er op hebben. Dan zit zon Arduino alweer aardig vol mee afhankelijk welk type controller.
Zelf geen ervaring verder mee maar zou de hele Zas sturing dan door de Arduino laten afhandelen.

[mauritswoudenberg]

Ik dacht aan een PID algoritme, dit is een typische toepassing waarbij dat goed zou kunnen werken. Met de parameters is de gevoeligheid en reactietijd goed in te regelen. Aan de voorkant kan ik met een lowpass-filter de arc spanning wat afvlakken en met condensator waardes spelen om de sweetspot qua vlakheid / reactietijd te vinden. Er zijn zat PID libraries te vinden, geschreven door mensen veel slimmer dan ik.

Ik heb zojuist een opstelling gemaakt met een tweede arduino die de step en dir pulsen uitleest en doorzet naar andere poorten. Het gaat wel, maar niet van harte. Ik denk dat ik beter een microcontroller met hogere kloksnelheid kan nemen. Een ESP32 of een raspberry pi Pico ofzo. Idealiter eentje met interrupt pins, maar dat hebben de meeste wel.

[hfjbuis]

Ik heb zojuist een opstelling gemaakt met een tweede arduino die de step en dir pulsen uitleest en doorzet naar andere poorten. Het gaat wel, maar niet van harte. Ik denk dat ik beter een microcontroller met hogere kloksnelheid kan nemen. Een ESP32 of een raspberry pi Pico ofzo. Idealiter eentje met interrupt pins, maar dat hebben de meeste wel.

Een Arduino is meer dan snel genoeg om dit te doen als je de pulse detecteert met een irq en geen gebruik maakt van de Arduino bibliotheek om de te zoeken naar welke pin de irq heeft veroorzaakt. Mocht je willen weten hoe, dan zoek ik wel een stukje code op die de irq initialiseert en serviced. Dat servicen is niet meer dan de status van de input port lezen en die status op de output port zetten.

Een ESP32 heeft 3.3V ingangen en is om te programmeren voor tijd kritische dingen "een ramp" als je niet alle valkuilen weet.

[Kjelt]

Ik heb daar mijn twijfels bij.
Misschien tot een paar kHz dat het geen probleem is maar als je bv met 20kHz gaat pulsen dan heeft die Arduino minder dan 50us om de registers op de stack te gooien, de ISR af te handelen en stack weer terug te zetten. Nog hogere frequentie nog minder tijd.
Hiervoor kun je veel beter een los hef40xx of hct 74 ictje pakken waarbij de arduino schakelt. Dan weet je ook bijna zeker dat er geen pulsen verloren gaan.

[hfjbuis]

Ik heb daar mijn twijfels bij.

Ik heb dat eens uitgezocht omdat een SAMD21 32 bit arm processor op 76 MHz beduidend langzamer was dan verwacht. Als ik het mij goed herinner, kan de UNO processor de puls in 1us afhandelen. Er worden ook alleen maar registers op stack gegooid die echt gebruikt worden. Die SAMD21 was niet beduidend sneller in het IO processen dan de UNO.

[Kjelt]

Als je uC f>50MHz gebruikt werkt het wellicht wel maar waarom zou je dit willen?
uCs zijn gemaakt voor sequentiele processing. Als je puur en alleen pulsen van 1 zender naar meerdere ontvangers wilt sturen/schakelen gebruik je een simpel logisch ic van 20 cent.
Dat is nog beter ook want als je het met een uC doet krijg je variabele delays afhankelijk van waar de uC mee bezig is wat resulteert in jitter en verschil in pulslengtes. Hoeft niet kritisch te zijn maar waarom zou je dat risico nemen?

De tijd die je nodig hebt en over houdt kun je eenvoudig zien door een pin aan en uit te zetten in de IRQ functie en aan een oscilloscoop te hangen. Dan mis je de stack tijden maar die staan meestal in de datasheet.

[FreesKever]

Een beetje door snuffelen?

Er zijn GRBL varianten die 6 (onafhankelijke) assen ondersteunen.