Possibly broke the Z limit switch

Hi, need a tip or two.

Long story short:
Yesterday My XC got baptized in beer as a certain left elbow knocked over a can while the owner of said elbow was busy sanding a newly carved dice box. No worries, the dice box turned out real nice…

This morning I assembled and tested the XC - no problems detected. The thing connected to my laptop, homed properly and movement was perfect.
All electronics got a bath yesterday and have dried in front of the blower on my house’s air-to-air heat pump. My XC electronics never looked so shiny!

But now, as I actually need the machine to carve out a lid for another dice box the homing cycle fails me. Z axis moves up and stops as the motor can’t push beyond the limit switch, but the arduino does not register that the switch has closed.

$H
ALARM: Homing fail

Is there a command I can run on the Arduino console in UGS to see what limit switches’ state are? I’d like to test if the switch is truly dead or not.

Also - do these look ok for replacing the stock inventables switches?

Thanx

Use this:

I must be blind. Didn’t catch that using the search engine.

Thanx

@Ebr

The switches you indicated will work fine.

1 Like

Wierd.

I read the post about direct communication with arduino and also the one on debugging limit switches. I’m pretty sure I have the arduino IDE set up properly.

When I isse the “?” command I do not see the expected “LIM” details.

“$$”:

Grbl 0.9i [’$’ for help]
[’$H’|’$X’ to unlock]
$0=10 (step pulse, usec)
$1=0 (step idle delay, msec)
$2=0 (step port invert mask:00000000)
$3=3 (dir port invert mask:00000011)
$4=0 (step enable invert, bool)
$5=0 (limit pins invert, bool)
$6=0 (probe pin invert, bool)
$10=19 (status report mask:00010011)
$11=0.050 (junction deviation, mm)
$12=0.002 (arc tolerance, mm)
$13=0 (report inches, bool)
$20=0 (soft limits, bool)
$21=0 (hard limits, bool)
$22=1 (homing cycle, bool)
$23=3 (homing dir invert mask:00000011)
$24=25.000 (homing feed, mm/min)
$25=750.000 (homing seek, mm/min)
$26=250 (homing debounce, msec)
$27=1.000 (homing pull-off, mm)
$100=40.050 (x, step/mm)
$101=40.040 (y, step/mm)
$102=188.976 (z, step/mm)
$110=8000.000 (x max rate, mm/min)
$111=8000.000 (y max rate, mm/min)
$112=500.000 (z max rate, mm/min)
$120=500.000 (x accel, mm/sec^2)
$121=500.000 (y accel, mm/sec^2)
$122=50.000 (z accel, mm/sec^2)
$130=290.000 (x max travel, mm)
$131=290.000 (y max travel, mm)
$132=100.000 (z max travel, mm)
ok

“?”:
Alarm,MPos:0.000,0.000,0.000,WPos:-39.599,-2.499,1.000
ok

@Ebr

I guess that got implemented in version 0.9j.

You’re running version 0.9i.

Doh!.. Didn’t think that far, sry

Not a problem. I’ll edit the homing switch testing instructions to include the required version of grbl.

According to the LIM output switch works. Get get these values testing each switch:

Alarm,MPos:0.000,0.000,0.000,WPos:-39.599,-2.499,1.000,Lim:000>
ok
Alarm,MPos:0.000,0.000,0.000,WPos:-39.599,-2.499,1.000,Lim:010>
ok
Alarm,MPos:0.000,0.000,0.000,WPos:-39.599,-2.499,1.000,Lim:001>
ok
Alarm,MPos:0.000,0.000,0.000,WPos:-39.599,-2.499,1.000,Lim:100>
ok

I think my Arduino got drunk on beer last night and is hung over. Reflashing the thing apparently fixed the problem. :smile:

Thanx, Larry!

One thing though… It appears that my coordinates are flipped.

homed the machine but these looks just plain wrong:

I’ve seen this before, but have no clue what causes it. My machine was doing this at one point during my initial testing and something that I did made it go away, but I don’t know what made the change.

@Ebr

Just took another look at your $$ output. You probably want to change $1 to 255. This will keep the stepper motors engaged which will keep the machine from moving when idle.

How can we verify what version of GRBL is on our arduino?

The output from the $$ command starts out with the version information. You can also get it with the $I grbl command.

Use either UGCS or the Arduino IDE serial monitor to issue grbl commands to the Arduino.

Easel may allow you to issue grbl commands in the Machine Inspector, but I don’t use Easel so I can’t test that.

Ok. Thanks LarryM

Currently I am only using easel. Just trying to get things dialed in and keep the confusion at a minimum when it comes to software. I am a completely new to CNC so I am attempting to take baby steps in certain areas, software happens to be the Main area. Lol.

I will download UGS and see what info/trouble I can find. Lol.

I’ll be in touch.

Thanks

Something changed with how GRBL and UGS works together with v9j
UGS insists on flipping the machine coordinates into the negatives after homing.

Drives me nuts… I have had no luck running any of my good old gcode files exported from fusion360. Up is down and down is up and whatnot. I certainly cannot set and hit work 0,0,0 correctly.

Reading the below in the GRBL wiki I think I have to compile v09j myself and tweak some things in config.h file. sigh

After homing, why are some of my machine positions negative and not zero!?!

After a homing cycle, Grbl sets the machine coordinate frame in all
negative space. This is common on professional CNC machines that is
mostly due to tradition and being able to identify what you are looking
at when both machine and work positions are displayed. If your limit
switch is not on the positive end of the axes (and you’ve inverted the
homing direction), Grbl will set the machine position to your -max_travel
setting. If you find this so annoying that you can’t stand it, you can
always have Grbl set the machine position to zero, regardless of where
your limit switches are. You will need to uncomment the #define HOMING_FORCE_SET_ORIGIN in config.h, re-compile, and re-flash. That’s it!

Yay! Finally it worked. Machine 0,0,0 is at lower left corner again.

This was a pain to figure out for a cnc noob.

I think I will do a write up on this to a dedicated post so others might save lots of time in the future.

But first, a walk with the dogs. We all need some air :smile:

1 Like

That explains why my problem went away.

I was having problems getting Xloader to load in any of the .hex files. My solution was to just compile the source and upload it from the Arduino IDE.

I just checked the source code in the Inventable fork and it has that #define enabled.

Nice to know what fixed the problem.

Thanks for the info.

If I remember correctly I tried XLoader with both the Inventables 9j hex file and the other one from the main grbl repo.

None of them worked for me so compiling was the only solution. Now I did compile and flash using the default grbl, not the inventables variant. Hope I do not hit on some vital difference mid job :smile:

The differences in the Inventables fork are just some changes to the config.h file. You might not have the correct grbl parameters and the $RST=$ will probably not restore the Inventables configuration.