Back
[06:29:19] <skunkworks> zlog
[06:37:23] <KGB-linuxcnc> 03John Thornton 052.7 2516558 06linuxcnc 10docs/src/gcode/overview.txt Docs: markup fixes * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=2516558
[10:25:17] <cradek> https://youtu.be/3aYaHxT6ZnQ
[11:01:53] <skunkworks> cool huh?
[11:03:16] <jepler> now run it backwards across a toolchange :-P
[11:05:04] <skunkworks> aww\
[11:07:44] <cradek> if only it hadn't led to a thread about how little ram some historical computers had
[11:07:47] <cradek> on the devel list (sigh)
[11:08:22] <skunkworks> heh
[11:08:41] <skunkworks> jepler, it stops at the tool change position... Rob may really be a genious...
[11:11:18] <skunkworks> if you set the adaptive feed to negative while the tool change is in progress - it just sit there.
[11:11:27] <skunkworks> until you go positive
[11:35:41] <ikcalB> looks like I'm too bullheaded to find - where's the kernel-config file for our "linux-image-3.4.9-rtai-686-pae" kernel?
[11:36:00] <ikcalB> (would use that as a starting point, rather than the default kernel config)
[11:36:56] <cradek> those go in /boot
[11:39:39] <ikcalB> cradek: tnx
[11:59:39] <jepler> you should probably start with the debian generic config from the matching kernel version, and turn on the rtai-related options..
[11:59:56] <jepler> rather than starting with 3.4.9 which will not have the options to turn on hardware support for post-3.4 drivers
[12:06:10] <jepler> so there was that weird failure on buildbot last week in the hm2-idrom test. I determined it to be a line missing from the halrun-stderr file. I observed about 2 failures in 1600 runs in a heavily-loaded system.
[12:06:48] <jepler> this change, which almost certainly doesn't fix the real problem, brings down the failure rate to less than 1 in 3046 runs and counting (same loading conditions):
http://paste.ubuntu.com/12314946/
[12:09:08] <jepler> what *should* be the case is that halcmd and rtapi-app share the same "file description" in the kernel, and thus the same file offset; write(2) is supposed to update that offset atomically so that write()s from two different processes or threads with the same underlying file description both appear in the output file in some order
[12:11:06] <jepler> the other awfully weird cause of failure could be an error return from write() in rtapi_app, but I don't know what that error return would be.
[12:11:46] <ikcalB> jepler: OT: your wiki page is just a _bit_ outdated: <quote>Official support for a newer version of ubuntu, possibly the upcoming version 7.10 </quote>
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?JeffEpler
[12:11:57] <jepler> anyway, the change heavily reduces the chances that halcmd will be writing the "waiting for component" message or its dots at the same time that rtapi_app is writing hostmot2's startup messages
[12:12:23] <jepler> ikcalB: hah
[12:17:21] <ikcalB> jepler: too much OT?
[12:45:27] <Tom_itx> skunkworks, what branch is that reverse code in?
[12:45:47] <Tom_itx> that's pretty cool
[13:04:23] <skunkworks> Tom_itx,
https://github.com/robEllenberg/linuxcnc-mirror/tree/feature/reverse-run-2.7-rebase
[13:05:29] <Tom_itx> i wonder if that's heading toward a resume after a tool breakage to rewind the code a bit
[13:05:36] <Tom_itx> or such
[13:07:59] <skunkworks> that plus the move off work - the only real thing missing is setting tool length/offsets.
[13:09:37] <Tom_itx> that'll be another big additon to the program
[13:59:53] <cradek> -Name=LinuxCNC
[13:59:53] <cradek> +Name=LinuxCNC Config Picker
[14:00:25] <cradek> jthornton: do you mind if I change this back? I think it's now harder to tell which thing on the menu you should use to just start the program.
[14:01:24] <cradek> this is part of 4ecac24
[14:01:31] <cradek> I like all the other parts of that change
[14:13:28] <JT-Shop> actually I was thinking of dropping all the LinuxCNC's except the Config Picker one after looking at the menu it looks too cluttered
[14:13:40] <KGB-linuxcnc> 03Chris Radek 052.7 dd085b7 06linuxcnc 10docs/src/getting-started/getting-linuxcnc.txt Update sums for new wheezy image containing 2.7.0 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=dd085b7
[14:13:40] <KGB-linuxcnc> 03Chris Radek 052.7 d3b6f4c 06linuxcnc 10share/axis/tcl/axis.tcl 10src/emc/usr_intf/touchy/touchy.glade Update copyright dates for AXIS and Touchy * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d3b6f4c
[14:13:59] <cradek> I agree it's pretty cluttered
[14:14:34] <JT-Shop> I didn't see that till I upgraded to 2.7.0
[14:14:41] <cradek> I think whether you want to drop all the LinuxCNCs depends on whether we suspect someone else will add stuff to the CNC menu
[14:15:16] <cradek> ... and I don't know the answer to that. I'd like to think someone might do that, I guess
[14:15:39] <cradek> whatever you think is fine with me, except I think the one you use to start the program should say just "LinuxCNC"
[14:28:08] <JT-Shop> I've got a plan to fix it :)
[14:28:27] <JT-Shop> just use the hover over hint for more detail
[14:33:15] <andypugh> It seems to me that the fabs in lin 71 is superflous, or the code doesn’t do quite what was intended?
[14:33:16] <andypugh> http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=blob;f=src/emc/motion/homing.c;h=43b1ee0d65aac67c333fae35ce4aa4758adb21b9;hb=HEAD#l717
[14:33:28] <andypugh> Line 718, I mean
[14:34:52] <cradek> I agree that has a weird smell to it
[14:37:18] <andypugh> It means that negative home final velocities are accepted, but become max velocitiies.
[14:37:45] <cradek> all the other homing velocities use their sign to mean something (direction)
[14:37:50] <andypugh> (Though that would be the case even without the fabs)
[14:38:01] <cradek> I think this one is weird in that it doesn't need/expect/use that distinction
[14:39:45] <cradek> do you think changing it to != 0 is better? (accept but ignore negatives in case someone puts the direction in there too)?
[14:40:11] <cradek> or just take out the useless fabs and keep the same behavior
[14:40:42] <cradek> or do nothing :-)
[14:41:44] <cradek> I would not change 2.7 unless it fixes an actual bug, but my religious beliefs are unusually strong about that
[14:50:07] <andypugh> It is a bug, I think.
[14:50:11] <andypugh> But not a serious one.
[14:50:41] <andypugh> Taking out the fabs saves CPU cycles. != 0 achieves the intended behaviour
[14:51:21] <cradek> http://www.linuxcnc.org/docs/html/config/ini-homing.html#_home_final_vel
[14:51:32] <cradek> fwiw, it's documented as must be positive
[14:53:14] <cradek> I like the new TOC
[14:55:25] <andypugh> OK, so if it is in the docs it is a feature rather than a bug, and can be left as-is. :-)
[14:55:38] <cradek> heh
[14:55:58] <cradek> always feel free to change any old weirdness in master
[16:20:22] <jepler> I should dust off my sampler/streamer libification
[16:20:23] <jepler> for master
[16:27:32] <seb_kuzminsky> i imagine there are many dusty branches that are starting to look interesting and potentially alive now
[16:53:40] <jepler> seb_kuzminsky: did you see my rantings above about that hm2-idrom failure? up to ~9000 iterations with my non-fix fix in place
[17:44:54] <seb_kuzminsky> jepler: nope, i missed it, will read back
[17:53:51] <seb_kuzminsky> jepler: ok i read your pasted patch, but i dont understand why it reduces the likelihood of the problem
[17:54:05] <seb_kuzminsky> as you say, halcmd should have the same file descriptor on the kernel side
[17:57:29] <seb_kuzminsky> cradek: thanks for the updated 2.7 install iso
[17:57:50] <seb_kuzminsky> i should have said something in the 2.7.0 announcement about upgrading after installing
[17:57:54] <cradek> welcome
[17:59:04] <seb_kuzminsky> maybe... maybe the buildbot should generate install ISOs on official releases?
[17:59:53] <jepler> .. stopping after 10345 test runs
[17:59:56] <cradek> eh
[18:00:18] <jepler> stashing my changes and running again
[18:00:55] <cradek> I mean I guess it could, but people need to install updates anyway, so why bother
[18:01:18] <cradek> and it would be nice if the md5sum in the docs was right at least sometimes
[18:01:48] <seb_kuzminsky> jepler: you mentioned a failed write() in rtapi_app, you mean from writing to stderr? that seems unlikely, but maybe you could strace for it?
[18:01:57] <seb_kuzminsky> cradek: yeah, the checksum thing is a bummer
[18:02:28] <jepler> seb_kuzminsky: yeah I think I can cook it up to strace the relevant thing and leave the evidence behind
[18:02:37] <seb_kuzminsky> maybe we dont need it? or maybe we should do like debian, and store it next to the image, instead of in our docs?
http://cdimage.debian.org/debian-cd/8.2.0/amd64/iso-cd/
[18:02:40] <jepler> you can never have a right md5sum in the docs on the cd
[18:03:41] <cradek> yeah fortunately people downloading the cd won't be looking at the cd's docs, they'll be looking at the online ones if at all
[18:03:42] <seb_kuzminsky> then the docs could say "download the .iso and the SHA1SUMS file and check with sha1sum --check"
[18:04:11] <seb_kuzminsky> now that i say it out loud i think it's crazy that we dont do it this way
[18:04:15] <cradek> heh
[18:04:54] <jepler> oh and check the gpg signature on the sha1sums file
[18:06:31] <seb_kuzminsky> but what about the shasum of the signature file?
[18:06:50] <jepler> I won't try to top you, we'd just get silly.
[18:07:35] <seb_kuzminsky> my 3d printing coworker has cooked up an rtpreempt kernel for the bbb, and cross-compiled linuxcnc 2.7 for it, and is tackling the pru mess
[18:08:22] <seb_kuzminsky> i asked him how he made the rtpreempt kernel, he said he cloned the beaglebone kernel git repo and the rtpreempt kernel git repo and merged them
[18:08:25] <seb_kuzminsky> he's a ninja
[18:09:07] <seb_kuzminsky> he says latencies are in the 100's of microseconds, but maybe that's good enough with the base thread on the PRU
[18:09:36] <jepler> 100s, so servo thread will be 2ms or more
[18:31:41] <andypugh> cradek: That light on my lathe is branded “Tranilite”
[18:32:08] <andypugh> And appears to have a 110V to 6V transformer in the holder. One that melts at 240V
[18:37:13] <andypugh> Are kins kernel modules?
[18:38:07] <cradek> andypugh: wow, a transformer
[18:38:09] <cradek> andypugh: yes they are
[18:38:17] <cradek> wellll they're hal components
[18:38:29] <cradek> which on some platforms are kernel modules
[18:38:36] <cradek> what are you working on?
[18:38:50] <andypugh> So, logging to file from inside kins is right out? (just checking, forum query)
[18:39:58] <cradek> if you run sim I guess you could
[18:40:19] <cradek> I like to compile and test kins completely outside of linuxcnc
[18:41:04] <cradek> often there are some positions where you know the expected result, and you can run that reverse and forward and reverse and forward and see if it all works right
[18:41:08] <skunkworks> so I am installing rtai on precise and following these directions. It installed the rtai kernel but it isn't in grub menu or boots
[18:41:10] <skunkworks> http://linuxcnc.org/docs/devel/html/getting-started/index.html#_updates_to_linuxcnc
[18:41:11] <cradek> usually the problem is forward and reverse don't match
[18:41:32] <skunkworks> oh - it is in the previous linux version menu
[18:41:52] <cradek> yuck
[18:42:33] <andypugh> I think that used to happen with the previous Ubuntu LiveCD too.
[18:44:08] <skunkworks> hmm - but this system doesn't boot with that kernel
[18:46:42] <andypugh> Time to snooze.
[19:14:26] <jepler> hmph, 1500 iterations with my patch reverted and no failure yet
[19:35:44] <jepler> 1568 iterations
[19:35:58] <jepler> Waiting for component 'hm2_test' to become ready.hm2/hm2_test.0: IDROM ClockLow is 12345, that's too low, aborting driver load
[19:36:11] <jepler> same thing, the message 'loading HostMot2 test driver' doesn't appear
[19:42:59] <jepler> hopefully strace doesn't disturb it in a way that hides the problem
[19:43:10] <jepler> but I fear strace changes the behavior of the observed program
[20:40:07] <seb_kuzminsky> jepler: that's on uspace on jessie too?
[20:40:28] <jepler> seb_kuzminsky: uspace (not setuid) on wheezy
[20:41:00] <seb_kuzminsky> the test script runs halrun, which runs halcmd, which runs loadrt, which, what? tells rtapi_app to dlopen something?
[21:00:44] <jepler> yeah pretty much
[21:03:02] <jepler> and both halcmd and rtapi_app are calling write(2, "....");
[21:03:26] <jepler> .. halcmd after a certain minimum length of time has elapsed without the realtime component load finishing
[21:29:20] <jepler> hm, might get better reproducibility by reducing that delay
[21:29:29] <jepler> 544 straced tests and no error, will leave it overnight
[22:37:00] <skunksleep> Could you just have a pin in the encoder counter that just counts 1 rev (resets every index?)