UGS homes and unlocks, but not moving spindle

Hi - just installed UGS Platform 2.0 (nightly) on my Windows 10 machine. First time using UGS.

I can connect to x-controller, unlock and home the machine fine, then the state shows “idle”
I have limit switches
it “appears” locked when i go to jog the spindle using the UGS jog commands. although the command is being sent to the x-controller, the gantry does not move - just makes a noise like it’s trying to move the stepper motor but can’t.

Here’s my settings.

Is there something basic I’m missing?

$X
ok

$C
[MSG:Enabled]
ok

$C
[MSG:Disabled]
ok
Grbl 1.1g [’$’ for help]

$$
$0 = 10 (Step pulse time, microseconds)
$1 = 255 (Step idle delay, milliseconds)
$2 = 0 (Step pulse invert, mask)
$3 = 3 (Step direction invert, mask)
$4 = 0 (Invert step enable pin, boolean)
$5 = 0 (Invert limit pins, boolean)
$6 = 0 (Invert probe pin, boolean)
$10 = 115 (Status report options, mask)
$11 = 0.020 (Junction deviation, millimeters)
$12 = 0.002 (Arc tolerance, millimeters)
$13 = 0 (Report in inches, boolean)
$20 = 0 (Soft limits enable, boolean)
$21 = 0 (Hard limits enable, boolean)
$22 = 1 (Homing cycle enable, boolean)
$23 = 3 (Homing direction invert, mask)
$24 = 25.000 (Homing locate feed rate, mm/min)
$25 = 750.000 (Homing search seek rate, mm/min)
$26 = 250 (Homing switch debounce delay, milliseconds)
$27 = 1.000 (Homing switch pull-off distance, millimeters)
$30 = 1 (Maximum spindle speed, RPM)
$31 = 0 (Minimum spindle speed, RPM)
$32 = 0 (Laser-mode enable, boolean)
$100 = 40.000 (X-axis travel resolution, step/mm)
$101 = 40.000 (Y-axis travel resolution, step/mm)
$102 = 188.976 (Z-axis travel resolution, step/mm)
$110 = 8000.000 (X-axis maximum rate, mm/min)
$111 = 8000.000 (Y-axis maximum rate, mm/min)
$112 = 500.000 (Z-axis maximum rate, mm/min)
$120 = 500.000 (X-axis acceleration, mm/sec^2)
$121 = 500.000 (Y-axis acceleration, mm/sec^2)
$122 = 50.000 (Z-axis acceleration, mm/sec^2)
$130 = 540.000 (X-axis maximum travel, millimeters)
$131 = 540.000 (Y-axis maximum travel, millimeters)
$132 = 100.000 (Z-axis maximum travel, millimeters)
ok

$G

Thanks in advance for any assistance!

I think I installed stable version 1.0.9 and that has been working flawlessly. Consider using that version.

Are you sure it is not trying to go the wrong direction and it is against the mechanical limits?

thank you! I got it working, i had neglected to do the “machine setup” and needed to reverse the x/y axis direction. so i kept hitting the limit switches after homing.

works fine, but there’s a GRBL macro to help find x/y/z heights that doesn’t work great. Got this from the Charley file:
image
that seems to just want to plunge the bit into the board even if I change Z0.25 to Z-0.25

I’m not so great with GRBL yet
any thoughts?

To use Charley’s file correctly you need a touch plate wired into the machine and a lead clipped onto the bit.
It will stop plunging when electrical contact is made to the touch plate and retract the programmed amount.

I’m using the inventables touch plate and holding it sideways on the x/y edges and then flat on the z. I entered the inch measurement in Charley’s file for my touchplate, it’s .630 inches.

z still wants to probe right through it once it makes contact w/the touchplate on the z axis probe macro.

You may want to reach out to Charley for some help there.

1 Like

Have you tested the wiring for continuity?
Some bits may also have coating on them which isolate and will prevent current to flow.

Obviously the controller do not register contact, question is why.
Within Easel you can test for continuity and a “green light” will show if it conduct upon contact.

