I think I left out some needed information. If I run the same exact G0 move from MDI there is no stuttering (machine velocity 100%), but when I load a longer file, the stuttering happens regardless of what the max machine velocity is set at.
Here is a video showing what I described above: https://youtu.be/oDitJfUODA4. I hope that this will address your concerns about the accelerations and velocities. <https://youtu.be/oDitJfUODA4> I am running a machinekit on a BBB using the PRU for the stepgen and mkwrapper for the gui (QTQuickVCP). I did some more digging in the meantime: I watched top in the terminal while the program was running and I saw systemd-journal's cpu usage spike as the stuttering was occurring. I then ran the ngc program again and watched tail -f /var/log/syslog. It appears syslog is getting slammed with logs emitted from rtapi. Here is a small( not even 0.1%) sample of what was in syslog during the stuttering: ... Jul 21 16:51:12 beaglebone rtapi:0: 4:rtapi_app:3423:user SET_LINE Jul 21 16:51:12 beaglebone rtapi:0: 4:rtapi_app:3423:user Jul 21 16:51:12 beaglebone rtapi:0: 4:rtapi_app:3423:user 89062570: CMD 9725 , code 29 Jul 21 16:51:12 beaglebone rtapi:0: 4:rtapi_app:3423:user SET_LINE Jul 21 16:51:12 beaglebone rtapi:0: 4:rtapi_app:3423:user Jul 21 16:51:12 beaglebone rtapi:0: 4:rtapi_app:3423:user 89062575: CMD 9726 , code 29 Jul 21 16:51:12 beaglebone rtapi:0: 4:rtapi_app:3423:user SET_LINE Jul 21 16:51:12 beaglebone rtapi:0: 4:rtapi_app:3423:user Jul 21 16:51:12 beaglebone rtapi:0: 4:rtapi_app:3423:user 89062578: CMD 9727 , code 29 Jul 21 16:51:12 beaglebone rtapi:0: 4:rtapi_app:3423:user SET_LINE Jul 21 16:51:12 beaglebone rtapi:0: 4:rtapi_app:3423:user Jul 21 16:51:12 beaglebone rtapi:0: 4:rtapi_app:3423:user 89062580: CMD 9728 , code 29 Jul 21 16:51:12 beaglebone rtapi:0: 4:rtapi_app:3423:user SET_LINE ... The syslog spam occurs only when the stuttering is happening. I verified /etc/linuxcnc/rtapi.ini: ... [global] # Default DEBUG level, 0-5 for NONE, ERR, WARN, INFO, DBG, ALL DEBUG=1 ... I would assume that these rtapi logs are of DBG level. I also tried DEBUG=0 with the same results: massive syslog spam from rtapi. Not sure if this is a red herring or the cause of the problem. To discuss my motion queue and interpreter therory: > I suspect this to be related to the motion queue and/or the interpreter... > > > Don't see how. The reason I think it has to deal with the motion queue is because the stuttering happens on a large file, right after a G43 (IIRC that is a queue-buster command), where the rest of the file has no queue-busters till the end of the file. This is why the machine can handle the single MDI commands and short files, but not the large files. The moment the G43 command is executed, the motion queue starts to get filled, filling the motion queue requires the file to be read line by line by the ngc interpreter, I assume this gets becomes CPU intensive (with all that parsing and then the naive CAM detection). What I can't explain with my theory is how the non-realtime interpreter is causing the PRU to stutter (or any of the realtime hal stuff for that matter). But I only know enough about the inner workings of machinekit to be dangerous... Thank you for responding! I hope I did a better job in this message providing pertinent details. -- website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit --- You received this message because you are subscribed to the Google Groups "Machinekit" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout.
