Re: [Emc-users] Fwd: Re: Gantry Best Practices
On 17 February 2014 18:15, Charles Steinkuehler char...@steinkuehler.net wrote: Yeah, this is the solution I'm leaning towards. I appreciate the concept of gantrykins, but given how LinuxCNC deals with non-trivial kins, I don't think it's the way to go unless you really have a non-Cartesian mechanism. JA4 has a gentrivkins kinematics. I am not sure how well that plays with a non-ja4 setup. It is basically like gantrykins, except with a KINEMATICS_IDENTITY type so that there is no joint mode -- atp If you can't fix it, you don't own it. http://www.ifixit.com/Manifesto -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Fwd: Re: Gantry Best Practices
2014-02-24 14:58 GMT+02:00 Charles Steinkuehler char...@steinkuehler.net: On 2/24/2014 4:11 AM, andy pugh wrote: On 17 February 2014 18:15, Charles Steinkuehler char...@steinkuehler.net wrote: Yeah, this is the solution I'm leaning towards. I appreciate the concept of gantrykins, but given how LinuxCNC deals with non-trivial kins, I don't think it's the way to go unless you really have a non-Cartesian mechanism. JA4 has a gentrivkins kinematics. I am not sure how well that plays with a non-ja4 setup. It is basically like gantrykins, except with a KINEMATICS_IDENTITY type so that there is no joint mode Hmm...that sounds like a good option. I'll have to review and see if it works properly with a non JA4 branch. One more possible thing to do to reduce potential operator error by jogging machines with non-trivial kinematics in joint mode is to switch to world mode automagically right after all joints have been homed. Take a look at this: http://www.cutting.lv/fileadmin/user_upload/axis-modified.py It implements new HAL pin axis: axisui.set-world-mode I think that its name is self-explanatory. All that is left to do is link it something in HAL. My experience tells that best results are achieved by connecting it toall axis.N.homed pins (through and2 modules although for me it is easier to create and4 or whatever the number of joints is). It behaves pretty nicely: 1) $ key still works so user can switch back to joint mode manually, if needed; 2) having axisui.set-world-mode set to true by whatever HAL magic does not disturb user activities in previous point; Viesturs -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Fwd: Re: Gantry Best Practices
Charles, I think you know my vote. 1) Never assume the user is anything other than a complete amateur. We are putting tons of these machines in schools now. 2) I believe this is the right way to do this. If the BBB cannot do this, we will be forced to add a secondary microcontroller in the pulse stream to apply the logic that we need to do this. Seems kinda silly since the software could do it. If I only knew more about LCNC programming, it already would. This is the one thing that's preventing us from moving all of our machines to the BBB immediately. 3) I am really surprised that this works at all without blowing the drivers. You cannot guarantee that both motors are identical. Len On 2/16/2014 7:47 PM, Dave Cole wrote: If you can control the current settings on the stepper drives, lower the torque settings and drive the gantry axes steppers together into the hard stops, set the axes to home, then reset the torque settings to normal. Dave On 2/16/2014 3:11 PM, Charles Steinkuehler wrote: With the recent release and general popularity of the ShapeOko V2 desktop mini-mill, I have several folks who are trying to use LinuxCNC running on the BeagleBone as a control. If you are unfamiliar with this machine, here's a link: https://www.inventables.com/technologies/desktop-cnc-mill-kit-shapeoko-2 Invariably, one of the first questions I get is how to setup a configuration to deal with the gantry setup of the ShapeOko. I know of at least three different ways to control a gantry system with LinuxCNC, each with it's own pros and cons: 1) Use gantrykins, and hope users are intelligent enough not to rack the gantry when moving around in joint mode. 2) Use trivkins and setup HAL to turn one axis into two by craftily combining the commanded motion with the homing switch states. This is easiest if HAL is doing software stepgen (just mask the step pulses in the base thread), but I'm pretty confident I can make this work pushing the logic in front of the PRU drive step/dir component (as a bonus, this setup would also work with Mesa hm2 cards and other hardware based controllers). 3) Ignore the gantry complexity, and just drive both servo motors from the same stepper driver. This works _OK_ for the Z axis on a 3D printer, but probably isn't a good idea for something that is actually making chips. Questions: Did I miss any significant options for controlling a gantry style machine? Which option would be recommended for novice users new to the LinuxCNC and CNC world? I'm thinking the Magic HAL Wye / Y Cable that splits one joint into two is probably the simplest for most folks to deal with, but am open to suggestions. -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Len Shelton Applications Engineer PROBOTIX 8800-B N. Industrial Rd. Peoria, IL. 61615 Email: l...@probotix.com Phone: (309) 691-2643 -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Fwd: Re: Gantry Best Practices
On 2/17/2014 11:41 AM, Len Shelton wrote: Charles, I think you know my vote. 1) Never assume the user is anything other than a complete amateur. We are putting tons of these machines in schools now. PEBKAM! :) 2) I believe this is the right way to do this. If the BBB cannot do this, we will be forced to add a secondary microcontroller in the pulse stream to apply the logic that we need to do this. Seems kinda silly since the software could do it. If I only knew more about LCNC programming, it already would. This is the one thing that's preventing us from moving all of our machines to the BBB immediately. Yeah, this is the solution I'm leaning towards. I appreciate the concept of gantrykins, but given how LinuxCNC deals with non-trivial kins, I don't think it's the way to go unless you really have a non-Cartesian mechanism. As soon as I'm done with the encoder stuff I'm working on, I'll whip up an N-axis HAL gantry module. My linear-delta printer will make a good test-bed for a 3-Axis gantry. In addition to avoiding the user racks the gantry in joint mode problem, the HAL component will fix problems with homing if HOME != HOMEOFFSET, at least for the simple gantry case. If anyone listening in doesn't know what I'm referring to, setup a gantrykins machine with a significant distance between the HOME and HOMEOFFSET positions, home your gantry axis, then watch in horror as one side of the gantry finishes homing and rapids to the HOME location while the other side is still poking around at HOMEOFFSET waiting for the home switch to release. ouch! 3) I am really surprised that this works at all without blowing the drivers. You cannot guarantee that both motors are identical. Yes, it's a total hack, but it works OK for things like the Z axis of a 3D printer, which moves _really slow_ most of the time. -- Charles Steinkuehler char...@steinkuehler.net signature.asc Description: OpenPGP digital signature -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Fwd: Re: Gantry Best Practices
3) I am really surprised that this works at all without blowing the drivers. You cannot guarantee that both motors are identical. You can feed two same identical step/dir inputs to multiple drivers. That is how my commercial accucut (48 sq) gantry did it. In theory, you could run an infinite number of parallel complete machines all mass producing the same thing if using steppers (signal driver fanout limitations ignored.) SMD -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Fwd: Re: Gantry Best Practices
True, but what happens if you stall one side out (ie tool comes loose from the collet and digs into the spoil board while off to one side of the machine). Having a proper homing sequence allows you to resquare the gantry by simply rehoming. We use this on our larger machines and it works beautifully. Len 3) I am really surprised that this works at all without blowing the drivers. You cannot guarantee that both motors are identical. You can feed two same identical step/dir inputs to multiple drivers. That is how my commercial accucut (48 sq) gantry did it. In theory, you could run an infinite number of parallel complete machines all mass producing the same thing if using steppers (signal driver fanout limitations ignored.) SMD - -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Fwd: Re: Gantry Best Practices
On 2/17/2014 12:15 PM, Charles Steinkuehler wrote: On 2/17/2014 11:41 AM, Len Shelton wrote: On 2/16/2014 3:11 PM, Charles Steinkuehler wrote: 2) Use trivkins and setup HAL to turn one axis into two by craftily combining the commanded motion with the homing switch states. This is easiest if HAL is doing software stepgen (just mask the step pulses in the base thread), but I'm pretty confident I can make this work pushing the logic in front of the PRU drive step/dir component (as a bonus, this setup would also work with Mesa hm2 cards and other hardware based controllers). 2) I believe this is the right way to do this. If the BBB cannot do this, we will be forced to add a secondary microcontroller in the pulse stream to apply the logic that we need to do this. Seems kinda silly since the software could do it. If I only knew more about LCNC programming, it already would. This is the one thing that's preventing us from moving all of our machines to the BBB immediately. Yeah, this is the solution I'm leaning towards. I appreciate the concept of gantrykins, but given how LinuxCNC deals with non-trivial kins, I don't think it's the way to go unless you really have a non-Cartesian mechanism. As soon as I'm done with the encoder stuff I'm working on, I'll whip up an N-axis HAL gantry module. My linear-delta printer will make a good test-bed for a 3-Axis gantry. In addition to avoiding the user racks the gantry in joint mode problem, the HAL component will fix problems with homing if HOME != HOMEOFFSET, at least for the simple gantry case. OK, I'm not done with the encoder logic yet, but I decided to take a break and make your gantry HAL module. It turned out to be slightly trickier than expected, because even at homing speed on my system and with fairly high accelerations the axis didn't just stop nicely after hitting the switch, even though it was being commanded to. Since I can't just mask the generated step signals, something more sophisticated was required. So I added some sticky multiplexing logic that uses one of the slave joints for feedback (it could be any of them), but hops around to track active joints when homing. Basically the module generates multiple commanded positions using an offset for each joint. The offset is fixed while all home switches are in the same state (either all closed or all open). If *SOME* of the home switches are closed and movement is towards the home switches (direction matches HOME_SEARCH_VEL), than the joints with closed home switches are disabled by changing their offset value rather than their commanded position, until all home switches are closed, at which point the joints are run in lock-step again. Otherwise, it's basically the same concept as the software stepgen HAL step masking code provided to me by Les Shelton, which he says came from one of the EMC lists some time ago. For best results, make sure that HOME_SEARCH_VEL and HOME_LATCH_VEL are the same sign (move in the same direction), since there is no special behavior when moving the joints off of home. I also recommend running as slow as practical for both velocities. The code is introducing discontinuities in velocity (instantly changing from commanding the home search velocity to commanding a full stop), so you wouldn't want to run very fast on something with lots of mass. It works pretty well on my linear-delta Kossel, however. Oh...and just for grins, you can have up to 7 slave joints, and I have tested with three. If it doesn't work for your dual-motor gantry, just get another motor! :) ...and I have only tested on a BeagleBone with PRU driven step/dir, but the comp should work to drive any other off-cpu based control, including Mesa hm2 step/dir and servo setups. The main drawback is only one joint is used to generate feedback into motion, so there's no alarm raised if one side of the gantry gets stuck but the other is still moving. Adding that is left as an exercise for the reader! :) Hopefully, the man page makes usage obvious, if not, let me know. The read thread should run after capturing the current position from your stepgen/encoders, and before motion. The write thread should run after motion, and before your motor controller update function. -- Charles Steinkuehler char...@steinkuehler.net /** * * Copyright (C) 2014 Charles Steinkuehler (charles AT steinkuehler DOT net) * * * This module allows multiple drive motors (joints) to be connected to a * single motion axis. This is useful for gantry style machines if you don't * want to use gantrykins * ** * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License * as published by the Free Software Foundation; either version 2 * of the License, or (at your
[Emc-users] Fwd: Re: Gantry Best Practices
If you can control the current settings on the stepper drives, lower the torque settings and drive the gantry axes steppers together into the hard stops, set the axes to home, then reset the torque settings to normal. Dave On 2/16/2014 3:11 PM, Charles Steinkuehler wrote: With the recent release and general popularity of the ShapeOko V2 desktop mini-mill, I have several folks who are trying to use LinuxCNC running on the BeagleBone as a control. If you are unfamiliar with this machine, here's a link: https://www.inventables.com/technologies/desktop-cnc-mill-kit-shapeoko-2 Invariably, one of the first questions I get is how to setup a configuration to deal with the gantry setup of the ShapeOko. I know of at least three different ways to control a gantry system with LinuxCNC, each with it's own pros and cons: 1) Use gantrykins, and hope users are intelligent enough not to rack the gantry when moving around in joint mode. 2) Use trivkins and setup HAL to turn one axis into two by craftily combining the commanded motion with the homing switch states. This is easiest if HAL is doing software stepgen (just mask the step pulses in the base thread), but I'm pretty confident I can make this work pushing the logic in front of the PRU drive step/dir component (as a bonus, this setup would also work with Mesa hm2 cards and other hardware based controllers). 3) Ignore the gantry complexity, and just drive both servo motors from the same stepper driver. This works _OK_ for the Z axis on a 3D printer, but probably isn't a good idea for something that is actually making chips. Questions: Did I miss any significant options for controlling a gantry style machine? Which option would be recommended for novice users new to the LinuxCNC and CNC world? I'm thinking the Magic HAL Wye / Y Cable that splits one joint into two is probably the simplest for most folks to deal with, but am open to suggestions. -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
