DIY Arduino THC - Video

[EmptyNester]

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

I have a Pi. I was one of the lucky people to get it right after it released, but I've been so busy with the CNC table and this project that I've never even booted it.

I had considered using it but I see a couple drawbacks with it. I have yet to see a well documented hardware interface for expansion (thought I haven't looked recently). The common board for hardware expansion cost more than the Pi. And finally, it runs Linux. I have nothing against Linux, but being a very feature rich and capable operating system it is very complex. I wanted something that would be simple for people to understand, learn and experiment with.

There are a couple of advantages with the Kinetis. I have a lot of experience with Freescale parts and tools (I'm partial). It can be used without an OS. If I want to use an OS, Freescale offers a free RTOS on most of their new processors. I've used MQX (the free RTOS) on a number of different work/commerical products I've developed and its worked well for me. Its full source, lightweight and you can't beat the price.

I guess the Kinetis is the case of being really good with a hammer so I want every project to be a nail

[EmptyNester]

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.

Thanks for the offer. I'm hoping once its out there I'll get feedback to make it better.

I would expect that someone will use the Pi for CNC since there seems to be such a big open source Linux-based CNC following.

I'm just created a gitHub repo to start uploading code and documents.

[Rambozo]

I guess the o-scope leads were just "noise antennas".

Good point, as you are running right next to what is basically a spark gap generator type of transmitter. I didn't even think about the lead issues. (doh) Do you have shielding over everything when you are making your test runs? Maybe that plastic box needs to become metal? Do you know what the inverter frequency is? I'm guessing it's clocked from the 60Hz input line based on what you have found.

Sounds like you are closing in on a solution. You can set hard and soft limits in Mach that will never be violated. In order to have a torch that can dip below the top of the part, you will have to make sure the limits are below that. Of course this will also allow a torch crash, so it might be something to add near the end.

There are so many different type of home brewed tables, so the speeds and feeds are going to be all over the place. I would say 200 ipm is probably a good target. Most small plasma cutters are not going to hit that except with thin sheet. In fact half that speed or less is probably more common. Z axis might be the one exception as it seems like a lot of kits use all the same motors and while they might have to have conservative acceleration settings to move a large gantry, they should be able to move the Z pretty snappy. Of course that assumes that people tune each axis independently, and I bet a lot will just use the same settings on all of them.

[EmptyNester]

Ram - I have no idea what the inverter frequency is, I haven't even looked at it.

I originally built a plastic box but it got to be such a pain taking the Arduino out to reprogram that everything is just laying flat out in the open between the PP50 on one side and the CNC and PC on the other side. I think I get most of the noise from the CNC power supplies and motor controller. They are enclosed in a metal box (old PC case), but it does have openings in the back.

Overall, I'd say that the level of noise on the Arduino is so low that it's a real credit to the design of the PP50.

The issue I had with Mach is that it wouldn't allow a negative value to be entered into the THC minimum height on the default screen. At some point I'd like to do a custom screen.

The disappointing thing about all the noise I do have is that it makes it hard to run the THC and use the o-scope to capture the phase delay between the raw arc voltage in and the filtered voltage out. Ignoring the motor acceleration ramp, if the Z-axis is running at 40 ipm, then you can move the Z-axis 0.67 thousandths per millisecond. So a 20 ms phase delay could be a z-axis overshoot of 13 thousandths. So, I guess that could cause the torch "sawing" I saw.

I'd like to try an angled cut today with the newly added filter and the Z-axis set to 20 ipm to see how that goes.

[sportbike]

I'd like to try an angled cut today with the newly added filter and the Z-axis set to 20 ipm to see how that goes.

Take a video of that if you can. Would be interesting to see.

Can you use shielded leads on the scope? Maybe even some old school aluminum foil wrapping :-)

[EmptyNester]

Maybe even some old school aluminum foil wrapping :-)

That's funny, but I wouldn't be surprised if it worked.

I've been trying to get a decent cut so that I could tape it. I'm hoping that the camera can still focus if I put a pair of #5 lens in front of it.

I've been having a number of issues with the laptop that I'm doing data captures with. I did get one capture with the sawing and found that it is definitely a software bug. I would signal torch up if it was off by more than 3 and stop signalling when off by 1. With a noise level of 2, those values are probably too close. But, I'm not sure if I also have a filter delay problem. Here's the capture I just did:



I think the legend on the graph for torch up and torch down are reversed.

The other software change included in this run was reducing the start of voltage control from 1200 ms after arc good to 800 ms after arc good.

So, I've changed the torch up/down thresholds (=> 7 on, <= 3 off). I've changed the delay back to 1200 ms, and I hope to retry later today.

Once I debug the obvious problems, I'll take a shot at videoing it.

[EmptyNester]

Made all the changes I had mentioned earlier. I also found that I had the voltage hysteresis values backwards, so that was really screwing things up. General summary of setup is:

• Turn on torch movement if >= 7 counts off (1 volt)
• Turn off torch movement if <= 3 counts off (about 1/2 volt)
• Currently using no software filtering on voltage
• Delay 1200 ms. after arc good to start torch height control
• Mach Z-axis speed set to 20 ipm
• 16 ga @ 30 amps with SheetCam set to 60 ipm (but G-code using 40 ipm)

