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…

Minimizing tool air-time

For a CAM software I wrote, intended for milling foam sheets, I needed a way to improve machining time, so once the feed rates are raised to the limit, the next step is to reduce any wasted time.

On an initial approach, our tool was finishing parts one after the other, so there was a bit of the tool going back and forth within the same part. While it may seem the whole problem is like a big TSP (travelling salesman problem) and the way to optimize the used time is to connect all the dots with the shortest possible path, it is not exactly so.

On a milling operation, the tool path has been carefully calculated so it will remove the proper amount of material by following a certain path. Changing such a path will alter the finish of the part and we do not want to go there.


So what we really have is something like two different sets of movements, one that corresponds to the actual cutting operations and a second one that moves the tool over the air to start a new cutting operation. It is that latter set of movements that can be approached as a TSP without affecting the quality of the CAM output.

Many CAM operations require removing material as a sequence of steps or layers, the order of each layer needs to be preserved as explained here.

But I am lucky our process just goes straight to the finishing pass as the tool can machine the whole stock depth in just a single pass (don't try this at home).

So what I have done is to rearrange the different movements between each milling pass so the total distance is minimized (though I am just using the simple 2-opt heuristic that most likely won't lead to the best solution but to an acceptable one).


I have got the idea from the StippleGen2 software I downloaded from Evil Mad Scientist Laboratories blog.

The lines in red correspond to the actual milling operations and are not changed and the grey lines represent the ones that we are trying to minimize but carefully rearranging them.

Comments

Hi, Miguel!

Interesting problem!
What about minimizind first the number of travels outside your part?
think about milling a surface of 20x40 with horizontal travels and compare with milling a 40x20 with horizontal travels.
Then, minimizo distance travlled each time the tool is outside the part...
may be this works... who knows.... ;)

best regards,
Rafa
Miguel Sánchez said…
Hi Rafa,

My axis do not move the same mass. That means moving along Y axis can be done faster than moving along X axis so rotating the job operation 90 degrees will reduce the average feed-rate obtained.

Popular posts from this blog

VFD control with Arduino using RS485 link

4xiDraw: Another pen plotter

Software I2C for Arduino