#linuxcnc-devel Logs

Apr 20 2017

08:15 AM jepler: can linuxcnc do this? https://assets.octodon.social/media_attachments/files/000/059/706/original/983fd8c6b933b816.mp4?1492639607 (better watched on loop, which may be available in your browser via right clickc
08:16 AM jepler: )
08:25 AM JT-Shop: :)
08:48 AM jepler: power cycling forum
08:50 AM skunkworks: I saw the lights flicker..
08:51 AM skunkworks: seems to be up here
08:57 AM jepler: sigh the answer is "not surprised if that crashes", not "we'll fix it right away111111" (rtai hard lock)
09:13 AM * skunkworks hugs uspace..
09:14 AM skunkworks: is xiaomi in the same boat?
09:42 AM jepler: xenomai? no idea.
09:44 AM jepler: but yeah I should look
09:51 AM skunkworks: I thought google corrected the spelling for me ;)
10:56 AM seb_kuzminsky: memleak, CaptHindsight, is that rtai bug something y'all would be interested in looking at?
11:18 AM jepler: I should also test whether setfsuid() has the same problem or not
11:19 AM jepler: I transitioned from setfsuid() to seteuid() [which calls setresuid()] for portability sake but one source says that setfsuid() is per-thread which if accurate would mean it probably isn't affected by the same underlying problem
11:42 AM pcw_home: Don't know if this is related, but unfortunately the permission fix on master that allows HALScope
11:42 AM pcw_home: to run on Ubuntu16.04/Mint18 causes real time issues with uspace (real time error when HALScope is launched)
11:44 AM jepler: yes it may be related
11:45 AM jepler: it *looks like* (high level view) the linux kernel stops all the threads in the process, applies the new permissions chosen by setresuid(), and then restarts them all
11:45 AM jepler: which .. yuck
11:54 AM pcw_home: ooh.. not good
11:59 AM skunkworks: pcw_home, stepgen max_acceleration is active in both velocity mode and position - right?
11:59 AM pcw_home: Yes
12:00 PM skunkworks: great
12:59 PM CaptHindsight: seb_kuzminsky: what problem?
01:00 PM CaptHindsight: problem/bug
01:02 PM CaptHindsight: seb_kuzminsky: the hard lock mentioned here ~14 hours ago?
01:10 PM cradek: CaptHindsight: http://mail.rtai.org/pipermail/rtai/2017-April/027437.html
01:14 PM pcw_mesa_ is now known as pcw_mesa
01:49 PM CaptHindsight: I'll ask memleak later when I see him but my understanding is that it is too much work to build RTAI and kernels the way it's being done here and at RTAI.org and then debug problems that arise. It's just too much effort and frustration.
01:51 PM CaptHindsight: I heard him say something about too many mismatched sources and tool chain
01:56 PM cradek: if I understand right, the bug is in every version of rtai
01:56 PM cradek: so if you build jepler's test program (1 small file) with any compiler you'll see the bug
01:57 PM cradek: I really sympathize with how hard collaboration gets when different people are maintaining divergent trees, but I don't think that's a problem in this particular case
01:58 PM CaptHindsight: not sure, I'll see what he says
01:58 PM cradek: cool
01:59 PM CaptHindsight: my preference is to have everything hardware and do away with all this software nonsense :)
02:02 PM cradek: "My favorite programming language is solder" (bob pease)
02:11 PM CaptHindsight: I miss reading his articles
02:11 PM CaptHindsight: I came across an archive at EDN recently and reread many
02:48 PM memfrob: Are you getting those hardlocks on the new RTAI 5 stuff or the tree Shabby and I worked on? Every hardlock I saw, photos and all, had Paolo's new calibration code in use, which is all stuff I never worked on.
02:49 PM memfrob: If it happens on every kernel version, does it also happen with both RTAI versions?
02:50 PM cradek: memfrob: can you try the test program on whatever rtai/kernel you think is the best?
02:50 PM memfrob: the histogram?
02:50 PM cradek: no, the short program that shows the bug
02:51 PM cradek: wait lemme find you the link
02:51 PM memfrob: Thanks!
02:51 PM cradek: http://mail.rtai.org/pipermail/rtai/2017-April/027437.html
02:53 PM memfrob: Uh.. "rtai 5.0~test2.2016.05.12.37.g1d358aa from seb's git except we
02:53 PM memfrob: rebased it or something" "ref doesn't seem to exist anymore" "probably similar to our ref a844a0751b11f" >_>
02:54 PM cradek: yeah the bugreport is fairly imperfect, but it sounds like every rtai is affected and it's easy to reproduce
02:54 PM memfrob: Just throwing this out there, I highly suggest knowing exactly what RTAI you're using. I'll try my custom system though with a gentoo build and see if I get it with my custom kernel that nobody else is using.
02:55 PM cradek: sweet
02:55 PM memfrob: I haven't had any issues on the work I do myself so I'll be shocked if I get any hard locks. Maybe you finally found a bug in my software.
02:56 PM memfrob: So this has to do with process UID switching while a RT thread is running?
02:58 PM cradek: did you see the next message in the thread? it has an exact kernel/rtai version where it also reproduces
03:00 PM memfrob: "rtai-modules-4.1.0-1" is that RTAI 4.1 or RTAI 5 compiled for kernel 4.1 ?
03:01 PM cradek: 5.0~... is the version number for rtai-modules, so I assume the latter
03:02 PM cradek: 4.1.18... is the version of the kernel
03:02 PM cradek: it's hard to see in italics but there's spaces in both lines
03:03 PM memfrob: And the underlying suspected cause so I understand correctly is something to do with a UID changing?
03:03 PM cradek: euid, yes
03:04 PM memfrob: does it matter which EUID changes after an RT thread has been started? i.e. firefox
03:04 PM cradek: I don't know anything about it that you don't, I've also just looked at the test program's code
03:05 PM memfrob: Alright, I'll give it a run xD
03:05 PM cradek: sweet thanks
03:57 PM andypugh: jepler: That robot / train thing is reminscent of: https://en.wikipedia.org/wiki/Iron_Council
04:02 PM seb_kuzminsky: the versions jepler talks about here: http://mail.rtai.org/pipermail/rtai/2017-April/027438.html
04:02 PM jepler: I haven't read that one. I really dug The City & the City but struggled through Railsea ..
04:03 PM seb_kuzminsky: are linux 4.1.18 and rtai 5.0~test2 with cvs updated on 2017 April 12
04:03 PM seb_kuzminsky: the bug also affects the old rtai 3.9 kernel from the shabbyx repo
04:04 PM jepler: oh and I think I read Kraken too
04:06 PM seb_kuzminsky: the version before that, rtai 5.0~test2.2016.05.12.37.g1d358aa, was a local build that I never pushed, it was probably some failed debug commits on top of this branch: https://github.com/SebKuzminsky/rtai/tree/vulcano-debs-2016-05-12
04:23 PM memfrob: where's that script again? I switched OSes and lost the link.
04:24 PM jepler: http://mail.rtai.org/pipermail/rtai/2017-April/027437.html
04:25 PM memfrob: also latency-test requires me to insmod RTAI manually and latency-histogram won't even work. I insmod rtai_*.ko by hand then it says to run halrun -U (which doesn't actually unload RTAI btw) so I get the same error again telling me to halrun -U until I rmmod rtai_*.ko by hand
04:25 PM memfrob: latency-histogram latency-test and halrun both fail to load and unload RTAI but latency-test I can at least get going if I insmod in advance.
04:26 PM memfrob: s/both/all/
04:27 PM memfrob: -DNO_KABOOM I like that!
04:46 PM seb_kuzminsky: memfrob: something's wrong, all three of those run fine here for me with no manual loading or unloading of modules
04:47 PM memfrob: I know something is wrong, I've never seen that happen before.
04:47 PM memfrob: Also RTAI 4 needs the definition for rt_free_timers as well.
04:48 PM memfrob: rtai_rtapi.c -> #if RTAI <= 3 -> #if RTAI <= 4
04:51 PM seb_kuzminsky: we never shipped or tested on rtai 4, as far as i know
04:51 PM seb_kuzminsky: so i'm not surprised that slipped through the cracks
04:51 PM seb_kuzminsky: can you make a PR on github?
04:51 PM memfrob: Heh!! And that's the only tree I ever use!
04:52 PM memfrob: Yeah sure thing xD
04:52 PM memfrob: That 3.4.55 kernel btw is meant to be used with RTAI 4
04:53 PM seb_kuzminsky: the one we ship on wheezy?
04:53 PM memfrob: Whatever one you ship 3.4.55 with
04:55 PM memfrob: Why is kernel 3.4.55 rebranded as 3.4.9 btw?
04:56 PM memfrob: Debian's versioning system always confused me.
04:56 PM CaptHindsight: 3.4.9 = 3.4.55 is the latest I see on the just updated Wheezy system here
04:56 PM memfrob: i.e. kernel 4.9.0 can actually be 4.9.23
04:57 PM seb_kuzminsky: that kernel uses the rtai kernel patch from commit a0dc5355ee23303292 in shabby's rtai repo (i think that commit was lost in some cleanup, but it's in my rtai repo still)
04:57 PM seb_kuzminsky: the configure.in in that commit says: AC_INIT([RTAI], [3.9.1-unofficial], [rtai@rtai.org])
04:57 PM seb_kuzminsky: that's what the matching rtai-modules deb is built from
04:57 PM memfrob: Oh wow so it was 3.9.1 my mistake.
04:58 PM seb_kuzminsky: CaptHindsight: nitpick, it's actually "3.4-9", not "3.4.9". The "-9" indicates the 9th ABI-break in the 3.4 kernel packaging
04:58 PM seb_kuzminsky: the debian folks do have complicated version numbers, but i think it's for a good reason - to encode all the stuff they need to keep track of
04:59 PM memfrob: so it's not just me.
04:59 PM seb_kuzminsky: yeah :-)
04:59 PM seb_kuzminsky: it turns out, all this stuff is complicated and difficult to get right :-)
04:59 PM CaptHindsight: heh, why I solder things. I forget the digits after walking a few steps from the other monitor :)
05:05 PM seb_kuzminsky: thanks memfrob
05:05 PM memfrob: np ;)
05:09 PM KGB-linuxcnc: 03Alec Ari 05memfrob-pr264 389885e 06linuxcnc 10src/rtapi/rtai_rtapi.c rtapi: rt_free_timers definition is needed for RTAI 4 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=389885e
05:10 PM seb_kuzminsky: i'll let the buildbot chew on it, and merge it tonight if it passes (which i bet it will)
05:11 PM memfrob: Any suggestions on fixing this mod load/unload issue?
05:12 PM memfrob: debugging at least
05:13 PM seb_kuzminsky: hmm
05:13 PM seb_kuzminsky: well the script called 'realtime' is supposed to do the module loading
05:13 PM seb_kuzminsky: it's in scripts/, made by configure from realtime.in
05:14 PM memfrob: I'll run that standalone and see what happens.
05:15 PM seb_kuzminsky: it gets its list of modules from scripts/rtapi.conf, built by configure from rtapi.conf.in
05:15 PM seb_kuzminsky: if the problem is that some module fails to load, you might get debugging output in dmesg
05:16 PM memfrob: anything else I should I check on before I reboot? I've got all security features disabled on my RTAI kernel so I removed the ethernet adapter from it.
05:16 PM seb_kuzminsky: i can't think of anything
05:16 PM memfrob: wanted to make sure any kind of stall wouldn't be related to r8169 or whatever. keepin it simple for now. alright be back in a bit
05:49 PM memfrob: well scripts/realtime doesn't have any rtai modules in it.
05:49 PM memfrob: MODULES_LOAD and _UNLOAD are empty.
05:53 PM memfrob: threadtest.cc stalls on this screwed up debian system btw with my RTAI stuff with rtai_sched.ko loaded
05:54 PM memfrob: with just rtai_hal.ko it's fine, but congrats on figuring out a way to break it!
05:54 PM memfrob: I had to compile it without -llxrt though, said it couldn't find liblxrt.so.1
05:56 PM memfrob: I know systemd is a big kludge when it comes to handling processes and such, I wonder if I'll get a different result with a sysvinit system.
06:25 PM seb_kuzminsky: probably not, the problem happens in a system call
06:26 PM seb_kuzminsky: so inside the kernel
06:57 PM andypugh: What is a decent text-editor for Wheezy? Mousepad only seems to open one file at a time, and doesn’t do syntax highlighting. Gedit needs you to install all of Gnome(?) so is about 10GB…
07:06 PM seb_kuzminsky: well i like vim
07:07 PM andypugh: Not sure I have enough lifespan remainign to learn the keybindings
07:11 PM andypugh: I rather want to be able to click on the text with a mouse and start typing there. I know that exposes me as a lighweight.
07:18 PM andypugh: geany is looking OK. In fact it is looking rather good
07:23 PM andypugh: Inside LinuxCNC is there a reason to prefer float_t over float?
07:23 PM andypugh: https://github.com/rene-dev/linuxcnc/commit/c47eb7de60e2f099d10e084e1e8f479859841413#diff-62fa1d1c4a021656abb536fd4c550fcdR1324
07:28 PM andypugh: OK, so float_t is not found anywhere in the code, that looks like an answer. (It is just that float_t was suggested by an unfamiliar editor, and I thought it was picking it up from elswhere. Maybe I should look at vim after all)
08:18 PM skunkworks_: so - the stepgen position mode has a steady state error - a few tenths at 10in/min
08:35 PM KGB-linuxcnc: 03Rene Hopf 05master 2a257d5 06linuxcnc 10src/hal/drivers/mesa-hostmot2/sserial.c 10src/hal/drivers/mesa-hostmot2/sserial.h add support for float values in the sserial driver. * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=2a257d5
08:35 PM KGB-linuxcnc: 03andy pugh 05master 9207cbc 06linuxcnc 10src/hal/drivers/mesa-hostmot2/sserial.c 10src/hal/drivers/mesa-hostmot2/sserial.h Further work on adding a FLOAT type to smart-serial datatypes * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9207cbc
08:38 PM skunkworks_: with a pid setup (now I have not tried with the software one) but with the 7i92 - the steady state error is zero. Also - I am surprised at how low the following error is with changes like backlash introduces. (<.0001 for 10ipm) is this because of FF1/ff2?
08:45 PM skunkworks_: it is impressive
08:48 PM pcw_home: Yeah ideally the PID control loop should be integrated into the position mode
08:48 PM pcw_home: to simplify the hal file (and remove the sensitivity to jitter in the current position mode)
08:53 PM skunkworks_: pcw_home, http://electronicsam.com/images/KandT/testing/followingerror.png
08:54 PM skunkworks_: that is a .001 backlash move (Which happens outside of motion) so 2x acceleration
08:56 PM skunkworks_: 1u following error
08:58 PM kwallace2: andypugh, in case you read back, I just use Synaptic to install gEdit and select gedit on a text file properties in file manager. The property seems to follow the selection for other text files so you just need to do it to one. Mousepad doesn't do it for me either.