On Sunday, October 16, 2011 11:37:29 AM Tom Easterday did opine: > Well, apparently the problem didn't get resolved with the jog velocity > vs axis velocity thing…. > > Begin forwarded message: > > From: Peter Jensen <jensen_rem...@yahoo.com> > > Subject: Screenshots > > Date: October 16, 2011 2:19:43 AM EDT > > To: Tom Easterday <tom-...@bgp.nu> > > Reply-To: Peter Jensen <jensen_rem...@yahoo.com> > > > > > > Ok, you know how I said I fixed the problem? Well, apparently not. > > It's doing it again. > > > > One important thing to pay attention to is that the error is that the > > reported "actual" position is getting AHEAD of the commanded > > position, and then at the end of the move jumping BACK. All the > > moves in the images below are from jogging in the positive direction > > on Axis 1. There are 4 images, taken with progressively faster jog > > speeds (you can see the jog speed in the jog slider on the left hand > > window). > > > > I am simply holding down the jog-positive key for a second or two, > > then letting go. When I took these screen grabs, the motor power is > > off, nothing is actually moving, and no encoder is actually > > connected to EMC. If I turn on the motor power, the motors do move > > and can be seen to come to the end of the jog and then move quickly > > back a fraction of an inch, just as these following errors would > > indicate (and the hal-scope graphs are the same - the motors being > > on or off has nothing to do with this, as there is no encoder > > feedback connected to EMC or the mesa card). > > > > Note that the Y axis scale of the following error is different in > > each image. As the speed increases, the "following error" > > increases. > > > > The scaling factor is 25464.79089470325 steps per inch, and the step > > length and step space parameters are both set at 300 nano-seconds > > each (for a total of 600 nano-seconds per step). At 3600ipm there > > would be 654 nano-seconds between steps, and this test topped out > > at only 3180ipm, so we should not be running out of time. > >
If you are going through optoisolators, those step timings could be a little short for opto work. But at the same time I can't see that as explaining this. I would double it for test purposes just for S&G though. > > So, there it is. Go figure. :) > > > > -- > > Peter J. Jensen > > http://bgp.nu/~tom/pub/Screenshot1.png > http://bgp.nu/~tom/pub/Screenshot2.png > http://bgp.nu/~tom/pub/Screenshot3.png > http://bgp.nu/~tom/pub/Screenshot4.png > > ------------------------------------------------------------------------ > ------ All the data continuously generated in your IT infrastructure > contains a definitive record of customers, application performance, > security threats, fraudulent activity and more. Splunk takes this data > and makes sense of it. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunk-d2d-oct > _______________________________________________ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users Cheers, Gene -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) One good reason why computers can do more work than people is that they never have to stop and answer the phone. ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
