Is there a way for Gsender to keep the offset(example G55) active even after the job is done? It always reverts to G54. I didn’t see an option in the Config tab. Thank you!
@dehoutwinkel I assume that you are talking about workspaces. If so, this has been discussed several times in the forum. The best explanation and solution are here.
Anyone who has ever worked with another controller must wonder why this was ever implemented. I still can’t understand the reasoning behind it. Like others have said, it cost me a brand new compression bit and a replacement arm for my auto dust boot.
In my opinion, this should be disabled permanently.
@mick_s IMHO, Sienci is in a no-win situation here. Some like the idea that things revert to 54 after a job. Others do not. They can’t please everyone.
Since this is not an issue caused by gSender or the controller, they are left with work-arounds as solutions.
As I am one of those who prefers that the workspace does not change until I change it, the solution was very simple. I looked to the root cause of the problem. It was/is the post processor provided by Vectric for my machine. I use grbl mm, but grbl inch is the same in this context. As @KGN pointed out in his post, these post processors add an M2 command to the end of every gcode file they create. This command restores the work space to 54. It was a simple matter to delete the M2 command from the post. Problem solved with no need to use gSender to work around the issue.
I don’t know if this solution applies to the posts provided by other CAD/CAM applications. I would bet that it does. If so, the solution it very simple.
Thanks for the reply. I had done a search when I first encountered it and have since edited the post. Just confused as to why it was there in the first place. I’ve worked with dozens of brands of routers/softwares/posts over the years and never seen that in a post.
At school I teach on an CAMaster using Aspire with a gcode post. Not in that post. I had an Axiom with V Carve Pro prior to the Altmill. Not in that post. I sometimes run a Fineline Automation with Aspire and Mach 4. Not in that post. Why the grbl post? Makes no sense to me.
I am talking about workspaces. I will give that article a look later.
There was one time when I used gSenders surfacing feature set up zeroed for G55 and it switched to G54 when I ran it, was able to salvage the project, but the switch caught me off guard.
I just checked what Fusion does to the end of my posts, and it has M5, M30. I believe M30 means to reset the program so I can run it again. But doesn’t explain why Gsender needs to reset the workspace. I haven’t read the article that you supplied in your previous post yet, but if I had to delete something from the code, that really isn’t an “easy fix” as you implied. Because I would have to open the code and edit it, instead of just moving on from posting it from Fusion and hitting go on my machine.
@mick_s I was not able to find specs on the Camaster machine. If I am reading it correctly, Axiom is using DSP to control their machines. Sienci machines use grbl or grblHal.
So, the short answer to your question “why the grbl post” is “because our machines are grbl machines.
@dehoutwinkel I’ll try to be more clear. I was referring to the post processors provided by Vectric. As I said, I cannot speak to post processors provided by any other CAD/CAM application.
For the Vectric posts, it is a simple matter to open the post in any text editor and deleted the M2 line. This only needs to be done once. From then on, you would be using the edited post processor and the M2 line would not appear in any of the gcodes created by it.
As Kevin said, if this is not acceptable or too complicated, you can insert the appropriate codes in the start and stop blocks in gSender.
By “why the grbl post” I didn’t mean why doesn’t Sienci / gSender use a different post, but why does the grbl post have it in the first place.
As I said above, I’ve used dozens of different machines with a variety of CAD/CAM programs and corresponding posts. I don’t recall any other post doing what the grbl post does at the end of the program when a G5x offset is used other than G54.
I also don’t remember seeing any mention of it in Sienci’s support docs. IMO, it should be mentioned in bold with instructions on how to remove it. I honestly can see no reason for it to be there.
@mick_s I have absolutely no idea why the grbl post has it. As I have said, for all I know, not all grbl inch and grbl mm posts have it. I can only speak to those offered by Vectric.
As for Sienci mentionning it in their documentation, I’m sure that they will see your suggestion here and consider it.
I’ve emailed Vectric support about the issue. I’ll let you know once I hear back from them.
It would be nice if that was more of an option then a do all.
@dehoutwinkel I’m not sure what you mean. If you edit the post processor to remove the M command, you will save it as a custom post processor. Then, when you create your toolpaths, you have the option to choose the one that returns the machine to 54 or the one you created. It will be your choice for every toolpath you create.
If you choose to use the program events feature of gSender to do the same thing, you have the option to enable or disable it before you run any gcode file.
Its like I said earlier. See my past post.