Back
[00:32:43] <CIA-15> EMC: 03cradek 07TRUNK * 10emc2/configs/lathe-pluto/lathe-pluto.ini: new limits and changes for active axes
[00:43:40] <skunkworks> active axes
[00:43:42] <skunkworks> ?
[00:44:31] <skunkworks> dlink wireless router only lasted 2 years in the elements. :)
[00:52:52] <jepler> skunkworks: remove specification of "Y" axis that doesn't exist on lathes
[00:53:59] <cradek> jepler: when I load my lathe tool with .8mm diameter, AXIS gives me a teeny tiny representation of the shape
[00:54:08] <cradek> it's much smaller than a tool with 0 diameter
[00:54:41] <cradek> * cradek waits for the well-deserved "well fix it"
[00:54:56] <skunkworks> heh
[00:55:23] <cradek> I wish there was a good way to measure tools. It's a pain.
[00:57:08] <skunkworks> legth or diameter?
[00:57:13] <skunkworks> eww - length
[00:57:26] <cradek> both "lengths"
[01:29:05] <CIA-15> EMC: 03cradek 07TRUNK * 10emc2/src/Makefile: lathe-pluto needs this
[01:30:28] <CIA-15> EMC: 03cradek 07TRUNK * 10emc2/debian/emc2.files.in: lathe-pluto needs this
[01:31:20] <jepler> cradek: is that one for the branch as well?
[01:31:26] <cradek> yeah, working on it
[01:31:29] <jepler> OK thank you
[01:31:36] <jepler> did the test failure in the gcode tests ever get fixed?
[01:31:45] <cradek> I don't think I did it
[01:31:48] <jepler> OK
[01:31:53] <jepler> I'll try to do it then
[01:32:03] <CIA-15> EMC: 03cradek 07v2_2_branch * 10emc2/src/Makefile: lathe-pluto uses this
[01:32:17] <cradek> thanks
[01:32:40] <CIA-15> EMC: 03cradek 07v2_2_branch * 10emc2/debian/emc2.files.in: lathe-pluto uses this
[01:33:35] <CIA-15> EMC: 03jepler 07TRUNK * 10emc2/tests/ccomp/lathe-comp/expected: update expected results to conform to changes in gcode interpreter
[01:33:35] <CIA-15> EMC: 03jepler 07TRUNK * 10emc2/tests/ccomp/mill-line-arc-entry/expected: update expected results to conform to changes in gcode interpreter
[01:33:36] <CIA-15> EMC: 03jepler 07TRUNK * 10emc2/tests/ccomp/mill-g90g91g92/expected: update expected results to conform to changes in gcode interpreter
[01:33:36] <CIA-15> EMC: 03jepler 07TRUNK * 10emc2/tests/ccomp/mill-zchanges/expected: update expected results to conform to changes in gcode interpreter
[01:33:39] <CIA-15> EMC: 03jepler 07TRUNK * 10emc2/tests/oword/sub.0/expected: update expected results to conform to changes in gcode interpreter
[01:39:47] <CIA-15> EMC: 03cradek 07TRUNK * 10emc2/src/emc/usr_intf/axis/scripts/axis.py: tiny tool diameter, like you can have on an indexable lathe tool, caused a very small tool display. this makes it no smaller than the zero-radius special case.
[01:39:49] <cradek> jepler: will you check that ^^
[01:40:06] <cradek> (I did test it)
[01:41:10] <jepler> what does "indexable" mean in this case?
[01:41:20] <CIA-15> EMC: 03cradek 07v2_2_branch * 10emc2/src/emc/usr_intf/axis/scripts/axis.py: tiny tool diameter, like you can have on an indexable lathe tool, caused a very small tool display. this makes it no smaller than the zero-radius special case.
[01:41:33] <cradek> it's a type of tool
[01:41:44] <cradek> the little inserts that screw onto a holder
[01:42:10] <cradek> they can have pretty sharp corners, like these that have "diameters" of 1/32 inch
[01:42:25] <CIA-15> EMC: 03jepler 07v2_2_branch * 10emc2/tests/ccomp/lathe-comp/expected: merge from TRUNK: update expected results to conform to changes in gcode interpreter
[01:42:25] <CIA-15> EMC: 03jepler 07v2_2_branch * 10emc2/tests/oword/sub.0/expected: merge from TRUNK: update expected results to conform to changes in gcode interpreter
[01:42:26] <CIA-15> EMC: 03jepler 07v2_2_branch * 10emc2/tests/ccomp/mill-line-arc-entry/expected: merge from TRUNK: update expected results to conform to changes in gcode interpreter
[01:42:31] <CIA-15> EMC: 03jepler 07v2_2_branch * 10emc2/tests/ccomp/mill-g90g91g92/expected: merge from TRUNK: update expected results to conform to changes in gcode interpreter
[01:42:31] <CIA-15> EMC: 03jepler 07v2_2_branch * 10emc2/tests/ccomp/mill-zchanges/expected: merge from TRUNK: update expected results to conform to changes in gcode interpreter
[01:47:05] <jepler> cradek: so this problem would exist if a tool has a very small diameter like 0.01?
[01:47:35] <cradek> yes
[01:47:36] <jepler> cradek: looks like your change improves that
[01:48:30] <CIA-15> EMC: 03cradek 07TRUNK * 10emc2/configs/5axis/.cvsignore: ignores
[01:48:30] <CIA-15> EMC: 03cradek 07TRUNK * 10emc2/configs/lathe-pluto/.cvsignore: ignores
[01:48:30] <CIA-15> EMC: 03cradek 07TRUNK * 10emc2/docs/man/man9/.cvsignore: ignores
[01:49:05] <CIA-15> EMC: 03jepler 07v2_2_branch * 10emc2/share/axis/tcl/axis.tcl: merge from TRUNK: show version number in title bar
[01:51:20] <CIA-15> EMC: 03jepler 07v2_2_branch * 10emc2/debian/changelog: note newly fixed items
[01:52:45] <cradek> I was just doing that - yay
[01:53:29] <jepler> I hope I didn't step on your toes too much
[01:53:36] <cradek> nahhh
[01:54:14] <cradek> now I wonder what I started out to do tonight :-)
[01:54:26] <jepler> hah
[15:04:55] <cradek> jepler: I do get bug 1876792 in 2.2.2/sim/axis_mm
[15:05:35] <jepler> cradek: huh really?
[15:05:42] <jepler> I was probably on TRUNK
[15:06:38] <jepler> if you see the bug, you can fix it :)
[15:06:48] <cradek> haha
[15:06:49] <cradek> dangit
[15:06:58] <cradek> I won't look for the one alex is working on then :-)
[15:07:36] <CIA-15> EMC: 03jepler 07TRUNK * 10emc2/scripts/emc.in:
[15:07:36] <CIA-15> EMC: Get rid of most explicit uses of EMC2_BIN_DIR, since EMC2_BIN_DIR is guaranteed
[15:07:36] <CIA-15> EMC: to be the leading path element. This makes things like
[15:07:36] <CIA-15> EMC: [TASK]
[15:07:36] <CIA-15> EMC: TASK=valgrind milltask
[15:07:38] <CIA-15> EMC: work
[15:07:56] <cradek> neato
[15:09:35] <alex_joni> cradek: dang me :P
[15:09:41] <alex_joni> ok, I'll try to replicate it later
[15:11:03] <cradek> huh, I figured this was a bug with toolchange/toolchange location, but it isn't
[15:16:57] <jepler> .. but unfortunately emc doesn't shut down correctly, because 'pidof' doesn't find the right things to kill (I think)
[15:17:58] <jepler> ah crap
[15:18:03] <jepler> * jepler just did a checkin he didn't mean to
[15:18:03] <CIA-15> EMC: 03jepler 07TRUNK * 10emc2/src/emc/ini/initraj.cc: fix uninitialized memory read found by valgrind
[15:18:04] <CIA-15> EMC: 03jepler 07TRUNK * 10emc2/src/emc/task/emccanon.cc: fix uninitialized memory read found by valgrind
[15:18:04] <CIA-15> EMC: 03jepler 07TRUNK * 10emc2/src/emc/usr_intf/stepconf/ (stepconf.glade stepconf.py): fix uninitialized memory read found by valgrind
[15:18:05] <CIA-15> EMC: 03jepler 07TRUNK * 10emc2/src/hal/drivers/pluto_servo.comp: fix uninitialized memory read found by valgrind
[15:18:08] <CIA-15> EMC: 03jepler 07TRUNK * 10emc2/src/libnml/os_intf/timer.cc: fix uninitialized memory read found by valgrind
[15:18:30] <jepler> (check in in src/ instead of a single file)
[15:22:13] <CIA-15> EMC: 03jepler 07TRUNK * 10emc2/src/emc/task/emccanon.cc: revert files accidentally committed
[15:22:14] <CIA-15> EMC: 03jepler 07TRUNK * 10emc2/src/hal/drivers/pluto_servo.comp: revert files accidentally committed
[15:22:14] <CIA-15> EMC: 03jepler 07TRUNK * 10emc2/src/emc/usr_intf/stepconf/ (stepconf.glade stepconf.py): revert files accidentally committed
[15:24:36] <CIA-15> EMC: 03jepler 07TRUNK * 10emc2/src/hal/drivers/pluto_servo.comp: fix reversed order of paramters to PWM function
[15:26:27] <CIA-15> EMC: 03jepler 07TRUNK * 10emc2/src/emc/usr_intf/stepconf/ (stepconf.glade stepconf.py): provide button to run latency test. fix search for sample configuration directory
[15:29:48] <cradek> http://cvs.linuxcnc.org/cvs/emc2/src/emc/rs274ngc/gcodemodule.cc.diff?r1=1.27;r2=1.28
[15:30:07] <cradek> checked in by me with an unrelated log message :-/
[15:31:25] <CIA-15> EMC: 03cradek 07v2_2_branch * 10emc2/src/emc/rs274ngc/gcodemodule.cc: fix wrong line in AXIS preview when changing tool length offsets
[15:33:11] <CIA-15> EMC: 03cradek 07v2_2_branch * 10emc2/debian/changelog: fix wrong line in AXIS preview when changing tool length offsets
[15:33:44] <jepler> yay!
[15:36:11] <jepler> that would explain why it worked for me on TRUNK
[15:36:27] <cradek> embarassing
[15:39:53] <jepler> that's another way to look at it
[15:39:56] <jepler> it must be about time for another releas
[15:39:58] <jepler> e
[15:40:27] <alex_joni> 2.2.3?
[15:40:31] <cradek> hey I even tested this change now
[15:40:43] <alex_joni> jepler: can you wait till I can figure out the run-from-line ferror bug?
[15:40:54] <alex_joni> (hopefully before the end of the week)
[15:41:14] <cradek> I sure want O-repeat in 2.2 but I know not having it is not a bug
[15:42:52] <alex_joni> it would be if there's an accepted bug-report :D
[15:45:22] <jepler> alex_joni: sure
[15:46:44] <alex_joni> gotta run home now
[15:48:24] <cradek> http://pastebin.ca/868593
[15:48:30] <cradek> err
http://pastebin.ca/raw/868593
[15:48:42] <cradek> can't read diffs in proportional font
[15:49:50] <jepler> "sure" referred to waiting for the ferror bug to be fixed, not that "O repeat doesn't work in 2.2" would be treated as a bug
[15:51:00] <cradek> yeah I figured that.
[16:00:40] <CIA-15> EMC: 03jepler 07TRUNK * 10emc2/src/libnml/cms/cms.cc: fix uninitialized memory read reported by valgrind
[16:34:15] <cradek> those darn uppity developers always poopoo my bug reports
[16:37:45] <CIA-15> EMC: 03jepler 07TRUNK * 10emc2/src/libnml/os_intf/timer.cc: fix uninitialized value usage reported by valgrind
[16:51:18] <CIA-15> EMC: 03jepler 07TRUNK * 10emc2/src/libnml/os_intf/_shm.c:
[16:51:18] <CIA-15> EMC: In the mists of time, somebody's system had a broken glibc installation and
[16:51:18] <CIA-15> EMC: rcslib got patched around it:
[16:51:18] <CIA-15> EMC:
http://cvs.linuxcnc.org/cvs/rcslib/src/os_intf/_shm.c#rev4.44
[16:51:18] <CIA-15> EMC: but today that code just led to valgrind errors at shutdown.
[16:53:21] <cradek> wow that looks craptacular
[16:57:27] <CIA-15> EMC: 03jepler 07TRUNK * 10emc2/src/libnml/os_intf/_shm.c: if shmctl fails, valgrind produces a diagnostic when the return value of rcs_shm_nattch is used. print a diagnostic and return 0 instead.
[17:03:06] <CIA-15> EMC: 03jepler 07TRUNK * 10emc2/src/libnml/os_intf/_sem.c: this argument shouldn't be required, but providing it shuts valgrind up
[17:04:04] <cradek> in sim can valgrind snoop on the rt code?
[17:04:50] <jepler> yes.
[17:05:31] <jepler> before starting emc, start the realtime environment under valgrind: valgrind rtapi_app
[17:08:56] <jepler> I probably lost it by now, but at one point I had a patch to the gnu pth library that "fixed" the stack change warnings
[17:15:30] <jepler> I don't have anything for the dlopen messages
[19:05:24] <jepler> cradek: interesting, I hadn't noticed that it's a stepconf-generated inifile
[19:05:30] <jepler> in that "following error" report
[19:05:48] <cradek> interesting!
[19:07:29] <jepler> ooh, "joint 3 following error"
[19:07:45] <jepler> unfortunately I didn't get a valgrind diagnostic :(
[19:07:56] <cradek> darn
[19:08:03] <cradek> did you at least have debug on?
[19:08:22] <jepler> Issuing EMC_TRAJ_LINEAR_MOVE -- (+220,+116, +0,0.000000,0.000000,0.000000,-5.000000,0.000000,0.000000,0.000000,0.000000,0.000000, +2,7.500000,20.000000,140.000000, +0,)
[19:08:26] <jepler> Outgoing motion id is 6.
[19:08:28] <jepler> Issuing EMC_TRAJ_LINEAR_MOVE -- (+220,+116, +0,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000, +2,7.500000,20.000000,140.000000, +0,)
[19:08:32] <jepler> Outgoing motion id is 7.
[19:08:35] <jepler> 11714: ERROR: joint 3 following error
[19:09:14] <cradek> I don't see anything wrong with that...?
[19:09:17] <cradek> that's A-5 then A0
[19:10:11] <jepler> http://pastebin.ca/868858
[19:10:22] <cradek> 7.5 deg/sec out of a max 20?
[19:10:31] <jepler> oh .. probably operator error here -- I don't think I had the A-axis loopbacks
[19:10:45] <cradek> oops
[19:10:47] <cradek> darn
[19:14:24] <jepler> darn, now I don't get it
[19:15:58] <cradek> are you running stepgen?
[19:16:38] <jepler> no, I used a limit3 block instead
[19:17:01] <jepler> setp limit3.0.maxa [AXIS_3]STEPGEN_MAXACCEL
[19:17:01] <jepler> net Apos axis.3.motor-pos-cmd => limit3.0.in
[19:17:01] <jepler> net Apos-fb limit3.0.out => axis.3.motor-pos-fb
[19:17:01] <jepler> addf limit3.0 servo-thread
[19:18:27] <cradek> but no vel limit?
[19:18:55] <jepler> stepconf doesn't use STEPGEN_MAXVEL
[19:19:06] <cradek> oh, true
[21:12:26] <fenn> is this worth thinking about?: (EXEC, python foo.py arg1 arg2 arg3)
[21:12:55] <fenn> which then inserts the output of foo.py into the g-code file
[21:13:30] <cradek> the gcode file has to be seekable
[21:13:43] <cradek> (for loops etc)
[21:14:03] <cradek> well maybe that's not the killer I thought it was
[21:14:11] <cradek> you'd just write it somewhere I guess
[21:39:59] <jepler> some days I feel like I should have adde the 'unexpected realtime delay on task N' alert; I think people are happier not knowing that their driver timings are being violated
[21:40:31] <SWPadnos> heh
[21:40:36] <cradek> does gantrykins use teleop?
[21:41:22] <cradek> I think teleop is fairly busted
[21:42:20] <jepler> I'm not sure myself
[21:43:07] <cradek> I'm pretty sure teleop does wrong accels but I haven't looked into it at all
[21:45:06] <jepler> it's like so many things -- I only wrote it (gantrykins), I have no idea whether or how well it works
[21:47:34] <SWPadnos> it's too bad there's such a tight link between "motion" and the GUIs - another method of doing gantrykins is to have a component that takes in one position, but has two outputs, one of which has an offset applied
[21:47:42] <SWPadnos> but you can't jog / home those without GUI help
[22:06:17] <alex_joni> jepler: I think it has KINEMATICS_IDENTITY so it doesn't need teleop
[22:08:48] <alex_joni> oops.. it's KINEMATICS_BOTH so you need to home, switch to world and use teleop
[22:09:55] <alex_joni> YAY.. I got the error on 2.2.2
[22:10:01] <alex_joni> this is way odd :D
[22:14:08] <alex_joni> Outgoing motion id is 343.
[22:14:09] <alex_joni> Issuing EMC_TRAJ_LINEAR_MOVE -- (+220,+116, +0,152.313640,17.000220,-0.254000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000, +2,0.000000,0.000000,0.000000, +0,)
[22:14:23] <alex_joni> cradek: how does the TP react if there's a tpAddLine with 0 velocities?
[22:29:53] <alex_joni> this is odd.. I don't get the error with 2.2.3~cvs, nor with TRUNK
[22:31:58] <alex_joni> aha.. I bet it's the initialisation in motion
[22:32:06] <alex_joni> + emcmotStatus->carte_pos_cmd.a = 0.0;
[22:32:06] <alex_joni> + emcmotStatus->carte_pos_cmd.b = 0.0;
[22:32:06] <alex_joni> + emcmotStatus->carte_pos_cmd.c = 0.0;
[22:37:11] <alex_joni> that wasn't it.. but I found the culprit/fix
[22:37:54] <alex_joni> the prize goes to jepler
[22:38:04] <alex_joni> - double joint_pos[EMCMOT_MAX_JOINTS];
[22:38:04] <alex_joni> + double joint_pos[EMCMOT_MAX_JOINTS] = {0,};
[22:39:25] <alex_joni> the commit message was "make g38.2 probe log zero for axes that do not exist", even if that doesn't have a connection.. it still fixes the bahaviour on 2.2.2
[22:46:49] <micges> hi alex
[22:46:56] <alex_joni> hi micges
[22:47:05] <alex_joni> can you test a small change?
[22:50:07] <alex_joni> micges: in src/emc/motion/control.c
[22:50:28] <alex_joni> change the "double joint_pos[EMCMOT_MAX_JOINTS];" with
[22:50:48] <alex_joni> "double joint_pos[EMCMOT_MAX_JOINTS] = {0,};"
[22:52:09] <micges> moment
[22:52:30] <micges> in 2.2.3 there is no error you know ?
[22:52:48] <micges> in 2.3
[22:53:57] <alex_joni> micges: the change I asked you to test is already in 2.2.3 and in pre-2.3
[22:54:18] <micges> ok
[22:54:53] <alex_joni> so when the next version comes out (probably by the end of the week) it'll be fixed
[23:02:07] <micges> it works
[23:02:23] <micges> this is the fix ?
[23:03:06] <alex_joni> micges: yeah.. seems like it
[23:03:22] <alex_joni> that's why I had such a hard time replicating it.. it was already fixed
[23:03:56] <alex_joni> (probably fixed while something else was beeing fixed.. G38.2 probing)
[23:04:30] <micges> whats wrong with porobing ?
[23:04:51] <alex_joni> there was something wrong in 2.2.2
[23:05:07] <alex_joni> it wrote bogus values for nonexistant axes (ABCUVW)
[23:06:05] <micges> I noticed this on or t wo times
[23:06:26] <alex_joni> :)
[23:06:45] <alex_joni> ok, so I can tag this as fixed (the run-from-line ferror bug)
[23:07:21] <micges> but forgot becouse this not interfere with my program :)\
[23:07:30] <micges> yes you can
[23:07:45] <alex_joni> great
[23:07:46] <micges> I reload few times axis and see it works
[23:07:58] <micges> few min wait please
[23:08:09] <alex_joni> sure, no hurry
[23:09:40] <micges> it works :)
[23:10:08] <alex_joni> micges: I wasn't able to make it error after that change
[23:10:12] <alex_joni> tried 10-20 times
[23:10:57] <micges> tried 8 times on two programs
[23:11:38] <alex_joni> good
[23:17:41] <micges> I wonder how this fix will behave on my modified AXIS
[23:17:42] <micges> :P
[23:17:53] <alex_joni> it shouldn't matter
[23:17:59] <micges> I'll wait and see :D
[23:18:01] <alex_joni> it's not in AXIS, nor anywhere near
[23:19:20] <micges> I know
[23:20:48] <micges> alex_joni: have strength to another error ?
[23:20:50] <micges> :)
[23:21:30] <alex_joni> sure
[23:21:41] <micges> well
[23:21:47] <alex_joni> can't promise I'll do it now, but by all means .. please report them :)
[23:23:05] <micges> when using M66 M65 M64 emc.stat.id value in module for about 200ms reset to 0
[23:23:26] <micges> even longer for about 300-400ms
[23:23:27] <alex_joni> don't mix M66 with 65 and 64
[23:23:46] <alex_joni> 66 is only handled by task (non-realtime) and it can take forever
[23:25:17] <micges> its not that that will take some time but that the emc.stat.id from is coping running_line value in AXIS
[23:25:46] <alex_joni> I'm not sure I remember what emc.stat.id is
[23:26:08] <micges> and emc.stat.id set to 0 for ~300ms and then set to correct value
[23:26:28] <micges> emc.stat.id is currently running line
[23:26:45] <alex_joni> ok, go on
[23:28:02] <micges> and when I stop in meantime of that delay I can't find currently running vector to resume or whatever
[23:28:13] <alex_joni> I understand
[23:28:31] <alex_joni> I'll have to see who changes that and where and why :)
[23:29:18] <micges> ok:)
[23:46:27] <micges> good night