Re: [Machinekit] Motion stuttering in in the beginning of a large NGC file.

[schoone...@btinternet.com]

On 21/07/17 18:46, Seth Pierson wrote: 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. OK, the bit that hit me immediately was following errors which go when you reduce velocity, albeit still don't know what figures you are using. I am running a machinekit on a BBB using the PRU for the stepgen and mkwrapper for the gui (QTQuickVCP). Afraid I cannot even try to replicate, I don't use any of those. 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. Jul 21 16:51:12 beaglebone rtapi:0: 4:rtapi_app:3423:user 89062578: CMD 9727, code  29 will be coming from https://github.com/machinekit/machinekit/blob/master/src/emc/motion/command.c#L435 Jul 21 16:51:12 beaglebone rtapi:0: 4:rtapi_app:3423:user SET_LINE will be coming from: https://github.com/machinekit/machinekit/blob/master/src/emc/motion/command.c#L915 but they are DBG level messages, so should not be emitted routinely unless debugging is set. All I get in /var/log/syslog, from restarting the daemon, running a sim and running the 'Machinekit' sample .ngc program is ``` Jul 22 11:50:22 INTEL-i7 systemd[1]: Started Daemon for generating UUIDs. Jul 22 11:50:22 INTEL-i7 msgd:0: startup pid=2861 flavor=posix rtlevel=1 usrlevel=1 halsize=524288 shm=Posix cc=gcc 6.3.0 20170516  version=unknown Jul 22 11:50:22 INTEL-i7 msgd:0: ØMQ=4.0.5 czmq=2.2.0 protobuf=3.0.0 atomics=gcc intrinsics    libwebsockets=2.0.3 Jul 22 11:50:22 INTEL-i7 msgd:0: configured: sha=86bb58c08 Jul 22 11:50:22 INTEL-i7 msgd:0: built:      Jul 20 2017 14:36:01 sha=86bb58c08 Jul 22 11:50:22 INTEL-i7 msgd:0: register_stuff: actual hostname as announced by avahi='INTEL-i7.local' Jul 22 11:50:22 INTEL-i7 msgd:0: zeroconf: registering: 'Log service on INTEL-i7.local pid 2861' Jul 22 11:50:22 INTEL-i7 msgd:0: zeroconf: registered 'Log service on INTEL-i7.local pid 2861' _machinekit._tcp 0 TXT "uuid=a42c8c6b-4025-4f83-ba28-dad21114744a" "instance=8f52ff5a-6ecb-11e7-9fb8-c04a0002bfd1" " Jul 22 12:00:19 INTEL-i7 rtapi:0: unload: '' not loaded Jul 22 12:00:19 INTEL-i7 rtapi:0: unload: '' not loaded Jul 22 12:00:19 INTEL-i7 rtapi:0: unload: '' not loaded Jul 22 12:00:19 INTEL-i7 rtapi:0: unload: '' not loaded Jul 22 12:00:19 INTEL-i7 rtapi:0: unload: '' not loaded Jul 22 12:00:19 INTEL-i7 rtapi:0: unload: '' not loaded Jul 22 12:00:19 INTEL-i7 rtapi:0: unload: '' not loaded Jul 22 12:00:19 INTEL-i7 rtapi:0: unload: '' not loaded Jul 22 12:00:19 INTEL-i7 rtapi:0: unload: '' not loaded Jul 22 12:00:19 INTEL-i7 rtapi:0: unload: '' not loaded Jul 22 12:00:19 INTEL-i7 rtapi:0: unload: 'comp' not loaded Jul 22 12:00:19 INTEL-i7 msgd:0: rtapi_app exit detected - scheduled shutdown Jul 22 12:00:21 INTEL-i7 msgd:0: msgd shutting down Jul 22 12:00:21 INTEL-i7 msgd:0: zeroconf: unregistering 'Log service on INTEL-i7.local pid 2861' Jul 22 12:00:21 INTEL-i7 msgd:0: log buffer hwm: 0% (0 msgs, 0 bytes out of 524288) Jul 22 12:00:21 INTEL-i7 msgd:0: normal shutdown - global segment detached ``` My rtapi.ini is set to DEBUG=1 The debug level in the actual config axis_mm.ini file, is set to 0 If you cannot stop them with DEBUG level, then try disabling logging and see what happens systemctl disable rsyslog That might give an idea if the puny processing power of the BBB is being overrun by logging stuff, whilst trying to read forward and process the gcode at the same time. The other possibility is to cut the log burst rate in /etc/rsyslog.d/linuxcnc.conf so it drops entries above a conservative rate or just rename linuxcnc.log and syslog (rsyslog will certainly not create a new one is it does not exist) that cancels out all logging on my system when running machinekit 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 machinekit+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout. -- 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 machinekit+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout.