Inventables Community Forum

Software Setup for X-Carve, runaway gantry!

I am using the J Tech Photonics GRBL version 0.9g firmware, and I’m having some trouble getting my 1000mm machine to behave correctly after the homing cycle. I have the homing switches sold by inventables. After homing the machine using UGS, the tool is at -789,-789, 1 machine coordinates and 0, 0, 0 work coordinates. Jogging after homing results in fractional movements. Before homing, entering 40 as the step size in UGS will result in a 40mm movement in X and Y. In UGS, selecting “Return to Zero” sends the tool RACING to the opposite corner (positive x, y) of the work area; I have to kill the power before it crashes! Very scary! Likewise, “Reset to Zero” in UGS says that it is not a supported function.

I’m just getting the machine setup, and I can connect to my machine/grbl using Ubuntu and a Windows 7 computer. However, I cannot, under any configuration or version of GRBL, connect the machine to Easel. I’m looking for a third computer to test.

So, what am I doing wrong or not understanding about initial machine software setup?

I’m using the following settings in GRBL:

$0=10 (step pulse, usec)
$1=255 (step idle delay, msec)
$2=0 (step port invert mask:00000000)
$3=3 (dir port invert mask:00000110)
$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)
$14=1 (auto start, bool)
$20=1 (soft limits, bool)
$21=0 (hard limits, bool)
$22=1 (homing cycle, bool)
$23=3 (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.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=790.000 (x max travel, mm)
$131=790.000 (y max travel, mm)
$132=100.000 (z max travel, mm)
$N1=F4000 (Default Feedrate)

There are some problems in the parameters you posted.

I would suggest that you pick a particular set of tools to get your machine working and then move to the alternate software paths to find your preferred operating setup.

Have you modified the $$ settings, or is that what you got when you installed 0.9g?

Which version of UGCS are you using?

From your post I can help you best if you use Windows 7, UGCS version 1.09 and maybe change out the version of grbl you are using.

Let me know how you would like to proceed.

1 Like

The settings file are the default setting given by Jtech Photonics from their website. I have UGS version 1.07, but I’ll upgrade to 1.09 as soon as I have a chance. I’ll follow a Windows 7 path first, and then port back over to Ubuntu. I don’t think there is much difference, other than the fact that I probably won’t be able to use Easel.

I for one wish that Inventables would develop Easel to be run on Linux; after the OS is free and works well with a community that builds, tinkers, etc.

I’d love to see your grbl settings file, although I realize you may have a very different setup.

I am going to be a bit delayed in addressing this issue. I just got my NEMA23 motors, and I’ll be busy over the Christmas holiday on some travel.

@StephenScheidt

Enjoy the holidays. Post back here when you are ready to continue.

The defaults for the 1000mm machine are the same as the 500mm, except $130=790 $131=790 for the original 1000mm or $130=740 $131=790 for the newer version.

Take a look at this to see if it would be helpful for your setup.

I’m hoping to do a machine test tonight. I replaced all my NEMA17 motors with NEMA23s. (That was a bear.) I’m a SO2 upgrader, so I don’t have everything new. I did purchase the one-piece wide-makerslide. (Very nice.) I also did a bunch of work to put in the back rail attached to the gantry for the x-axis drag chain to lay on. So, long story short - I made a number of machine provements while I was at it.

I just wanted to make sure I’m reading this correctly: you typed in $130=740 instead of 790. Just want to make sure that’s not a type-o. That simply could have been my problem with the “run-away” and crash I experienced. I simply may not have had my soft limits set correctly.

I’m been so careful about putting everything together to spec, making careful measurements of how the machine is being put together. (I want to do some high resolution stuff with fine detail.) Yet, I didn’t actually measure what my actual machine limits are… That just slipped through my build process. I expect I’ll be able to solve the soft limits issue.

I’ll let you know what happens.

Best and happy holidays to you as well.

@StephenScheidt

If you have the new one piece X makerslide then use 740.

If you don’t, use 790.

You can adjust $130,$131, and $132 as you see fit based on how close you want to work at the rails. These values are used with homing to establish the soft limits.

No, I don’t think so. I think the runaway was due to bad settings for $3 and/or $23.

I’ll be around. Let me know how it goes and if you need more help.

Well, I’m all good, and in time for the holiday season! Upgrading to UGS 1.09 was essential. Secondly, I just needed to set my soft limits to the correct values. For my machine they are $130=780mm and $131=760 mm. The x is shorter because of the laser mounted on the side of my spindle mount; the y is shorter because (?) … not sure. Maybe it’s because I have different Makerslide on my y rails. In any case, it’s fit as a fiddle. Did a successful homing cycle; send to 0,0,0 works; and no crashing. I’m definitely going to put limit switches on the other end of my rails just for safety.

This video shows the final result. It would be more useful if the autofocus on this camera wasn’t completely losing it.’

Thanks for your help.

Glad to hear that you got it working. Now for the fun.

If you home your machine, with soft limits on, you really don’t need the hard limits on the far end of each axis. If you use the switch inputs on the Arduino/gShield or X-controller you still rely on grbl to function properly to recognize when a switch is tripped and if grbl is functioning properly then soft limits will catch any out of bounds request and not execute it.

However, it would give you some additional protection if the hard limits were not using grbl, but instead caused the power supply to shut down if a switch is tripped. A much bigger modification for not much return.

Right, but what about missed steps? If the machine loses its position, it could overrun the soft limits?

Missed steps can be an issue for soft limits, but you are going to keep your machine well maintained, right?

Usually with missed steps you start seeing them show up in your work and you can correct them before they really become an issue.

Great advice from you all. Thanks!