Chris Radek wrote: >Actually no, if you look closely at his error, you can see he >has a much larger deviation. > >[ 193.318209] In recent history there were > >[ 193.318211] 2412729, 2414583, 2413107, 2413341, and 2415294 > >[ 193.318213] elapsed clocks between calls to the motion controller. > >[ 193.318216] This time, there were 3629106 which is so anomolously > >[ 193.318218] large that it probably signifies a problem with your > >[ 193.318220] realtime configuration. For the rest of this run of > >[ 193.318222] EMC, this message will be suppressed. > > > >At 2400 MHz, this overrun is something like 500 microseconds, which is >many BASE_PERIODs and therefore probably represents a real problem. >He should start troubleshooting with these hints: > > > I'm wondering if this error test should be a configurable option? I haven't figured out what causes these variations in the execution time of the motion task. But, at least in a true servo system, it makes no difference in system performance unless the motion task has not completed before the next dispatch time. Even a 500 us variation might not actually cause a problem, although it sure represents an anomaly. I'm still evaluating whether two of the systems I have here are actually in any danger of servo loop problems, or whether the reports can be safely ignored. So far my variations have not been anywhere as large as the one above.
Jon ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
