#emc-devel | Logs for 2010-06-24

[14:17:35] <skunkworks> Thanks!!
[14:17:59] <JT-Work> you guys dry out yet?
[14:18:07] <cradek> yep it's fine this morning
[14:18:10] <SWPadnos> I'm just starting to get wet
[14:18:17] <SWPadnos> the rain followed me
[14:18:20] <skunkworks> yah - the sun is trying to peak out
[14:33:50] <SWPadnos> ok, so here's a really basic question that I'm pretty sure I know the answer to
[14:33:59] <SWPadnos> if I have int a,b; float c;
[14:34:13] <SWPadnos> and I assign a=c, then a should have the integer portion of c
[14:34:29] <SWPadnos> if I then do c=c-a, then c now should have the fractional portion
[14:34:56] <SWPadnos> and if I then assign b=(1e9*c), then b should have the number of billionths from c
[14:35:26] <SWPadnos> (yes, this is meant to convert a float to seconds/nanoseconds)
[14:40:50] <jmk-lucidvm> sounds good to me
[14:41:07] <SWPadnos> me too. sadly it seems to not be working
[14:41:15] <jmk-lucidvm> I'd be nervous trying that with negative numbers
[14:41:18] <SWPadnos> or the subtractions aren't working
[14:41:26] <SWPadnos> sure, the numbers should always be positive
[14:41:31] <jmk-lucidvm> what do you get instead?
[14:41:40] <SWPadnos> though I may have used hal_u32s, come to think of it
[14:41:58] <SWPadnos> well, the timeouts never happen
[14:42:13] <jmk-lucidvm> well, print a and b silly
[14:42:15] <SWPadnos> and halmeter shows numbers which are too big to fit
[14:42:21] <SWPadnos> yeah, doing that :)
[14:43:05] <SWPadnos> I still haven't fired up that computer though, so it'll take me a sec to see if I did the stupid thing of if (some unsigned number < 0)
[14:46:55] <SWPadnos> which seems likely, since halmeter was showing hex numbers in addition to decimal
[14:59:34] <CIA-2> EMC: 03jepler 07v2.4_branch * r8a00e9b8a867 10/tcl/bin/pickconfig.tcl: Don't present an option that doesn't work
[14:59:35] <CIA-2> EMC: 03jepler 07v2.4_branch * r3e89a25a2819 10/scripts/emcmkdesktop.in: Make icon appear
[14:59:37] <CIA-2> EMC: 03jepler 07v2.4_branch * r46ce3d2b908e 10/src/emc/usr_intf/axis/scripts/axis.py: Show a prompt when a user re-homes.
[14:59:43] <CIA-2> EMC: 03jepler 07v2.4_branch * r167ec44a7a9c 10/tcl/bin/pickconfig.tcl: make desktop files executable to placate lucid
[15:02:45] <SWPadnos> ok good. I am stupid in the simple way (u32 vs s32)
[15:02:53] <SWPadnos> but I'm recovering
[15:11:38] <ries_> ries_ is now known as ries
[15:12:49] <CIA-2> EMC: 03cradek 07master * r636a0528e657 10/src/emc/usr_intf/touchy/ (emc_interface.py touchy.glade touchy.py): show new status information in touchy
[15:25:14] <CIA-2> EMC: 03swpadnos 07master * r28729a6722a5 10/src/emc/iotask/ioControl.cc: Change HAL pin and param creation to use ...newf functions
[15:25:15] <CIA-2> EMC: 03swpadnos 07master * rf9020388ed2d 10/src/emc/motion/motion.c: Change HAL pin and param creation to use ...newf functions
[15:25:16] <SWPadnos> well that was harder than it had to be
[15:34:54] <jepler> SWPadnos: what was the trouble?
[15:35:29] <SWPadnos> oh, I wanted to make my changes come after all the stuff that was added to master
[15:35:40] <jepler> that's exactly what jmk and I are working on now
[15:35:51] <jepler> except you don't get the benefit of my rambling explanations of git
[15:36:17] <SWPadnos> so I did a series of things that made no sense, and then copied the changed files out of my tree, did a git reset origin/master, and re-did the commits
[15:36:23] <SWPadnos> yeah, darnitall
[15:36:43] <jepler> that's one way to do it!
[15:37:35] <SWPadnos> I decided on "whatever (I think) works" :)
[15:42:02] <Jymmmm> What's a NEWF?
[15:42:44] <jmk-lucidvm> it's like a newt
[15:42:47] <CIA-2> EMC: 03jmkasunich 07master * r65c35fd53383 10/src/hal/components/ (16 files): clean up usage of HAL_NAME_LEN
[15:42:48] <CIA-2> EMC: 03jmkasunich 07master * rec5f871b2cf3 10/src/hal/drivers/ (24 files in 2 dirs): clean up usage of HAL_NAME_LEN
[15:42:49] <CIA-2> EMC: 03jmkasunich 07master * r203f8efa8813 10/src/emc/usr_intf/halui.cc: clean up usage of HAL_NAME_LEN
[15:42:50] <CIA-2> EMC: 03jmkasunich 07master * ra6e1f17de7a0 10/src/hal/ (8 files in 2 dirs): clean up usage of HAL_NAME_LEN
[15:42:53] <jepler> someone who lives in newfoundland
[15:43:03] <Jymmmm> haha
[15:43:04] <SWPadnos> it's a type of dog
[15:43:05] <cradek> I thought that was newfie
[15:44:39] <jmk-lucidvm> newf is a truncated newfie (tail cut off)
[15:44:56] <SWPadnos> to answer the question though, there are functions that can create pin names with a formatted string (like printf), rather than with a constant string
[15:45:19] <SWPadnos> using those eliminates snprintf calls and in some cases local char array variables
[15:45:34] <SWPadnos> and also gets rid of possible buffer length issues
[15:47:02] <SWPadnos> style question: the watchdog component now seems to work (now that I'm using signed variables), but I have named the inputs/timeouts watchdog.input-n and watchdog.timeout-n, rather than watchdog.n.input and watchdog.n.timeout
[15:47:06] <SWPadnos> I did this because it
[15:47:16] <SWPadnos> I did this because it's a single instance with multiple inputs
[15:47:32] <jmk-lucidvm> that's how I'd interpret such names
[15:47:41] <SWPadnos> and there's only one processing function
[15:47:46] <SWPadnos> ok, so no preference for the other way then?
[15:48:14] <jmk-lucidvm> for example, we have and2.<n>.in-<m>, where n is instance and m is pin num within the instance
[15:48:24] <jmk-lucidvm> if there can only ever be one instance, then n seems redundant
[15:48:35] <SWPadnos> ok, I'll commit as is
[15:48:44] <SWPadnos> someone should test on RT please
[15:48:46] <jmk-lucidvm> and having it there (as zero) might falsely imply that you can have more than one instance
[15:48:57] <jmk-lucidvm> question - _can_ you have more than one instance?
[15:49:46] <SWPadnos> actually, I didn't prevent it, but since it will always use the same HAL component name, it shouldn't be able to be loaded twice
[15:49:59] <jepler> the existing "charge_pump" component never has multiple instances and omits the number
[15:50:05] <SWPadnos> or was that a question of "why not?"
[15:50:09] <jmk-lucidvm> well, if you intend there to be only one, comp can prevent that with "singleton"
[15:50:14] <SWPadnos> it's a C component
[15:50:26] <SWPadnos> since it has (but may not need) a variable number of inputs
[15:50:49] <SWPadnos> well, the array could be fixed size, it would still have a variable number of inputs
[15:51:00] <jmk-lucidvm> ok, does it have an argument that specifies the number of instances?
[15:51:07] <jmk-lucidvm> (like "count" for comp components)
[15:51:34] <jmk-lucidvm> if not, then it is a singleton, and the instance number can be omitted
[15:51:39] <SWPadnos> not instances, but inputs yes - "count=n"
[15:51:47] <jmk-lucidvm> hmm
[15:51:52] <SWPadnos> it has a user-specified number of inputs
[15:52:09] <SWPadnos> I can rename that to "inputs" or something
[15:52:09] <jmk-lucidvm> I think 'count' should be reserved to indicate number of instances
[15:52:12] <SWPadnos> ok
[15:52:37] <SWPadnos> (I was noticing that with stepgen and others - it should be count= instead of num_stepgens ...)
[15:53:01] <jmk-lucidvm> yeah, they predate the convention, so changing them would annoy people, but they should be changed
[15:54:39] <SWPadnos> I think I noticed it with siggen actually, since I used that to make a test HAL setup for the watchdog
[15:55:58] <SWPadnos> ok, I changed it to num_inputs
[15:56:02] <jmk-lucidvm> yeah, actually I think stepgen does not have that issue - there can be only one instance (only one set of update/makepulses/capture functions), although that instance can produce multiple sets of outputs
[15:56:04] <jepler> nun_inputs?
[15:56:13] <SWPadnos> no nuns here
[15:56:32] <SWPadnos> besides, they have no inputs ;)
[15:57:03] <SWPadnos> damn. I should write a man page
[15:57:16] <jepler> I think I agree with what jmk-lucidvm says
[15:57:19] <SWPadnos> I hate groff/nroff/troff/buggeroff or whatever it is
[15:57:24] <jepler> at least as he told it to me verbally; I'm too tired to read the screens
[15:57:36] <SWPadnos> I'm too far away to hear it
[15:58:34] <jmk-lucidvm> I said we want to follow the comp convention - count = number of instances, singletons have no count argument, and if a singleton has variable number of inputs, outputs, etc, then we use something like num_inputs
[15:58:39] <SWPadnos> the watchdog is similar to stepgen in that regard, since it only has one "set-timeouts" function, and one "process" function for all inputs
[15:58:46] <jmk-lucidvm> yeah
[15:58:46] <SWPadnos> ok
[15:59:16] <jmk-lucidvm> is the only load-time argument the number of inputs?
[16:00:33] <SWPadnos> yep
[16:00:43] <SWPadnos> the timeouts are float parameters
[16:01:51] <jmk-lucidvm> stepgen deals with something like that using array parameters
[16:02:13] <jmk-lucidvm> step_type="0,0,1" means three stegens, with those three types
[16:02:41] <jmk-lucidvm> you could do "timeout=100,1000,50,100000" to say "four inputs, with those timeouts"
[16:03:08] <jmk-lucidvm> that avoids the problem of someone saying num_inputs=3 and then providing 2 or 4 timeout values
[16:03:09] <SWPadnos> yeah, I had thought about doing it with load-time "fixed" values
[16:03:21] <SWPadnos> they can't, they're params
[16:03:31] <jmk-lucidvm> oh, duh, I misread your response
[16:03:56] <jmk-lucidvm> I missed the "yep", thought you meant that the timeouts were load time parameters
[16:04:05] <jmk-lucidvm> but you really meant they are hal params - my mistake
[16:04:11] <SWPadnos> ah
[16:04:31] <SWPadnos> it's more "watchdog-ish" to specify them once and have them fixed for all eternity thereafter
[16:04:40] <SWPadnos> (per run anyway)
[16:04:57] <jmk-lucidvm> yeah
[16:05:13] <jmk-lucidvm> but I don't have a very strong opinion there - do what you feel is right
[16:05:37] <SWPadnos> there are pathological ways of tricking array parameters into not working right (which serves them right, but still)
[16:05:53] <SWPadnos> step_type="0,1,-1,-1,2", for example
[16:06:11] <SWPadnos> (won't work there since there's a num_stepgens as well)
[16:08:08] <SWPadnos> that's actually a slightly valid thing to do even - say you remove one thing you were watchdogging, number 2 of 6. you could disable #2 only, and only have to remove the hal references to #2, without having to shift all the others down by 1
[16:08:36] <SWPadnos> (but I'm not doing that, so no cause for alarm)
[16:47:37] <CIA-2> EMC: 03cradek 07master * r2ec0a074070d 10/src/emc/kinematics/maxkins.c: remove incorrect comment
[17:01:59] <CIA-2> EMC: 03seb 07master * r47de58f1a1dc 10/src/hal/drivers/mesa-hostmot2/pins.c: remove an old obsolete pin number
[17:02:00] <CIA-2> EMC: 03seb 07master * r636de57b3e8b 10/src/hal/drivers/mesa-hostmot2/doc/ (README.regmap regmap): remove the regmap, point to the one in the firmware repo
[17:02:01] <CIA-2> EMC: 03seb 07master * r427c459381e3 10/src/hal/drivers/mesa-hostmot2/pins.c: fix the PD Secondary Pin mask
[17:14:02] <CIA-2> EMC: 03jmkasunich 07master * rd054e9e34d8c 10/src/emc/motion/motion.c: HAL_NAME_LEN fixes
[17:41:51] <SWPadnos> so, just to be sure I'm not forgetting anything, I can add a watchdog.9 file to docs/man/man9 without having to change a makefile, but I need to change makefile and makefile.inc.in to get watchdog to build, and I've just realized that I also need to change a debian file or two to add these to the packages
[17:41:56] <SWPadnos> is there anything else?
[17:44:45] <dgarr> for consideration: http://www.panix.com/~dgarrett/stuff/0001-halshow-add-menu-options-for-load-save-exit.patch
[17:44:53] <SWPadnos> oh. it looks like some things are automagically added to the debs
[17:47:49] <CIA-2> EMC: 03swpadnos 07master * rd99ce7617c72 10/ (4 files in 3 dirs): New HAL component: watchdog
[17:48:27] <SWPadnos> darned typos
[18:14:10] <andypugh> If my kins code runs OK in SIM, but not in Live, can I start to consider the possibility that the problem is outside my module, or does an error somewhere in that code still seem the most likely thing?
[18:14:40] <SWPadnos> considering that other kins modules don't seem to exhibit this problem, I think the likely culprit is your code
[18:14:58] <cradek> what goes wrong when running it in realtime?
[18:15:10] <SWPadnos> NaNs and stuff
[18:15:14] <SWPadnos> IIRC
[18:19:10] <andypugh> I send zeros, but NaNs come back. If I leave one line in then one of the stepgens wanders a fraction every time the forward kins function runs, despite the fact that it is a completely unrelated axis that it refers to, another line always returns atan2(0,1) as 0.7815 and the pin that I increment by 1 every call actually increments in 1/sqrt(2)s.
[18:23:04] <andypugh> I just tried booting into a non-SMP kernel and recompiling EMC, but it won't run, specifying that it requires kernel version (which is odd, because that isn't even in the menu.lst, they are all variants on the theme of 2.6.24-16 and it ran perfecly happily for the last year or so)
[18:23:39] <SWPadnos> is this in a VM?
[18:24:07] <andypugh> No, this is my actual, live, computer that runs my machines.
[18:25:13] <andypugh> Effectively all I have done since last night when I must have recompiled and run EMC dozens of times is change the boot kernel and reboot.
[18:25:28] <SWPadnos> so there's no 2.6.29.* kernel on the machine, and yet the emc you compile wants that version?
[18:25:37] <andypugh> Yes
[18:25:51] <SWPadnos> are you absolutely sure that you are running the version you just compiled?
[18:25:57] <andypugh> No.
[18:26:44] <SWPadnos> please make sure of that. there is no way I can think of for a version you compile to require a RT kernel you don't have
[18:27:41] <andypugh> Actually, I might be wrong. It occurs to me that the entry in menu.lst called "My SMP Kernel" might be 2.6.29
[18:27:53] <SWPadnos> I can believe that
[18:28:06] <SWPadnos> and that it's that installed version which is being run
[18:29:05] <andypugh> I did . ./emc-environment in the sorce tree I just compiled though.
[18:29:46] <andypugh> Where does the non-RIP version live? Just so I can see if it is stil there.
[18:31:48] <SWPadnos> /bin/emc maybe?
[18:31:53] <andypugh> First things first, I will reboot into the previously selected kernel
[18:33:18] <andypugh> Which is called 2.6.24-16-rtaismp.... There really is no 2.6.29 kernel on this machine
[18:34:09] <andypugh> WHen the 10.04 liveCD comes out I am going to wipe this computer back to scratch.
[18:36:39] <andypugh> It really does seem like the only EMC2 on this machine is the one I just compiled.
[18:38:08] <SWPadnos> find / -name emc
[18:42:25] <andypugh> I have the dev tree I know about, and a set of directories in ~/rtai/emc2-2.3.4/src/emc
[18:43:11] <andypugh> Right! that's it! I am going to shoot this computer.
[18:44:48] <andypugh> menu.lst back to how it was, recompile the exact same source as yesterday, "EMC2 requires the real-time kernel to run....
[18:47:59] <SWPadnos> make clean ; ./configure --enable-run-in-place --with-realtime=<wherever the real realtime is>
[18:48:24] <SWPadnos> there may even be a kernel version --with-whatever option
[18:48:29] <SWPadnos> but you really shouldn't need it
[18:49:43] <andypugh> It does look like it might be a spuriously exact error message which actually means "I can't find RTAI"
[18:51:05] <SWPadnos> is this a 9.04 install?
[18:51:37] <andypugh> I don't think so
[18:52:27] <andypugh> It seems to be 8,04
[18:53:39] <SWPadnos> there are no files on linuxcnc.org with that number in them, and no references to that number in the source
[18:53:47] <SWPadnos> I'm pretty sure it's a local issue
[18:54:01] <andypugh> Sorry to be a pain in the neck, but when you say "wherever the real realtime is" am I looking for a specific file or directory?
[18:54:26] <SWPadnos> actually, just leave that out and look at where configure finds it
[18:54:37] <SWPadnos> it'll be in the log
[18:55:13] <SWPadnos> hmmm. I need to fix a computer or two now, sorry I can't (try to) help any more
[18:55:14] <andypugh> yes, usr/realtime/
[18:55:58] <SWPadnos> what's in /usr/src?
[18:56:16] <SWPadnos> and /boot
[18:56:31] <SWPadnos> just because it's not in the menu doesn't mean it doesn't exist :)
[18:56:36] <andypugh> usr/src has a rtai-3.7.1
[18:57:30] <andypugh> and several linux*** debs
[18:57:45] <andypugh> Hmmmm
[18:59:28] <andypugh> It appears that grub has ignored my edit to menu.lst
[19:00:04] <andypugh> probably need to press a magic key at reboot
[19:14:52] <LawrenceG> how are the emc festers today? survived the tornado?
[19:21:38] <seb_kuzminsky> we had a tornado siren blast in our faces last night, then a rain storm, now it's clear and sunny
[19:21:43] <seb_kuzminsky> most of the guys are out to lunch
[19:22:00] <seb_kuzminsky> getting lots of good stuff done here & having fun! :-)
[19:23:06] <SWPadnos> bummer that I missed you
[19:27:41] <Jymmm> SWPadnos: I miss you too <sniff><sniff?
[19:29:19] <SWPadnos> I'm so lovable
[19:29:56] <Jymmm> love and hate are a very fine line
[19:30:17] <Jymmm> then there's always love to hate you
[19:30:26] <Jymmm> and of course hate to love you
[19:31:23] <micges> hi guys
[19:33:17] <micges> is something going on on joints_axes3 on emc fest?
[20:07:24] <jepler> micges: no.
[20:10:24] <alex_joni> too bad ;)
[20:48:36] <CIA-2> EMC: 03cradek 07master * r59b20d5219d3 10/src/emc/usr_intf/touchy/ (emc_interface.py touchy.glade touchy.py): touchy: show the number of lines of the loaded program
[20:48:37] <CIA-2> EMC: 03cradek 07master * rd4db08e89536 10/src/emc/usr_intf/touchy/emc_interface.py: touchy: make some numbers more readable
[20:51:23] <cradek> jepler: is len([long array]) expensive enough to bother to cache/avoid it?
[21:36:31] <cradek> hi mozmck - wish you wer ehere
[21:36:34] <cradek> or, were here
[22:00:08] <JT-Hardinge> hmm the error window does not pop up in 2.5 when you have something that prevents EMC from loading like a typo in your .hal file
[22:23:17] <jepler> JT-Hardinge: it works for me. remember that you do not get the pop up when you are running in a terminal.
[22:26:47] <CIA-2> EMC: 03seb 07master * r721715f8eda5 10/src/hal/drivers/mesa-hostmot2/stepgen.c: fix a bug in stepgen mode setting
[22:28:18] <JT-Hardinge> I'm not running in terminal, I'm running a RIP with a desktop icon
[22:38:23] <CIA-2> EMC: 03seb 07v2.4_branch * r551940c2f7c7 10/src/hal/drivers/mesa-hostmot2/stepgen.c: fix a bug in stepgen mode setting
[22:45:11] <mozmck> hey cradek! me too.
[22:46:03] <mozmck> I built an iso, but it's a little large. I think all I removed was gnome-games. I need to look and see what else I can get rid of.
[22:50:43] <JT-Hardinge> mozmck your 10.04 is running fine on my Zotac motherboard!
[22:51:16] <mozmck> great! it sounds like it's working pretty well for most people doesn't it?
[22:51:24] <andypugh> mozmck: Is this a 10.04 ISO? I am desperate to try a competently built installation to see if my kinematics oddness goes away
[22:51:41] <mozmck> andypugh: yes.
[22:52:13] <mozmck> have you tried using my 10.04 packages? I wouldn't think an iso would be any different...
[22:52:41] <JT-Hardinge> the last time I installed it I upgraded 10.04 first and it complained on one that newer things were all ready installed
[22:53:15] <JT-Hardinge> the funny thing is I didn't have to pick the rtai kernel on boot up it was just there
[22:53:25] <jepler> mozmck: did you evber resolve the problem on your 6-core machine of the emc2 realtime code seemingly not even running?
[22:53:54] <andypugh> Talking of that, I still have Stepgen.0 drifting as soon as I turn on motion (effectively as soon as the forwardkins starts to be run). It really shouldn't, as I have disconnected the stepgen.0.position-cmd pin in hal.
[22:54:00] <mozmck> jepler, no that is one thing I haven't gotten back to again.
[22:55:37] <jepler> not enough round tuits I suppose
[22:57:02] <mozmck> not around here for sure!
[22:57:05] <mozmck> bbl
[23:48:23] <JT-Hardinge> fresh build on master
[23:48:25] <JT-Hardinge> emc/task/emccanon.cc:1179: warning: ‘double chord_deviation(double, double, double, double, double, double, int, double&, double&)’ defined but not used
[23:48:36] <JT-Hardinge> emc/rs274ngc/gcodemodule.cc:157: warning: ‘double TO_PROG_LEN(double)’ defined but not used
[23:51:31] <JT-Hardinge> SWEET! the DRO page gives you a status update on the coordinate systems no more excuses for smashing pumpkins into the spindle
[23:54:17] <JT-Hardinge> If the DRO tab just had the tool information and if a tool offset was in effect that would be wonderful
[23:54:37] <SWPadnos> picky picky
[23:54:39] <SWPadnos> :)
[23:55:25] <JT-Hardinge> just remembering things that caused me to tighten up and reach for the BRB or crash my tool into the spindle :)
[23:55:58] <JT-Hardinge> You could call it the Status tab now :)
[23:59:00] <JT-Hardinge> * JT-Hardinge wanders inside to start the pizza