Once I send a program in UGS, machine moves away from work piece

I’m having a problem with my X-carve. After I zero xyz, I send the program and Z moves up, then heads to the back right corner of the work area. I have to power down the machine to prevent it from crashing. Any suggestions?

Not sure what you are using to create tool paths in but had similar problem but only with Z-axis in VCarve. Started run of GCode in UGS and Z-axis would raise up. LarryM helped me find that “Z Gap above material” setting in Tool Paths “Material Setup”
image

Mine was set to 15.401", so the first action was to raise the Z-axis 15+ inches… Once I switched this to 0.2 much better carving.

I would check your X & Y position values too and see if this takes care of your back corner problem.

This assumes that you VCarve, but I imagine the resolution would be a similar setup configuration in other toolpath programs.

Ash

I’m using Aspire 8. I flashed GRBL to 1.1 and started having these problems. I tried going back to 0.9j but it still isn’t working… I’ve tried going back through the Easel machine setup. No luck

I double checked all settings. Everything is setup correctly and there are no offsets. Here are the first few lines of code I’m trying to send. The first move is G0Z0.5000, wouldn’t this be .5000 above the surface where I set Z0? After probing for Z0, I back off 1.000 so the first move should be down, but it goes up, then takes off to the back right corner of the machine.

T1
G17
G20
G0Z0.5000
G0X0.0000Y0.0000S24800M3
G0X1.8660Y3.5816Z0.1000
G0Z0.0500
G1Z-0.0200F20.0
G1X1.8616Y3.5404F80.0
G1X1.8660Y3.5396
G1Y3.5816

Which version of grbl are you using?

Do you home your machine?

Your post processor is not a good one to use with the Xcarve.

These post processors should work for you. Grbl versions 0.9j through 1.1f

1 Like

this sounds like the issue i was having after updating to 1.1

you will have to recompile GRBL after making a minor change to the config.h file

in the config file youll need to delete the “\\” before HOMING_FORCE_ORIGIN and then save and recompile/flash to your arduino

That’s not necessary if you set work zero appropriately.

1 Like

I may be wrong, but I had a simular issue with UGS. My issue then was with the difference between work zero and machine zero. Try homing the machine before setting your work zero. I was jogging my machine then power cycling without resetting the connection to the computer leaving it not knowing where the bit was.

if you want machine zero to be correct it is. if you arent homing then it shouldnt matter but his issue sounds like mine where it would go off to the right back corner to start a cut because it thinks that is the 0,0 point

forcing home origin sets the machine 0 to the left front corner and then you can set work zeros off of that.

Machine Zero is arbitrary, so there is no “correct” Machine Zero.

I agree that if you want the Machine Position 0,0,0 to be front, left, up, then you need to use HOMING_FORCE_ORIGIN.

But that is just a personal preference (I like it that way also, and I do run with positive quadrant machine space).

You can run without issue using negative machine space as long as you set things up properly.

2 Likes

Alrighty then.