Workspace reverting to G54 (P1)

gSender ❓ Question
1

I did some work on workspace P1

Moved to P2 so that my P1 0,0 datum was saved.

At the end of the first carve on P2, the workspace automatically reverted to P1.

It is lucky that I noticed that. I would have expected it to stay on P2 until I manually changed it to another workspace.

1 Like
2

@GregM - What version are you using? I thought that issue was addressed and solved in a prior version to version 1.1.7 which is the current version. Hopefully I’m not wrong but I do remember others having that issue.

3

I am in 1.1.7

So apparently not fixed or it has crept back in from an earlier build.

4

@GregM - Not sure what to tell you Greg. Hopefully someone with more knowledge will chime in.

5

Hi,

Just to clarify, gSender doesn’t change your workspace when a toolpath is finished. The issue Heyward is talking about is that stopping jobs (with the stop button) soft-resets the board which restores modals to default, and we changed this to restore active WCS after the reset a while ago, which I just verified is still the current behaviour.

What’s likely happening if WCS is reset when your toolpath is finished running is that you have an M2 or M30 in your gcode towards the end. This will also reset modals to default, which would result in the WCS going back to P1/G54.

If this is the case, you can either remove the M2/M30, or alter the start/stop gcode blocks options to reset back to the initial WCS when a job is complete. Instructions can be found here: Problems / Bugs? - gSender Docs

Take a look at your first carve, and see if this is the case.

Cheers,
Kevin

1 Like
6

Thanks Kevin

Here are the last few lines of one of the gcode files:
It does indeed have an M2.
These files are generated by Vectric Vcarve.
So are you saying that to make this workspace concept useful, it is incumbent on the user to manually edit every Vcarve output file to remove the M2 ? Is there not a way of doing that in one of the program (Gsender or Vectric) UI’s ?
If they have to be removed manually, it seriously devalues the usefulness of multiple workspaces.

G1X17.349Y13.282

G1X17.542Y13.920
G2X17.262Y13.376I-0.635J-0.018
G0Z5.080
M5
G0Z20.320
G0X0.000Y0.000
M2

1 Like
7

@kgn - Thanks Kevin for clarifying my response.

8

@GregM While waiting for Kevin, you may want to take a look at the link that he included in his explanation. The link shows how to do what you are asking. It shows how to put values into gSender to reset the workspace values to what they were when you started the toolpath.

9

Thank you …I will relook !

1 Like
10

@GregM Just an FYI, Greg. I just tried it using the start and stop commands that Kevin said to use and they do work. The work space stays where it was when the job completes.

FWIW, I did not enter the quotation marks, but I did enter the square brackets in the stop command. I did enable both the start and stop sliders and I did click on the update start event and update stop event buttons.

11

M2 resetting modals is part of the g-code specification and executing to that specification on the firmware level.

https://linuxcnc.org/docs/html/gcode/m-code.html#mcode:m2-m30

It’s not something we plan on ignoring on the sender side (by filtering out/commenting out or by forcing a modal set after execution) since it’s a valid gcode and expected behaviour - if a toolpath has a M2, the user should be able to expect that modals are reset and we don’t want to change that. There are very good reasons for resetting modals at program end, similar to making sure all expected modals are set in the toolpath preamble.

It might be possible to stop it being inserted in the Vectric post-processor - I’m not familiar enough with it to say one way or the other unfortunately.

The start/stop gcode block that I linked is our way to workaround it since this has come up before. It let’s the user handle it themselves automatically if they don’t want to edit files and are ABSOLUTELY SURE they know what they’re doing while avoiding cases of a user expecting a gcode to behave a certain way and that not happening. We want to make as few judgement calls on how gcode executes as possible.

2 Likes
12

Thanks a lot Grant. !

I will be giving it a go this afternoon…such a relief this works!

1 Like
13

The M2 can be removed from the Vectric PP but with all the things that M2 does my thinking is that the gSender start and stop code is probably the safest way. Other than that you would have to add what you want to keep out of what M2 does to the PP. I found a list from linuxCNC of what M2 does.

  1. Change from Auto mode to MDI mode.

  2. Origin offsets are set to the default (like G54).

  3. Selected plane is set to XY plane (like G17).

  4. Distance mode is set to absolute mode (like G90).

  5. Feed rate mode is set to units per minute (like G94).

  6. Feed and speed overrides are set to ON (like M48).

  7. Cutter compensation is turned off (like G40).

  8. The spindle is stopped (like M5).

  9. The current motion mode is set to feed (like G1).

  10. Coolant is turned off (like M9).

Edit: Lol. I just realized that Kevin already provided that link. Well at least I feel like I can trust that resource if a gSender developer uses it.

1 Like
14

@GregM What post processor are you using?

15

I am using grbl

Thanks to Kevin and the reminder from Grant to update the start and stop events, this works perfectly for me now.

1 Like
16

Well, “grbl” isn’t actually a post processor, but maybe you don’t need any more help from @NeilFerreri .

Glad you got it fixed.

17

Hi, I also had it revert back to G54.
But another question I have is I am using 1.1.7 gsender with files from VCarve, at the end of a cut and then doing a bit change I lost the Z zero on G55, but it retained X&Y. G54 retained all X,Y&Z zeros.
Any suggestions of what to check?

18

I am not sure I understand…after you have done the bit change,z is different? If so, it would be as it depends on the length of the new bit.

Else, maybe I am not understanding the issue.

19

Hi Greg,

I set X,Y&Z zeros for G54.
For my second location at G55 I set its X,Y&Z zero.
I do my cut on G54.
Then I do my (same) cut but over at G55.
I do the initial tool macro (@NeilFerreri code)
Switch bits.
Do the new tool macro.
Load new file.
Cut at G54 (no issues)
Switch to do cut at G55.
But now have a different Z at G55, X&Y were correct.

G54 & G55 are on same board, so Z’s are the same.

Was I supposed to run the Initial and New tool macros for each G54 and G55?

Thanks.

20

@spcnc The macros are setup to work only on the current WCS.
In your case, it makes more sense to use a dynamic tool offset. There are many reasons why I chose to move away from that in my macros, but it’s coming up more and more now.
Check this thread over at the Carbide forum (though much was discussed via PM).

I’m curious as to why you’re switching back and forth between WCS in the same job.