Back
[00:00:14] <jmkasunich> just a tiny bit
[00:00:52] <BigJohnT> * BigJohnT wanders off to kick back and get the cat to warm my lap
[01:01:04] <jmkasunich> hmm, some things that swp and chris are saying are starting to gel
[01:01:15] <jmkasunich> imagine this scenario:
[01:01:23] <jmkasunich> 1) dev writes new driver or component
[01:01:35] <jmkasunich> 2) said dev (or someone else does the following:
[01:01:43] <jmkasunich> 3) loadrt the-new-thing
[01:01:59] <jmkasunich> 4) show pin >the-pin-list
[01:02:14] <jmkasunich> 5) make-test-panel <the-pin-list
[01:02:37] <jmkasunich> make-test-panel would be python, and would generate one widget of the appropriate type for each pin
[01:03:01] <jmkasunich> s/generate/export the XML that generates in pyvcp/
[01:03:32] <jmkasunich> bit outs - LED, bit ins, button, etc
[01:03:57] <jmkasunich> it would also generate a hal file that loadrt's the-new-thing and the corresponding test panel, and connects them
[01:04:52] <jmkasunich> the-new-thing-test.xml and the-new-thing-test.hal go into CVS ?
[01:05:21] <jmkasunich> * jmkasunich goes back to sealing windows
[01:37:38] <seb_kuzminsky> jmkasunich: if it's that mechanical, maybe we should make #2 the buildbot and make steps 3-5 part of the build process
[02:39:06] <SWPadnos> seb_kuzminsky, it wouldn't work with the buildbot, unless it had all possible hardware configurations in it
[02:40:02] <SWPadnos> or at least there would need to be slaves attached with all the hardware
[02:40:37] <davidma> skunkworks: i'm watching thaht othher video. jesus man get your head out of there, I'm thinking as I watch it.
[02:41:02] <davidma> as he's fiddling with the coolant
[02:41:16] <cradek> fortunately it doesn't move very fast!
[02:42:14] <davidma> those look like some big cuts.
[02:43:41] <cradek> looks like a 3/4 rougher I think
[02:43:56] <SWPadnos> isn't that head only about 5 tons? or was it 15?
[02:43:58] <cradek> then at the end, maybe it's a 3/8 to finish?
[02:44:11] <cradek> SWPadnos: I don't know...
[02:44:32] <SWPadnos> I can't remember if Stuart said it was 10000 pounds or 30000 pounds
[02:44:56] <SWPadnos> I guess I'm thinking of the whole Z assembly, not the actual pivtong part
[02:45:01] <SWPadnos> +i
[02:45:30] <cradek> neat to see it 'drill'
[02:47:00] <SWPadnos> hmmm. there was a jerk around the 3 minute mark, and I can't tell if it means we need jerk limiting or if the camera/editing was the culprit
[02:47:33] <seb_kuzminsky> SWPadnos: it'd basically only work with software components, not with hardware driver components
[02:48:00] <SWPadnos> seb_kuzminsky, yes, that's correct - but only for certain specific configurations
[02:48:09] <SWPadnos> (even for software comps)
[02:49:07] <SWPadnos> cosnider that there can be more than one PID (defaults to 3), so it doesn't really help much to create a panel with all parameters for 3 PIDs if the person (a) only wants to tune P and I, or (b) had 4 PIDs to tune
[02:49:12] <SWPadnos> consider, that is
[02:49:31] <jmkasunich> what I was proposing wouldn't really give you a panel for tuning anyway
[02:49:32] <SWPadnos> if it's easy enough to make VCP panels, then there's no reason to include them with EMC
[02:49:50] <jmkasunich> it would give you one with widgets for every pin, including the inputs and outputs
[02:50:07] <SWPadnos> yes, but the "input" widgets would be controls in my program
[02:50:19] <SWPadnos> buttons or numeric entry boxes
[02:50:26] <jmkasunich> still, doesn't help for tuning
[02:50:38] <SWPadnos> it does now that PIDFF are pins :)
[02:50:43] <jmkasunich> having the position command come from an entry box doesn't help tuning
[02:50:52] <SWPadnos> oh, no it doesn't
[02:51:10] <jmkasunich> you ONLY want controls on the PIDFF pins, not the command/feedback/output
[02:51:13] <SWPadnos> sure
[02:51:25] <jmkasunich> the auto-generated panels would be good for "what does this do" testing
[02:51:32] <jmkasunich> mostly for I/O devices
[02:51:36] <SWPadnos> my idea was to have a "pin spec" as an argument (or arguments) to the vcp panel creator
[02:52:00] <jmkasunich> I dunno what it is gonna take to get people to test their I/O before they try to run EMC, maybe such panels might help
[02:52:07] <SWPadnos> if you do full regexp, that means something like makevcp pid.*[PID]gain
[02:52:16] <SWPadnos> yeah, sure could
[02:52:42] <SWPadnos> the thing that would make this really useful would also enable an "offline" GUI HAL editor
[02:53:15] <SWPadnos> which is a "fake-params" option or sim-style program for each driver/RT component
[02:53:31] <SWPadnos> but that's a big change, so soemthing for 3.x maybe :)
[03:56:25] <davidma> thanks for the pointers. i'll get back with you folks when i've got a dev environment set up.
[04:58:02] <CIA-42> EMC: 03swpadnos 07TRUNK * 10emc2/src/hal/utils/halcmd_main.c:
[04:58:02] <CIA-42> EMC: add bash command-line completion to halcmd
[04:58:02] <CIA-42> EMC: To use this, you must execute the following line in any bash shell where you
[04:58:02] <CIA-42> EMC: want completion to work:
[04:58:02] <CIA-42> EMC: complete -C "halcmd -C" halcmd
[05:02:47] <CIA-42> EMC: 03swpadnos 07TRUNK * 10emc2/scripts/emc-environment.in: Make halcmd completion work for run-in-place systems
[05:11:05] <SWPadnos> well, it still needs a little work, but it works. time for bed
[07:24:03] <CIA-42> EMC: 03seb 07TRUNK * 10emc2/src/hal/drivers/mesa-hostmot2/ (hostmot2.h encoder.c): Reorganize the encoder code, in preparation for better low-speed velocity estimation.
[07:24:39] <CIA-42> EMC: 03seb 07TRUNK * 10emc2/src/hal/drivers/mesa-hostmot2/TODO: just some updates so i remember
[12:55:53] <jepler> SWPadnos: cool, glad you finished that up
[12:58:11] <jepler> wfm too
[14:13:27] <alex_joni> SWPadnos: bug me when around..
[14:52:12] <SWPadnos> jepler, cool. it works here, but you get interesting results with e.g. halcmd loadusr halmeter <tab><tab><tab> ...
[14:55:55] <cradek> in C++: struct A { A(){} double z}; do I have any reason to believe z is intialized?
[14:56:24] <jepler> cradek: no
[14:56:39] <cradek> thanks
[14:57:18] <jepler> the proper way to initialize it is: struct A { A() : z(0) {} double z; };
[16:59:07] <CIA-42> EMC: 03cradek 07TRUNK * 10emc2/src/emc/nml_intf/emcops.cc: fix occasional arc-skipping behavior (yay!)
[16:59:15] <SWPadnos> woohoo!
[16:59:35] <CIA-42> EMC: 03cradek 07v2_2_branch * 10emc2/src/emc/nml_intf/emcops.cc: fix occasional arc-skipping behavior (yay!)
[17:01:55] <CIA-42> EMC: 03cradek 07v2_1_branch * 10emc2/src/emc/nml_intf/emcops.cc: fix occasional arc-skipping behavior (yay!)
[17:03:56] <micges> cradek: what issue was generated by those lines ?
[17:04:51] <cradek> micges:
http://thread.gmane.org/gmane.linux.distributions.emc.user/11093
[17:05:37] <SWPadnos> so some error checking code later on would see totally bogus numbers in UVW and throw up?
[17:06:42] <micges> I understand
[17:07:08] <cradek> it would compare the uninitialized U/V/W value to zero and think the joint [which does not exist] moved. This would lead to various unsavory things including possibly dividing by zero in emccanon
[17:14:36] <cradek> I don't understand why, but I could not reproduce it in sim mode.
[17:15:12] <SWPadnos> you'd maybe have to inject bogus values in there
[17:15:12] <cradek> in rt, as soon as I set the [uninitialized] data to something other than zero, the problem appeared
[17:15:23] <SWPadnos> what constitutes bogus is unknown though, I guess
[17:15:30] <SWPadnos> oh, cool
[17:15:42] <jepler> yay
[17:15:44] <cradek> yeah, I did that to verify the problem - on sim it didn't seem to work.
[17:15:45] <jepler> and there was much rejoicing
[17:16:00] <seb_kuzminsky> * seb_kuzminsky rejoices
[17:16:01] <cradek> (I wish I understood why that is)
[17:16:22] <SWPadnos> malloc data is zeroed in userspace, isn't it?
[17:16:34] <cradek> not unless you do it explicitly
[17:16:39] <SWPadnos> hmm
[17:16:43] <cradek> (calloc)
[17:16:47] <jepler> SWPadnos: that's c++ code, so it's always userspace
[17:16:56] <SWPadnos> oh, well that makes sense :)
[17:17:16] <SWPadnos> but the RT part that it communicates with isn't
[17:17:37] <SWPadnos> nevermind me - I'm still on the completion thing :)
[17:37:53] <skunkworks_> cradek: Nice Job!
[17:46:05] <alex_joni> * alex_joni agrees
[18:27:51] <micges> I think that uvw must be initialized in more places in emcops.cc ? like EMC_TASK_STAT_MSG ?
[18:28:05] <micges> (or maybe not..)
[18:33:11] <alex_joni> it wouldn't hurt
[18:41:25] <alex_joni> origin is of type EmcPose which contains x..w
[18:52:08] <jepler> it might be appropriate to add initializers for all those fields in all those classes
[18:52:54] <CIA-42> EMC: 03cradek 07TRUNK * 10emc2/src/emc/nml_intf/emcops.cc: initialize a few more things - thanks micges
[18:52:56] <alex_joni> for status it's not as problematic, as it gets updated on the first status update
[19:49:02] <jepler> so a lot of people think this fix warrants a new release. what else do we want for 2.2.8? is this weekend for a release too quick a schedule?
[19:49:12] <jepler> bbl
[19:53:04] <alex_joni> jepler: not for me
[19:54:35] <SWPadnos> I don't know that it requires a new release
[19:54:49] <SWPadnos> I can probably backport the halcmd completion stuff
[19:55:04] <SWPadnos> and also the gs2 driver (if I haven't added it there yet)
[19:56:07] <Guest260> Guest260 is now known as skunkworks_
[20:22:53] <micges> I've been asking this already but what means world mode, joint mode (I'm translating AXIS)
[20:25:17] <cradek> joint mode lets you jog or home the joints individually. world mode lets you move the machine in cartesian space (XYZ).
[20:26:12] <micges> thanks
[20:27:23] <alex_joni> for a XYZ machine there's no real difference (only conceptual)
[20:27:36] <alex_joni> big difference for an articulated robot (or any non trivkins machine)
[20:31:32] <jepler> SWPadnos: I'd skip the halcmd completion stuff -- it changes a very important part of emc that every user requires, just to add a new feature
[20:31:40] <jepler> gs2 I wouldn't mind
[20:31:49] <SWPadnos> ok
[20:35:35] <micges> in axis title "smth ON smth": 'on' could be able to translation
[20:52:31] <jepler> this change diff -u -p -u -r1.76 axis.tcl
[20:52:32] <jepler> --- tcl/axis.tcl19 Nov 2008 21:51:16 -00001.76
[20:52:32] <jepler> +++ tcl/axis.tcl8 Dec 2008 20:51:45 -0000
[20:52:43] <jepler> er
http://pastebin.ca/1280080
[20:52:49] <jepler> should improve the translatability of the title
[20:53:04] <jepler> if someonce can verify this please check it in for me; I have other edits in that file right now and can't conveniently commit it
[21:02:32] <micges> jepler: "no file" can't be translated
[21:02:50] <micges> File "/usr/lib/python2.4/lib-tk/Tkinter.py", line 1345, in __call__
[21:02:50] <micges> return self.func(*args)
[21:02:50] <micges> TypeError: ugettext() takes exactly 2 arguments (3 given)
[21:03:06] <micges> no_file works fine
[21:03:14] <jepler> oh, should be [_ "(No file)"]
[21:03:33] <micges> one sec
[21:08:52] <micges> jepler: sth on sth is doesn't added to axis.pot
[21:09:15] <micges> no file works fine
[21:12:07] <micges> I don't know tcl ..
[21:12:25] <jepler> clearly I don't either
[21:16:06] <jepler> next try:
http://pastebin.ca/1280110
[21:21:01] <micges> jepler: everything ok
[21:22:02] <jepler> cradek SWPadnos seb_kuzminsky alex_joni: can one of you check that in? it's inconvenient for me to do so right now
[21:22:08] <jepler> TRUNK only please
[21:36:20] <SWPadnos> hmmm. I made the change to axis.tcl, but I don't know how to test it
[21:36:44] <SWPadnos> I can see a title, but can't seem to get AXIS to not load a file
[21:36:57] <SWPadnos> (to see if "(no file)" shows up
[21:36:58] <SWPadnos> )
[21:37:11] <jepler> I take micges word for it
[21:37:25] <SWPadnos> well, it's more making sure I did it right :)
[21:39:49] <CIA-42> EMC: 03swpadnos 07TRUNK * 10emc2/share/axis/tcl/axis.tcl: from jepler: make AXIS title translatable
[21:43:11] <skunkworks_> SWPadnos: With the goal boards - did you use the 64bit kernel?
[21:43:25] <SWPadnos> no, I installed from the EMC2 liveCD
[21:43:54] <skunkworks_> ok - I remember the latency being a little worse with the 64 kernel
[21:45:19] <jepler> only a masochist should use 64 bits. the only system that I've really tried to run my 64bit kernels on crashes from time to time with that kernel, but not with the standard ubuntu kernel.
[21:48:42] <skunkworks_> I just tried it. From what I found - the standard one works great
[21:49:03] <SWPadnos> the standard 64-bit kernel?
[21:49:08] <skunkworks_> heh
[21:49:31] <skunkworks_> I think I may have a flaky goal 3 board.
[21:49:44] <SWPadnos> I use only 64-bit stock kernels, it's the RT part that gets you :)
[21:50:06] <skunkworks_> I thought you installed it from the livecd..
[21:50:11] <SWPadnos> have you run memtest86+ (not the one on the Ubuntu CD, the latest from memtest.org or com)?
[21:50:28] <SWPadnos> well, on all my "normal" PCs, I use the stock 64-bit kernel
[21:50:32] <skunkworks_> yes - I have run the memtest86 - no it was from the ubuntu cd
[21:50:41] <SWPadnos> on the RT PCs, I use i386
[21:51:21] <SWPadnos> ok, I know there are additional chipsets recognized by the latest (2.01 maybe), I don't know if the tests have been improved at all
[21:52:51] <skunkworks_> Ok - buning the memtest86 iso right now
[21:53:03] <skunkworks_> V2.10
[21:56:17] <SWPadnos> oh interesting. I have 2.01 - didn't realize there was an update 3 weeks ago :)
[21:57:14] <skunkworks_> hmm - 2.10 doesn't want to boot
[21:57:50] <SWPadnos> odd
[21:58:23] <SWPadnos> maybe they need to re-fix this: Fix Memtest86+ not recognized as Linux Kernel :)
[21:59:06] <skunkworks_> boots on my laptop
[21:59:37] <SWPadnos> maybe you have a flaky GOAL3 board ;)
[21:59:57] <skunkworks_> heh - all I get is a flashing cursor
[22:00:08] <SWPadnos> on the lapyop?
[22:00:11] <SWPadnos> t
[22:00:58] <skunkworks_> no - on the goal3 board
[22:01:54] <CIA-42> EMC: 03swpadnos 07TRUNK * 10emc2/src/hal/utils/ (halcmd_main.c halcmd_completion.c):
[22:01:54] <CIA-42> EMC: remove cruft from bash completion code
[22:01:54] <CIA-42> EMC: start to make interactive completion not sensitive to extra spaces
[22:14:57] <CIA-42> EMC: 03cradek 07v2_1_branch * 10emc2/src/emc/nml_intf/emcops.cc: well that was stupid
[22:15:53] <SWPadnos> no u v and w in 2.1?
[22:57:26] <CIA-42> EMC: 03swpadnos 07TRUNK * 10emc2/src/hal/utils/halcmd_completion.c: make completion tolerant of extra spaces between words
[23:05:02] <CIA-42> EMC: 03swpadnos 07TRUNK * 10emc2/src/hal/utils/halcmd_completion.c: make completion for "delf" only match functions attached to threads
[23:33:03] <SWPadnos> hmmm. in theory functions can be added to multiple threads
[23:33:24] <SWPadnos> I think in practice it doesn't happen at all, since the function would have to be marked as reentrant
[23:33:27] <jmkasunich> in practice, I doubt any function sets the flag that permits that
[23:33:31] <SWPadnos> right
[23:33:49] <jmkasunich> maybe that is a clue that the flag should be removed, and some code can be simplified
[23:34:05] <SWPadnos> I was just considering whether completion for addf should only complete functions that aren't attached to a thread
[23:34:17] <jmkasunich> seems reasonable to me
[23:34:32] <jmkasunich> I might take a look at that flag later, and see if it is ripe for removal
[23:34:48] <SWPadnos> I guess the feature is unused now, but should it be usable?
[23:35:06] <SWPadnos> I guess if we can see a need for it later, then I wouldn't remove it
[23:58:28] <jmkasunich> HAL has existed for 3, 4? years now without a reentrant function
[23:58:48] <jmkasunich> I'll do a carefull check to confirm that, but I bet it is true
[23:59:01] <jmkasunich> bbl, dinner
[23:59:22] <SWPadnos> ok