Sheetcam and trying to generate spotting gcode.

Just letting anyone know I've started a thread over on the Sheetcam forum as I'm having problems with Sheetcam generating the correct gcode for spotting.

forum.sheetcam.com/viewtopic.php?f=2&t=8568

It's probably something I'm doing wrong.

Keith

I don't think there is a bug
Are you using this post?
forum.linuxcnc.org/plasmac/38438-plasmac-post-processors

I've been doing this since pre-plasmac and just had to change the tool name to Centre Spot
I create a layer and move all holes to that layer and apply a drill operation using that tool.
You also need to make sure the holes are < the minimum hole diameter set in the drill operation.

Cheers Rod,

Yep did all that, I'll check that post you linked to.

Keith

That's where I originally got the post Rod.

Just downloaded it again and re-imported into Sheetcam. Same result.

See what I said in my 2nd post in the Sheetcam forum. The issue appears to be coming from the fact the same tool is being used in the DRILL operation and the PLASMA operation. In the post code, it's the OnNewTool() function that does the checks to see if spotting is being done. It's as though this function is only running once because there is only one tool being used.
When I copied that tool, giving it a new number in the process, and using it in the PLASMA operation, not doubt "function OnNewTool()" is being run again in the post, thus turning off the spotting functionality.

Maybe try in your Sheetcam using the same tool for the DRILLING and the PLASMA operations, and see what happens. Maybe you have always had different tools for those operations.

Of course using different tools appears to make everything work great, but I'm wondering is the better and more foolproof solution is to have the post modified. I noticed there's no function in the post "OnNewOperation()" so when we have more than one operation in Sheetcam, do we need to be getting some checks done in that function. I mentioned this to Les on the Sheetcam forum.

Keith

I am away for a couple of days and only have my phone so it is difficult to follow the code...

It may well be that OnDrill() should set Spotting to 1 at the beginning and reset it at the end rather than testing if it is 1.

No problem at all Phill, I mainly posted here so anyone interested can view the Sheetcam forum where I started a thread on this.

This is nothing urgent at all, and I can easily get around the issue by ensuring a different tool is used in any drill operations and plasma operations.

In a nutshell it appears to be that if the tool is the same, then the OnNewTool() function does not run for the subsequent plasma operation, and so the post stays in "spotting mode".

I'm basically waiting to see if Les has a suggested modification to the post to prevent this happening.

Keith

My other thought is that maybe onDrill doesn't even need to test for spotting at all because it is spotting

I don't think Les can offer an opinion on a 3rd party post processor he did not write.

I think the current performance is expected behaviour becasue when we load our centre spot tool, we are actually changing the spindle as well as the tool. The spotting tool is never designed to do anything other than spotting.

I can confirm the the issue found by beefy.

Given the criteria for a spotting operation
I also agree with beefy. I don't think a user should be required to change their tool when they can simply click a drill operation. It's not intuitive or expected that one should be *required* to change tools.

The code above says you should be be able to do it either way, but effectively you have to change your tool to ensure the expected operations are executed.

[ EDIT ]
After reviewing the rest of the pp in context it seems that as it's currently designed a tool change should be required for a spotting operation and I don't see a quick way around that. We should find a way to make that crystal clear to the users.

To avoid this behavior I wonder if the OnNewOperation() event can be utilized?

For what it's worth this example workaround seems to work at first glance. I haven't taken scribing into consideration.
The three variables used to determine cut, scribe, or spot are toolName, toolClass, and operationClass. Unfortunately the current toolName and toolClass aren't available to the OnNewOperation() event.

I'm starting to wonder if it might be best to just ignore drill operations all together and force the user to explicitly select a spotting tool to guarantee expected behavior.