The test setup is shown above. I cut a 2” long rectangle. The difference in height from one end of the rectangle to the other is 0.43 inches.

The voltage capture with torch up/down signals is below:



I guess I need to start thinking about other tests, and finally starting to use my table.

I'll try to do a video capture of this later today or this week.

[sportbike]

If you can find a piece of corrugated roofing sheetmetal or perhaps just bend a piece of sheetmetal into a zig zag or even just a single bow / arc and give it a shot.

[EmptyNester]

I did a video with the same setup as the last voltage capture.




I didn't realize that there was still a little "sawing" until I saw the video. I think that will be easy to fix by making the voltage control range a little tighter. I had made that change already based on the last voltage capture, I just hadn't loaded it into the THC yet.

The cut piece is below. It's a little out of focus because I don't have a good close-up lens.



In spite of the sawing, it still looks like a pretty decent cut. But I'm sure I can get it better.

Last night I finished updating the schematics and laying out the board. It has the new 35 Hz filter added and I changed the optos so that the RS-232 will run faster. I uploaded it last night and it already went out to fab today. I should have it in about 2 1/2 weeks. The image created on the upload is below. It will actually be a little narrower than that as it shows board under the pins on the right side when there really isn't any there.

[sportbike]

Wow, that looks pretty good (even with the "sawing"). I'm impressed.

Certainly doing a much better job than if you didn't have any THC :-)

I would be surprised if that wouldn't work just fine with a "zig-zag' bent or corrugated metal.

Cut quality looks pretty good to me.

[sportbike]

I just looked at it again and noticed the torch crash and material drag at the end.
I assume that is because the voltage gets out of range because the cut is finished.

[EmptyNester]

I just looked at it again and noticed the torch crash and material drag at the end.
I assume that is because the voltage gets out of range because the cut is finished.

I hadn't notice that before with flat or angled cutting. I didn't have the steel secured very well and it moved a couple times while trying to set it up.

I originally though it was due to how the piece was mounted and secured. But, now I'm wondering it that's been happening all along and I hadn't noticed. It is crossing the starting kerf before doing the lead out. You can see the kerf cross in the most recent voltage capture. I think I'll need to work on detecting kerf crossing by large voltage changes over a short time period and suspend movement.

[EmptyNester]

When crossing a kerf, the voltage shots up and the control loop directs the torch down, so by the time you're at the other side of the kerf the tip could be below the top of the metal.

While I'm only looking at one data sample, I think I've figured out how to detect kerf crossing.

On normal voltage control, once the "torch down" command does active the voltage never climbs and usually starts going down within 3 samples (3 milliseconds) but never more than 7 samples (7 milliseconds). On the kerf crossing after the torch down signal is given, the voltage slowly climbs. By 7 ms after initial "torch down" if the voltage is the same or higher, you can assume you're crossing a kerf.

In that case it would seem to make sense to stop servoing the torch and start a timer to determine when to resume the servo control.

I think I can use the tip diameter/kerf width and the cutting speed to determine how long to leave the voltage control off.

[Rambozo]

When crossing a kerf, the voltage shots up and the control loop directs the torch down, so by the time you're at the other side of the kerf the tip could be below the top of the metal.

While I'm only looking at one data sample, I think I've figured out how to detect kerf crossing.

On normal voltage control, once the "torch down" command does active the voltage never climbs and usually starts going down within 3 samples (3 milliseconds) but never more than 7 samples (7 milliseconds). On the kerf crossing after the torch down signal is given, the voltage slowly climbs. By 7 ms after initial "torch down" if the voltage is the same or higher, you can assume you're crossing a kerf.

In that case it would seem to make sense to stop servoing the torch and start a timer to determine when to resume the servo control.

I think I can use the tip diameter/kerf width and the cutting speed to determine how long to leave the voltage control off.

Sounds like your detection method will be fine. However, I would look for another voltage change for the detection of when to start THC action again. That way the size of the kerf will not matter, and you can cut things like expanded metal or cross larger holes in a part. Also that code would probably help to allow starting from an edge without a pierce, something that will allow cutting of thicker materials with smaller plasma cutters.

[EmptyNester]

Sounds like your detection method will be fine. However, I would look for another voltage change for the detection of when to start THC action again. That way the size of the kerf will not matter, and you can cut things like expanded metal or cross larger holes in a part. Also that code would probably help to allow starting from an edge without a pierce, something that will allow cutting of thicker materials with smaller plasma cutters.

The idea of trying to detect it by voltage change sounds good. I would think you'd still need to limit how long you ignored the voltage difference before you try to start controlling again.

With respect to starting from the edge, I've been going under the assumption that the initial height is okay. That makes it very simple to enable waiting a fixed time (a second or so) to start control. The voltage is all over the place at the beginning, so it would be hard to figure out what was going on and start control immediately. Do you really think you'd have metal warped enough that you couldn't cut for a second or two at a fixed height?

I've never done anything with expanded metal, but I thought that the twisted parts came close to parallel to the torch. If that's the case, I'm not sure how you could tell what's going on.

