entityClosed nd OnNewEntity explanation

Hey Les, when does the variable entityClosed get updated. I am trying to use it and i need to use it inside OnPenDown, but it is either broken or not updated until after OnPenDown is called. That being said, is OnNewEntity executed before or after OnPenDown? I could possibly use that, but only if OnNewEntity is executed before OnPenDown.

entityClosed is updated just before OnNewEntity is run. If I remember correctly it is called before OnPenDown. You can check using the post editor/debugger. Create a OnNewEntity function and set a breakpoint on it (Click on the grey bar on the left where you want to set a breakpoint). Set a breakpoint on OnPenDown as well. Now run the post. It will stop and show the editor when it hits a breakpoint. Use F5 or the continue button on the tool bar to continue.

I see why what i was trying to do isn’t working now. entityClosed isn’t updating. Or at least its staying False. There should only be one open entity on this part and the rest should be closed, am i wrong in my understanding? Well, the drill points may count as an open entity also, but that wont matter.

Do you have a leadin or leadout? Any path with leads will be considered open.

Les,

is there any way to check for leadins in the post ?

Personally I’ve never had a leadin / leadout on an open path, so if I can check for leadins/outs on a path, I can assume the path is a closed one with leadins/outs applied.

Of course the ideal way would be to be able to check if the path was a closed one BEFORE the leadins/outs were applied.

Keith

Keith,
There is a way to do that actually. There is a variable “leadinType” – 0 if it is not, 1 for leadin, 2 for leadout. That was an excellent thought you had, this may just work for what i am trying to do. I’ll report back shortly.

I cannot think of any situation right now that i would ever want a leadin/out on an open path either. For jet cutting anyways. But i can now however think of a few random times when i would not use a leadin/out on a closed path… the post would be tricked into thinking it is an open path and not offset. Then though, i could use a combination of leadinType and entityClosed to determine what type of path it is. That’s just complicated. It would be wonderful if there was an offsetDir variable that was no offset, left offset, right offset. That’s exactly what i need. Sorry, i was thinking out loud in that paragraph.

Of course the ideal way would be to be able to check if the path was a closed one BEFORE the leadins/outs were applied.

Agreed, ideally the entityClosed needs to be evaluated without the leadin/out in consideration.

Hi David,

thanks for that info David. I actually broke my own rules and asked the question before running through the Sheetcam post documentation. Just opened my file and there is the variable listed.

And yes, that’s exactly what I’d do regarding combination tests of variables, example pseudocode:
if entityClosed or if leadinType 1 or if leadinType 2
then I can assume it’s a closed path

Please, please, never stop “thinking out loud”. If there’s one person on this forum that sparks my interest with questions it would have to be you. The technical side of the cnc plasma game seems to have died off immensely the last few years. Now lots of people don’t even understand basic gcode and have no interest in learning even when they encounter a problem. I’ve lost count of the amount of times I suggest to machine users to single step through the gcode to see where their issue pops up and their response is just “I don’t do gcode”.

I consider the likes of you a dying breed on cnc forums. Carry on thinking and expressing your thoughts, it’s great.

Keith

I thought I posted this yesterday but it looks like I didn’t hit submit or something.

It would be wonderful if there was an offsetDir variable that was no offset, left offset, right offset. That’s exactly what i need.

There are three undocumented event functions:
OnOffsetLeft
OnOffsetRight
OnOffsetNone

They are undocumented because they may not always work as expected. Use at your own risk!

Hey Les,
thank you for bringing that up because i saw that in my code but i dont have it doing anything. I remember talking about these functions a year or two ago, but i cant remember if that is something i asked you for or if it was something you already had in sheetcam. I do remember finding some problem with it, but i cannot for the life of me remember what now. I’ll do some research and tests and see what happens and report back. And i may just be confusing my request for the inside vs outside contour variable/function.

Hey Keith,

Please, please, never stop “thinking out loud”…

Thank you for those kind words, that is much appreciated and reassuring. I just worry about what i say sometimes because i certainly do have the “too much” gene in me.
I certainly agree with what you said though, but i think it expands to more than just CNC. The technical side of a lot of things has died off immensely. Everyone not just wants, but expects instant gratification these days and when something doesn’t work they don’t bother to try to figure it out and fix it. They expect someone to do it for them. At least that’s my experience here in the USA, i don’t know about other parts of the world. I’ll stop here because i could literally rant for 3 pages lol.

This was a the start of some work towards implementing G41/G42 support. At the time I gave up due to the number of different ways G41/G42 is supported on different machines, especially when it comes to some of the more tricky toolpaths SheetCam can generate.

