DIY Arduino THC - Video

[MuttonHawg]

This is a heck of a project - very cool! I'm envious - wish I had more time to devote to something like this. My first job out of college was real-time servo control of a high-speed (~100KHz frequency) high-accuracy (.0000625-mm) vertical actuator, quite similar in operation to the THC you're developing here. That may have been my favorite job to date! I didn't have too much of and hand in the filter design, but more of the software architecture around it and higher-level algorithm work. However, I believe that a properly-tuned PID controller loop (http://en.wikipedia.org/wiki/PID_controller) could be what you're looking for, if you haven't already tried it. I'm not the guy to help tune the various coefficients (sounds like agent4573 has expertise here), but I might be able to help implement and optimize the code, if you like.

This is dangerous for me - one more thing to put on the list of cool projects that I want to work on and occupy my time. I'll be watching with great interest - keep it up!

[EmptyNester]

Thanks MuttonHawq.

I've implemented a number of PID's, but I'm more of a software guy than a math guy. I figured that the filtering would have to get more complex as time went on to deal with stuff like kerf crossings. I always like to start simple - but you are right, I probably need to start looking at PID's (though, that makes it more like work than fun).

I do need to do data collection on this so that I can see what the filtered voltage data and torch control signals look like. I just didn't have time last night.

I have been thinking about moving the the "Freescale Freedom" platform with a Kinetis processor because its cheaper ($12) and much faster (Kinetis, which is a 32 bit Arm processor), but it's 3.3 volts - so I thought I'd take it as far as I could with the Arduino before making that jump.

I really want to do the next pass of the hardware, but I just haven't had the time. Maybe if I get snowed in this weekend I can work on it.

[agent4573]

Sorry for taking so long, got busy at work and all. Started looking at your data, but I couldn't get very far without one key piece of info. What was the sample rate of the data file you sent me? 10 samples/sec, 60 samples/sec? Can't do FFT's without sample rate. Thanks.

EDIT* Also, you gave the counts per volt, but what is the volts per inch value? Thanks.

[EmptyNester]

Sorry for taking so long, got busy at work and all. Started looking at your data, but I couldn't get very far without one key piece of info. What was the sample rate of the data file you sent me? 10 samples/sec, 60 samples/sec? Can't do FFT's without sample rate. Thanks.

EDIT* Also, you gave the counts per volt, but what is the volts per inch value? Thanks.

No problem, I completely understand.

I assume that the sample rate is 1 millisecond. In past testing I found that it varies from under 1 millisecond to up to 7 ms. But, the average seemed to be around one. I updated the code so that it will run no faster than 1 ms. (The baud rate isn't fast enough to dump timestamps with data. I hope to fix that in the next rev of hardware.)

I can only guess at the volts per inch based on what i've read, but I'm under the impress it's around 0.015 inches/volt.

[MuttonHawg]

Do you mean the sample rate varies from run to run? Or varies continuously? Every digital filter I've dealt with needs a fixed time base, otherwise the filter doesn't work right. I'd think you really need to pin down that sample rate to something you absolutely KNOW, or you'll have a hard time getting stable results from your control loop.

[EmptyNester]

Do you mean the sample rate varies from run to run? Or varies continuously? Every digital filter I've dealt with needs a fixed time base, otherwise the filter doesn't work right. I'd think you really need to pin down that sample rate to something you absolutely KNOW, or you'll have a hard time getting stable results from your control loop.

I was seeing variability within runs. When I was capturing time stamps it turns out that I was dumping more data than the UART could handle due to limited data rates. Given that the code path didn't change, the occasional delay in loop time did fit the UART overruns.

After fixing the data output, the variability appeared to be gone. But I'm limited in the amount of data I can output, so I didn't do any specific timing testing. And, in other testing the timing seemed okay.

But, if it were for work and I was asked by the FDA, I'd have to that I don't have any definitive testing to prove that.

[agent4573]

So after looking at your equation, I think you're going to have a harder time correcting for "being low" than you think. Its low because it started at zero, and if you only had 1/20 the value of the next point, it will take a long time to pull the value to the "true" value. However, if you started with a high count value, you would be biased high and would be trying to pull to a lower count value. The problem is, without more code, you won't know if you started high or started low and which way to offset to correct.

I would use either of the following options instead. I didn't bother doing the FFT, because after fooling around a little bit, I think you're right that most of your noise is ~60Hz. The first option is to switch from using your equation to a rolling average equation. The first plot shows a 20 point rolling average, the second plot shows a 50 point rolling average. Assuming a sample rate of 1000 Hz(1 milisecond), this will give you .02 or .05 seconds of lag. If you're cutting at 20fpm (4 inches/sec), that gives you a 0.2 inch lag. I don't think any material will change a huge amount of height in 0.2 inches.

Formula:
value = average(value(i-19):value(i)) - for 20 point
value = average(value(i-49):value(i)) - for 50 point




I think a better option would be to just create an analog low pass filter with an RC circuit. I used a 2 pole Butterworth digital filter to create the following two plots. The first one has a cutoff frequency of 35 HZ, the 2nd one has a cutoff freq of 80 Hz. You can see how much noise is left in the 80 Hz plot. Any low-pass analog filter with a cutoff below ~30 Hz should completely remove the 60 Hz noise without it falling in the transition band. Here is a link on how to come up with the RC values of various order butterworths. http://www.electronics-tutorials.ws/.../filter_8.html
I tried higher order, but the higher the order, the higher the phase shift of the data and the more laggy it will become. Using the analog filter will also allow you to remove the lines of code from the control software and free up some processor power for other things.






As a final note, you may have better luck going to an open loop control mode. Instead of trying to control between 0.5 and 1 volt, you may want to try setting an upper and lower bound, and when you hit the bound, just move it ~.010 inches to correct. This will also free up processor power and give you a more stable sample rate, as it doesn't have to monitor voltage constantly, but just check it every 0.05 seconds or so.

[Rambozo]

A couple of points.
THC should not start collecting samples until after the pierce, so it will not be starting from zero. It will have the baseline height set in the CNC and should be at close to optimal cut voltage. In fact that might be the place to pick up the desired cut voltage as the control should have an exact height above the workpiece at that time. It all depends on if you want to enter a cut voltage or a torch height as your baseline.
Thin material like HVAC parts are often cut at frighteningly high speeds of several hundred inches per minute. (some can reach over 1000 ipm) They also have more extreme warping issues, where the THC has to make fast changes. So that amount of lag may not be acceptable.
I would also go with analog filtering as the best approach to filter the noise.

[agent4573]

For a few bucks you can pick up a 4 or 8 Mhz pic chip and once the start up routine finishes and you get into the control routine you ahoud be on the order of 20 lines of code, that's maybe 100 processor cycles, add in 10 more for the digital to analogue conversion and you have maybe 150 processor cycles max between samples. On a 4 Mhz processor, that UPS your sample rate to over 26000Hz from 1000 Hz. that's cuts your delay on a 50 sample rolling average down to 0.002 seconds, or at 300 inches a minute, a .01 inch delay.

[EmptyNester]

I'm currently using an Atmega2560 that runs at 16 Mhz.

I've done a lot of "old school" microprocessor stuff that's needed to be developed for speed. I figured this should be able to handle software developed for readability and extensibility (since I plan on open sourcing it when it works). So, while there's not a ton of processing in the loop, it's definitely not written for speed. (I used C++ classes to handle the different modes of operation.)

I had expected the op-amp butterworth filter to take care of everything, but it had a 100 hz cutoff (based on a recommendation from a "consultant"). After looking at some of the 2 pole butterworth filters I found a calculator that said for a 35 hz cutoff to use a 470 ohm and 10 uF. I can solder those on the existing board and just tie them into another analog input. So, I'll give that a try this weekend.

I had done some averaging over different ranges from 10 to 50 or 60. The problem with the rolling average is that to get a cleaner signal you ended up adding too much delay for high speed cutting.

Based on earlier discussions with Rambozo - I've been hoping to get sufficient performance for over 100 ipm.

All the voltage captures I do only start after the torch on signal. I know when Arc good is, but the voltage is still on the initial climb when that happens. I've assumed that the initial drop in voltage is when the arc transfers. AFter that there's a brief jump up. I don't know if that's after the pierce completes and before movement starts. I haven't been able to make sense of the timing.

The "cruise control" does work well though. You can set it in that mode and once it starts cutting, just hit the "select" button and it uses the current voltage for the control voltage. That was a great idea Ram.


Rambozo - assuming I'm just doing 18 guage mild steel as the thinnest, any idea on how what the maximum height change over a distance would be? It seemed like the 3/4" over 4" was pretty significant. I didn't seem to have any problem with that, though I was only cutting at 60 ipm.

[Rambozo]

I've seen one video where there was a pretty thin part and it sorta curled up from the heat and the heat sinking of the slats. When the torch finished I would say the edge was probably close to 2 inches above the slats. Now while I'm sure a lot of that was bad settings, the THC running that table had no problem in maintaining that cut. Of course there is that corrugated roofing material that everyone likes to demo. I think the PlasmaCAM demo has some that looks to be 3 or 4 inches tall, with a peak to peak of around 6 inches.

[EmptyNester]

I've seen one video where there was a pretty thin part and it sorta curled up from the heat and the heat sinking of the slats. When the torch finished I would say the edge was probably close to 2 inches above the slats. Now while I'm sure a lot of that was bad settings, the THC running that table had no problem in maintaining that cut. Of course there is that corrugated roofing material that everyone likes to demo. I think the PlasmaCAM demo has some that looks to be 3 or 4 inches tall, with a peak to peak of around 6 inches.

Any idea what kind of distance the torch travelled for a 2" height gain?

[Rambozo]

Of course I can't find the example I was looking for, but here is another that illustrates the control required.

[Rambozo]

And here is another. I would shoot for being able to accommodate any change that the torch nozzle diameter will allow. If the nozzle contacts the material, this will trigger the E-stop on many designs. There is no point in being able to handle a faster rise time. I think most home/hobby machines have pretty slow travel speeds, but I'm also sure that will increase as servos get cheaper and easier to use, and displace steppers.

[sportbike]

I would say the speed of the plasmacam one shown in the video would be adequate.
Most home brew machines may not be capable of the z-axis speeds shown with the tracker machine.

If it were mine Nest, I woudl focus on getting something fairly robust at a modest speed. The accuracy of interpreting the voltage and providing the height adjustment is more important than the all out speed.

Once you get the logic figured out and become a THC expert, if the speed is really an issue, I am sure the same or similar logic can be built into a faster response system.

[EmptyNester]

I would say the speed of the plasmacam one shown in the video would be adequate.
Most home brew machines may not be capable of the z-axis speeds shown with the tracker machine.

If it were mine Nest, I woudl focus on getting something fairly robust at a modest speed. The accuracy of interpreting the voltage and providing the height adjustment is more important than the all out speed.

Once you get the logic figured out and become a THC expert, if the speed is really an issue, I am sure the same or similar logic can be built into a faster response system.

Thanks Sport. I guess I'm still not sure what "modest speed" is. I'm still doing test cuts on 16 ga and I'm running at 60 ipm. I saw a reference from somebody else's machine that said to run at 240 ipm and 30 amps or 180 at 20a. I'm not even close to that. But based on that, I figured that 200 ipm would probably be max.

Of course, I fall prey to the "American Way" - more, bigger and faster is always better

The big challenge is trying to learn so many things all at once (basics of using the CNC, SheetCAM, Mach, hardware design and THC theory). I'm having fun, but its just slow.

[EmptyNester]

I took Agent4573's advice and put in a 2 pole filter. I used a calculator I found on the web and it said for a 35Hz filter to use a 470 ohm resistor and 10 uF capacitor.

I put those on and did a couple cuts with data captures. They were worse then the previous cuts. I realized the only other difference on that run was I had my o-scope on the circuit both before and after the new filter. I tried another capture without the o-scope and it was really good. I guess the o-scope leads were just "noise antennas".

A blow-up of the raw analog to digital readings (no software filter) is below.



You can see that the signal is now typically +/- 1 count from the baseline. Couldn't ask for anything better.

A full trace of cutting a 1/2" x 2" rectangle is below:



I did look at the timing. I'm currently dumping data every time through the control loop. I have a delay so that it won't run more than every millisecond. The software currently waits 1200 ms from an "Arc Good" signal until it starts voltage control. In the capture it showed 1142 ms. between "arc good" and start of control. So, it's off by about 5%. I'm guessing that dumping all the data could have something to do with that, though, the display updates could also have something to do with that.

This is running on an Arduino Mega that uses an ATmega2560 that is an 8 bit processor running at 16 mHz. So, it's not a speed demon but looks like it may do okay for an entry level system.

I think after I have the first pass running well and all the source posted, I may move to the Freescale Freedom. It's a 32-bit arm processor with a $12 board.

On the THC front, I have to figure out the best algorithm for up/down. Since it's a digital signal instead of a up/down speed - I'm guessing that I should just continue with the set "trip points". I think the biggest impact is the response time of Mach and the steppers, but I have no idea what that is. Given the latest capture I think that maybe I should trip torch movement if it's > 3 off and turn it off if its within 1 off. Anybody have any thoughts on that?

I still need to figure out how to setup Mach. It currently won't allow going below the height of the initial height sensing. Also, I have to figure out the "THC Rate" to use.

Thanks for all the help everybody!

[sportbike]

You could also look into Raspberry Pi. I haven't used it, but it will operate at 800mHz and has 512MB onboard memory for $35. Might need a bit of thought to get an onboard display, but you may be able to stream via Ethernet to the PC and just use it as an interface box. They even have an "apps store"

http://www.raspberrypi.org/faqs

[MuttonHawg]

Nicely done, EmptyNester! I remember how happy I was whenever I got a control loop working and stable. Watching it work always feels like magic!

You know that when I get the time and space to build my own CNC plasma cutter, I'm calling you for hints, right? If you ever need a hand doing any of the software work as you port your controller to a different platform, let me know.

sportbike, thanks for reminding me about the Raspberry Pi. I've been looking for an excuse to get one of those boards/kits, anyway. I haven't checked since just after their release, and at that time they were sold out for awhile. Glad to know they're available now. Heck - you could probably run an entire CNC operation from one of those.

[sportbike]

There is a post in the Pi forum about running multiple servos from the board.