I am using the Xcarve unit for a custom application. I have used the arduino+the gshield with grbl with great success. I have recently built a second unit but am now using the X-Controller box for the new system. I have written my own control code in VB.net and works very well with the Arduino system; basically sending G-code commands. My thought was the X-Controller, which also uses grbl, would simply be a pug and play with my software, but alas, not working correctly. I’ve also used the same settings in my grbl setup as the Arduino, seeing the the motors, gears and alike are all the same. Are my assumptions wrong here and if so, what am I missing?
The X-controller is basically the same from an interface standpoint; the differences lie in any changes between GRBL firmware versions on that front.
What is not working correctly? I am a .Net developer so maybe I can help.
You can change the firmware in the X-controller (and the Arduino). Which version of grbl is installed on the Arduino? the X-controller?
Do you use the status command to get homing switch states (this changed between 0.9 and 1.0c)?
Also, the USB interface chip is different in the Arduino and X-controller (which also means there is a different software driver in the PC for each device).
If you don’t set the baud rate in your program then you need to make sure that the baud rate in the properties of the COM port are set to 115200 baud.
Larry,
My current units, in the field, are using grbl 0.9j and the new unit is using rev1.0c. I’d rather just use the 0.9j rev and get this unit operational. How does one go about going backward with the revisions? any help here will be most appreciated!
Stephen
You can use Xloader to update (downgrade) the grbl code. If you have the .hex file of the version of 0.9j that is on your other machines then you would load that into the X-controller.
I don’t have an X-controller to test it on, but it should work ok.
Here is the Xloader program, remember to set the baud rate at 115200.
XLoader.zip (678.3 KB)
Here is a version of 0.9j
grbl_0_9_j_positive.hex (79.2 KB)
This version is set up to return Machine Position in positive space. If you have problems because your program is written expecting Machine Position in negative space I can post one of those here.
1 Like
The X-Controller has the same ATmega328 procesor as the Arduino, the capabilities are equal. The X-Controller electrical diagrams are not published so you have to do with some guesswork-observations made on this forum.
The return message from the X-Controller differs from the Arduino, it seems that the safety door pin is part of the Inventables toolchain. I suspect this to be pulled high in the X-COntroller hardware, with the Arduino it will think the door is open and refuse to run. The status report shows more pins with a 1 status, no idea which pins they represent.
If you edit the config.h and disable the safety door, maybe even the status updates your solution will probably work. Downside is that you will probably lose Easel too as it needs the status updates to function.
The schematics are online.
Nope.
Larry,
Got it installed and everything is OK but all axis are moving in the opposite directions… I know there is a mask statement that will correct that but not sure which one to use…got a fix for me?
Yes, I have a post somewhere that will help. Let me locate it.
Here is how the grbl parameters work for axis direction and homing.
If this doesn’t do it, ask again
.
The bit order is ZYX left to right. (Z100, Y010, X001).
$3 changes the direction the motor moves the axes. Get this working correctly using jogging. You want X to move right with positive moves, Y to move to the back with positive moves, and Z to move up with positive moves.
$23 changes the orientation for homing an axis.
Once you have jogging working correctly as above then you want Z to home up, X to home left and Y to home to the front.
$23=3
Larry,
I’m baffled , I am able to get the x and y, moving right and up/away but the z, when given a g0 z10, moves down and when I give the $H homing command, the z moves in the wrong direction. I’ve changed both $3 and $23 as suggested but still can’t seem to find the right combination that works.
I am using the X-controller with grbl 0.9j… it’s all about the z and not the bass…hehehhe.
The init file listed below… now do the voodoo, that you do, so well,
$0=10 (step pulse, usec)
$1=255 (step idle delay, msec)
$2=0 (step port invert mask:00000000)
$3=0 (dir port invert mask:00000000)
$4=0 (step enable invert, bool)
$5=0 (limit pins invert, bool)
$6=0 (probe pin invert, bool)
$10=3 (status report mask:00000011)
$11=0,020 (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=0 (homing dir invert mask:00000000)
$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,000 (x, step/mm)
$101=40,000 (y, step/mm)
$102=188,947 (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)
Try $3=4 $23=3 don’t worry about homing until we get the Z axis moving the correct direction.
If that doesn’t work then check to make sure that you don’t have a loose wire in the Z axis wiring. Check for shorts between terminals in the motor wiring.
just tried it and worked fine… thanks for holding my hand 
and you didn’t even squeeze it very hard! 
Thanks!
1 Like
Could not find it? Can you post a link?
Here:
1 Like
Thanks
1 Like
Pulling pin A1 high is part of the X-Carve hardware. The schematic published is for the UNO.
No. and No.
Pulling the A1 pin high is a function of the ATmega328 processor which is used on the Arduino and in the X-controller.
The schematic link I provided is for the X-controller.
2 Likes
Sorry but some part of that no does not make sense to me. I found this documentation:
"You need to enable it in config.h and it’ll use the feed hold pin. It assumes normally-open switches connected to ground, but you can use normally-closed connected to ground with the INVERT_CONTROL_PIN compile option.
I read that as when the door is open the switch is open, and when the door closes is connected to ground. But if you bring the pin to ground it triggers the hold, then you cannot run the machine.
It is unlikely the documentation is wrong but I do not see where I make the wrong assumption.
There is a config.h setting that enables or disables the “Safety Door” function in grbl.
Inventables released version 0.9j with the safety door option disabled.
Inventables released version 1.0c with the safety door option enabled.
When enabled the safety door option redefines the functionality of the Feed Hold pin (A1). In addition to the Feed Hold function the safety door function will stop the spindle and if “Parking” is configured move the spindle away from the work surface.
When Cycle Start (A2) is activated and the safety door option is configured (and the door is closed) the spindle will move back to the work surface (if “Parking” is configured) and restart the spindle.
For the Inventables builds tripped is A1 pulled to ground
Not tripped is A1 pull high (by the ATmega328).
For a normally set up machine with the safety door switch open ( = door closed = pulled high) then grbl will not execute the safety door open / feed hold function.
When the switch is closed (= door open = feed hold) grbl will stop until the door closes (switch open).
You can change the logic of the switch by compiling with the INVERT_CONTROL_PIN compile option.
Hope that clears things up.
Also see: