#linuxcnc-devel | Logs for 2018-11-13
Back
[01:07:06] -!- ve7it has quit [Remote host closed the connection]
[01:32:10] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15c-morley pushed 3 new commits to 06qt5vcp_py2: 02 https://github.com/LinuxCNC/linuxcnc/compare/ae18f7d1874e...542418db1712
[01:32:10] -linuxcnc-github:#linuxcnc-devel- 13linuxcnc/06qt5vcp_py2 14cabba14 15Chris Morley: qtvcp -fix spelling error in keybindings...
[01:32:10] -linuxcnc-github:#linuxcnc-devel- 13linuxcnc/06qt5vcp_py2 140ecfd2c 15Chris Morley: qtvcp -add an icon for versaprobe
[01:32:10] -linuxcnc-github:#linuxcnc-devel- 13linuxcnc/06qt5vcp_py2 14542418d 15Chris Morley: qtvcp -really fix packaging error...
[04:48:50] -!- selroc has joined #linuxcnc-devel
[04:49:36] -!- selroc has quit [Client Quit]
[05:22:33] <rmu> indentation of change_prolog in 5.3 of http://linuxcnc.org is messed up
[05:55:38] -!- jthornton has quit [Quit: Leaving]
[05:56:03] -!- jthornton has joined #linuxcnc-devel
[07:09:14] -!- JT-Shop has quit [Remote host closed the connection]
[07:10:07] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15rene-dev pushed 1 new commit to 062.7: 02 https://github.com/LinuxCNC/linuxcnc/commit/196939cef18ccff18ab72018feaccbbeda14342e
[07:10:07] -linuxcnc-github:#linuxcnc-devel- 13linuxcnc/062.7 14196939c 15Rene Hopf: fix indentation of change_prolog in docs
[07:10:16] -!- JT-Shop has joined #linuxcnc-devel
[10:14:34] -!- dgarr has joined #linuxcnc-devel
[10:16:26] -!- c-log has quit [Ping timeout: 260 seconds]
[10:16:52] <dgarr> rmu: if you're curious, you can look at histograms of hal pins using hal-histogram (sim example at configs/sim/axis/histogram_demo.ini)
[10:18:54] -!- c-log has joined #linuxcnc-devel
[10:42:03] <rmu> dgarr: curious about what?
[10:52:28] <dgarr> statistics of .time pins
[11:03:25] <rmu> the strange thing is there is some periodicity to it
[11:03:57] <rmu> will have to dig in the code where these values are assigned
[11:11:36] <rmu> i'm seeing something close to 10hz modulating the times
[11:26:29] <rene_dev_> Dgarr thanks for your explanation, I get that
[11:26:55] <rene_dev_> but it doesn’t answer my question :D you can do exactly the same with floats
[11:27:34] <rene_dev_> Rmu what is the problem you are having?
[11:28:04] <rene_dev_> dgarr I do the same in the stmbl, the servo never moves on enable
[11:29:49] <rmu> rene_dev_: no real problem, just reevaluating the whole raspberry pi situation ;)
[11:31:44] <rmu> rene_dev_: servo thread execution usually takes around 240-300usec, but this time is modulated with about 10Hz and goes up to 600usec
[11:31:56] <rmu> 700 even
[11:32:07] <rmu> all while idle
[11:32:41] <rmu> classicladder alone takes 100usec which seems excessive
[11:34:01] <rene_dev_> I think each comp has a max time pin
[11:34:10] <rene_dev_> so you can see which one it is
[11:35:36] <rene_dev_> if it is spread across all comps, there is another irq preempting it
[11:36:56] <rmu> there is no tmax pin, but time show last execution time if i'm right
[11:37:13] <rene_dev_> try changing the servo thread period, see if that changes the 10hz
[11:37:17] <rmu> and it spreads, looks like whole core grinds to a halt
[11:38:00] <rmu> no messages about throttling in dmesg, cpu clock governor is performance
[11:38:44] <rmu> other IRQ preempting should not slow down all functs
[11:39:54] <rene_dev_> yes, if the irq fires at a different frequency, and hits a different function every time
[11:40:14] <rmu> i am plotting the time in halscope
[11:40:37] <rmu> so i see each servo period, and the symptom is, a "long" servo period has all functs being slow
[11:42:50] <rene_dev_> could be usb related, the PI doesn’t have a real isb host controller, so a lot of usb stuff is done in software. I recall something about usb irq issues on the pi
[11:43:33] <rmu> no hw irqs fire on that core according to /proc/interrupts
[11:44:50] <rene_dev_> Hmm, ok
[11:44:58] <rmu> https://paste.ubuntu.com
[11:45:11] <rmu> i suspect memory/cache issues
[11:46:41] <rene_dev_> Ah, so it does fire on another cpu. Sounds like a cache/Bus issue
[11:47:16] <rmu> the usb stuff is happening on core 0
[11:49:40] <rmu> will experiment with to other system
[11:51:16] <rene_dev_> Try without usb, but that requires using a serial console
[11:57:51] <rene_dev_> Maybe the rt patch doesn’t patch the usb irq properly?
[12:00:00] <pcw_home> There's definitely something busted with the USB IRQ on RPI (look at it with top...)
[12:02:23] <pcw_home> You see similar behavior on X86 I also think it may be bus contention/memory allocation/cache related
[12:05:24] <pcw_home> 10 hz may be axis GUI update rate
[12:06:47] <pcw_home> on the RPI I see the latency get much worse when you do large GUI ops like moving windows
[12:09:24] <pcw_home> Though I have had the RPI up and running Axis/SPI hardware for about 4 months now with no RT errors so there does seem to be an upper bound to the latency
[12:24:06] <rmu> pcw_home: in this case i was running "headless" with remote-display through ssh
[12:31:01] <rmu> somehow it is strange that execution time varies nearly 3-fold
[12:35:35] -!- ve7it has joined #linuxcnc-devel
[12:38:19] <pcw_home> Yes I've wondered about similar artifacts on X86 (motion command handler on this machine normally takes a < 1 usec but has peaks of ~60 usec)
[12:38:58] <rene_dev_> Keep in mind that ethernet on the pi puts a lot of load on the usb
[12:39:38] <pcw_home> Im not using Ethernet on mine and USB usage is still crazy
[12:40:02] <pcw_home> good portion of CPU servicing USB interrupts
[12:40:43] <pcw_home> I think it maybe related to a quick fix of a USB related crash on Preempt-RT
[12:42:41] <rmu> the real-time core is isolated and should not do anything at all except realtime stuff
[12:43:45] <pcw_home> but the core may have to wait for shared hardware
[12:45:41] <rmu> memory/cache?
[12:46:15] <rmu> does the realtime stuff call any syscalls?
[12:47:01] <rmu> logging/debug stuff? perhaps it is a kernel issue
[12:55:18] <pcw_home> Not sure, I do know cache size does have an effect
[12:56:06] <pcw_home> http://freeby.mesanet.com motion command handler very peaky latency
[12:57:32] <pcw_home> err time not latency
[13:22:00] <rene_dev_> rmu pcw_home I guess the usb IP and some other stuff share the bus, so the cpu has to wait
[13:22:38] <rene_dev_> for the stm32 there is a bus matrix, where you can see which busses are connected to what
[13:22:53] <rene_dev_> there is some way to see such a block in linux, but cant remember how
[13:23:49] <rene_dev_> the real problem is that the synopsis otc core is really really stupid, so what a normal host controller does in hardware, all has to happen in the driver
[13:23:53] <rene_dev_> otg
[13:24:00] <rene_dev_> in fact, its the same core as on the stm32 ;D
[13:24:26] <rmu> found out something: i used nohz_full=3, that means that the isolated realtime core receives no scheduler ticks
[13:24:59] <rmu> but that seems to change RCU behaviour and may have effects on syscalls
[13:25:36] <rmu> without that parameter it looks a little bit less insane
[13:50:45] <pcw_home> That's my experience also (on X86) nohz seems to worsen latency vs periodic tics
[14:09:46] <rene_dev_> rmu did you ever test the stmbl?
[14:15:03] -!- dgarr has quit [Ping timeout: 245 seconds]
[14:24:56] <rmu> rene_dev_: not yet
[14:25:32] <rmu> rene_dev_: more pressing stuff interrupted
[14:25:43] <rene_dev_> yeah, same here :(
[14:26:52] <rmu> i need to get that damn toolchanger going
[14:27:32] <rene_dev_> are you also desperatly waiting for my pocket number fix? :O
[14:28:59] <rmu> hehe, yes, among other stuff
[14:29:27] <rmu> the PLC stuff is insane
[14:30:10] <rmu> the manual toolchange button is not easy to integrate with the automatic stuff
[14:30:35] <rene_dev_> what plc?
[14:30:50] <rmu> the integrated classicladder ;)
[14:31:05] <rene_dev_> I never used classicladder
[14:31:29] <rmu> i also have some prehistoric "siemens" s200 lying around but i shoot something befor i use them
[14:31:55] <rmu> that was probably not a proper english sentence ;)
[14:32:28] <rmu> the whole concept is insane if you have more than 10 rungs
[14:33:53] <rmu> the classicladder editor has some warts
[14:35:02] <rmu> and the file it generates is not for human consumption, non-graphical maintenance of ladder diagrams is not possible
[14:38:17] <rene_dev_> I just code whatever I need in c as a comp
[14:42:39] <rmu> https://unfoo.net
[14:42:52] <rmu> yeah, will do that
[14:43:14] <rmu> more patterns ;)
[14:44:18] <rmu> this is with a 2khz servo period and no "real" hardware (except 7i90) on a rpi3b (without +)
[14:46:11] <rmu> oh forget that picture that was "ondemand" governor
[14:56:32] <pcw_mesa> A behavior that suggests some of the latency issues are caching related is that the average latency decreases with thread period
[15:01:50] <jepler> oh yes if the CPU frequency is changing that sure could explain the parts that look downright bimodal
[15:02:29] <jepler> I think classicladder is by default set up so that it doesn't recalculate every servo cycle, but I'm not convinced this helps in general (putting it on a different thread might, since the faster threads could preempt it then)
[15:10:30] <rmu> classicladder seems to update with 1khz even if called with 2 or 4 khz
[15:37:30] -!- KimK has quit [Ping timeout: 252 seconds]
[15:43:49] -!- andypugh has joined #linuxcnc-devel
[15:47:41] -!- KimK has joined #linuxcnc-devel
[16:08:33] -!- c-log has quit [Ping timeout: 252 seconds]
[16:10:05] -!- c-log has joined #linuxcnc-devel
[17:17:04] -!- ve7it has quit [Remote host closed the connection]
[17:19:01] -!- ve7it has joined #linuxcnc-devel
[17:27:17] -!- mozmck has quit [Quit: Leaving.]
[17:32:19] -!- mozmck has joined #linuxcnc-devel
[17:35:02] -!- ve7it has quit [Remote host closed the connection]
[17:40:53] <CMorley> rmu: You are right, comment from module_hal from classicladder:
[17:40:57] <CMorley> // This actually does the magic of periodic refresh of pins and
[17:40:58] <CMorley> // calculations. This function runs at the period rate of the thread
[17:40:58] <CMorley> // that you added it to.
[17:40:58] <CMorley> // period, leftover, t0,and t1 are in nanoseconds.
[17:40:58] <CMorley> // This function first checks to see if at least 1 millisecond has gone by
[17:40:58] <CMorley> // if the period is under 1 MS then if will not refresh rungs yet but
[17:40:58] <CMorley> // will keep track of how many NS were left over. Does this each period
[17:40:59] <CMorley> // till at least 1 MS has occurred, if more then 1 MS then keeps track of
[17:40:59] <CMorley> // leftover NS for accuracy. Bottom line is you can run classiclader in
[17:41:00] <CMorley> // a thread faster than 1 millisecond but it will not refresh the rungs
[17:41:00] <CMorley> // any faster (it can be slower though). If your refresh is too slow and
[17:41:01] <CMorley> // your timer are using multiples of 100 microseconds they might not be accurate.
[17:41:01] <CMorley> // t0 and t1 are for keeping track of how long the refresh of sections,
[17:41:02] <CMorley> // and HAL pins take (it is displayed in the 'section display' GUI (in microseconds).
[17:47:44] -!- ve7it has joined #linuxcnc-devel
[18:00:51] <mozmck> I don't normally run the runtests, but did just now and got a number of seg faults running halrun - is that normal on a machine with no realtime kernel?
[18:02:16] <mozmck> bbl
[18:11:17] <jepler> mozmck: no that's not normal, assuming you have a uspace build.
[18:54:04] -!- ve7it has quit [Remote host closed the connection]
[18:55:22] -!- ve7it has joined #linuxcnc-devel
[19:00:33] <mozmck> jepler: yes, it's uspace. I'm running it on master and getting lots of failures. This is a rip build, but I also have linuxcnc 2.7 installed from packages. I'm running on linuxmint 17.3
[19:00:51] <mozmck> Do you think having the packages installed could be causing problems?
[19:03:57] <seb_kuzminsky> nah that shouldn't be a problem
[19:05:52] <mozmck> Well, I'm probably not doing something right then
[19:10:55] <seb_kuzminsky> i've never tried to run linuxcnc on mint 17.3
[19:11:52] <mozmck> I've run it on that and xubuntu 14.04 a *lot*
[19:12:08] <mozmck> But I don't normally run the runtests
[19:13:20] <seb_kuzminsky> i'm surprised linuxcnc runs fine, but the tests segfault
[19:13:51] <mozmck> Here is one error from ccomp/early-exit: + linuxcnc -r test.ini
[19:13:51] <mozmck> can't find package Linuxcnc
[19:13:51] <mozmck> while executing
[19:13:51] <mozmck> "package require Linuxcnc "
[19:14:00] <seb_kuzminsky> is it the packaged 2.7 that works, and rip master that fails? try running the tests on rip 2.7?
[19:14:15] <mozmck> I should try that.
[19:14:20] <seb_kuzminsky> hmm, did you remember to run rip-environment in the shell where you run runtests?
[19:14:49] <mozmck> I uninstalled the packaged 2.7 and the master runtests are still failing - some of them. Anywhere from 20 to 64 each time.
[19:14:52] <mozmck> yes.
[19:14:58] <seb_kuzminsky> well that's odd
[19:15:38] <mozmck> That's what I be thinking!
[19:15:42] <seb_kuzminsky> "package require Linuxcnc" is a tcl thing
[19:15:54] <seb_kuzminsky> do you have all the tcl stuff installed? (as indicated by dpkg-checkbuilddeps)
[19:16:05] <seb_kuzminsky> did you configure & build for the tcl version that's installed?
[19:16:30] <mozmck> I'm sure I did.
[19:16:58] <mozmck> make clean; ./configure --with-realtime=uspace; make -j8; etc...
[19:17:22] <seb_kuzminsky> try:
[19:17:26] <seb_kuzminsky> git clean -fdx ..
[19:17:33] <seb_kuzminsky> ./autogen.sh
[19:17:36] <seb_kuzminsky> then what you said
[19:17:43] <seb_kuzminsky> err
[19:17:53] <seb_kuzminsky> only run git clean if you don't have anything you care about in your repo
[19:17:59] <seb_kuzminsky> anything uncommitted, that is
[19:18:20] <mozmck> hmm, I'll check that.
[19:18:38] <mozmck> I did ./autogen.sh once at least
[19:26:53] <mozmck> strange - that did not help. I can't run linuxcnc either - and I did it just the other day with master
[19:27:11] <mozmck> dpkg-checkbuilddeps: error: cannot read debian/control: No such file or directory
[19:29:45] <seb_kuzminsky> cd debian; ./configure uspace; cd ..
[19:30:39] <mozmck> oh - duh! git clean wiped that out didn't it
[19:31:16] <mozmck> yeah, builddeps are all met - I did that the other day
[19:32:14] <mozmck> ok, I just built and ran it in another directory - I wonder if the problem is the directory this repo is in
[19:32:54] <seb_kuzminsky> did it work?
[19:33:12] <seb_kuzminsky> after the git clean and the total rebuild?
[19:33:22] <mozmck> I have a repo in another directory and it works there.
[19:33:38] <mozmck> Did not work in the one I was using after the git clean and total rebuild though.
[19:33:59] <seb_kuzminsky> different commits? uncommitted changes somewhere?
[19:34:12] <mozmck> Nope, both tip of master
[19:34:31] <mozmck> I have to go eat - I'll look at this more later. Seems really odd.
[19:34:52] <seb_kuzminsky> yeah, something's unusual about that
[19:34:56] <seb_kuzminsky> ok, talk to you later
[19:35:38] -!- andypugh has quit [Quit: andypugh]
[20:05:13] <mozmck> seb_kuzminsky: is there a way to clean better than make clean but maybe not as thorough as git clean -fdx?
[20:13:38] <rene_dev_> seb_kuzminsky whats #5400 or #_current_tool on startup?
[20:14:00] <rene_dev_> I know what it is, but Im looking for documentation backing that up.
[20:27:56] <mozmck> I wonder if it could be memory errors on my computer? here is another error from near.0: rtapi_shmem_new failed due to shmget(key=0x48535430): Invalid argument
[20:31:33] -!- mozmck has quit [Quit: Leaving.]
[20:33:04] -!- mozmck has joined #linuxcnc-devel
[20:59:10] <mozmck> hmm, 2.7 runtests all ran without errors
[21:03:16] <mozmck> I did find that my ulimit was only 64, and I increased that to 20480
[21:10:40] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15dngarrett 04deleted 06dgarr/multispindle_linuxcnctop at 14e1cffd4: 02 https://github.com/LinuxCNC/linuxcnc/commit/e1cffd4
[21:10:48] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15dngarrett pushed 4 new commits to 06master: 02 https://github.com/LinuxCNC/linuxcnc/compare/cb3d4b414f00...7626740fe91d
[21:10:48] -linuxcnc-github:#linuxcnc-devel- 13linuxcnc/06master 14715d224 15Dewey Garrett: sim_spindle_encoder: remove debug spindle print
[21:10:48] -linuxcnc-github:#linuxcnc-devel- 13linuxcnc/06master 143291d57 15Dewey Garrett: multispindle: linuxcnctop update
[21:10:48] -linuxcnc-github:#linuxcnc-devel- 13linuxcnc/06master 14a579092 15Dewey Garrett: linuxcnc_info support getopts options...
[23:03:27] -!- rmu has quit [Ping timeout: 240 seconds]
[23:16:01] -!- rmu has joined #linuxcnc-devel
[23:46:22] -!- Roguish has quit [Quit: ChatZilla 0.9.92-rdmsoft [XULRunner 35.0.1/20150122214805]]