[Rambozo]

The idea of trying to detect it by voltage change sounds good. I would think you'd still need to limit how long you ignored the voltage difference before you try to start controlling again.

With respect to starting from the edge, I've been going under the assumption that the initial height is okay. That makes it very simple to enable waiting a fixed time (a second or so) to start control. The voltage is all over the place at the beginning, so it would be hard to figure out what was going on and start control immediately. Do you really think you'd have metal warped enough that you couldn't cut for a second or two at a fixed height?

I've never done anything with expanded metal, but I thought that the twisted parts came close to parallel to the torch. If that's the case, I'm not sure how you could tell what's going on.

I know very little about this, I'm just throwing out ideas. I would say collect some data about what happens when you cross a cut kerf, and then what happens when you cross wider gaps and see what you can trigger on. Setting a time limit might be ok, but I can see where it could be an issue, especially with CNC. There are times where you might have to stop a cut for any number of reasons, then make a program change and restart. It's not always easy to pick up where you left off, depending on the code, so you might have to start back and recut over where you have cut before. So the kerf timer could cause a problem with that. In CNC milling it's no biggie to cut air while you get back to the part. If you pause the control you can usually pick right up, but let's say you are cutting a large circle, and your speed is a little too fast and you lose the cut. You would hit the E-stop and then reduce your cutting speed. However, to go back to that part of the program you would have to start that circle over from the beginning as it's only one line of code. So you would need the torch to stay out of THC mode until it caught up to where the cut ended. Not sure if this is easily detectable, or some place where you might just override the THC then start it once you have picked up the cut again. Just an idea. I'm sure as you cut more materials you will collect more data. I am really learning a lot from your experiments, and appreciate all the data you are posting.

[MuttonHawg]

Is there any way to feed information to the THC from the program controlling the X & Y movements? If so, at least in some cases, it would seem like the CNC program would know that a kerf crossing is coming up because it's something that was cut earlier in the program. This wouldn't help in the case of expanded metal, but it would seem to me that the more information that the THC had regarding what to expect about what's going to happen in the near future, the better a job it could do. Or is the THC a completely autonomous piece of code that does not and cannot have any strong coupling to the software that controls the path of the torch?

[Rambozo]

Is there any way to feed information to the THC from the program controlling the X & Y movements? If so, at least in some cases, it would seem like the CNC program would know that a kerf crossing is coming up because it's something that was cut earlier in the program. This wouldn't help in the case of expanded metal, but it would seem to me that the more information that the THC had regarding what to expect about what's going to happen in the near future, the better a job it could do. Or is the THC a completely autonomous piece of code that does not and cannot have any strong coupling to the software that controls the path of the torch?

While the CAD and CAM software will have that information, the actual CNC control is very basic, and does not look ahead or back more than a line or two. After all the G/M codes started out life as paper tape programs. There are some systems that do away with G code and have the CAD/CAM system drive the machine directly. I'm sure those could do things like that pretty easy, but not your average CNC. Think of it as an interpreted language, rather than a compiled one.

[EmptyNester]

Is there any way to feed information to the THC from the program controlling the X & Y movements? If so, at least in some cases, it would seem like the CNC program would know that a kerf crossing is coming up because it's something that was cut earlier in the program. This wouldn't help in the case of expanded metal, but it would seem to me that the more information that the THC had regarding what to expect about what's going to happen in the near future, the better a job it could do. Or is the THC a completely autonomous piece of code that does not and cannot have any strong coupling to the software that controls the path of the torch?

As Rambozo said - the G-code has no idea of what's already happened. I use Sheetcam. It would be possible for it to figure that out and insert it in the G-code, but it would probably make the G-code a lot choppier (if you had to stop a cut segment to issue a "kerf cross" alert and then restart the cut segement).

From what I've read, it is possible to interface the THC to Mach. I know some of the THC vendors do that, I just don't know if you have to have more information than is publicly available.

Longer term - I'd like to develop a custom THC screen for Mach that is more to my liking. With the serial port on the THC, I could then interface it to Mach. (I think Mach is pretty complex, so it could take a while to figure it out.) At the very least, it should be pretty straight-forward to replace the display and push buttons on the THC with control from the Mach screen.

[EmptyNester]

I've implemented an initial kerf detection that looks for rapidly changing voltage. While it can probably be impoved, it does work.

This graph shows the kerf crossing. The voltage is in blue and the voltage control status is in red. It turned voltage control back on when the voltage dipped, but then turned it right back off. I"m sure this could be improved but its good enough for now.



The full graph of the voltage, torch up signal, torch down signal and voltage control signal is below.



What I have been referring to as a "sawing" motion is only going in one direction, so it's really just "stepping". I think the z-axis speed would need to slow down to "smooth" it out. I'm not sure if that's the right thing to do.

Below is a video of both a slant cut and a flat cut.




At this point, I just want to clean up the source code and I'll post the first release on GitHub. It will be at:

https://github.com/regeg/ArdunioTHC

I'm also waiting on the second pass hardware boards to build and test.

At this point, I'm going to start using it with my table so I can do stuff more interesting that circles and squares.