Back
[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 2.6.29.4-RTAI (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 2.6.29.4-RTAI 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***2.6.29.4 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