My (kinda) budget build 4x4 plasma table

[Dmaxpwr]

acceleration is more important than rapid (G0) velocity / speed.

you have a 45xp,

Makes sense to me, I'll make those changes first thing, thanks.

[Dmaxpwr]

1/5" pitch, 20T = 4" per revolution

200 motor steps X 10 microsteps = 2000 steps per revolution

2000 steps per revolution / 4" = 500 steps per inch

Does it make sense that the X axis (single motor) has a higher SPU (5387.0997) than the Y/A axis (two motors) that has a lower SPU (3044.9416)?

Both of these were tuned to 1/64" over a 46" span. And the DRO shows the same measurements.

[Rodw]

Dmaxpwr, Are you running a reduction drive? I'm not seeing one in your numbers.

Robert, could you share the formula for the minimum arc radius? I thought it would be r = V^2/a but the results seemed wrong.
I'm not sure where the 0.3 G benchmark comes from. Can you elaborate? I suspect Jim Colt.

When I recently reviewed some high end machines looking for their acceleration numbers and several quoted around 0.7G. I was able to obtain 0.8G on the X axis but the best I could get away with on the heavier Y axis today was 0.5G. The difficulty is building a rigid enough table so that the accuracy is not affected by the inertial forces. I suspect that designing for 0.3 G will be infinitely easier.

Personally, while setting up parameters for the fasted cut speed in the book does make sense, you need to make sure the motor has enough left in the tank for the rapids. A nest of small parts with a few holes in them has a lot of rapids in it. With my upgrade, I've been able to double the rapid velocity and that combined with a recent revision to Plasmac to speed up probing time by smashing into the material at rapid speeds and depending on the float switch travel to coast to a halt will make a massive difference to job run times. The probing will remain dead accurate as after that initial contact, the torch will back up at a slower speed, then probe forward and back again at progressively slower speeds.

[Dmaxpwr]

Rod, I'm not running any reduction, just the 20T pinion.

[robertspark]

Robert, could you share the formula for the minimum arc radius? I thought it would be r = V^2/a but the results seemed wrong.
I'm not sure where the 0.3 G benchmark comes from. Can you elaborate? I suspect Jim Colt.

When I recently reviewed some high end machines looking for their acceleration numbers and several quoted around 0.7G. I was able to obtain 0.8G on the X axis but the best I could get away with on the heavier Y axis today was 0.5G. The difficulty is building a rigid enough table so that the accuracy is not affected by the inertial forces. I suspect that designing for 0.3 G will be infinitely easier.

Yes 0.3G, came from one of Jim Colts posts on here, or cnczone

Don't forget that this is a "budget" build using belt drives so there will be some flex in the belts and also in the rubber teeth of engagement.

I'm a bit busy today but will come back to you with better answers tomorrow / later.

[robertspark]

Robert, could you share the formula for the minimum arc radius? I thought it would be r = V^2/a but the results seemed wrong.

Its the same centripetal acceleration formula, but all I've done is allowed for arcs to slow the feedrate to 60% of the optimum linear feedrate which will allow for a tighter corner (sheetcam path rules)
[325ipm / 60 ]^2 / [9810 / 25.4 *0.3] = 0.25" radius (sorry, I'm actually metric at heart, hence g~9.81m/s/s.... but can interchange mm/inch)

