On Thursday 06 December 2012 21:24:20 Michael Haberler did opine: > 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 > Ok, then consider this: On those atom boards, with just a slight lag to the rest of the system, it can run a 19 microsecond base thread, but will probably throw the "unexpected" before you can click around and get the machine enabled.
With a 21 microsecond base thread, it might take 2 or 4 minutes before it pops up. With a 23 u-s base thread , it might take half an hour. At 25 u-s, I've not seen one even after a couple of days. Currently running at 24 u-s. I might get one in 1 or 2 hours. Now, I have an unrelated question. I modified that spindle interface of Arturo's to speed it up by 10/.2=50x. The spindle servos load response is much stiffer now, but I need to be able to make my electronic fuse behave a bit better. To that end, I want to put all the spindle control related stuff into 4 "paragraphs" in my hal file just to clarify my overview. Paragraph one would be everything from axis, to the pid modules speed command input. This path will and does have a fairly long time constant lo-pass, so that neither my punch on the +- buttons, or a programmed speed change aren't so sudden as to jerk the thing by 500 rpm in 50 milliseconds and blow a fuse, but to effect a speed change gently enough the servo can follow without sending up fireworks. Paragraph 2 would be from the encoder velocity output back to the pid.feedback input. This path should be as fast as it can be because it will directly impinge on the stiffness of control. And paragraph 3 then is the path from the pid output to the pwmgen input. This also seems to need a high bandwidth, as fast as the servo thread runs. Paragraph 4 then is the pid.error output back to the motion_enable input. This is my electronic fuse. So, what signals, coming into the hal stuff, represent the fwd, rev, and -/+ speed buttons in the axis gui? I will be back later asking questions about the scale of the data. At present, the error climbs slowly till about 250 rpm, then decays again, finally going negative when the spindle is at its top speed in low gear, or around 20 rps. That tells me I probably have a scale gain AFU someplace. 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) My web page: <http://coyoteden.dyndns-free.com:85/gene> is up! Data, n.: An accrual of straws on the backs of theories. 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
