#linuxcnc-devel Logs

Jul 26 2018

12:02 AM pcw_home: going to try le potato and rock64 RPI clones also but a bit more trouble
12:11 AM hazzy-lab: pcw_home: man, it would be awesome to have an easy to set up single board computer option!
12:18 AM pcw_home: yeah a lot of things could be preset with a few default configs (and only adjustments are tweaking for more performance if the mechanics/drives can do it)
03:46 AM rmu: regarding OpenGL: anybody thought about using a toolkit like OpenInventor?
03:47 AM rmu: https://wiki.qt.io/Using_3D_engines_with_Qt
11:12 AM skunkworks: these stmbl amps are really well thought out. quite amazint
11:12 AM skunkworks: amazing
11:36 AM hazzy-lab: rmu: TurBoss experimented with a VTK based backplot a while back, it had poor performance even with small programs, but it looked nice! Might be worth investigating some of the other toolkits
11:49 AM rmu: freecad uses coin3d, openinventor api, performance can't be that poor
11:49 AM rmu: perhaps with 100km of toolpath it gets slow
01:30 PM jepler: Because I selected Python+Tk when I created AXIS, there weren't a whoe lot of choices for how to do 3D -- and even worse, the one I picked, PyOpenGL was buggy in the first Ubuntu we ever tried to run on just didn't work, and that's how we got "minigl" instead of a proper, high quality OpenGL wrapper
01:31 PM jepler: AXIS/Gremlin's needs are so modest it feels like a toolkit is overkill, it just needs to be aligned with current OpenGL standards
01:34 PM pcw_mesa: Good news and bad news: Enabling OpenGL on the RPI solves the slow gremlin issue but makes latency bad enough that 1 K servo thread wont work (500 Hz seems ok though)
01:36 PM pcw_mesa: overhead of running with a dense backplot went from 200% CPU to 13%
01:37 PM pcw_mesa: (and glxgears runs correctly, faster and no blinking)
01:37 PM hazzy-lab: pcw_mesa: 500Hz would probably be ok, right?
01:38 PM pcw_mesa: If you dont have very high accel it should be OK
01:39 PM pcw_mesa: Or I need to add accel to the hm2 stepgen
01:40 PM hazzy-lab: Probably be fine with the type of machines the the Pi would normally be used with
01:44 PM rmu: pcw_mesa: i have no issues with 1khz servo thread and opengl enabled
01:45 PM rmu: pcw_mesa: probably even 2khz could work
01:47 PM pcw_mesa: As soon as I enable openGL I get real time errors at 1 KHz
01:48 PM rmu: i must admit, i get exactly 2 realtime excursions each time i start gmoccapy
01:48 PM rmu: but only at startup
01:48 PM pcw_mesa: but this is with no isolcpus (which made little difference without OpenGL)
01:49 PM rmu: i have isolcpus and run all realtime stuff on core 3
01:50 PM pcw_mesa: let me try isolcpus again, it may help with the OpenGL issue
01:57 PM pcw_mesa: no, still wont run at 1 KHz
02:00 PM rmu: i have to use "export RTAPI_CPU_NUMBER=3" to actually get linuxcnc to bind to the isolated core
02:02 PM pcw_mesa: where is that? just shell environment?
02:02 PM rmu: yes, shell environment where i start linuxcnc
02:04 PM pcw_mesa: made no difference here :-(
02:07 PM rmu: strange
02:14 PM hazzy-lab: Ok, question/observation about probed position parameters (5061-5069):
02:14 PM hazzy-lab: The docs do not say what the probed positions are relative too, but it seems they are relative to the current WCS.
02:14 PM hazzy-lab: (another thing for me to clarify in the docs :-) )
02:14 PM pcw_mesa: yeah servo thread tmax is about 1.2 ms with OpenGL
02:14 PM hazzy-lab: (Also, This is not consistent with the values returned by `stat.probed_position` which returns the ABS position at which the probe tripped ...)
02:15 PM hazzy-lab: Since one of the main uses of probing is to set a WCO, why are the probed possession relative to the current WCS, instead of ABS pos?
02:15 PM hazzy-lab: For example, if the probed pos was ABS it would be easy to set the current Z WCO to the probed pos with "G10 L2 P0 Z[#5063]"
02:16 PM hazzy-lab: But since it is not you have to do some calculations to convert the probes pos to ABS pos
02:16 PM pcw_mesa: there's also a weirdness with RPI timing ( all times seem to be ns rather than CPU clocks as expected)
02:16 PM rmu: what times?
02:17 PM hazzy-lab: It would be really nice to be able to probe in the machine coord system, would be be possible to enable doing something like G53 G38.2 Z-2?
02:17 PM pcw_mesa: things like motion servo-thread time
02:18 PM pcw_mesa: servo-last-period I mean
02:19 PM rmu: I'm not near the machine at the moment, but latency-histogram --nobase outputs "min(us) -12, max(us) 13.3 sdev(us): 0.8" over some very slow ssh -X connection
02:21 PM rmu: cat /proc/cmdline:
02:21 PM rmu: 8250.nr_uarts=0 bcm2708_fb.fbwidth=1600 bcm2708_fb.fbheight=900 bcm2708_fb.fbswap=1 vc_mem.mem_base=0x3dc00000 vc_mem.mem_size=0x3f000000 sdhci_bcm2708.enable_llm=0 dwc_otg.lpm_enable=0 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait isolcpus=3 nohz_full=3
02:22 PM rmu: nohz could be relevant
02:22 PM pcw_mesa: I'm using that cmdline
02:23 PM pcw_mesa: well with added idle=poll
02:25 PM rmu: hmm. running some opengl stuff increases worst case latencies to +-100us
02:32 PM rmu: cat /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
02:32 PM rmu: performance
02:33 PM rmu: seems i have to prepare an image ;-)
03:02 PM pcw_mesa: yeah already have the CPU running at a constant 1.2 GHz and scaling policy is performance
03:03 PM rmu: can you verify that linuxcnc really is bound to cpu3?
03:04 PM rmu: taskset -p <pid>
03:09 PM rmu: pcw_mesa: perhaps SPI transfers take too much time? then again that should not depend on opengl
03:57 PM pcw_mesa: Let me try the taskset thing
04:00 PM pcw_mesa: shows mask of 7
04:07 PM pcw_mesa: minimum servo thread time is in the 70 usec region so SPI time must be less than that
04:09 PM jepler: hmm how does taskset behave when you are running it on a multhreaded program? Only the individual hal threads are bound with pthread_attr_setaffinity_np to the realtime CPU
04:09 PM jepler: the main thread of the program, which is not realtime, is left to run on the others
04:09 PM jepler: so I think what you're seeing from taskset is that the main process in rtapi_app is running in CPUs 0-2
04:15 PM jepler: at least, I hope that's it
04:19 PM jepler: http://paste.debian.net/1035325 is what I get on a desktop x86 system. The first thread is the main thread, the second thread has to do with printing log messages, and the third is the realtime one
04:19 PM jepler: no isolcpus on this machine though
04:22 PM rmu: the pi with isolcpus says affinity mask 7 for the first two threads and 8 for the last
04:23 PM jepler: OK, that seems rightOK, that's what I would hope for
04:23 PM jepler: oops
04:23 PM jepler: that seems right
04:23 PM rmu: seems right
04:23 PM jepler: I was "emulating" isolcpus by 'taskset 0x7 halrun' and then was surprised to see the middle task get mask 0xf .. I don't know why that would be.
04:24 PM pcw_mesa: how did you get the 8?
04:24 PM jepler: there's no pthread_attr_setafinity_np call for that task's creation so I would have expected it to inherit the main task's mask
04:24 PM jepler: pcw_mesa: 'ps -C rtapi_app H -L' will show you the 'lwp' of each of rtapi_app's threads. Those numbers can be given to taskset's pid argument
04:26 PM rmu: hehe... i found out i'm cheating because something didn't work obviously as it is supposed to... and didn't file bug report
04:26 PM rmu: http://paste.debian.net/1035326/
04:29 PM jepler: it is interesting that you found you needed that. you should also be able to set RTAPI_CPU_NUMBER in the environment fwiw
04:30 PM rmu: perhaps it is leftover from experiments
04:37 PM pcw_mesa: Yeah that doesn't seem to make any difference
04:39 PM rmu: i'm out of ideas
04:39 PM pcw_mesa: and taskset here also shows 7 for the first two thread and 8 for the last
04:39 PM pcw_mesa: Do you have a Pi 3B or B+? (grasping at straws)
04:40 PM rmu: i'm running on the original pi 3
04:41 PM rmu: pi 3 B
04:43 PM pcw_mesa: so fairly mysterious, base OS related?
04:44 PM rmu: raspbian 8, fairly up to date
04:47 PM rmu: oh, so i'm running jessie... perhaps thats the difference?
04:48 PM pcw_mesa: Yeah I think this is Stretch
04:50 PM rmu: i will try to setup a stretch system tomorrow and try again, perhaps the newer opengl libs in stretch introduce additional latency
04:57 PM pcw_mesa: possibly...
04:59 PM rmu: the other possibility is that i don't really have opengl enabled... glxgears runs at 170fps, with the vc4 driver it should sync to monitor refresh rate, 60hz
05:00 PM rmu: but GL driver in raspi-config says GL (Full KMS)
05:02 PM rmu: X11 log says "AIGLX: reverting to software rendering"
05:04 PM jepler: what's glxinfo say?
05:05 PM jepler: specifically the "OpenGL renderer string" l,ine
05:06 PM rmu: OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.9, 128 bits)
05:07 PM jepler: I'm pretty sure that indicates software
05:09 PM rmu: dtoverlay=vc4-kms-v3d was commented in /boot/config.txt
05:09 PM rmu: so no hardware opengl
05:24 PM rmu: "full KMS" doesnt work for some reason, with "fake KMS" and running 6 glxgears i get worst case latency of about 200, std-dev 9. definitely worse than software rendering.