gSender 6.6 Beta Windows - "Stop Run" button Adds 50mm to the Y axis with no movement

I am going to do my best to describe this problem.

1 - I can reproduce this EVERYTIME on demand.
2 - the setup for the behaviour seems a bit odd, however, it has to do with the RESETing of the X & Y and the STOPING of a program.
if you never click on the Stop Run, the problem never happens.

1 - I move the HEAD to the X0 LEFT and Y0 Front of the Longmill, like it would do in a Homing procedure. (see 00:00:11)

2 - I have a macro that Moveā€™s the head to the Worrkpiece is setup (x54, Y54) See (see 00:00:18)
and it RESETS the X and Y to zero See (see 00:00:23)
(g0 x54y54)
(92 x0y0)

NOTE* if you move the head around by Jogging, it will always go to the X0 Y0 where the workpiece is set.

3 - click on Start Job See (see 00:00:29)
(allow it to move the head a little bit)

***** NOTE ****
When I click on the STOP BUTTON, note that the HEAD STOPS MOVING, however the Y Setting all of a sudden jumps 55mm, but the head never moves. I am also NOT left with the warm and fuzzies that the X isnt wrong either, I dont see the head move, but the X grows and shrinks, its just not as obvious as the Y jump

4 - Click Stop Job See (see 00:00:37)

See (see 00:00:43)
Y Setting all of a sudden jumps 55mm,

5 - When I Click on the GOTO XYZ Zero, the head returns to the 0,0 however its resetting to the X,Y,Z that gSender set to Zero, not the values that G92 reset to zero.

I want to re-iterate, the SOLE difference between the Unit going back to X0,Y0,Z0 before the G92 command, is because of the Stop Job.

if the Stop job had not been clicked, then the ā€œgoto X0,Y0,Z0ā€ would have taken me back to the X0,Y0,Z0 which was really X54y54,Z0

Video Attached
https://www.youtube.com/watch?v=3YaeCig7x7k

p.s. ignore me talking on the video, I was trying to give myself hints for logging the bug.

Hey,

This isnā€™t really a bug in the program but a combination of G92 which youā€™re using to set offset and how the stop button works. G92 doesnā€™t persist through power cycle/resets/e-stop by command definition. The stop button, on top of making sure the program feeder starts from line 1 of the program, sends a hard reset to the firmware to make sure the controller isnā€™t in a state where youā€™ll be unable to start sending a program fresh.

This is pretty standard behaviour for the more common senders - I know off the top of my head UGS, CNCJs and Openbuilds will also send a reset to the board when you stop a program. The issue youā€™re experiencing is that that reset removes your G92 WCS shift which is why youā€™re seeing the position value jump. Itā€™s expected behaviour based on the firmware definition and I donā€™t see us not having a reset sent when stop is clicked.

Cheers,
Kevin

1 Like

Weird that it does that.

But as you say, not a bug

1 Like

In my perfect world.

I would like to hit the HOME button , and have it go to the bottom left corner of the mill with limit switches.

Set everything to zero

Move to x54 y54. Where I have my corner Brack to mount my work.

Then set to zero

So I can always start from the same location.

I need to be able to do it as a macro, but your saying g92 isnt the right way

Is there a reason youā€™re not using G10 to set the offset? That will persist on power cycle and would get you the same result.

Your original macro could be re-written as:

G0 X54Y54
G10 L20 P1 X0Y0

Different behaviour between the commands is that:

  1. G92 sets offset for all WCS while G10 needs a specific workspace specified (P1-P6)
  2. Persistance - G10 is saved on power cycle/e-stop and can be viewed by sending a $# command.

G10 is very good in situations where your point of interest in the workspace are common - if your corner bracket is always at X54Y54 it sounds like a great use case.

Cheers,
Kevin

1 Like

Thanks Kevin that really helped itā€™s solved everything I was looking for

Anybody who sees this thread might have the similar problem that I just had

I had to add g90 into my code so it was using the XY coordinate rather than a relative position

So I have a macro that is g90 g0 x0 y0
Which translates into go to x0 and y0

I also created a macro that is g91 g0 x 50 y50
Which translates into go 50 points in the direction of X and y

G91 is the incremental go to g90 is the absolute go to

To answer your question as to why I didnā€™t do it that get way Kevin is I had no clue my understanding of G-Code is only what Iā€™ve been able to Google and Iā€™ve never found anything like what youā€™re describing but which is fine because now it works fine and itā€™s perfect

2 Likes

My homing macro

G90
$h
G0 x54 y54
G10 l20 p1 x0 y0

This is my home my machine, set the offset to 54 x 54 and then set to zero

For anyone wanting it

If anybody wants to comment and let me know if maybe Iā€™ve done something wrong please let me know

2 Likes