Hugh Currin wrote: >EMC List: > >I've just upgraded my drivers to Gecko G202s. All seems to work well and I'm >trying to fine tune EMC. > >These microstepping drives and higher rapids push the 1GHz computer much more >than the original half step drivers. I was getting "joint 0 following error". >After some experimentation I decreased the Base Task Period, Servo Task >Period, and Trajectory Planning Period. I kept the ratio between these the >same. > > It's not necessary to keep the ratio the same. The BASE_PERIOD needs to be fast enough to do step generation at the rate you need. The SERVO_PERIOD needs to be fast enough to make the shapes you want within the following error you specify, and is usually set to 1 ms. This is the rate at which new velocity commands are generated for the step generator.
>Using 30,000 / 600,000 / 6,000,000 for these periods I was able to get 51 >in/min before a following error. Using 20,000 / 400,000 / 4,000,000 I started >losing steps around 75 in/min. This seems to solve the problem with >the "joint 0 following error" problem and I'm running into driver/motor >limits. Reducing the periods further doesn't seem to do much. This is fine >and I've set rapids to 60 in/min which is fast enough to scare me real good. > > You should be able to set SERVO_PERIOD to 1,000,000 and TRAJ_PERIOD to 10,000,000 without adverse effects. >However, I now seem to get an "Unexpected realtime delay, check dmesg for >details" warning. Minimal testing seems to show this error occurs once, soon >after EMC is started. After it seems to be fine. I checked the dmesg file and >can find nothing related. (I saved dmesg, ran EMC getting the warning, then >compared the old and new dmesg files finding no change) Decreasing the >Periods seems to promote this warning sooner after starting EMC. > > Yep - the error is printed from the TRAJ thread, I think. It measures the actual time between executions, and if it's more than 1.1 times the expected time (or something around there), the error is printed. Since you decreased the period, you also decreased the margin around it by a similar ratio. Note that EMC1 in the early days would report that error if the delay was soemthing like 10x expected, so this warning has a much tighter tolerance. I think the warnings only print once per run of EMC2, so that would be why you only see one copy in dmesg. >What would "Unexpected realtime delay" indicate and what should I adjust to >get rid of it? > > You should look at the actual numbers - if it's telling you that the actual time was 600,000 instead of 400,000, that's probably not an issue. If it's telling you that the time is 300,000,000 instead of 400,000, that may be a problem. You can correct it by setting TRAJ_PERIOD and SERVO_PERIOD back to 10 ms and 1 ms - I don't think that will hurt anything in your setup, since your rapid speeds aren't too high, and you aren't running analog servos. - Steve >I'm not sure what's helpful, but I'm using: > GPL Version 2 (2006) (EMC2 2.0.5) > TkEmc > *.ini modified from stepper_inch.ini > TASK = milltask > PARAMETER_FILE = stepper.var > EMCMOT = motmod > HALFILE = core_stepper.hal / standard_pinout.hal > >Thank you for any help. > > ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
