Example Gantry Configs

[Charles Steinkuehler]

I finally crafted some example configurations for the gantry HAL
component I wrote some time ago. These specific configs are for a Comet
router from Probotix, but should work as a starting point for any gantry
style system that has a homing switch available for each gantry joint
(ie: Shapeoko or similar).

Video on Youtube:
https://www.youtube.com/watch?v=7XhIoDV8Hp8

Configs are in a github PR (already merged while I was typing!):
https://github.com/machinekit/machinekit/pull/276

The relevant portions of the config in the HAL file:

Splitting one commanded position into two with the gantry comp:
https://github.com/machinekit/machinekit/blob/master/configs/ARM/BeagleBone/Probotix/Comet.hal#L54-L62

Home/limit switch setup:
https://github.com/machinekit/machinekit/blob/master/configs/ARM/BeagleBone/Probotix/Comet.hal#L105-L111

Holler if there are any questions!

--
Charles Steinkuehler
cha...@steinkuehler.net

[Joseph]

Hi Charles,

Thank you for sharing this.  I have a home-built table with a 32x60x6 work envelope I want to convert from Mach3 controls to BBB LinuxCNC.  Like the Comet, one axis has dual screws.  From my perspective this long axis is X and in Mach3 what ends up happening is Axis A is "slaved" to master axis X.   XYZX instead of XYYZ

Is it simply the case that for my configuration I work with stepgen.00 and stepgen.03 (x1 and x2) instead of 01 and 02?
Also the line in the hal file, "loadrt gantry count=1 personality=2" - does that change?

Thank you.  I appreciate your patience with the newbie questions.

All the best,   Joe

[andy pugh]

On 31 October 2014 15:12, Joseph <jth...@gmail.com> wrote:

Is it simply the case that for my configuration I work with stepgen.00 and stepgen.03 (x1 and x2) instead of 01 and 02?

It is completely up to you which stepgen drives which motor, and which stepgen is driven by each axis. 

But it helps to not confuse the future-you if you keep things consistent. 

--

atp
If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto

[Charles Steinkuehler]

On 10/31/2014 10:12 AM, Joseph wrote:
> Hi Charles,
>
> Thank you for sharing this. I have a home-built table with a 32x60x6 work
> envelope I want to convert from Mach3 controls to BBB LinuxCNC. Like the
> Comet, one axis has dual screws. From my perspective this long axis is X
> and in Mach3 what ends up happening is Axis A is "slaved" to master axis
> X. XYZX instead of XYYZ
>
> Is it simply the case that for my configuration I work with stepgen.00 and
> stepgen.03 (x1 and x2) instead of 01 and 02?

Well, if you want to keep the names consistent in HAL, you'll need to
rename a bunch of nets connected to the gantry component:

https://github.com/machinekit/machinekit/blob/master/configs/ARM/BeagleBone/Probotix/Comet.hal#L54-L62

Holler if you have questions or run into problems making the change.

> Also the line in the hal file, "loadrt gantry count=1 personality=2" - does
> that change?

The gantry component stays the same. You still have a single gantry
with two motors, so you don't need to change the settings.

--
Charles Steinkuehler
cha...@steinkuehler.net

[Joseph]

I have things running along nicely now.  Thank you.  Single axis rapids are humming along at 450 ipm without any problems - or at least Axis is reporting 450 ipm velocity.

Now I am enabling the charge pump functionality.  It is working.  I verified signal on the desired pin.  The challenge is with the charge pump enabled on the G540, the fault line (which also indicates estop) reports high so LinuxCNC sees immediate estop and won't let me power up the machine which would allow the charge pump to clear the fault.  If I leave the G540 in "charge pump off" mode, start LinuxCNC, go through the F1/F2 sequence to initialize the machine and then enable the charge pump functionality on the G540 it all works - the G540 status LED stays green.

I am using the example at http://wiki.linuxcnc.org/cgi-bin/wiki.pl?About_Charge_Pumps

"net emcOn motion.motion-enabled => charge-pump.enable"

Any suggestions on how to decouple the initial fault indicator from ESTOP detection?  Is there a different attribute I should use to drive the charge-pump.enable state?

All the best,   Joe

[Kirk Wallace]

... snip

Did you connect charge-pump.out to something?

In the example:
"net myCPname charge-pump.out => parport.0.pin-17-out"

connects the charge pump signal to a parallel port pin which then gets
wired to the G540 pump input pin.

The charge pump _enable_ bit tells the charge pump when to and when not
to run.

