Interesting loss of Home when jogging carriage

I’m using the nightly version of UGS (tool path from Vcarve). I’ve done lots of carves and have never seen this happen before. I did a test carving of my current project onto foam board. My project will carve with the first bit for a few hours with no problems, when it’s done, the carriage returns to home with no problems. It then use UGS to job the controls towards to me for a bit change. I’ve done this hundreds of times with no problems. I change the bit with no problem, reset my Z axis and return it to home… it overshoots the X axis by nearly 1/4" of an inch. I reset HOME, do the next carve step which takes about 2 hours… no lost steps, nothing… returns home to the right place. Job controller and it loses X axis again by about the same amount. It’s always to left side of original spot, meaning it moved too far. It used to work fine… same version of UGS, firmware and everything.

I’m scratching my head on this one. I’m not sure if its the 1.1 firmware or what. I have plans to drop to 1.0c but didn’t want to change things between my test carves and production runs.

Are you really talking about Home, or Work Zero?

Work zero. I typically mount my board, move the carriage over to bottom left corner and reset x,y and z in UGS. Anytime I hit ‘return to zero’ button in UGS, it should go back to that exact same spot.

Here is a pic of my project… I need to do the inlays next and then use Phil’s methodology of sealing before painting the recesses.

1 Like

There are some changes in this area in 1.1f.

Prior versions report Machine Position and Work Position (chosen by bit values in $10) in response to a status request (? command).

1.1f only reports one of the them (chosen by the $10 parameter) and a conversion factor for the sending program to calculate the one that is not reported.

When I’m looking in the console of UGS, it’s constantly streaming info. If I enter “?” in the command line, I get nothing… just the same streaming data. Just a bit annoying. My $10 value is 3 when I look at firmware settings.

UGS does not accept the ? command from the command tab, but it issues it to get the values for Machine Position or Work Position.

To use the ? command you need either Arduino IDE serial monitor or any other terminal type program. PicSender will issue it as well.

$10=3 says report Machine Position and Buffer State

$$ is parameter output
? is status output

1 Like

Did you turn verbose mode on? I only get a constant stream when I turned on verbose mode in the Options.

Yeah, it was on verbose. I just figured that out. Turned it off. It only appears to show firmware when you first connect. I’m at 1.1f. Phil talked about 1.0c for both laser and CNC. I may go that route.

1 Like

1.1f supports both as well. What Phil was referring to is a specialized 1.0c build that @LarryM customized and optimized. That build has worked very well for a lot of people.

I personally run Inventables 1.1f and have had no issues so far. But I don’t use laser mode.

As for your UGS problem, the return to zero is just running “G90 G0 X0 Y0” followed by a “G90 G0 Z0” so you can jog the carriage and then manually enter the command and see if UGS is doing something else strange.

In 1.1f, jogging should not affect the standard Gcode system parameters so I’m not sure what’s going on unless you have a rogue G92 or something in your program that changes your coordinates.

@TimVannaman How are you “reseting your Z-axis” on a tool change? Have you tried another UI for sending your code?

The newest version of GRBL was doing VERY strange things for me.
Weird mm vs inches conversion and display issues.

After messing with it I gave up and down converted to 1.0c - everything has been stable since then.

@AaronMatthews

Most likely your problems were with the G-code sending program. The User Interface for grbl changed significantly between 1.0c and 1.1f which required most sending programs to update to the new interface.