Moving code from ESP8266 to ESP32

Image
A while ago I made a mashup of Dan Royer's code CNC 2 Axis Demo with my own code for trapezoidal motion stepper and servo control for ESP8266.

I assumed porting the code to the ESP32 would be trivial, and that was true for the most part: changes like library name being Wifi.h instead of Wifi8266.h were not a problem. UDP now does not like multicharacter writes but you can use print instead. So far so good.

However, when it came to the interrupt code I was stuck with the stepper interrupt causing an exception sometimes. And to make things weirder, the servo interrupt worked flawlessly (both of them had the IRAM_ATTR directive if you ask me).

Going little by little, I could narrow down the culprit to a floating point operation during the interrupt, that would cause problems sometimes but not always. Browsing around I found this post. Where the solution was simple: do not use floats within the interrupt routines but doubles. The reason was the float calculation would be performed by…

Getting work done faster on a CNC machine

I have been playing with CNC machines for a while and one idea of improving their performance
came to my mind: what if, like they do with processors, we could add some parallelism to the process to get more work done in the same amount of time? So a multi-core processor will be the analog of a CNC machine with several spindles.

As usual, a quick look at the Internet reveals that a "dual-gantry CNC" is not really a new idea as a few videos can be shown on youtube from some commercial units. Interestingly enough, there are just a few cases shown, which makes me think it is either a bad idea or too complex to work properly in most cases.

My plan here is to have two gantries that move independently and to follow the RISC approach: I will handle the dependencies in software so I will create to g-code files, each one feeding one of the gantries in a way that both gantries planing contains no collisions. I guess another approach could be to put in place some kind of collision detection system that would pause one gantry when a collision was about to happen, but that seems less efficient than creating a manufacturing plan containing no pauses (or collisions :-).


This first video shows how a sample job would be split into two different parts. If the motion is done in both cases left to right, there seems no gantry collision would happen. However, this raises the point of where to perform the cut. Just in the middle does not guarantee each gantry would have to work the same amount of time, and if that does not happen, then one gantry is going to finish sooner than the other, leading to unbalance workload and reduced overall efficiency.  

So a good workload balance needs to be obtained by dividing the sheet into two parts with similar workload (which usually would mean one side is wider than the other) as the next video illustrates.


However, though the left-to-right scanning pattern seems very appealing in terms of guaranteeing a collision-free motion for the gantries, it is quite difficult to obtain the best performance out of this pattern so a compromise will have to be done. Like the one shown in the next video, where motion evolves from left to right but some leeway is allowed so gantry can move right to left within certain limitations so the overall toolpath remains shorter than the one with a unidirectional motion yet still remains collision-free.

Please note that last video is not performing a real-time simulation of the approach, so do not be surprised if one half of the work finishes sooner than the other. The actual simulation shows that both halves would require exactly the same running time and therefore would finish at once.

If you've worked with similar systems do not hesitate to pitch in with your comment. If you haven't but want to share your ideas, you are welcome too.



Comments

Popular posts from this blog

VFD control with Arduino using RS485 link

4xiDraw: Another pen plotter

Software I2C for Arduino