Puddle Jump Height and Puddle Jump Delay Values

Plasmac has the option for both puddle jump height and puddle jump delay. My reading seems to indicate this is probably more useful for cutting thicker materials. Does anyone have some recommended values for 6-12mm thick materials (mild steel, aluminum, stainless)?

Thanks,
Steven

Steven,

Puddle jump height is not needed until you get into the 25mm plus range, 6-12mm does not need it, what you do need is correct pierce height and cut height setting and correct lead in setting.

If your using a hypertherm unit there is a cut chart with these settings for different material in your user manual.

the puddle jump height is to get over the outer edges of the crater / topside dross which is formed when trying to pierce thick materials.

the plasma gas obviously has blowback / spray when piercing thick materials where the metal is displaced upwards and outwards.

the consideration whether you need it or not is (in my opinion) to consider the height of the crater formed , or rather the edge above the material, and if this is higher that the cut height (or close to) then you may want to add a bit of puddle jump... the delay is obviously the time to give the torch time to clear the edge of the crater before decending to the cut height. the delay will be a function of the distance and xy distance to travel

the reason why it's needed is because the torch decends from pierce height to cut height after the arcOk signal AND the pierce delay and you don't want to drag the tip of the torch though the top of the piece crater (which may be molten or solidified dross), also there is normally a THC delay where the torch is given a chance to get a stable voltage reading so you want that THC delay to be long enough to get a "clean" voltage sample past the pierce crater / topside dross.

You realise by the time you are finished with him poor old Phill will also have to add in built ramp and wiggle piercing to Plasmac?

Interesting snippet here from Autocad re Fusion360

On industrial plasma / oxy-fuel cutters this is all handled in the control.

forums.autodesk.com/t5/fusion-360-manufa...eration/td-p/6390913

I have not used it, but ramp piercing makes a lot of sense to me where the torch drops to cut height while moving along the leadin so there is clearance for the dross to shoot out behind. Wiggle piercing attempts to wiglge the torch to try and make room for the puddle.

Thanks for the input. Having read a few horror stories about first cuts going very bad due to the slag created by the pierce, I didn't want to repeat those mistakes. I am using (well, will be once it gets delivered) a Hypertherm 45xp unit and have set the cut and pierce heights, as well as the pierce delay, per the cut charts.

Rod,

You replied while I was in the middle of my last reply!

I've seen that discussion. Fusion360 has definitely made some progress with plasma cutting but there is still a lot left to do. I have modified the Fusion360 LinuxCNC post-processor to work with plasmac. It seems to be working as well as I can tell without a plasma. All the movement seems to be correct and comparing my output to what you and others have posted, all seems to be in order. I haven't put it up for public consumption yet - I want to be sure there are no glaring problems first.

I like the ramp piercing idea as well and will have to start thinking about how I might add that to the post-processor. Looks like Phill did end up using the hole overcut code I had sent him. Maybe, if I can figure this part out, I can send him what I have to see if he wants to use it as well.

Rod,

Just had a quick look to see if there would be a way to look at the g-code to determine when the ramp should start. It could be done but everyone would have to agree on what the lead-in to the cut would be. For example, here is code that uses 2 lines (a short straight segment [G1 X41.23 Y-3.1] followed by an arc [G3 X36.9 Y-0.6 I-4.33 J-2.5]) as a lead-in to the cut:Realistically, the lead in could be any move or moves, we would just need to agree on how many lines of g-code there would be for the lead-in. If we had consistency in the number of lines, it wouldn't be too hard to parse and then plasmac could generate the ramp down (z steps) needed over those line(s) of code.

If Phill doesn't respond in this thread, I'll post something back over in the plasmac thread to see what he thinks. I would suspect this should be an option and not something the user is required to use.

why does no one want to use the post processor to do these tasks (leadin + leadout + overcut etc)

(just in my opinion) realistically you need the leadin to follow the direction of the cut and the ramp angle to be a function of the acceleration and federate to that at the end to the ramp angle and the leadin the torch is moving at the defined feedrate

I tend to like arcs and loops for lead-ins, leadouts and sharp outside corners with the radius determined by the feedrate so that the federate does not drop below 60% of the linear feedrate

Robert,

Since plasmac takes over control of the Z-axis and strips all Z commands out of the .ngc file, a ramp down during the lead-in created in the post processor would never be executed. What I am suggesting is that you let the post processor take care of the X and Y movements, whatever you want them to be, and then let the g-code parser in plasmac find those movements and execute the lead-in controlling the Z-axis to move from the pierce height at the start of the lead-in move(s) down to the cut height by the end of the last lead-in move. The g-code parser will have to be able to understand what the lead-in moves are vs. the moves that create the actual cut you want. I can see how this could be set up as an option:

1. Use/Do not use ramped lead-ins
2. If using ramped lead ins, number of lead in moves at the start of a cut

Fusion360 offers a straight lead-in cut at whatever angle you choose, a radius lead in at whatever radius you choose, or a combination. Again, we let the user and the postprocessor determine the X and Y moves, plasmac would only adjust the Z.

With the exception of the Z movements, I agree the post processor can probably handle just about anything needed for plasmac. I programmed my post processor to do the overcut for holes (so will not likely use that option in plasmac) but not everyone is going to be able to or even want to do that. Phill has been great at making these sorts of things as options which makes a lot of sense to me.

You bring up an interesting point about the ramp angle. One issue that would have to be considered, especially for thicker material, relates to the time it takes to pierce the material. Even just a short lead in on 1mm material would take enough time for the material to be pierced; but if you used that same feedrate and acceleration and lead-in distance on material that was 25mm thick, you would be into the cut before you ever fully pierced the material. This shouldn't be too difficult to handle mathematically as plasmac has the pierce delay time from the material file. You would need to be certain the lead-in movement time would be at least as great as the pierce delay time.

All of this may be irrelevant if Phill is not interested in adding it to plasmac - especially since you can already protect your torch by using puddle jump. But it's still interesting to think about how to implement it.

Steven