Arc ignites on rapid speed height, than lowers.

[Valère]

Hello,

I am having trouble with the g-code that is created by sheetcam.
Sometimes the arc ignites on the rapid speed height, and than it goes down to the cutting height.
I found out that this doesnt happen if i have cutting height at 3.0mm, but when i do 2.8, 3.2, 3.5, 4.0 etc it causes the problem.

Are there any solutions for this?

Another small question,
I often see that when the object i am cutting has some arc's in it, the arc's are not always smooth. Is this a problem of the table or g-code?

Kind regards,
Valère Houben

[Valère]

This is an example of the ignition.

So u see the z 40, thats the rapid height. (Behind M5 torch off)
Than coordinates of next startpoint, than M03 (torch on), pierce delay and after all that cutting height...

[mancavedweller]

My first thought is you are using the wrong post processor. Which one are you using.

The gcode is clearly very wrong for plasma cutting.
After a cut it rapids to a safe Z height, then rapids to the next XY location, then instead of coming down to pierce height, it's just firing at the safe Z height, doing the pierce delay at safe Z height, then coming down to cut height. Very wrong.

[Valère]

Thankyou for replying,

I use the postprocessor delivered by the table supplier. (its not a big company like those american brands)
The thing is, like i said, all is fine if i use 3mm cutting height, if i make that 3,2 3,5 or 4, it does this problem. And when the job has 5 startpoints, its 1-2 random ones that do this.

-Is this a problem of the postprocessor, or within sheetcam? (cuz i believe cutting height has to do with it)
-If it is the post processor, is it easy to use another one? or do i than have a problem with my table?
-Also like i said in the first post, sometimes my arcs are not neatly round, but have an edge to the inside of the arc. Is this than also affected by the postprocessor?

Kind regards,
Valère

[mancavedweller]

Attach a copy of a job file that has this problem.

Find out which post you are using by going to:
Options menu / Machine / Post processor tab
This is where you can also choose a different post processor.

Also attach a copy of the post processor you are using. If it's a custom post processor go to:
help menu / Open settings folder/ posts

Default post processors that come with Sheetcam are found in:
C:\Program Files (x86)\SheetCam TNG\posts

That way I can have a look at the post processor and try it out.
It's rather weird that simply changing the cut height affects this issue. It could be some conditional coding in the post.

[Valère]

Thankyou for your time!

i put the job file in it, aswell as the g-code of it (check line 75-85) and the postprocessor.

But can i use any post processor, or am i limmited to the one of the table's brand?

[mancavedweller]

I had a play with your job file using the post processor you supplied.

I generated the gcode file and got the same as the gcode file you supplied, where the probing code has mysteriously been omitted at the line you mentioned.

I did a "Save As" on your job file and deleted your drawing then imported a drawing with 5 separate shapes. Used the same tool and generated the gcode but this time all 5 sets of probing code appeared in the gcode.

Seems to me like a coding bug in the post processor so I had a look.
The only thing I can see that appears wrong is at line 129 in the post processor file where it says this:

firstRef = refDistance >=0

I've done a little coding, and to me that statement is incorrect. The ">=" means "is greater than or equal to" and is normal used as a conditional check on a variable. However in this case it appears to be used incorrectly and I'm guessing this is "confusing" the post processor.

I think Les himself (Sheetcam creator) or the company that supplied your equipment, needs to look further into this to confirm whether I'm correct about this.

Sorry I can't be much more use than this.
The only other alternative is to use a different plasma post processor that will work with your equipment, but again if it's a custom designed system maybe you need to ask the manufacturer.

EDIT:
Had a bit more play with things. In the post processor at line 17 there is this code:

Code: Select all

--this is the distance between each torch reference in MILLIMETRES
--set it to -1 if you never want to reference
refDistance = 200

I changed that bottom line to:
refDistance = 1

When I generated the code after doing that, the probing was included.
So if you make the same modification in your post processor, hopefully your problem will be fixed.

Overall I think the post processor is not written correctly because if the torch is not doing the probing/reference moves before some pierces, then the gcode should be bringing the torch down to pierce height, and NOT firing the torch at Safe-Z height.
I looks like the post processor has simply been written to omit the referencing code if the torch has not moved at least the refDistance, but it's not as simple as that as you have found out.

I did more tests. I set refDistance at 3000 and had 4 objects only about 200mm apart. Therefore after the first reference/probe, there should not have been any more on the other 3 objects. However, the 2nd object did not have probing code, the 3rd object did have probing code, then the 4th object did not have probing code.
I set the refDistance back to 1 and all objects had the probing code.

Sorry to say it but the post processor seems to be written wrong and it has bugs in it.

Was this a cheap table ?

[Valère]

Thankyou, thats atleast a start!

I will adjust it and see how it works.

This is the table: https://www.pritec-automation.com/nl/product/acros-150/

Can you recommend me another post-processor? Table has x, y and a floating z-axis.

[mancavedweller]

I'll have a look for you but for now I need to inform you I was wrong about the statement I mentioned earlier, where I said that:

firstRef = refDistance >=0

was an incorrect statement.

In fact it is correct, and I now understand it's meaning. So disregard what I said about that.

OK, I've had a play with an old post I used some years ago. I put the switch offset at 1 which is the same as your original post.
See if this one works any better for you. It does have one advantage, in that at the beginning it raises the Z axis to the safe Z height before it moves to the first pierce point.

Hope it works.

MP1000-THC.scpost

(4.53 KiB) Downloaded 58 times

[Les Newell]

This should fix it. If you are interested in what was wrong, compare the two posts around line 327. Basically the code to move to pierce height was in the wrong place so it only worked after a probe cycle.

[Valère]

Great, thankyou very much both of you!

Good to know that there is a good community around here. Pretty sure i wil run in some more problems later on:p