thanks - the probe registers contact, because the bit touches the probe and then stops for the X. for the Y and Z Charley added the “GO Z0.25” after G92, which is supposed to move the bit back so you can place the probe for Z. In my case it tries to send the bit INTO the probe. I even changed it to GO Z-0.25 and same thing. Can’t for the life of me figure it out.

@BrianPeterson You’re temporarily setting your Z at 0.63 when you hit the probe. I assume that you are 0.63" above your surface on contact. Immediately following, you are sending the endmill to 0.25" which is well below the surface of your probe.
Before the G38.2 probe, add G91 to force relative motion. After the G0Z0.25 ( which is now a retract from where you are), restore G90 (absolute motion) which is the default motion mode.

And that just doesn’t make sense. :upside_down_face:

Also, make sure you’re using 0s and not Os (zeros not Ohs)

1 Like

Thanks @NeilFerreri1 , appreciate the detail. Makes sense now!

Yeah, that Z-0.25 did absolutely nothing :slight_smile:

def using zero’s not Oh’s, except for the word “go”, right?

G0 - G and zero = Rapid Positioning/Rapid Move

It is NOT the word Go.

2 Likes

Well crap, that explains a lot. thank for clarifying. Again, I’m really new with GRBL

thank you

1 Like

We were all new at this at one time. Hang in there, it will all fall into place.

1 Like

I sent you an email with some explanations on the lines of gcode.

Also be sure your axis are moving in the correct directions’

X -x.xxx moves your bit to the left
Y -x.xxx moves your bit to forward (towards the front of your machine)
Z -x.xxx moves your bit Down

The below code you posted for the Z Axis is correct. It probes for the touch plate, then sets the location, and finally moves the bit up 0.25. If probing works for the X and Y axis and not for the Z axis then there is something wonky in your wiring. Double check it to make sure something isn’t coming loose when you move the touch plate around…

The code for the X and Y are also correct.

To move the bit back to X Y Z zero you can either click a button in UGS labeled Return to zero or send the commande:

G90 G0 X0Y0Z0

image

1 Like

This assumes G91 motion mode which is not the GRBL default.

I stand corrected. In my zeroing codes that are generated by the Triquetra Tool Box I include G91 for at the beginning of all my moves to insure that they are incremental and not absolute. It makes a major difference in how the machine interprets the commands and responds.

To clarify for those that don’t understand:

Two common movement types that come into play when zeroing are G90 and G91.

G90 sets your machine to Absolute mode. This means that your machine will move to a defined set of coordinates.

G91 sets your machine to Incremental Mode also know as Relative Mode. This means that your machine moves in increments relative to its current position.

Lets assume that your bit is currently located at coordinates X10 Y10 and Z1
Lets also assume that your machine is in G91 (Incremental) mode and you are moving in Inch Mode.

If you send the command G0 X1.000 your bit will move 1 inch to the right. So now your would be at coordinates X11 Y10 Z1.

If your machine was in G90 (Absolute) Mode and you issued the same command G0 X1.00 your machine would move to coordinates X1. Now your machine would be located at coordinates X1 Y10 Z1

To avoid problems that arise when you are using both G90 and G91 moves in gcode files it is good idea to include those commands at the beginning of each line of code. In the below code I want to move from X10 Y10 Z1 to X Y Z zero. A easy way to accomplish this is to send the absolute movement:

G90 G0 X0 Y0 Z0 This command will move all three axis at the same time until they reach zero.

You could also send the move in Incremental mode using G91 instead:

G91 G0 X-10 Y-10 Z-1 Your machine would respond the same either way, however, the G90 move is a better choice because it doesn’t matter where you start if you know exactly where you want to stop such as X Y Z zero.

4 Likes

You were always correct. The G-code snippets without context can cause confusion (and crashes) in new users.

2 Likes

Thanks for all the help on/off this forum guys - I really appreciate the helpful nature of this group.
Happy CNC’ing!