On Oct 29, 2011, at 9:06 AM, Viesturs Lācis wrote: > Since You have shared zero information about the machine, its construction > and purpose, my opinion is based in my own experience -
Sorry, I have shared information about it, just not in this thread I guess. Here is a video when we had it running with Gecko 320x drives (which we thought had some problems which we now think may have been noise on our step/dir signals): http://www.youtube.com/watch?v=yPOZPVsHyV0&feature=related We have a D510MO motherboard driving a Mesa 7i43 with Mesa 7i42 buffer card which sends step/dir to Granite VSD-E servo drives. The power supply is a linear 72V 20A DC supply (from Antek). It has Keling Nema 34 Servo Motors (http://www.kelinginc.net/KL34-180-90.pdf) with CUI AMT-102 encoders on them and rack and pinion drive on X and Y. The purpose is twofold. To carry a plasma torch and to also be able to carry a high speed spindle (or standard router). We want it to be able to rapid at high speed (1500-2000 ipm). It has a 53" travel in both X and Y. We don't have the Z head built yet but it has a smaller NEMA 23 motor and will have a ball screw instead of rack and pinion. > the constructions of those gantry machines I have worked on are flexible > enough that even few centimeters back or forth on one gantry side do not > cause any damage to construction, so jogging both joints together by holding > 2 buttons is not a problem, because I am sure that any operator can press > both buttons within 0.2 seconds. I suspect this one could be off 3/4"-1" and still move but when it gets that far off it sounds terrible (buzzing and creaking). It really wants to stay in line. I tried to jog using two keys some more but for whatever reason I cannot move much more than a couple feet before the gantry is racked. I don't think the jog speeds are different on the different joints but I need to investigate further because it almost seems like it. I can't imagine that my button pushing timing is that far off… I don't ever envision needing to jog Y in Joint Mode though. Assuming EMC works they way it should, I ought to be able to go to World Mode and jog, then go back to Joint Mode and home it. > AFAIK jogging before homing is done, only to save time, when current machine > position is relatively far from its home position and it would take a long > time for machine to go home with home search velocity (given that machine > construction and config is set up properly, homing sequence is indicated > correctly, so that machine can always find its home in a safe manner without > a risk to hit something in its way). If that is Your case, I think it would > be obvious to eliminate the need for jogging and move machine closely to home > position before shutting it down. One easy way to do that is to introduce VCP > button, that tells the machine to go (almost) home, so after finishing work > operator can easily move machine to a position, from which it can home > quickly and easily. I agree and we started working on that yesterday. We put a "home" button in the PYVCP panel and are working on the config to tie it all together. I wish we could hide Joint mode altogether in Axis. In our case we don't ever need to be in Joint mode and it just reeks havoc on the Y axis when you forget to switch to World mode and jog. Given that the machine can move at over 2000ipm it is way too easy to do severe damage to the Y trucks if you accidentally jog in Joint mode and have the velocity turned up for some reason. > I am saying that gantry config is very nice example, where axis vs. joint > concept is demonstrated. And currently in EMC2 both these conventions are > mixed up in many places and used interchangeably (and thus creates a lot of > confusion) - in INI file AXIS_N actually should read as JOINT_N, because > those parameters are applied to particular joints, without regard to > kinematics and which Cartesian axis they really are "connected" to. Agreed, we were discussing this same thing yesterday. It is confusing and mixes Axes and Joints together in places that makes it very confusing and prone to misconfiguration. Your suggestion to add the 4th letter did help us understand a couple things. We have Joint 1 and Joint 3 which are Y1 and Y2 respectively, When we only had three letters in the COORDINATES line we only see three axes (aka Joints) in Axis which is actually as it should be. But we couldn't understand where Axis was getting it's position information shown in the DRO. Adding that 4th letter, added another axis (aka Joint) to the display and we see that when in World mode Axis uses the encoder of Joint 1 (Y2). I don't know the history to understand why the highest number encoder was chosen as opposed to an average, or a letting the user configure which one is used, but that too made it very confusing. Adding the forth letter to the config allowed us to understand the cause of the jerk movement when homing the Y axis. I think what was happening is that the when we turn on the machine some noise is introduced on the encoder line to the Mesa and so non-zero values appear in the DRO at the start. So, Y1 and Y2 are at slightly different non-zero encoder positions. Then when we jog and then go back to Joint mode to do homing EMC is trying to re-align the Y1 encoder to match the Y2 encoder and so we get the jerk. We don't have any of the homing parameters set (like velocities, etc) so I suspect it is doing this alignment at max accel and some high velocity and so this short (always less than 0.1") appears to be a somewhat violent jerk. We are now zero'ing the encoders upon machine-on signal in Axis to get the encoder values to a known state. > Jonts_axes3 branch is the place, where these things are gradually sorted out. > Unfortunately my programming skills are so low, that I do not really > understand, what is the progress there - I have been looking through > different commits in that branch, but do not really understand much of the > stuff I can see :)) I am glad to hear work is being done there! I see a lot of questions and lots of confusion (including my own) on gantry configuration in EMC. It is (obviously) possible to make a multi-jointed gantry work as it is now but it sure seems there are as many ways to do it as there are people doing it. It seems like someone finds a way that it works and then just dances around the issues/bugs with various procedures and lives with it. And if the next person is doing something slightly differently then all bets are off on using the previous person's configuration. > > Based on tiny details You have shared about Your config - no. It _should_ be > fine. I will again post my configs to pastebin and send the link. I did that a while back but quite a few things have changed. You are right, just adding the 4 letter didn't make EMC complain, I didn't have to change anything else. -Tom ------------------------------------------------------------------------------ Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World™ now supports Android™ Apps for the BlackBerry® PlayBook™. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
