We use cookies to personalize content, interact with our analytics companies, advertising networks and cooperatives, and demographic companies, provide social media features, and to analyze our traffic. Our social media, advertising and analytics partners may combine it with other information that you’ve provided to them or that they’ve collected from your use of their services. Learn more.
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?
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
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.
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.
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.
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.
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!
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
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.
