Re: [Emc-users] gantry revisited
That's also why I have home offset programmed, but ie. if I jog thoward limit with 3000mm/min and hit it, what will happen? It will stop with acceleration values, defined in INI file. Actually yes as long as I stay in joint mode this works, but after entering world mode, this doesn't work any more, it just notify me that I'm over soft limit and after hitting limit switch it stops with e-stop. So, is this difference caused by kinematics that I'm using (5axiskins) or anything else? I didn't test it with gantrykins -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with 2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] gantry revisited
2013/5/29 Tomaz T. tomaz_...@hotmail.com That's also why I have home offset programmed, but ie. if I jog thoward limit with 3000mm/min and hit it, what will happen? It will stop with acceleration values, defined in INI file. Actually yes as long as I stay in joint mode this works, but after entering world mode, this doesn't work any more, it just notify me that I'm over soft limit and after hitting limit switch it stops with e-stop. So, is this difference caused by kinematics that I'm using (5axiskins) or anything else? I didn't test it with gantrykins What is the distance between soft limit, defined in INI file and location of limit switch? I am using gantrykins and it stops me near soft limit, when I try to jog over it. I say near, because it tends to overshoot few milimeters. -- Viesturs If you can't fix it, you don't own it. http://www.ifixit.com/Manifesto -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with 2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] gantry revisited
It will stop with acceleration values, defined in INI file. Actually yes as long as I stay in joint mode this works, but after entering world mode, this doesn't work any more, it just notify me that I'm over soft limit and after hitting limit switch it stops with e-stop. So, is this difference caused by kinematics that I'm using (5axiskins) or anything else? I didn't test it with gantrykins What is the distance between soft limit, defined in INI file and location of limit switch? I am using gantrykins and it stops me near soft limit, when I try to jog over it. I say near, because it tends to overshoot few milimeters. Distance donesn't change anything, usually I have 5mm offset from switch. Then there is probably some difference in kinematcs? -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with 2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] gantry revisited
2013/5/29 Tomaz T. tomaz_...@hotmail.com It will stop with acceleration values, defined in INI file. Actually yes as long as I stay in joint mode this works, but after entering world mode, this doesn't work any more, it just notify me that I'm over soft limit and after hitting limit switch it stops with e-stop. So, is this difference caused by kinematics that I'm using (5axiskins) or anything else? I didn't test it with gantrykins What is the distance between soft limit, defined in INI file and location of limit switch? I am using gantrykins and it stops me near soft limit, when I try to jog over it. I say near, because it tends to overshoot few milimeters. Distance donesn't change anything, usually I have 5mm offset from switch. It certainly does change a lot - if the switch is very close, then it will be tripped during the overshoot I see on my machine. If the distance is larger, then it will not reach it. I do not have limit switches, so I do not know, what offset value would be most appropriate. Then there is probably some difference in kinematcs? I do not think so. It may be related with Your kinematics module being non-trivial. Can You try this jogging over soft limit with trivkins? Which LinuxCNC version do You have? -- Viesturs If you can't fix it, you don't own it. http://www.ifixit.com/Manifesto -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with 2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] gantry revisited
It certainly does change a lot - if the switch is very close, then it will be tripped during the overshoot I see on my machine. If the distance is larger, then it will not reach it. I do not have limit switches, so I do not know, what offset value would be most appropriate. That's right, but in my case if I do homing and then stay in joint mode to test this limits by jog (on single motor axes), it works the way it should, machine decelerate and stops on soft limits. After entering world mode, this is ignored. -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with 2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] gantry revisited
On 24 May 2013 04:36, Jon Elson el...@pico-systems.com wrote:
These rigid gantrys seem like you could get into trouble, and the homing
needs to be done the right way or it could throw the machine out of
square.
As I understand it, the one thing that gantrykins is good for is
homing. As far as I know it Just Works.
Both joints move at the same speed to their home switches, and then
run through the latch sequence.
If the gantry is perfectly square at the start, it will stay perfectly
square throughout. If it is slightly out-of-square then it will only
ever get ore square through the homing sequence.
For peace-of-mind I would suggest an e-stop trigger on encoder
position divergence. This needs to be masked by the homing state, as
there is a sudden step in position at the homing point.
I think I would put this mask in a HAL comp, and add in a timer that
also throws an e-stop if there is more than a certain time difference
between each side switching state:
This was all looking very easy until I noticed that axis.N.home-state
is a parameter (the only axis.N parameter in motion...)
http://www.linuxcnc.org/docs/html/config/emc2hal.html#_parameters_2
if it _wasn't_ a parameter, and was instead a pin,then the comp body
would jut need to be:
;;
if (home_state(0) == home_state(1)){
timer = 0;
if (fabs(position(0) - position(1)) tolerance){
e_stop_out = 1;
}
else
{
timer += fperiod;
if (timer maxtime){
e_stop_out = 1;
}
}
I have no idea how you escape from this e-stop condition, however. It
may need an enable pin linked to an over-ride keyswitch. (though it
will clear on a complete power-down when the encoders both zero)
--
atp
If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto
--
Try New Relic Now We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] gantry revisited
Of course the shaft is hollow.(the actual pinion shaft is only half inch, this is a light duty machine) It would be silly to have a solid shaft that long. - Original Message - From: Gregg Eshelman g_ala...@yahoo.com To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net Sent: Friday, May 24, 2013 1:39:30 AM Subject: Re: [Emc-users] gantry revisited --- On Thu, 5/23/13, Todd Zuercher zuerc...@embarqmail.com wrote: We have about a half dozen old gantry routers that work this way. Rack and pinion drive, with a 2 diameter shaft connecting the 2 pinion gears about 10 feet apart. Not the most elegant solution, but it works. (one is currently for sale) The biggest problem with the design is clearance for the shaft, either the racks and shaft need to be above the table or below. Above is simplest, but gets in the way accessing the work space. Hollow shaft? Hollow, larger diameter shafts can be much stiffer with less weight than a smaller diameter, solid shaft. That's why drive shafts for rear wheel drive, front engine vehicles are 3~4 diameter and made of quite thin metal. -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] gantry revisited
The problem with all these gearboxes, sprokets chains and belts, is each mechanical transmission joint you add adds lash to the system, not to mention more things to wear out. Add this to the fact that large wood routers like this need to move fast and I think he is much better off sticking with what he has. I think that if the motors he has have indexes, I would think that some setup homing to index would be best. After making sure the index points on both motors are set so they are at the point where the gantry is square. Some experimentation will be reqired of course to see how best to impliment this. With a bit of clevverness it might be able to work with trivkins. The real trick might be tuning the servos. - Original Message - From: Gregg Eshelman g_ala...@yahoo.com To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net Sent: Friday, May 24, 2013 1:51:05 AM Subject: Re: [Emc-users] gantry revisited Another way to mechanically connect the ends of any gantry. Fit a rack along each side. Mount a vertical shaft on each end with a gear at the bottom to engage the racks. At the top ends of the shafts, mount right angle gearboxes with a cross shaft connecting them. If the underside of the table is clear, with part of the gantry running below it, then there are arrangements of cables and pulleys that make it always stay square. The original Thermwood control system never had a problem with the gantry trying to get crooked. Perhaps digging into its system could yield some useful information? Is this retrofit a complete one, motors, drives and all? Or is it leaving the motors and drives and replacing the computer? Just wondering if the never-fail keep it square system had nothing to do with the controlling system but was built into the drive system? If you've replaced *everything* electronic and electrical on the machine, then you've removed the 'magic' system that kept the gantry square. -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] gantry revisited
Hi this is a very interesting discussion. A couple of days ago i went to an exhibitionhttp://www.sps-italia.net/en/inside.aspdedicated to the automation sector and I met an interesting small company http://www.promax.it/index_en.html that make CNC and motion controller with integrated PLC and they use a PC winzoz to interact with their controllers. One of the features that they are proud of is the gantry axes management . This is a videohttp://www.youtube.com/watch?v=_zdtPvDA9K8feature=youtu.bethat shows a pretty fast gantry machine in action (low resolution video, sorry). I don't know exactly what they are doing for the X axis homing sequence and for their gearing but seems to work really nicely. regards bigalex On Fri, May 24, 2013 at 3:23 PM, Todd Zuercher zuerc...@embarqmail.comwrote: The problem with all these gearboxes, sprokets chains and belts, is each mechanical transmission joint you add adds lash to the system, not to mention more things to wear out. Add this to the fact that large wood routers like this need to move fast and I think he is much better off sticking with what he has. I think that if the motors he has have indexes, I would think that some setup homing to index would be best. After making sure the index points on both motors are set so they are at the point where the gantry is square. Some experimentation will be reqired of course to see how best to impliment this. With a bit of clevverness it might be able to work with trivkins. The real trick might be tuning the servos. - Original Message - From: Gregg Eshelman g_ala...@yahoo.com To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net Sent: Friday, May 24, 2013 1:51:05 AM Subject: Re: [Emc-users] gantry revisited Another way to mechanically connect the ends of any gantry. Fit a rack along each side. Mount a vertical shaft on each end with a gear at the bottom to engage the racks. At the top ends of the shafts, mount right angle gearboxes with a cross shaft connecting them. If the underside of the table is clear, with part of the gantry running below it, then there are arrangements of cables and pulleys that make it always stay square. The original Thermwood control system never had a problem with the gantry trying to get crooked. Perhaps digging into its system could yield some useful information? Is this retrofit a complete one, motors, drives and all? Or is it leaving the motors and drives and replacing the computer? Just wondering if the never-fail keep it square system had nothing to do with the controlling system but was built into the drive system? If you've replaced *everything* electronic and electrical on the machine, then you've removed the 'magic' system that kept the gantry square. -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] gantry revisited
On 5/24/2013 12:50 AM, Viesturs Lācis wrote: 2013/5/24 Jon Elsonel...@pico-systems.com Dave wrote: I did a gantry system with LinuxCNC a few years back. The gantry was very stiff and self squaring when powered off. The gantry was 10-12 feet across and very heavy. It used used 2 - 1 KW servo drives driving two ball screws on each end of the gantry for the Y axis. In order to keep things simple I used step and direction on the servo drives and fed the same signals to both of the Y axis servo drives. Thanks for the info. This machine has servo motors on each end of the gantry, so it really needs LinuxCNC in the loop for BOTH motor/encoder units. What you did works great for step/dir drives, but won't work for servos. When LinuxCNC starts, the encoder counters are zeroed. When it is moving toward the home switch, it is going to keep them synched the same way as at startup. But, when it arrives at home, the first axis' counter is going to get zeroed. At this point, something special has to happen to prevent the two motors from diverging. Assuming it has moved 1 counts from startup to the home switch, the first motor to find the index mark on its encoder will suddenly have the encoder count jump from 1 to zero. I'm not sure what the other motor will be following at that instant. I have been following this thread and it seems to me that I have missed something. Last week I finally made some chips on my self-built router with servos. The construction is not most rigid, but it squares itself within 10 mm or so, the gantry is 3 m long. I use gantrykins, homing simple - each joint homes to its own switch (I have small inductive proximity switches). The main thing is to set up homing sequence and set all the search and latch and final velocities to be the same. The way it works - both joints start their homing moves simultaneously, move at the same speed, so gantry is not racked and, as much as I can see on screen, it seems that both joints meet their homeswitches pretty much at the same time. I have pretty slow home search velocity (and latch velocity even slower), so that is why I already have G0 G53 X10 Y10 in my MDI history to bring machine back to almost home. I recall that in first posts there was mentioned something about homing to index, but I really do not see a point for that, so I somehow do not understand, where is the problem. Andy Pugh last autumn shared a way to add a new HAL pin to Axis GUI to switch machine to world mode, so I have it connected to axis.n.is-homed pins through and2 components and it works pretty nicely for me. You could use that to make sure that operator will not start jogging the machine in joint mode, once it has been homed. Viesturs Sounds like you have this nailed down already. Perhaps this is even easier than I thought. How are your two parallel axes arranged with regards to XYZ assignments etc? Are you tying the axes together via hal after homing?? Can you post your ini and hal file? (That would answer all questions..) Thanks, Dave Cole -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] gantry revisited
Hi Dave . Maybe you are misunderstanding my message. This video shows how the company that is making the CNC hardware solution is integrating their hardware/software with that gantry machine (woodworking I think). The machine seem to work well but I don't know what specifc solution they did. They only told me that the gantry axes kinematics is well supported by their CNC system with high performance level. bigalex On Fri, May 24, 2013 at 5:28 PM, Dave e...@dc9.tzo.com wrote: On 5/24/2013 12:50 AM, Viesturs Lācis wrote: 2013/5/24 Jon Elsonel...@pico-systems.com Dave wrote: I did a gantry system with LinuxCNC a few years back. The gantry was very stiff and self squaring when powered off. The gantry was 10-12 feet across and very heavy. It used used 2 - 1 KW servo drives driving two ball screws on each end of the gantry for the Y axis. In order to keep things simple I used step and direction on the servo drives and fed the same signals to both of the Y axis servo drives. Thanks for the info. This machine has servo motors on each end of the gantry, so it really needs LinuxCNC in the loop for BOTH motor/encoder units. What you did works great for step/dir drives, but won't work for servos. When LinuxCNC starts, the encoder counters are zeroed. When it is moving toward the home switch, it is going to keep them synched the same way as at startup. But, when it arrives at home, the first axis' counter is going to get zeroed. At this point, something special has to happen to prevent the two motors from diverging. Assuming it has moved 1 counts from startup to the home switch, the first motor to find the index mark on its encoder will suddenly have the encoder count jump from 1 to zero. I'm not sure what the other motor will be following at that instant. I have been following this thread and it seems to me that I have missed something. Last week I finally made some chips on my self-built router with servos. The construction is not most rigid, but it squares itself within 10 mm or so, the gantry is 3 m long. I use gantrykins, homing simple - each joint homes to its own switch (I have small inductive proximity switches). The main thing is to set up homing sequence and set all the search and latch and final velocities to be the same. The way it works - both joints start their homing moves simultaneously, move at the same speed, so gantry is not racked and, as much as I can see on screen, it seems that both joints meet their homeswitches pretty much at the same time. I have pretty slow home search velocity (and latch velocity even slower), so that is why I already have G0 G53 X10 Y10 in my MDI history to bring machine back to almost home. I recall that in first posts there was mentioned something about homing to index, but I really do not see a point for that, so I somehow do not understand, where is the problem. Andy Pugh last autumn shared a way to add a new HAL pin to Axis GUI to switch machine to world mode, so I have it connected to axis.n.is-homed pins through and2 components and it works pretty nicely for me. You could use that to make sure that operator will not start jogging the machine in joint mode, once it has been homed. Viesturs Sounds like you have this nailed down already. Perhaps this is even easier than I thought. How are your two parallel axes arranged with regards to XYZ assignments etc? Are you tying the axes together via hal after homing?? Can you post your ini and hal file? (That would answer all questions..) Thanks, Dave Cole -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] gantry revisited
On 24 May 2013 16:45, alex chiosso achio...@gmail.com wrote: They only told me that the gantry axes kinematics is well supported by their CNC system with high performance level. LinuxCNC supports gantries well too. It is just that there are issues (not related to gantries) with non-trivial kinematics. The issues are almost entirely limited to jogging wierdness. There is a sim-gantry demo config to play around with if you want to see what happens. The main issue is that you can jog onto the limit switches in World mode. (again, IIRC) As far as I know (I haven't actually tried it) these issues are solved in joints_axes3 (an alternative branch). In addition ja3 has a trivial kinematics for multi-joint machines (gentrivkins) which reportedly works admirably. -- atp If you can't fix it, you don't own it. http://www.ifixit.com/Manifesto -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] gantry revisited
Viesturs Lācis wrote: Andy Pugh last autumn shared a way to add a new HAL pin to Axis GUI to switch machine to world mode, so I have it connected to axis.n.is-homed pins through and2 components and it works pretty nicely for me. You could use that to make sure that operator will not start jogging the machine in joint mode, once it has been homed. Well, then maybe that solves all the problems, and requires no new code, or hal components! Very good! Jon -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] gantry revisited
Viesturs Lācis wrote: Andy Pugh last autumn shared a way to add a new HAL pin to Axis GUI to switch machine to world mode, so I have it connected to axis.n.is-homed pins through and2 components and it works pretty nicely for me. You could use that to make sure that operator will not start jogging the machine in joint mode, once it has been homed. Well, then maybe that solves all the problems, and requires no new code, or hal components! Very good! Any quick tips how to implement this would be nice, I'm still relaying on myself that after homing will press shift+4 to enter world mode before start jog... Just a thought... I'm also using gantry style of machine (with slightly modified 5axiskins) and before I switched to linuxcnc, I was using mach3, and there were also two features, that I'm missing in linuxcnc. First one is in case of gantry, when first of parallel axis reaches home switch, waits for the second one and then together make move to home offset (if there is home offset set)... in linuxcnc the axis after reaching home switch immediately go on home offset... probably this could be done with a bit customized hal? Second future was deceleration (for a settable distance) before hitting limit switch or software limit, so if you are not careful and jog with high speed all the way to the limit, you have no chance to hit limit with that speed and cause sudden stop and mechanical stress to machine...Can be this done with customization of hal? -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] gantry revisited
On 24 May 2013 18:39, Tomaz T. tomaz_...@hotmail.com wrote: Second future was deceleration (for a settable distance) before hitting limit switch or software limit, so if you are not careful and jog with high speed all the way to the limit, you have no chance to hit limit with that speed and cause sudden stop and mechanical stress to machine...Can be this done with customization of hal? LinuxCNC simply won't allow itself to hit the limit switch. If it knows where the limit switch is. (ie, if it is homed) If it doesn't know where the limit switch is, then it has no way to decelerate before hitting it. -- atp If you can't fix it, you don't own it. http://www.ifixit.com/Manifesto -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] gantry revisited
Second future was deceleration (for a settable distance) before hitting limit switch or software limit, so if you are not careful and jog with high speed all the way to the limit, you have no chance to hit limit with that speed and cause sudden stop and mechanical stress to machine...Can be this done with customization of hal? LinuxCNC simply won't allow itself to hit the limit switch. If it knows where the limit switch is. (ie, if it is homed) If it doesn't know where the limit switch is, then it has no way to decelerate before hitting it. That's also why I have home offset programmed, but ie. if I jog thoward limit with 3000mm/min and hit it, what will happen? machine will immediately stop (like hitting e-stop) and pop out message. I think stopping machine with e-stop like is not very healthy for machine at higher speeds (mechanical reasons), so that is the reason why I think deceleration would be better... -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] gantry revisited
2013/5/24 Tomaz T. tomaz_...@hotmail.com That's also why I have home offset programmed, but ie. if I jog thoward limit with 3000mm/min and hit it, what will happen? It will stop with acceleration values, defined in INI file. -- Viesturs If you can't fix it, you don't own it. http://www.ifixit.com/Manifesto -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] gantry revisited
There are problems in Gantrykins besides being too easy to jog in joint mode - which in and of itself is a serious problem. When we first built the gantry (http://wiki.linuxcnc.org/cgi-bin/wiki.pl?GantryPlasmaMachine) we used Gantrykins as I thought that was the only way to do it, but ultimately we abandoned that due to several issues we had with it. I meant to go back and write up what issues we had, but I didn't do it and now I have forgotten the details. I do remember that there are problems between World/Joint modes and Manual/MDI where Axis seemed to be confused as to its status and would tell you it was in World mode when it wasn't. This happened to us many times and caused the gantry to rack badly under MDI control and come off the track. There were several other issues as well some of which I posted about in the Fall of 2011 to the list. However, we changed everything to Trivkins with 3 axes (X,Y,Z) and set up X, Y1, Z, and Y2 in the ini and hal and everything has been smooth sailing since. Our config files are all posted on the wiki at the end. I am sure though, that it is best to learn from the mistakes of other's by repeating them yourselves :-) Tom -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] gantry revisited
On 23 May 2013 02:43, Jon Elson el...@pico-systems.com wrote: Anybody have any ideas or especially experience with a system like this? My only experience comes from reading the mailing lists, forums and IRC. I have never actually seen a gantry. There is a kinematics which allows you to independently home two joints on the same axis to independent home switches. Called, unsuprisingly, gantrykins it lets you map more than one joint to each axis, and as long as it is configured correctly the two motors will home independently but simultaneously. It has a number of issues which make it generally more trouble than it is worth (mainly to do with world-mode jogging, because as a non-trivial kinematics it makes a distinction between world-mode and joint-mode) The problems with gantrykins are, as far as I know, all addressed in an alternative one-axis - many-joints kinematics called gentrivkins. Unfortunately gentrivkins only works in the joints_axes3 branch of LinuxCNC (which is currently quite up-to-date, as far as I know, but isn't available as a package) -- atp If you can't fix it, you don't own it. http://www.ifixit.com/Manifesto -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] gantry revisited
andy pugh wrote: Called, unsuprisingly, gantrykins it lets you map more than one joint to each axis, and as long as it is configured correctly the two motors will home independently but simultaneously. A number of problems have been reported with gantrykins, is it now considered fixed? The problem is the two encoders need to stay in the same relative alignment throughout the approach to home sequence or it may bind the carriage. At startup, the gantry is relaxed, and the encoder counters will be cleared to zero. If the count on the two encoders will remain equal during the initial home move, then that should be fine. Presumably, they will be within a very small number of counts out of sync, and the final homing to each encoder's index mark will not twist the gantry any, assuming they both do the home-to-index at the same time. It has a number of issues which make it generally more trouble than it is worth (mainly to do with world-mode jogging, because as a non-trivial kinematics it makes a distinction between world-mode and joint-mode) Yes, this is not a computer-savvy customer, so I don't want to drive them crazy with joint-mode. It really needs to stay in world-mode all the time. Obviously, if you jog one side of the gantry in joint-mode, it will damage the machine. The problems with gantrykins are, as far as I know, all addressed in an alternative one-axis - many-joints kinematics called gentrivkins. Unfortunately gentrivkins only works in the joints_axes3 branch of LinuxCNC (which is currently quite up-to-date, as far as I know, but isn't available as a package That may be a better solution. I can handle getting him a custom install from source, if needed. But, I had hoped to be able to do this without building a gantry machine here just to understand the homing issues. Jon -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] gantry revisited
On 23 May 2013 17:33, Jon Elson el...@pico-systems.com wrote: I had hoped to be able to do this without building a gantry machine here just to understand the homing issues. Two motors on the bench linked by spaghetti would seem like a usable surrogate system :-) If the spaghetti shaft breaks then more work is needed. (limit switches simulated by some HAL tracking Rawcounts from the encoders, which as far as I know never change.) -- atp If you can't fix it, you don't own it. http://www.ifixit.com/Manifesto -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] gantry revisited
In my simplistic way I've always thought that homing a gantry by bringing both sides up against a hard stop, manually if necessary, then enable the servos and set zero or maybe reverse the sequence and set zero first. Probably less than ideal but might work. Has anyone done a gantry that drives with a central motor and mechanical linkage to both sides. I'm thinking more like a solid T not gearing to both sides. Just to put your mind at ease I've not had my coffee yet. Dave On Thu, 2013-05-23 at 17:42 +0100, andy pugh wrote: On 23 May 2013 17:33, Jon Elson el...@pico-systems.com wrote: I had hoped to be able to do this without building a gantry machine here just to understand the homing issues. Two motors on the bench linked by spaghetti would seem like a usable surrogate system :-) If the spaghetti shaft breaks then more work is needed. (limit switches simulated by some HAL tracking Rawcounts from the encoders, which as far as I know never change.) -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] gantry revisited
On 05/23/2013 11:42 AM, andy pugh wrote: On 23 May 2013 17:33, Jon Elson el...@pico-systems.com wrote: I had hoped to be able to do this without building a gantry machine here just to understand the homing issues. Two motors on the bench linked by spaghetti would seem like a usable surrogate system :-) If the spaghetti shaft breaks then more work is needed. (limit switches simulated by some HAL tracking Rawcounts from the encoders, which as far as I know never change.) haha! do you mean spaghetti literally? as in a bundle of dried noodles as a shaft that would break when/if the crabbing got too great? maybe some shearing friction plate coupler with a mark would do same. regards tomp -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] gantry revisited
dave wrote: In my simplistic way I've always thought that homing a gantry by bringing both sides up against a hard stop, manually if necessary, then enable the servos and set zero or maybe reverse the sequence and set zero first. Probably less than ideal but might work. Yes, this is great for steppers, but can blow fuses, jump pinion teeth and otherwise not a great idea with servos. Also, it needs to stay synched ALL THE WAY to the home position. This is going to be a commercial production machine, so manual homing is probably not the best. Jon -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] gantry revisited
I did a gantry system with LinuxCNC a few years back. The gantry was very stiff and self squaring when powered off. The gantry was 10-12 feet across and very heavy. It used used 2 - 1 KW servo drives driving two ball screws on each end of the gantry for the Y axis. In order to keep things simple I used step and direction on the servo drives and fed the same signals to both of the Y axis servo drives. It homes to a prox switch but since this is a waterjet, the home position really isn't all that important. That machine has been running for almost 3 years now everyday. It has never had any homing issues. I keep hearing that Gantrykins has issues. If you wanted to stick with Trivkins I would try to implement something in hal probably with some custom components that did something like this: Gear both axes together at 1:1 and do some minor hal tricks to have both of them follow each other towards the home switches. Then detect which axis sees it's home switch first, then back that axis up a predetermined amount, continue to run the other axis until it's home switch is seen, then back that axis up a predetermined amount. If more precision is required, repeat the routine at a much lower speed. I think some hal logic and probably one or two custom components would be required, but it should not be very difficult. Once the homing is complete, shift the hal logic so that both axes are again locked/geared together. This would avoid gantrykins and the associated issues. The limit3 component can be used to drive an axis. That would be a good component to use as part of or morph into another custom component that could be part of this scheme. Running both drives into a hard stop might be workable if the homing speeds are low, but with big servo drives and a heavy gantry, probably not a good idea. Dave Cole On 5/22/2013 9:43 PM, Jon Elson wrote: So, the issue of homing a dual-motor gantry comes up, again. This one is a stiff structure, and the customer says if the motors get seriously out of synch, it will bend the slide rails. Well, at power-on, the motors will be pretty well synched by mechanical forces. So, there would be two ways to home it. One is to kill one servo amp and allow just one of the servo amps to drive to the home position. Then, enable the 2nd amp and home it. The machine builder would need to be sure the home positions were such that with both at home the gantry was not under stress. The other scheme would be some kind of simultaneous homing that kept both encoders at the same relative offset during the whole process. If the home switch was only on one side of the gantry, then maybe there is a way to have both encoders home to their own index pulses at the same time. (When properly set up, the two encoders should arrive at their index positions nearly simultaneously.) Anybody have any ideas or especially experience with a system like this? Jon -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] gantry revisited
We have about a half dozen old gantry routers that work this way. Rack and pinion drive, with a 2 diameter shaft connecting the 2 pinion gears about 10 feet apart. Not the most elegant solution, but it works. (one is currently for sale) The biggest problem with the design is clearance for the shaft, either the racks and shaft need to be above the table or below. Above is simplest, but gets in the way accessing the work space. - Original Message - From: dave dengv...@charter.net To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net Sent: Thursday, May 23, 2013 2:14:20 PM Subject: Re: [Emc-users] gantry revisited In my simplistic way I've always thought that homing a gantry by bringing both sides up against a hard stop, manually if necessary, then enable the servos and set zero or maybe reverse the sequence and set zero first. Probably less than ideal but might work. Has anyone done a gantry that drives with a central motor and mechanical linkage to both sides. I'm thinking more like a solid T not gearing to both sides. Just to put your mind at ease I've not had my coffee yet. Dave On Thu, 2013-05-23 at 17:42 +0100, andy pugh wrote: On 23 May 2013 17:33, Jon Elson el...@pico-systems.com wrote: I had hoped to be able to do this without building a gantry machine here just to understand the homing issues. Two motors on the bench linked by spaghetti would seem like a usable surrogate system :-) If the spaghetti shaft breaks then more work is needed. (limit switches simulated by some HAL tracking Rawcounts from the encoders, which as far as I know never change.) -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] gantry revisited
Dave wrote: I did a gantry system with LinuxCNC a few years back. The gantry was very stiff and self squaring when powered off. The gantry was 10-12 feet across and very heavy. It used used 2 - 1 KW servo drives driving two ball screws on each end of the gantry for the Y axis. In order to keep things simple I used step and direction on the servo drives and fed the same signals to both of the Y axis servo drives. Thanks for the info. This machine has servo motors on each end of the gantry, so it really needs LinuxCNC in the loop for BOTH motor/encoder units. What you did works great for step/dir drives, but won't work for servos. When LinuxCNC starts, the encoder counters are zeroed. When it is moving toward the home switch, it is going to keep them synched the same way as at startup. But, when it arrives at home, the first axis' counter is going to get zeroed. At this point, something special has to happen to prevent the two motors from diverging. Assuming it has moved 1 counts from startup to the home switch, the first motor to find the index mark on its encoder will suddenly have the encoder count jump from 1 to zero. I'm not sure what the other motor will be following at that instant. I can think of a couple ways to do this. One is to simply make the 2nd motor coast by disabling the servo amp until the master motor has completed it's homing sequence. Then, enable the 2nd servo amp and home that motor, which will be VERY close to home. Except that it would have accumulated a bunch of movement while the master motor homed. I can easily see a few HAL components could fiddle the commanded position to make this work. What seems important is to keep the machine out of joint mode, so maybe that eliminates gantrykins. The two motors must NEVER be moved separately on this machine. The customer assures me this will cause structural damage to the guideways. But, maybe gentrivkins will solve the problems. Jon -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] gantry revisited
Todd Zuercher wrote: We have about a half dozen old gantry routers that work this way. Rack and pinion drive, with a 2 diameter shaft connecting the 2 pinion gears about 10 feet apart. Not the most elegant solution, but it works. (one is currently for sale) The biggest problem with the design is clearance for the shaft, either the racks and shaft need to be above the table or below. Above is simplest, but gets in the way accessing the work space. I don't know the Thermwood, but I can easily imagine some machine layouts that make this completely impossible. Like, rack on the bottom of the table, and big legs or vacuum holddown system in the middle of the table. I looked at a big vertical boring mill a long time ago at an auction, and have seen some similar gantry systems on other machines that have a bearing at the top of each gantry pylon. The beam across the pylons has a slot for one of the bearings, so the pylons can be significantly out of square without applying stress to the frame. They probably have an E-stop limit switch so if the beam gets too far out of square it stops the machine. The two pylons can be homed somewhat separately, and then when homed, the machine is perfectly in square. This seems like the smartest way to go, you can't break the machine, and if a servo fails or starts to runaway you get an E-stop. These rigid gantrys seem like you could get into trouble, and the homing needs to be done the right way or it could throw the machine out of square. Jon -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] gantry revisited
On 5/23/2013 11:29 PM, Jon Elson wrote: Dave wrote: I did a gantry system with LinuxCNC a few years back. The gantry was very stiff and self squaring when powered off. The gantry was 10-12 feet across and very heavy. It used used 2 - 1 KW servo drives driving two ball screws on each end of the gantry for the Y axis. In order to keep things simple I used step and direction on the servo drives and fed the same signals to both of the Y axis servo drives. Thanks for the info. This machine has servo motors on each end of the gantry, so it really needs LinuxCNC in the loop for BOTH motor/encoder units. What you did works great for step/dir drives, but won't work for servos. When LinuxCNC starts, the encoder counters are zeroed. When it is moving toward the home switch, it is going to keep them synched the same way as at startup. But, when it arrives at home, the first axis' counter is going to get zeroed. At this point, something special has to happen to prevent the two motors from diverging. Assuming it has moved 1 counts from startup to the home switch, the first motor to find the index mark on its encoder will suddenly have the encoder count jump from 1 to zero. I'm not sure what the other motor will be following at that instant. I can think of a couple ways to do this. One is to simply make the 2nd motor coast by disabling the servo amp until the master motor has completed it's homing sequence. Then, enable the 2nd servo amp and home that motor, which will be VERY close to home. Except that it would have accumulated a bunch of movement while the master motor homed. I can easily see a few HAL components could fiddle the commanded position to make this work. What seems important is to keep the machine out of joint mode, so maybe that eliminates gantrykins. The two motors must NEVER be moved separately on this machine. The customer assures me this will cause structural damage to the guideways. But, maybe gentrivkins will solve the problems. Jon Right, what I did with the step/dir servos won't work with analog servos. What I am saying is that the homing routine needs to be remade in hal probably using custom hal components so it can work with two drives while using Trivkins. The one that is there will not work with Trivkins and two parallel axes. On the large machine I did before, there was no way that one motor could drag the other motor to the home position, even if the drive was disabled. The gantry was stiff, but over a 10+ ft span that would simply not work. The gantry would bind up and jam. Dave Cole -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] gantry revisited
2013/5/24 Jon Elson el...@pico-systems.com Dave wrote: I did a gantry system with LinuxCNC a few years back. The gantry was very stiff and self squaring when powered off. The gantry was 10-12 feet across and very heavy. It used used 2 - 1 KW servo drives driving two ball screws on each end of the gantry for the Y axis. In order to keep things simple I used step and direction on the servo drives and fed the same signals to both of the Y axis servo drives. Thanks for the info. This machine has servo motors on each end of the gantry, so it really needs LinuxCNC in the loop for BOTH motor/encoder units. What you did works great for step/dir drives, but won't work for servos. When LinuxCNC starts, the encoder counters are zeroed. When it is moving toward the home switch, it is going to keep them synched the same way as at startup. But, when it arrives at home, the first axis' counter is going to get zeroed. At this point, something special has to happen to prevent the two motors from diverging. Assuming it has moved 1 counts from startup to the home switch, the first motor to find the index mark on its encoder will suddenly have the encoder count jump from 1 to zero. I'm not sure what the other motor will be following at that instant. I have been following this thread and it seems to me that I have missed something. Last week I finally made some chips on my self-built router with servos. The construction is not most rigid, but it squares itself within 10 mm or so, the gantry is 3 m long. I use gantrykins, homing simple - each joint homes to its own switch (I have small inductive proximity switches). The main thing is to set up homing sequence and set all the search and latch and final velocities to be the same. The way it works - both joints start their homing moves simultaneously, move at the same speed, so gantry is not racked and, as much as I can see on screen, it seems that both joints meet their homeswitches pretty much at the same time. I have pretty slow home search velocity (and latch velocity even slower), so that is why I already have G0 G53 X10 Y10 in my MDI history to bring machine back to almost home. I recall that in first posts there was mentioned something about homing to index, but I really do not see a point for that, so I somehow do not understand, where is the problem. Andy Pugh last autumn shared a way to add a new HAL pin to Axis GUI to switch machine to world mode, so I have it connected to axis.n.is-homed pins through and2 components and it works pretty nicely for me. You could use that to make sure that operator will not start jogging the machine in joint mode, once it has been homed. Viesturs If you can't fix it, you don't own it. http://www.ifixit.com/Manifesto -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] gantry revisited
--- On Thu, 5/23/13, dave dengv...@charter.net wrote: Has anyone done a gantry that drives with a central motor and mechanical linkage to both sides. I'm thinking more like a solid T not gearing to both sides. Just to put your mind at ease I've not had my coffee yet. Yes, there's some videos on youtube of various systems. One version uses a stationary chain or belt, looped around a drive sprocket and a couple of idlers. A shaft runs across the gantry to an identical set of sprockets and chain. The gantry cannot get out of square. A similar approach can be used with a rack and pinion drive. The connecting shaft wouldn't have to be connected to the drive system, just the gantry. If it's only going to be used on sheet material all it would need is a shaft with a gear on each end to engage the rack and sufficient bearings to support the shaft across the table. If the shaft can't be down low, use two meshed gears at each end or pair a sprocket with the gear and run chains up to sprockets on the shaft ends, high as need be to clear what the gantry moves over. What gets me is why on a 5x10 foot table the manufacturer would put the gantry across the long way. Across the short way it could do exactly the same work. There's a way to connect the sides with a shaft without completely redesigning the gantry. It just takes looking at with a bodger's eye. ;-) A benefit to that would be freeing up a controller axis by replacing the motor on each side with one, more powerful motor. -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] gantry revisited
Since the next machine I build will be a servo powered gantry this is a very interesting discussion for me. I'm curious, Jon, if you were able to discern how Thermwood managed the homing problem. If you haven't, perhaps you could find some Thermwood owners here who may be able to shed some light: http://www.woodweb.com/cgi-bin/forums/cnc.pl +++ Anyone who believes exponential growth can go on forever in a finite world is either a madman or an economist. -Kenneth Boulding, economist “How unfortunate that the Earth’s first intelligent social animal is a tribal carnivore” -E.O. Wilson, sociobiologist From: Jon Elson el...@pico-systems.com To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net Sent: Thursday, May 23, 2013 12:08 AM Subject: Re: [Emc-users] gantry revisited Gregg Eshelman wrote: --- On Wed, 5/22/13, Jon Elson el...@pico-systems.com wrote: So, the issue of homing a dual-motor gantry comes up, again. This one is a stiff structure, and the customer says if the motors get seriously out of synch, it will bend the slide rails. The simplest way to do it is a cross drive shaft linking both sides and slave two axes together. This is a 5 x 10 foot Thermwood router, so the motors are TEN FEET apart. All the mechanicals are complete, this is only a controller retrofit. The motors are pretty small (650 Oz-In continuous servos) so it really needs both motors. It worked for years with the Thermwood controller. I think the motors are on little gearboxes with rack and pinion drive, and the shaft may well be impossible to set up without completely redesigning the machine. Jon -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] gantry revisited
--- On Thu, 5/23/13, Todd Zuercher zuerc...@embarqmail.com wrote: We have about a half dozen old gantry routers that work this way. Rack and pinion drive, with a 2 diameter shaft connecting the 2 pinion gears about 10 feet apart. Not the most elegant solution, but it works. (one is currently for sale) The biggest problem with the design is clearance for the shaft, either the racks and shaft need to be above the table or below. Above is simplest, but gets in the way accessing the work space. Hollow shaft? Hollow, larger diameter shafts can be much stiffer with less weight than a smaller diameter, solid shaft. That's why drive shafts for rear wheel drive, front engine vehicles are 3~4 diameter and made of quite thin metal. -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] gantry revisited
Another way to mechanically connect the ends of any gantry. Fit a rack along each side. Mount a vertical shaft on each end with a gear at the bottom to engage the racks. At the top ends of the shafts, mount right angle gearboxes with a cross shaft connecting them. If the underside of the table is clear, with part of the gantry running below it, then there are arrangements of cables and pulleys that make it always stay square. The original Thermwood control system never had a problem with the gantry trying to get crooked. Perhaps digging into its system could yield some useful information? Is this retrofit a complete one, motors, drives and all? Or is it leaving the motors and drives and replacing the computer? Just wondering if the never-fail keep it square system had nothing to do with the controlling system but was built into the drive system? If you've replaced *everything* electronic and electrical on the machine, then you've removed the 'magic' system that kept the gantry square. -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] gantry revisited
--- On Wed, 5/22/13, Jon Elson el...@pico-systems.com wrote: So, the issue of homing a dual-motor gantry comes up, again. This one is a stiff structure, and the customer says if the motors get seriously out of synch, it will bend the slide rails. The simplest way to do it is a cross drive shaft linking both sides and slave two axes together. Can't get out of synch even if one motor quits. Same concept the V-22 Osprey uses to keep both rotors turning in synch. Why fiddle with a finicky electronic/software method when a dead simple piece of metal will work and won't fail? That's my plan for a plasma table if the place in Texas the electronics were ordered from will get off their arse and get it shipped. -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] gantry revisited
Our gantry uses feature in the Granite Devices drives that lowers torque, homes to a hard stop (until a configurable ferror is reached) and then backs to the encoder index. It is described here: http://wiki.linuxcnc.org/cgi-bin/wiki.pl?GantryPlasmaMachine#Homing_Controller. This system has worked great. Seems like you could implement something like this even without using Granites though you would need to be able to lower the torque while you do the homing... Tom On May 22, 2013, at 9:43 PM, Jon Elson el...@pico-systems.com wrote: So, the issue of homing a dual-motor gantry comes up, again. This one is a stiff structure, and the customer says if the motors get seriously out of synch, it will bend the slide rails. Well, at power-on, the motors will be pretty well synched by mechanical forces. So, there would be two ways to home it. One is to kill one servo amp and allow just one of the servo amps to drive to the home position. Then, enable the 2nd amp and home it. The machine builder would need to be sure the home positions were such that with both at home the gantry was not under stress. The other scheme would be some kind of simultaneous homing that kept both encoders at the same relative offset during the whole process. If the home switch was only on one side of the gantry, then maybe there is a way to have both encoders home to their own index pulses at the same time. (When properly set up, the two encoders should arrive at their index positions nearly simultaneously.) Anybody have any ideas or especially experience with a system like this? Jon -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] gantry revisited
Gregg Eshelman wrote: --- On Wed, 5/22/13, Jon Elson el...@pico-systems.com wrote: So, the issue of homing a dual-motor gantry comes up, again. This one is a stiff structure, and the customer says if the motors get seriously out of synch, it will bend the slide rails. The simplest way to do it is a cross drive shaft linking both sides and slave two axes together. This is a 5 x 10 foot Thermwood router, so the motors are TEN FEET apart. All the mechanicals are complete, this is only a controller retrofit. The motors are pretty small (650 Oz-In continuous servos) so it really needs both motors. It worked for years with the Thermwood controller. I think the motors are on little gearboxes with rack and pinion drive, and the shaft may well be impossible to set up without completely redesigning the machine. Jon -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] gantry revisited
Tom Easterday wrote: Our gantry uses feature in the Granite Devices drives that lowers torque, homes to a hard stop (until a configurable ferror is reached) and then backs to the encoder index. It is described here: http://wiki.linuxcnc.org/cgi-bin/wiki.pl?GantryPlasmaMachine#Homing_Controller. This system has worked great. Seems like you could implement something like this even without using Granites though you would need to be able to lower the torque while you do the homing... I think we can find similar ways to reduce torque. Thanks, Jon -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