This can be checked with monitoring the pump.out and pump.enable signals
with HALscope. The pump signal the G540 sees must cycle (0v 5v 0v 5v
...) to enable the G540. A constant 0 Volts or constant 5 Volts will
disable the G540. A volt meter should see something around 2 to 3 volts
while the signal is cycling.


--
Kirk Wallace
http://www.wallacecompany.com/machine_shop/
http://www.wallacecompany.com/E45/

[Joseph]

Hi Kirk,

Yes.  In my config,
net chargePump charge-pump.out  => bb_gpio.p8.out-19

This works when I get past the estop.  Since charge-pump.enable defaults to TRUE (http://www.linuxcnc.org/docs/html/man/man9/charge_pump.9.html) I also tried leaving it out and connecting only charge-pump.out to the gpio pin.  No joy.

I also loaded up estop_latch and connected the watchdog to the gpio output.  Still no joy. 

It feels like I'm fighting estop logic during init but I am a newbie so not confident that is the case.

Thank you,   Joe

[Kirk Wallace]

On 11/06/2014 04:50 PM, Joseph wrote:
> Hi Kirk,
>
> Yes. In my config,
> net chargePump charge-pump.out => bb_gpio.p8.out-19
>
> This works when I get past the estop. Since charge-pump.enable defaults
> to TRUE (http://www.linuxcnc.org/docs/html/man/man9/charge_pump.9.html)
> I also tried leaving it out and connecting only charge-pump.out to the
> gpio pin. No joy.
>
> I also loaded up estop_latch and connected the watchdog to the gpio
> output. Still no joy.

Have you tried HALscope to see want the signals are trying to do?

If you are not familiar with HALscope, look here:
http://www.linuxcnc.org/docs/2.4/html/hal_tutorial.html#sec:Tutorial%20-%20Halscope

Basically, start Machinekit, then start a terminal session, Applications
-> Accessories -> Terminal

At the command line prompt type:
halcmd loadursr halscope

This should give you a window like the first one under "1.5.1 Starting
Halscope" unless you have already run HALscope before. Choose a thread
period, then okay. The thread period you choose should be the same as
the one you assinged to the charge pump function, such as "addf
charge-pump base-thread". You did assign charge pump to a thread, didn't
you? (I've made that mistake more often than I'd like to admit.)

You can go through the rest of the tutorial to see how to find and
connect the charge pump signals to channels and set a trigger. Then go
back to the Machinekit UI and toggle whatever button is supposed to
start the pump.

Unfortunately, I haven't installed or run Machinekit, so I don't even
know if HALscope is available. If you can run HALscope, it's worth
learning how to use it.

[Phill Carter]

The following is my estop/charge pump config from a parallel port to a G540, pin 15 is the estop switch and pin 16 is the charge pump out to the G540.

I hope it helps.

net estop-ext parport.0.pin-15-in-not => iocontrol.0.emc-enable-in

net estop-out iocontrol.0.user-enable-out => charge-pump.enable

net charge-pump charge-pump.out => parport.0.pin-16-out

Cheers, Phill

[Kirk Wallace]

Just in case, the G540 sometimes has a problem with LinuxCNC using a
parallel port. The G540 charge pump input takes a fair bit of current to
charge an internal capacitor rather than a logic input. A parallel port
needs to be in EPP mode in order to enable buffering in the port to get
enough current to drive the G540 input. Some parallel ports in EPP mode
still won't work and need help. I think if your I/O pin can supply 5
Volts at 24 ma, you should be okay. Many parallel ports are rated for 3
ma which is not enough. A 3 Volt signal might be a problem too.

(My notes on the G540 charge pump:
http://www.wallacecompany.com/machine_shop/G540/)

[Joseph]

Thank you both.  Yes, I fired up halscope and definitely see waveforms reported for the mapped signals. Very cool tool.

Kirk, I think what I am seeing aligns with the G540 sensitivities you describe.  It appears there isn't enough current to charge the necessary circuitry.  If I start up with the G540 switch in the charge pump off position and then flip it to on even before "Power on machine" operation, the charge pump detector stays happy (no fault).  If I hit F2 to power down, the G540 indicator remains green.  When I exit LinuxCNC the G540 immediately faults (charge pump waveform gone).

I'll do some exploring to determine what these signal levels are.

Ever onward,   Joe

[Sivert]

Hi Charles

I'm new at this and is looking to use this Hal Code on My BBB with PMDX-432 so that i can rung gantry on it.

But as i actual don't know what i'm doing when it comes to coding this. It usually becomes trail en error until i have something descent.

Is there any good instruction videos for have to program HAL on a BBB?

Do you know if anyone have done this for the PMDX-432 before? 

[Neo Phema]

Charles, just an orientation question. 

My study shows trivikins to be less specialized that gantrykins for this type of control. That I might learn, I am interested in what led you to choose trivikins.  

[Charles Steinkuehler]

Mostly because of all the stuff in the legacy LinuxCNC stack that
breaks when you aren't using trivialkins, and the associated extra
hassle required when using the application. Switching between
world/joint modes, no coordinated MPG jogging with non-trivialkins,
more complicated (IMHO) homing setup, etc.

A gantry system is basically just a Cartesian machine with duplicated
drive and a modified homing scheme for the paired joints. Both
gantrykins and my gantry component are essentially hacks to make this
work with LinuxCNC, but using gantrykins comes with a bunch of other
UI fallout I didn't want to deal with. So I wrote the gantry comp.

One example:
Configure your gantry system to move to the center of the work
envelope (let's say it's 100.0 for example) when finished homing, and
the home switch is at 0.0. So that means for your gantry joints you'd
set:

HOME = 0.000
HOMEOFFSET = 100.000

Now home your gantrykins machine in joint mode and watch as one side
of the gantry rapids from the home switch to the midpoint, while the
other side is still searching for the home latch position. This is
*NOT* a GoodThing! The gantry component I wrote handles this case
correctly. :)

--
Charles Steinkuehler
cha...@steinkuehler.net

[Neo Phema]

It's very well done. Is the gantry component you wrote beaglebone dependant? 

[Bas de Bruijn]

Hi Neo,

On 29 Nov 2015, at 21:31, Neo Phema <neop...@gmail.com> wrote:

It's very well done. Is the gantry component you wrote beaglebone dependant? 

the components that are used in HAL are meant to be the link between software and hardware. Some components are specifically for setting up hardware, most are not. So _you_ can decide the hardware that gets attached to this component. The beaglebone and pins etc are just the hardware part. In the terminal type "man gantry” which should give you the manpage. Or have a look here https://github.com/machinekit/machinekit-docs/blob/master/machinekit-documentation/components/gantry.asciidoc

You might also have a look here:

https://github.com/machinekit/machinekit-docs/blob/master/src/hal/intro.asciidoc

Cheers,

Bas

--
website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit
---
You received this message because you are subscribed to the Google Groups "Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to machinekit+...@googlegroups.com.
Visit this group at http://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

[Tom M]

Hi Charles,
I'm getting ready to bite the bullet and give up on gantrykins and switch over to this method for my dual gantry MPCNC/Cramps setup.

One thing that I'm a little fuzzy on is syncing the limit switches.
I understand the trick/feature you developed; that both switches need to close for the homing cycle to finish and a is the mechanism for  de-racking the gantry.

So I'm assuming that the implication to this is that the switches on the gantry need to be aligned perfectly.   Is this correct or is there some offset compensation built into code that will account for error in the switches(that I'm not seeing /understanding)

The reason I'm asking is need make the mounts for the endstops.  If I need to take out error using the stops only, I need to create some sort of fine alignment feature in end stop mount.

Tom

[Charles Steinkuehler]

Yes, the switches on the gantry (or at least their trip points) are
expected to be aligned. On the systems I was using with the gantry
component, the switches were fixed but there was an adjustment screw
on one axis which actually tripped the switch. This allowed fine
tuning of the trip point so it would align with the other side.

On 4/2/2017 5:11 PM, Tom M wrote:
> Hi Charles,
> I'm getting ready to bite the bullet and give up on gantrykins and switch over
> to this method for my dual gantry MPCNC/Cramps setup.
>
> One thing that I'm a little fuzzy on is syncing the limit switches.
> I understand the trick/feature you developed; that both switches need to close
> for the homing cycle to finish and a is the mechanism for de-racking the gantry.
>
> So I'm assuming that the implication to this is that the switches on the gantry
> need to be aligned perfectly. Is this correct or is there some offset
> compensation built into code that will account for error in the switches(that
> I'm not seeing /understanding)
>
> The reason I'm asking is need make the mounts for the endstops. If I need to
> take out error using the stops only, I need to create some sort of fine
> alignment feature in end stop mount.
>
> Tom
>
> On Sunday, November 29, 2015 at 2:59:46 PM UTC-6, Bas de Bruijn wrote:
>
> Hi Neo,
>

>> website: http://www.machinekit.io <http://www.machinekit.io/> blog:
>> http://blog.machinekit.io <http://blog.machinekit.io/> github:

>> https://github.com/machinekit
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Machinekit" group.
>> To unsubscribe from this group and stop receiving emails from it, send an

>> email to machinekit+...@googlegroups.com <javascript:>.

>> Visit this group at http://groups.google.com/group/machinekit

>> <http://groups.google.com/group/machinekit>.

>> For more options, visit https://groups.google.com/d/optout

>> <https://groups.google.com/d/optout>.

>
> --
> website: http://www.machinekit.io blog: http://blog.machinekit.io github:
> https://github.com/machinekit
> ---
> You received this message because you are subscribed to the Google Groups
> "Machinekit" group.
> To unsubscribe from this group and stop receiving emails from it, send an email
> to machinekit+...@googlegroups.com

> <mailto:machinekit+...@googlegroups.com>.
> Visit this group at https://groups.google.com/group/machinekit.

> For more options, visit https://groups.google.com/d/optout.
>

--
Charles Steinkuehler
cha...@steinkuehler.net

[Daniel Skrlin]

Interesting concept. I deal with machines that use only 1 homing switch for both Y axis servos. They have an additional component to correct for "skew" and fault out for "skew". Might have to use this as a base and build upon this. Very cool Charles!

On Friday, August 15, 2014 at 10:32:46 AM UTC-5, Charles Steinkuehler wrote:

[Jim McIntosh]

Hi,

 I'm running the BBB with the Probotix breakout board; but I don't have any limit switches. How do I make it to where I can manually home the machine? (it's on an entirely different setup, not a comet)

 any help would be appreciated.

-Jim

[Charles Steinkuehler]

If you want to manually home the machine, you may want to use
gantrykins, where you can jog each gantry axis separately, but I've
generally not enjoyed using non-trivialkins configurations (this is
reportedly a lot better if using the Joints-Axis code from LCNC, but
that hasn't been ported to Machinekit yet).

Otherwise, if you want to use the gantry component (as is done in the
Comet configs), you need to wire at least one limit switch. Then you
can hold that switch and jog the axis and only the other motor will
move (towards the home position, anyway). You will probably want two
switches, since hitting the limit only stops motion in one direction.

If you want to carry on without limit switches, I think you'll find it
easiest to just use a plain trivialkins setup. You can manually
remove any skew between the gantry joints prior to powering on, then
jog to and set your home position as usual.

So...I'd recommend you either add limit switches or don't use the
gantry component.

> cha...@steinkuehler.net <javascript:>

[Tom M]

I'm in the process of changing my Mostly Printed CNC MPCNC from gantrykins to trivialkin with Charles's gantry solution.

The MPCNC is somewhat unique in that it has a dual gantry solution.
I setup a git repo where I have my perfectly working gantrykin solution (less limit switches) a branch called autohome where I'm working on the trivialkin/ gantry solution.

At this point, I don't have the limits switches wired, but I have the "S", "-" switches wired together so they simulated NC.
I can get axis to display and simulate jogging, but nothing is happening with the motors.    In my master(gantrykin) solution, I can here the motor's click when I enable axis, but there is silence when I run trivial kins.

I'm not sure if instantiated the gantry object correctly(it looks a little weird to me)  Could someone give this a quick gander and see if there's anything obviously wrong with this?
https://github.com/Workshop88/MPCNC/blob/AutoHoming/MPCNC.hal#L58

> <mailto:machinekit+unsub...@googlegroups.com>.

[Charles Steinkuehler]

On 9/18/2017 10:01 PM, Tom M wrote:
> I'm in the process of changing my Mostly Printed CNC MPCNC from gantrykins
> to trivialkin with Charles's gantry solution.
>
> The MPCNC is somewhat unique in that it has a dual gantry solution.
> I setup a git repo where I have my perfectly working gantrykin solution
> (less limit switches) a branch called autohome where I'm working on the
> trivialkin/ gantry solution.
>
> At this point, I don't have the limits switches wired, but I have the "S",
> "-" switches wired together so they simulated NC.
> I can get axis to display and simulate jogging, but nothing is happening
> with the motors. In my master(gantrykin) solution, I can here the
> motor's click when I enable axis, but there is silence when I run trivial
> kins.
>
> I'm not sure if instantiated the gantry object correctly(it looks a little
> weird to me) Could someone give this a quick gander and see if there's
> anything obviously wrong with this?
> https://github.com/Workshop88/MPCNC/blob/AutoHoming/MPCNC.hal#L58

I don't see any obvious goofs in your HAL file.

Check the ESTOP and machine-power signal chains on your hardware and
make sure the stepper drivers are being enabled.

Also, you can find a bit of documentation regarding instantiated
components here:

http://www.machinekit.io/docs/hal/instcomp_writing_a_component/

...but it looks like the newinst command didn't get added to the
online HAL docs.

--
Charles Steinkuehler
cha...@steinkuehler.net

[schoo...@btinternet.com]

On 19/09/17 12:28, Charles Steinkuehler wrote:
> Also, you can find a bit of documentation regarding instantiated
> components here:
>
> http://www.machinekit.io/docs/hal/instcomp_writing_a_component/
>
> ...but it looks like the newinst command didn't get added to the
> online HAL docs.
>

Every component that is instantiated, has a description in its man page
of how to load it.

Covers loadrt method and the newinst method
eg
http://www.machinekit.io/docs/man/man9/debounce/

However it is not covered here
http://www.machinekit.io/docs/hal/basic_hal/
and probably should be

[Tom M]

Well, I'm doing my happy dance..
My current issue is I didn't have my xenable signal tied into my enable, powerup and led on my cramps board... (Thanks for the hints but not the answer) Now I'm getting dangerous since I'm starting to think I almost know what I'm doing...
I'm able to jog and do manual homing...Next step I need to get my switches wired up and working on the autohoming. I'm hoping I can get this ready for the Milwaukee makerfaire without pulling an all nighter or two.... Hoo hoo

[Tom M]

Well the Milwaukee Makerfaire is done, I had my MPCNC running for 2 days straight and I was fair pleased with how it ran.
At the time I only had auto-homing working on the x but that's all fixed now.

If someone wants use an  MPCNC with Machinekit and a Cramps  on a beaglebone you can find it here: https://github.com/Workshop88/MPCNC/tree/AutoHoming
Its not perfect and I'm not done, but it works.   One issue I had was that the motors would skip after a the carriage deracked and it was returning to the home position.  I could keep if from skipping by keeping the home distance short.  It seems that this mode doesn't respond to max job speed or max velocity overide in axis display.   I'm assuming the fix is just to reduce the max velocity settings.

[Tom M]

I finally got my homing and deracking tuned for my dual gantry MPCNC.
Here's a video:
https://youtu.be/FRT0teFvGy8

(Thanks Charles, for your wonderful work)

[Bradley Turner]

Hello,

I am trying to setup a similar config on my machine, although I only have a gantry config on the X axis. Every time I change something in the .hal file I will no longer be able to get machinekit to boot. It will show the splashscreen and then never load the AXIS gui. I am very new to Linux CNC, so any help would be greatly appreciated.

[Paulo Sherring]

Hey there! I guess it would help if you post your hal file, set debug to 5 and post your debug output.

Best regards.

[Bradley Turner]

Here is my hal file. I am currently getting the error "3D.post.gui.hal:4 Pin 'pyvcp.E0.Temp.set' does not exist." And I am not totally sure what that all means, Sorry!

I took the standard CRAMPS CNC configuration files, and used the deracking MPCNC settings to try and setup deracking on the Y-gantry.

[Paulo Sherring]

My mistake, it seems that your issue is on your ini file. I am guessing there is a line invoking a post GUI Hal file. If you comment that line out you might get your config running.

[Tom M]

It sounds like not everything is getting mapped on start up. 

Are you building an MPCNC or something with just single axis deracking.   Are you using a cramps board?

--

website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit
---

You received this message because you are subscribed to a topic in the Google Groups "Machinekit" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/machinekit/To6ivNZpEHU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to machinekit+...@googlegroups.com.

[Bradley Turner]

I am setting up just single axis deracking. I am using a Beagle Bone Black with CRAMPS. I got the issue of posting figured out, it was an issue with my 3D post gui hal file. The issue I am having now is when I start the machine, turn it on, everything begins to work fine, but when I go to move any axis, I get a "Joint 1 Following Error" and the machine software - turns off, graying out my buttons until I re-turn on the machine (in the AXIS GUI). This happens on the Y, Z, and A axes - with joint 1, 2, and 3, following error respectively. The X axis does not have this issue, and seems to work fine.

To unsubscribe from this group and all its topics, send an email to machi...@googlegroups.com.