the alternative for arcs / holes less than 25mm diameter (1")
[325ipm / 60 * 0.6 ]^2 / [9810 / 25.4 *0.3] = 0.091" radius

The 60% for holes less than 25mm (1" dia) came from here, but there are numerous posts from Jim too
https://www.hypertherm.com/en-US/suppor ... ter-holes/

I think this is largely for highdef plasma and not air, but the advice is similar, but you won't get the same hole quality as a $100K+ machine obviously for $2K...
https://www.hypertherm.com/support/syst ... e-quality/

I'm not sure where the 0.3 G benchmark comes from. Can you elaborate? I suspect Jim Colt.

Some of Jims posts noted 0.3G and upwards

here is one that has an optimum band of 0.5 to 0.3G at 400ipm
viewtopic.php?f=103&t=21011&p=124153&hi ... on#p124153
the post or two has a youtube clip of a very fast moving machine (3000IPM at .6G)

When I recently reviewed some high end machines looking for their acceleration numbers and several quoted around 0.7G. I was able to obtain 0.8G on the X axis but the best I could get away with on the heavier Y axis today was 0.5G. The difficulty is building a rigid enough table so that the accuracy is not affected by the inertial forces. I suspect that designing for 0.3 G will be infinitely easier.

and cheaper...... it is probably worth while relating to the cut.....
remember that a radius less than x1 - x1.5 the material thickness is probably not going to cut very well, because the torch has to slow down so much it will have a bevel
and also consider the kerf width.

give me a practical example of what is your thinnest material you intend to cut and what is its optimum linear feedrate, and do you know what it's kerf width is?

Personally, while setting up parameters for the fasted cut speed in the book does make sense, you need to make sure the motor has enough left in the tank for the rapids. A nest of small parts with a few holes in them has a lot of rapids in it. With my upgrade, I've been able to double the rapid velocity and that combined with a recent revision to Plasmac to speed up probing time by smashing into the material at rapid speeds and depending on the float switch travel to coast to a halt will make a massive difference to job run times. The probing will remain dead accurate as after that initial contact, the torch will back up at a slower speed, then probe forward and back again at progressively slower speeds.

If you have a big table then high rapids make sense in a production environment.

In a hobby environment, no, sorry that is just big engine, small appendage syndrome....

2020-07-15 21_33_29.png

note: acceleration makes no difference to these times, because the as the acceleration increases the distance for acceleration and deceleration gets shorter, but the distance for travel at the rapid traverse distance gets longer to compensate for the shorter acceleration distances (as the accel/decel increases).

Here are a few other tables to consider:

2020-07-15 21_39_36.png

2020-07-15 21_41_56.png

2020-07-15 21_45_12.png

2020-07-15 21_47_14.png

2020-07-15 21_49_25.png

[Dmaxpwr]

I meant to post this earlier as an FYI, but forgot too. Part of the cause for the extremely slow travel speed that I was having earlier was that the manual that I got from the supplier for the KL5056 driver is incorrect.

I set my switches (Sw1-on, Sw2-off, Sw3-off) for 4.9a per the manual.

fullsizeoutput_1b80.jpeg

But looking at the KL5056D manual, I noticed that the 1/0 or on/off is reversed between the two manuals. So when I set the driver for 5.6a I set the dipswitches to all on (Sw1-on, Sw2-on, Sw3-on) per the KL5056D manual.

fullsizeoutput_1b7d.jpeg

[Rodw]

Robert, could you share the formula for the minimum arc radius? I thought it would be r = V^2/a but the results seemed wrong.

Its the same centripetal acceleration formula, but all I've done is allowed for arcs to slow the feedrate to 60% of the optimum linear feedrate which will allow for a tighter corner (sheetcam path rules)
[325ipm / 60 ]^2 / [9810 / 25.4 *0.3] = 0.25" radius (sorry, I'm actually metric at heart, hence g~9.81m/s/s.... but can interchange mm/inch)

the alternative for arcs / holes less than 25mm diameter (1")
[325ipm / 60 * 0.6 ]^2 / [9810 / 25.4 *0.3] = 0.091" radius

The 60% for holes less than 25mm (1" dia) came from here, but there are numerous posts from Jim too
https://www.hypertherm.com/en-US/suppor ... ter-holes/

I think this is largely for highdef plasma and not air, but the advice is similar, but you won't get the same hole quality as a $100K+ machine obviously for $2K...
https://www.hypertherm.com/support/syst ... e-quality/

I'm not sure where the 0.3 G benchmark comes from. Can you elaborate? I suspect Jim Colt.

Some of Jims posts noted 0.3G and upwards

here is one that has an optimum band of 0.5 to 0.3G at 400ipm
viewtopic.php?f=103&t=21011&p=124153&hi ... on#p124153
the post or two has a youtube clip of a very fast moving machine (3000IPM at .6G)

When I recently reviewed some high end machines looking for their acceleration numbers and several quoted around 0.7G. I was able to obtain 0.8G on the X axis but the best I could get away with on the heavier Y axis today was 0.5G. The difficulty is building a rigid enough table so that the accuracy is not affected by the inertial forces. I suspect that designing for 0.3 G will be infinitely easier.

and cheaper...... it is probably worth while relating to the cut.....
remember that a radius less than x1 - x1.5 the material thickness is probably not going to cut very well, because the torch has to slow down so much it will have a bevel
and also consider the kerf width.

give me a practical example of what is your thinnest material you intend to cut and what is its optimum linear feedrate, and do you know what it's kerf width is?

Personally, while setting up parameters for the fasted cut speed in the book does make sense, you need to make sure the motor has enough left in the tank for the rapids. A nest of small parts with a few holes in them has a lot of rapids in it. With my upgrade, I've been able to double the rapid velocity and that combined with a recent revision to Plasmac to speed up probing time by smashing into the material at rapid speeds and depending on the float switch travel to coast to a halt will make a massive difference to job run times. The probing will remain dead accurate as after that initial contact, the torch will back up at a slower speed, then probe forward and back again at progressively slower speeds.

If you have a big table then high rapids make sense in a production environment.

In a hobby environment, no, sorry that is just big engine, small appendage syndrome....

Robert, very valuable info thanks. My 400kg+ table is not so elegant with its footwork while dancing... Its currently sitting on casters which were rocking but I have some M30 threaded adjustment legs to go on once its finished and I don't want to move it again ... I think the frame will stay in one place but it did occur to me to drill some holes in the feet so I could anchor it to the floor!

My Spaceship Plasma was always designed to be industrial quality. Jim has some good advice.

I have been able to teach Linuxcnc to tell me the arc radius in real time and if that radius is a hole or not. So assuming the trajectory planner follows the same fundamental physics, it will now be possible to calculate how much the velocity needs to be slowed for a given radius which can be achieved in Linuxcnc in real time via adaptive feed.... the final step would be to offset the motion path to account for the wider kerf. Of course the other thing I am learning is that I should be using a 7mm radius not 5mm when designing parts....

DmaxPwr welcome to the dodgy world of plasma misinformation. Great you got it working. Sorry we've hijacked your thread...

[Dmaxpwr]

I got the torch connected and can fire it manually by turning the Spindle CW switch on, but I still can't run any gcode without getting errors, or skipping past the torch and Z-axis movements. When I attempt to run it, it will either run the torch hard into the table (past the probe switch), or it travels all the way up and tries to continue until ether I turn it off, or it times out with a "MACRO ALARM 3 MERROR_NOT_NOW" message.

Up until tonight I've been assuming that I was having issues with the gcode itself, but I ran it through a simulator and it runs just the way i would expect it to. So now I'm pretty sure that the issue is with my Mach4 setup.


Homing and offsets

n6N9q1eyTt6PPKSwyD7%yA.jpg

This is a video of me attempting to run the test code from Mach4
<iframe width="560" height="315" src="https://www.youtube.com/embed/RxvM5onNccI" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>




.

[Dmaxpwr]

Finally made some progress today, it turns out that one of the guys on the fire department is a Machinist and he offered to give me a hand. Thank god for that because I've been lost with this thing for weeks .

I've been thinking that since I'm attempting to run the test gcode supplied with Mach4, that the issue was with my Mach4 settings. Well, it turns out that the problem was with the gcode and post processors. Once he edited the gcode, the table would function and everything worked, kinda. We think that I either have an issue with backlash or the movement is so fast (14ga material) that the weight of the gantry is causing flex and drive belt stretch?!? The pattern looks right on the screen but when I try to run it, the shapes aren't even close.

The drive belts are currently relatively loose and I can move the gantry slightly by pressing on the belt. I'll see if I can tighten them up tomorrow. I'll also run the same pattern on thicker material to see if its still screwed up at slower trade speeds.

[Dmaxpwr]

So I tightened the belts and it seamed to take some of the loosens out of the gantry, at least when wiggling it by hand. I spent quite a bit of time running patterns without firing the torch just trying to figure out what needs to be edited in the post processor. Its getting closer so I decided to run a cut again, when I did, the pattern it was terrible. Clearly there's quite a bit of looseness somewhere. When I checked the pinion gears again and found that the set screws came loose again. They're only 3mm screws and are so short that I'm hesitant to put any real torque on them. I decided to drill them out and re-tap to 4mm screws to get more bite. When I installed them I used blue lock-tite, hopefully this takes care of the slop issue.

Unfortunately I won't have much time to work on it before next week, so I'm not sure if I'll have time to test it again.








_____

[acourtjester]

2 things file a flat on the motor shaft where the setscrews contact, the shafts are hardened and without a flat they still can slip.
Next do a search on mounting an ink pen to the torch to mark paper in place of cutting much easier to see mistakes and saves metal.
about half way down in this post
viewtopic.php?f=52&t=30504&p=184317&hil ... en#p184317

[Rodw]

Also sometimes you can drill a dimple in the shaft thru the set screw hole once its all into position.
The last ones I mounted used a keyway...

[Dmaxpwr]

2 things file a flat on the motor shaft where the setscrews contact, the shafts are hardened and without a flat they still can slip.
Next do a search on mounting an ink pen to the torch to mark paper in place of cutting much easier to see mistakes and saves metal.
about half way down in this post
viewtopic.php?f=52&t=30504&p=184317&hil ... en#p184317

I really like the ball point pen idea, I keep putting sharpies on there with zip ties but they get mashed up pretty quick.

Also sometimes you can drill a dimple in the shaft thru the set screw hole once its all into position.
The last ones I mounted used a keyway...

The shaft already has 1 flat, but I like the idea of filing or drilling for the second set screw. I'll get some cupped set screws to keep on hand and if/when it loosens up again I'll have the parts on hand to fix it correctly. Keyway would be the ultimate solution.

[Rodw]

I just rediscovered a recommendation I was given years ago. There is always these too
https://au.rs-online.com/web/p/keyless-bushes/0814950/
The last keyway one I did had different sized key on both the motor and the pulley so I had to machine a stepped key... but once I got it on, its never going to move!

[Dmaxpwr]

I've finally have some time to come back out to the shop and play around with the plasma table. I thought all I needed to do now was to figure out how to fine tune the post processor script. The issue I'm having with it is that when I create a file in SheetCam and import it into Mach4, it looks right (I think) but when I attempt to run it the torch doesn't pierce at 0.15", it will go from the 1.5" travel height directly to 0.06", fire the torch and then follow the pattern without any other height change until that cut is complete. Here's a portion of the code that I'm currently testing with. I think it looks right but am not sure, what am I missing?

N0010 (Filename: HOP BOTTLE OPENER_Rev. 1.5 Mach3 plasma.tap)
N0020 (Post processor: Mach3 plasma.scpost)
N0030 (Date: 02/08/2020)
N0040 G20 (Units: Inches)
N0050 G53 G90 G91.1 G40
N0060 F1
N0070 S500
N0080 (Part: HOP BOTTLE OPENER)
N0090 (Operation: Outside Offset, 0, T40: PM45XP 45A 3/16 Mild Steel Best Quality)
N0100 M06 T40 F85.0 (PM45XP 45A 3/16 Mild Steel Best Quality)
N0110 G00 Z1.5000
N0120 X5.9028 Y0.7477
N0130 Z0.1500
N0140 M03
N0150 G04 P0.5
N0160 G01 Z0.0600 F80.0
N0170 G03 X6.0389 Y0.6283 I0.1277 J0.0084 F85.0
N0180 G01 X6.0794 Y0.6310


On top of that I'm now I'm having another issue, I can no longer home the machine. When I attempt to home/reference it, the Z and X axis will home properly but as soon as the Y/A axis home switches are tripped, all indicators on theC25 BOB go out. When this happens the DRO on Mach4 continues to count until I disable the machine.



I'm really struggling with this thing so any opinions on either of these issues would be greatly appreciated.

[acourtjester]

the first part I don't see where you establish where Z 0.0 is, are you moving the torch to the metals surface as a start point. Your first Z move is to 1.5" from where? There is not home for Z (G31 ohmic sensor, G28 floating head switch).

It seems you are stating the Y/A axis moves to home and the switches are tripped and the led goes out. Normally when an axis homes it backs away from the switch a small amount. It seems like there is a move command (DRO counting) but the motor is not moving, even the move command should have a small value for the axis to move, not continue to count. I assume you can move the Y/A axis with the keyboard keys.

[Dmaxpwr]

the first part I don't see where you establish where Z 0.0 is, are you moving the torch to the metals surface as a start point. Your first Z move is to 1.5" from where? There is not home for Z (G31 ohmic sensor, G28 floating head switch).

I've been trying so many different post processors to find one that works, that I didn't even notice that this one isn't set up for the floating head. But to answer the question, yes, I've been lowing the torch to the metal surface and zeroing out the z axis.

It seems you are stating the Y/A axis moves to home and the switches are tripped and the led goes out. Normally when an axis homes it backs away from the switch a small amount. It seems like there is a move command (DRO counting) but the motor is not moving, even the move command should have a small value for the axis to move, not continue to count. I assume you can move the Y/A axis with the keyboard keys.

This was working great for quite a while, typically when I would home the unit, the M0, M1, M2 & M3 indicators as well as the X, Y and Z home indicators will be on. For some reason I've never been able to get the A home indicator working. These motor and home indicators would stay on until I moved the unit away from respective home switch.

With this recent development, when the Y/A axis trips the home switch, the X & Z home switch indicators go out, the Y/A indicators don't turn on whatsoever.

[acourtjester]

It seems there is a problem in how the limit/home switches are wired or configured this is what the M indicators are saying ( I'm sure you understand that) M1= X m2=y ect. the + = all the way in a positive direction and - = all the way negative limits and the M home is at 0.0 for each axis.
When it moves to home and trips the switch it should move lightly away from the switch and the indicator should go out. If you are using Mach you need to enable A switch as you did for X, Y, and Z and the +, - and home if you want to use those functions. Also checking the active low either for NO or NC as to how they are wired. All my +, -, and home switches are wired in series and in a NC condition using only one input pin on the BOB. This works for me as to how I use them.
If Mach is moving any axis and a switch is tripped it stops as a limit. And if Mach is if moving to a home and any switch trips if acts as a home and backs off the switch. A floating head switch works as it should when using a G-code G28 with the Z axis even as it trips all switch indicators Mach sees it as Z home and backs away and the next G-code moves to a backlash correction and then to pierce height. Not everybody does it this way but I do and it works fine for me.

switches.JPG

switches.JPG

[Dmaxpwr]

It seems there is a problem in how the limit/home switches are wired or configured this is what the M indicators are saying ( I'm sure you understand that) M1= X m2=y ect. the + = all the way in a positive direction and - = all the way negative limits and the M home is at 0.0 for each axis.
When it moves to home and trips the switch it should move lightly away from the switch and the indicator should go out. If you are using Mach you need to enable A switch as you did for X, Y, and Z and the +, - and home if you want to use those functions. Also checking the active low either for NO or NC as to how they are wired. All my +, -, and home switches are wired in series and in a NC condition using only one input pin on the BOB. This works for me as to how I use them.
If Mach is moving any axis and a switch is tripped it stops as a limit. And if Mach is if moving to a home and any switch trips if acts as a home and backs off the switch. A floating head switch works as it should when using a G-code G28 with the Z axis even as it trips all switch indicators Mach sees it as Z home and backs away and the next G-code moves to a backlash correction and then to pierce height. Not everybody does it this way but I do and it works fine for me.

I'm open to try anything at this point, my biggest battle right now is finding time to work on it. Lately I only have a few minutes every other day or so to be able to work with it.

This is how I have my home switches are set up and up until recently it seemed to work great. I tried to the X/Y/Z/A++ settings also but all it didn't seem to have an effect other than e-stopping the machine. I had to click on "limit override" to be able to move the machine. And when I attempted to home it I had the same thing happen, the DRO kept counting until I disabled it.

When it trips the home switches, it definitely doesn't move back any. It stops in place and the switches stay activated. I think as soon as I have some more time I'll check to see if the C25 BOB board is loosing power when the Y/A axis home switch is tripped, that's what I think is happening.

[acourtjester]

Here is how my home/limit switches are configured with NC wiring and Active low green checked. I think Mach 4 would be the same, I has been years since I messed with Mach 4 so I may not be the best to get help from.

[Dmaxpwr]

Here is how my home/limit switches are configured with NC wiring and Active low green checked. I think Mach 4 would be the same, I has been years since I messed with Mach 4 so I may not be the best to get help from.

So thats pretty much what I did, other than checking active low because I'm running NO switches. And I have each home switch going to a separate input because I didn't realize that I could run all the axis switches in series. But because I have it set up to stay in place when it trips the home switch, I need to click limit override to move again.

So I guess the first thing I need to do is set it up to move off the home switch once homed, sorry for the dumb question, but how do I do that?

I have a -3.375" offset on the X axis, will the software automatically compensate for this for my X++ or do I need to enter this somewhere also?

[acourtjester]

In Mach 3 you go to home/limit and each axis has a off home box, I put like 0.250" It may be different in Mach 4

limit.JPG

[Dmaxpwr]

In Mach 3 you go to home/limit and each axis has a off home box, I put like 0.250" It may be different in Mach 4
limit.JPG

Thanks, I haven't had a chance to even look at the machine for three or four days now, but I just checked my screenshot pictures and now I see where to enter the home offset. It was staring me right in the face, its even labeled "Home Offset". Hopefully I can get a few minutes to try this out this week.

Thanks again for your help!

[Dmaxpwr]

I had to put this project on hold for a few months because of work, other projects, and life taking priority. But I recently started back on the rock crawler buggy project and need some brackets cut. And I just can't bring myself to have my buddy cut them for me when the plasma table is so close.

So, after months of this thing sitting in the corner of the garage I finally pulled it back out to see it I can get it working. I decided to remove all of the proximity switches and replace them with plain old microswitches. I also rewired them in series to limit my inputs. I still separated the Y, X, and Z limit switches but now I only have 3 signals (4 wires) instead of 7 signals (14 wires). I also installed a Kemo waterswitch to use as a ohmic sensor. After rewiring the limits, and the previous stepper motor rewire, that left me with a ton of unused wires so I removed the 18/19 multi conductor harness and re-wired everything through the other one.

With all the switches replaced and the re-wire done I figured I'd fire it up and see where things stand. I still had an issue with the pierce sequence so I did a ton of experimenting with different post processors, I got sick of dealing with the Mach4 Demo version timing out on me while messing around with these so i finally bit the bullet and purchased Mach4 Hobby. My first test after installing the product key worked fine, the pierce started at 0.150", ran for about 1/2 second, lowered to 0.060" and proceeded to travel. I'm guessing that there was a glitch in my Mach4 Demo version because it's now working. It really sucks that I spent so much time chasing this problem, but at least it's working now. Still have a lot of fine tuning to do but I have a good starting point so hopefully this goes a little easier.