I just worry about what i say sometimes because i certainly do have the “too much” gene in me.

Too much is better than too little as far as I’m concerned. It helps me a lot when people tell me what they want, rather than keeping quiet and making me guess. Even if some of your wilder suggestions have sometimes given me ideas for worthwhile improvements to SheetCam.

Sounds like we have a few common thoughts. As I get older I’m learning to stay quiet about capabilities I have because I’m learning I can become too “useful” to certain people who don’t even want to try and learn how to do something themselves. I can certainly relate to what you said.

This was a the start of some work towards implementing G41/G42 support. At the time I gave up due to the number of different ways G41/G42 is supported on different machines, especially when it comes to some of the more tricky toolpaths SheetCam can generate.

I found out what the problem was that i ran into now. I never found any issue with the functions themselves working as expected. The problem i ran into was OnPenDown is called BEFORE OnOffset. When this happens and OnPenDown is used to start the plasma arc, the arc is started, then the offset (G41/G42) gets applied and the leadin has a dog leg in it. This causes a problem with tight nests and wide kerfs.

I remember talking about this now and you pointed out some logic as to why OnPenDown is called first. Id be scared to ask you to change that now, as i am sure some have made posts that rely on this sequence and it would catch them off guard and scrap parts.

EDIT: Les, is there anywhere that shows the code being generated during the post debugging process?

Yes, that is correct. Rapid moves do not normally have G41/G42 applied (many controls won’t let you) so the start of a cut is as follows:
Rapid to pierce point (G40)
Pierce
Lead in while applying G41/G42.
Start cut.

This link shows an example of what happens http://linuxcnc.org/docs/2.6/html/gcode/tool_compensation.html#sec:cutter-compensation

If you use a straight lead in, the lead in will be at a slightly different angle. Depending on the control an arc leadin will produce a dogleg, a disorted arc or an error message.

To get the pierce point in the exact place shown in SheetCam you would need a short tangential ‘pre-leadin’ move to let G41/G42 sort itself out.

This is just one of the many interesting quirks of using G41/G42 offsets that are handled differently by different controls.

If you really want to work around this you could defer the pierce:

In OnInit() add:

pierce = false

Rename OnPenDown() to CheckPenDown(). At the start of the function add this code:

function CheckPenDown()
   if not pierce then return end
   pierce = false

Create a new OnPenDown:

function OnPenDown()
   pierce = true
end

Now at the start of OnMove() and OnArc() add this line:

  CheckPenDown()

It’s fugly but it should work. The rest of the code in CheckPenDown should now run on the first move after the pierce.

That is more or less what i started working on before i left for lunch. Except i tried doing it inside the OnOffset functions. Problem i ran into and why i asked about shoring the output code during debugging is the OnOffset functions do not appear to be called if the operation offset is set to “No Offset” So i am glad you said that, it gives me an idea what to do. I am going to have to use an intermediate function like you are with CheckPenDown… I’ll probably call them OnCutStart and OnCutStop.

This link shows an example of what happens

Our plasma operates even differently from that. It looks a block or two ahead to see whats coming. Now i need to test with our waterjet and laser to see how they behave. For the plasma:
G0 (rapid to pierce point)
G41 (tool offset, head moves perpendicular to cut path in the next block)
M04 (arc start sequence)
G1 (leadin feed move acts just as if G40 is active)

If M4 is placed before G41, the picture below shows what is cut.

EDIT:
Well… that doesnt work either… looks like OnOffset is getting called after the leadin move is done?

Have you had a chance to think any more about this one Les? Any thoughts of what could be done or could the order the functions are called be changed? Possibly in the next release? Hopefully?

I just had a look into this and I think I can add it to the next release. It isn’t in the release I put up earlier today.

When might we expect the next update? I’m trying to wait on this to update our other computers here.

I’ll try to get it out this week. However as you already know I don’t always manage to keep to my deadlines…

I understand… same situation over here. Things come up and plans change

Hey Les, I saw the last update fixed the OnOffset being triggered by leadins, but it seemed to only work right on the first start point and for some reason the breakpoints do not seem to be working on the post debugger. Can you have a look when you get a chance please?

EDIT: Hang on a second, i may have jumped the gun on it only working on the first point. I forgot OnOffset is called AFTER OnPenDown. The breakpoints not working seems to still be an issue though.

EDIT 2: Its hard to tell without the breakpoints, but it looks like the OnOffset function is still being updated after the OnMove or OnArc function is called. If that is the case and OnOffset cannot be updated preferably before OnPenDown is called, then i just dont think i am going to get this to work as intended without a whole bunch of resource draining code.