Back
[02:07:20] <micges-dev> logger[mah]: hello
[02:07:20] <logger[mah]> micges-dev: Log stored at
http://linuxcnc.mah.priv.at/irc/%23linuxcnc-devel/2014-11-14.html
[07:18:47] <KGB-linuxcnc> 03Jeff Epler 052.7 5735855 06linuxcnc 10src/hal/hal.h 10src/hal/hal_priv.h hal: increase some limits * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5735855
[07:19:18] <KGB-linuxcnc> 03Jeff Epler 05master 19dcbde 06linuxcnc Merge remote-tracking branch 'origin/2.7' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=19dcbde
[08:47:10] <micges> jepler: make after git pull doesn't rebuild hostmot2
[08:47:50] <micges> jepler: still got 41 chars
[08:48:30] <micges> jepler: (I know make clean will fix it but still I think it could be fixed)
[09:12:54] <skunkworks> cradek, what ethernet to wireless adaptors have you used?
[09:13:39] <cradek> I just use old wrt54 family routers from goodwill with dd-wrt on them
[09:13:57] <cradek> I have a handful of them
[09:14:23] <skunkworks> can you have 2 bridges on 1 access point/router?
[09:14:42] <cradek> sure
[09:14:48] <cradek> there's nothing magic about it
[09:14:54] <skunkworks> great!
[09:15:15] <cradek> my little lathe (which is on a wheeled cart) has one permanently on it
[09:16:13] <jepler> micges: uspace or rtai?
[09:16:25] <micges> uspace
[09:17:18] <jepler> oops I did not mean to type make -j156
[09:17:49] <jepler> $ touch hal/hal.h
[09:17:51] <jepler> $ make -j15
[09:17:53] <jepler> ...
[09:17:59] <jepler> Compiling realtime hal/drivers/mesa-hostmot2/hostmot2.c
[09:18:32] <jepler> here it appears to rebuild as expected when hal.h changes
[09:19:44] <micges> hmm here doesn't, I'll pay attention to this, thanks
[09:19:53] <jepler> If you can figure out the cause, let me know.
[09:20:14] <jepler> http://pastie.org/9719169
[09:20:58] <micges> ok
[09:21:45] <jepler> or, if not the cause, at least how to reproduce the problem
[09:22:07] <micges> here's mine:
http://pastebin.com/s25ZyMbJ
[09:23:16] <jepler> so if you do what I did, touch hal/hal.h; make -j15 ../rtlib/hostmot2.so
[09:23:18] <jepler> what output do you get?
[09:24:13] <jepler> also what is the content of the file [src/]objects/rthal/drivers/mesa-hostmot2/hostmot2.d
[09:24:39] <jepler> mine is
http://pastie.org/9719177 which as expected includes /home/jepler/local/src/linuxcnc/src/hal/hal.h
[09:27:48] <micges> ok that's not the problem
[09:27:52] <micges> it compiles ok
[09:28:53] <micges> problem is when I pull --rebase after message today '<KGB-linuxcnc> Jeff Epler 2.7 5735855 linuxcnc src/hal/hal.h src/hal/hal_priv.h h' changes doesn't get to local repo
[09:29:35] <micges> I tried to compile about 1h later
[09:29:53] <micges> (git pull and compile)
[09:30:27] <jepler> $ git fetch; git log -1 --oneline origin/2.7
[09:30:28] <jepler> 5735855 hal: increase some limits
[09:33:00] <jepler> $ git remote show origin | grep 'Fetch URL'; git ls-remote origin 2.7
[09:33:00] <jepler> Fetch URL: git://git.linuxcnc.org/git/linuxcnc.git
[09:33:01] <jepler> 5735855f5e3c7456299f4e16931d11d63979ecfe refs/heads/2.7
[09:38:12] <jepler> in other words, I have no idea how you are getting 66dd596 as the tip of 2.7 when you fetch (pull).
[09:50:08] <micges> now it's ok but 1h after KGB message with your's todays commits I got 66dd596
[09:51:27] <skunkworks> you do live in poland..(you need to take into account the speed of light...) ;)
[09:52:12] <cradek> not to be too blunt, but you must have done something wrong? the kgb message is generated by a hook that runs at git push time, so there is no delay.
[09:54:34] <micges> it could be but I did the same operations many times, right after interesting push
[09:56:17] <micges> I'll pay attention on this
[09:56:41] <micges> skunkworks: seems cables goes through russia :)
[10:01:10] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/jog_no_fo 0d18f03 06linuxcnc 10src/emc/motion/control.c jogging: ignore feedoverride * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0d18f03
[10:29:03] <skunkworks> dad has decided that a linear scale on y is a priority.. he is chasing .003 cold to hot. (funny how .003 is a lot..)
[10:31:21] <seb_kuzminsky> i wish dgarr had called it jog_no_fo_mofo
[10:32:24] <skunkworks> wow
[10:34:07] <cradek> the question is: 2.6 or 2.7
[10:34:33] <cradek> skunkworks: it'd be easier to just sneak in and hide the micrometers
[10:40:03] <archivist> give him his chalk back, that should be good enough
[11:08:09] <seb_kuzminsky> we're so helpful
[11:13:11] <skunkworks> :)
[11:20:16] <jepler> if you were pulling from some other place, like github linuxcnc-mirror, there can be a delay
[11:22:06] <seb_kuzminsky> cradek, dgarr: i think 2.7, and an apologetic release note about accidentally changing it in 2.6
[11:25:37] <cradek> seb_kuzminsky: dgarr isn't here
[11:26:24] <skunkworks> he is on users..
[11:28:21] <jepler> huh, linux kernel (A) still supports gcc 3.2 (or maybe 3.4) as a minimum version and (B) remain committed to using gnu89 as the C standard
[11:29:05] <jepler> so now that gcc 5 will make -std=gnu11 the default (or maybe -std=c11) they are in trouble
[13:22:41] <seb_kuzminsky> whew, finally, i have a super-quick repro test program for the dropped-mdi bug in the lui branch
[13:26:12] <jepler> yay
[13:29:53] <seb_kuzminsky> the repro is this: be in mdi mode, send an mdi command (& wait for task to echo the serial number), send a command to change the task mode
[13:30:16] <seb_kuzminsky> task receives the mdi command and starts proessing it, then it drops the mdi when the task-mode command comes in
[13:31:56] <seb_kuzminsky> this is with lui sending the commands, but the debug output from task clearly shows it doing the wrong thing: receiving the mdi & echoing the serial, then dropping it when the task-mode command comes in
[13:35:37] <seb_kuzminsky> http://pastie.org/9719635
[13:35:44] <seb_kuzminsky> bbl
[13:36:53] <jepler> if you send an mdi command and then immediately switch out of mdi mode, what do you expect to happen?
[13:37:08] <cradek> if you start a long-running mdi command in AXIS and then switch to manual (jogging) mode, it aborts the mdi command
[14:35:49] <seb_kuzminsky> hmmm
[14:36:07] <seb_kuzminsky> i guess i had expected the mdi to run until completion or abort
[14:36:50] <seb_kuzminsky> maybe i've been chasing a misunderstanding these past few days :-/
[14:42:41] <seb_kuzminsky> wait, no, the original (slow-running) test waits for the reported motion to get to the target of the mdi g0 before switching modes
[14:45:29] <seb_kuzminsky> maybe i monkeyed up command completion detection in halui
[15:22:35] <seb_kuzminsky> haha
[15:22:54] <seb_kuzminsky> i think it's a bug i introduced in halui, just like jepler said like 3 days ago
[15:23:28] <seb_kuzminsky> i update the lui status buffer but not the emcStatus buffer, and bogusly use the old out-of-date emcStatus buffer to see if the mdi command is done yet
[15:23:31] <seb_kuzminsky> maybe
[15:23:33] <seb_kuzminsky> will look more
[15:23:36] <seb_kuzminsky> sigh
[15:32:09] <Tom_itx> on the bright side... it _is_ Friday
[15:44:44] <seb_kuzminsky> hm, no, that's not it either, since jeff's lui_get_status_nml() trick
[21:08:53] <jepler> seb_kuzminsky: it'd be a good idea to rebase lui on top of master soon, as some of it will have to change with the nml sequence number change
[21:09:07] <jepler> seb_kuzminsky: I can do it this weekend if you want
[21:24:47] <KGB-linuxcnc> 03Dewey Garrett 052.7 50b1fbe 06linuxcnc 10src/emc/motion/control.c jogging: ignore feedoverride * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=50b1fbe
[21:26:58] <jepler> thanks dgarr!