Am 07.12.2012 um 02:09 schrieb Gene Heskett: > On Thursday 06 December 2012 19:50:33 Michael Haberler did opine: > >>>> >>>> How did you determine a) the stepper stalled (for how many steps?) >>>> and b) actually the cause was the delay you mention? >>>> >>>> - Michael >>> >>> If a stepper stalls, running above 1/3 its max speed, and does it at >>> random times, that is the doorstep I lay the blame on. > > Its also the point where I may add 1 or 2 microseconds to the base_thread > before I restart. There is of course a point of diminishing returns there > because the available step rates then must have a coarser value, resulting > in a noticeably less smoother speed variation. For tolerably smooth > control those steps should be only 5% or so up or down. > >> Do you have any hard evidence for that, or is that pure conjecture? > > I suppose it could be called conjecture, but I've had the latency overrun > advisor come up at at the same time too often for it to be just a co-inky- > dunce as one friend of mine was fond of saying.
I assume you are referring to 'Unexpected realtime delay...' messages. That brings up a very good point, and that is why I was asking. The message per se is, too put it mildly, less than helpful. All it says is that the _motion_ thread hasnt been invoked within a certain time window. I'm not aware of the stepgen comp actually trying to detect that situatiom, and that would be relevant for steppers (assuming sw stepgen). It is fair to assume though if motion timing is wrong, sw stepgen is likely to be off, too. Having looked at the code, I think it sends the completely wrong message - "o my god, something bad happened". Myself, I care exactly nothing about 'Unexpected realtime delays', what I am interested is: is the overall cutting path off more than a certain margin, or not. However, that message doesnt tell you that, it is just a very circumferential indication something might be wrong (sometimes it is, for instance if it hints at fundamental setup problem); interestingly the component which might to be able to compensate in part for what is wrong doesnt even try to do that, but thats a different story. I think it is due that on the software and design side of things, a bit more academic rigor is applied to what delays actually mean and if, and if so, how, they can be dealt with, for instance by attempting to correct for it. All I am trying to do here is to refocus on what the problem actually is. The problem might not be 'what is the fastest motherboard', I think it is 'path quality within a certain margin', and we do not have any analytical measures for that. I think that it would be a worthwhile endeavor to find ways to measure and compare that. It might be we need completely different gauging mechanism - one which is a bit closer to which this is all about. - Michael > >> How do you discriminate that suggested cause against mechanical >> overload? > > If the machine is 'cutting air', I think its not likely to be mechanical. > I do run the machine by hand to check on binding if I adjust any of its > ways. > > Cheers Michael, 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) > My web page: <http://coyoteden.dyndns-free.com:85/gene> is up! > "Of all the tyrannies that affect mankind, tyranny in religion is the > worst." > -- Thomas Paine > I was taught to respect my elders, but its getting > harder and harder to find any... > > ------------------------------------------------------------------------------ > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > Remotely access PCs and mobile devices and provide instant support > Improve your efficiency, and focus on delivering more value-add services > Discover what IT Professionals Know. Rescue delivers > http://p.sf.net/sfu/logmein_12329d2d > _______________________________________________ > Emc-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-developers ------------------------------------------------------------------------------ LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
