Puddle Jump Height and Puddle Jump Delay Values

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

Actually, thinking about this, I may have defined the ramp in incorrectly. It would be interesting to see what Code Sheetcam generates for wiggle and ramp in.

I also think that as Stefan said, you don't need to worry about this on thin material and you probably are not going to be able to find it useful with a 45 amp machine.

Looking at my 120 amp machine, the pierce time at 16mm thick mild steel is 0.7 seconds but that becomes 1.6 seconds at 20mm.
The same machine at 40 amps, 12mm quotes pierce delay of 2 seconds so we are piercing faster than a smaller machine.

The book say edge start should be used for thicknesses from 25mm to 40mm so its probably in that range that the ramp in would become useful. I have not cut anything thicker than 16mm. The torch has nearly pierced it before it gets an ArcOK!

I kinda think if you were going to do this in the controller (eg. Plasmac), perhaps the controller would offset the start point so that the ramp in was at the programmed start point on completion of the pierce. This is a level of sophistication well beyond where we currently are and I think perhaps is something that could be easier in a plasmatask module suggested by Andy. I discussed this yesterday in another thread. I have got as far as compiling a copy of milltask renamed as plasmatask as proof of concept and I got that working in about half an hour but I suspect real modifications might take a bit longer!

Just to be clear when talking about piercing being controlled by the controller, I am not talking about a simple Gcode filter but doing it internally either within HAL via a component or deeper in Linuxcnc's internals via a modified version of task.