Rotary Plasma G00 plunge below surface before and after path.

[ionian]

Morning and Merry Christmas all,

I've got a FastCut IconElite that had a rotary attachment added by one of their preferred technicians (one off).

There have been a few hiccups with the post processor that I've tolerated editing the g-code, but I'd like to knock them on the head for training some young guns.

Before and after the cutpath, the head will plunge below the surface of the pipe using a G00 command. I've just been using a ReplaceAll edit to work around this but it's getting to be a bit much as we get busier and I'm making lots of prototypes that need small tweaks.

I've attached bot the g-code and the post. Fair warning there are a couple other errors in the post that I will made separate threads about.

Any help would be hugely appreciated.

Jono

[ionian]

Sorry, I was going to post separate topics for some unrelated issues but they were denied.

Second problem is that between each rotation dependent part such as HSS the A axis doesn't return to 0. Which means for each new part I need to zero A with a bubble. I've attached an example file, and my post.

[ionian]

The third issue I've been having, and most serious to getting this job done, is I'm cutting five 5/16" holes in a line on a 2-7/8 pipe, and though identical in the dxf, the first two holes cut normally with X/Y coods, the third and fourth cut very slowly with G03 and I/J, then the fifth cuts normally, as you can see in the attached file (which still has the unedited plunge G00 Z problem). Of course the tolerances are all blown out. I've attached the post as well.

[ionian]

Hoping to get a general direction on where to start on some of these issues - is there an option for direct payment support by the hour? FastCut the table builder doesn't do rotary, and my technician that built the rotary is sort of at the limits of his software skills.

eedited for grammar.

[Les Newell]

Sorry about the delay in replying.

Before and after the cutpath, the head will plunge below the surface of the pipe using a G00 command. I've just been using a ReplaceAll edit to work around this but it's getting to be a bit much as we get busier and I'm making lots of prototypes that need small tweaks.

Someone added those moves to the post. I will take them out.
The referencing looks suspect as well. Have you had any problems with the torch height after referencing?

Second problem is that between each rotation dependent part such as HSS the A axis doesn't return to 0

For some reason it has a G92 at the end, which resets your A axis zero. I have taken it out.

The third issue I've been having, and most serious to getting this job done, is I'm cutting five 5/16" holes in a line on a 2-7/8 pipe, and though identical in the dxf, the first two holes cut normally with X/Y coods, the third and fourth cut very slowly with G03 and I/J

Could you send me the job file (File->save job) with everything set up ready to post process.

[ionian]

Thank you very much for your response Les.

Here's a the job file, I tested it again on rev2 to make sure it's still doing the weird behavior which it is. RE: funny referencing - maybe! I have to reference the center of the rotary axis, which is a bit of a pain, it would be much easier to reference the surface of the pipe, though I don't know if this would complicate referencing square shapes? Also, I've had an issue day 1 with "sewing machining" on the THC especially with thicker plate, I turn off THC entirely for rotary - I think THC is a no go for HSS, maybe not for pipe? I've always suspected my THC doesn't work as well as it should but being a novice I was sure to have been my error. That said I don't think bad table THC or sewing is a SheetCam issue though?

All your time and help is greatly appreciated! Happy Christmas and a Merry New Year.

Jono

[Les Newell]

Hmm, your job highlights a bug in the rotary plugin that only shows up sometimes on round tubes with small holes. It should not be using G02/G03 arcs.
The attached post has a workaround. It will still use arcs but at least the feed rate will be correct.

I have to reference the center of the rotary axis, which is a bit of a pain, it would be much easier to reference the surface of the pipe, though I don't know if this would complicate referencing square shapes?

Yup, in rotary mode the post uses the centre of the rotary axis. As you suspected this is because of square and custom shapes.

The original Fastcut post I wrote reset the Z axis after a reference cycle to allow for this. For some reason this code has been removed. I have put it back.

Also, I've had an issue day 1 with "sewing machining" on the THC especially with thicker plate

I have to admit I have never used Fastcut's THC but this sounds like a THC tuning issue. Does it save some form of damping adjustment? If so try turning it up. If it has a sensitivity adjustment try turning it down.

[ionian]

Brilliant! With any luck I'll retire just before you.

One issue though, REV4 seems to output empty files. I'm sure it's something simple.

Another thing I had forgot to ask, wiggle seems to work best for me on thick plate, but when I change that in the tool, and us a rule for curves, I get two pierces (wiggle pierce, stop, slow wiggle pierce to cutpath). Hope you're well.

Jono

[ionian]

Quick bump!

[Les Newell]

Sorry about that. I'll look into the wiggle. I just tested the post and can't find anything wrong. Could you send me a job file that demonstrates the problem.

[ionian]

Sorry Les, user error, must have loaded the post improperly, it's outputting.

Unfortunately it's behavior is worse, I still get the below depth plunge, and after each cut path the nozzle starts higher and higher. Good news is the arcs seem to be cutting at the same speed! I'll attach the tap and job. You can see in the g-code it sends z lower than 1.4375 which should be pipe surface.

Hope you're well.

[Les Newell]

Give this a try.

Wiggle is a potential issue if a rule occurs in the middle of a wiggle.
Currently it does wiggle - rule - wiggle, which is not ideal. Firing the rule multiple times as it runs the wiggle probably isn't ideal either. How about saying that rules cannot be applied during a wiggle pierce. If a rule does end up in the wiggle it will be moved to the end of the wiggle. Would that work for you?

[ionian]

I'm only barely following along with what you're suggesting - best I can offer is to try it out and report back! Downloading REV5 now, will try in the next 10 minutes.

[Les Newell]

I'll change the wiggle pierce for the next release. Posts don't have control over that.

[ionian]

So! An improvement, but before the first pierce it seems to reference itself 0.400" higher in Z, then 0.400" more after each cutpath. I measured the floating "cut" at 0.461" so I'm guessing with cut height and my caliper skills being medium it's 0.400" somewhere in the code. If we can figure that out I think it's solved! Tap and job attached.