#emc-devel | Logs for 2006-01-02

[01:03:58] <ajoni> ajoni is now known as alex_joni_
[04:06:04] <ajoni> ajoni is now known as alex_joni_
[11:38:02] <SWP_Away> SWP_Away is now known as SWPadnos
[17:59:05] <SWPadnos> hiya jmk
[17:59:16] <SWPadnos> last day off from work?
[18:01:47] <jmkasunich> hi swp
[18:01:57] <jmkasunich> nope, today is the last day of my vacation
[18:02:02] <SWPadnos> heh
[18:02:11] <jmkasunich> (since the 1st fell on sunday, they gave us monday)
[18:02:30] <SWPadnos> right - my wife's off today as well (still)
[19:03:54] <jmkasunich> morning alex
[19:04:06] <alex_joni_> evening john :)
[19:04:14] <jmkasunich> or afternoon, or evening, or whatever it is on your personal clock
[19:04:15] <alex_joni_> not really morning at 21:04 ;)
[19:04:31] <alex_joni_> my personal clock is screwed, that is local time however
[19:04:40] <jmkasunich> when did you go to sleep, and when did you wake up? ;-)
[19:05:01] <alex_joni_> about 7am, and about 2pm I think
[19:05:36] <jmkasunich> 7 hrs since you woke up then... so it is afternoon for you ;-)
[19:05:49] <alex_joni_> yup
[19:06:10] <alex_joni_> although I slept too little last night, so it feels like evening
[19:06:43] <jmkasunich> then maybe you can go to sleep in a couple hours, and be back on schedule
[19:06:59] <alex_joni_> I think so..
[19:07:11] <alex_joni_> anyways, there was a nice long discussion with ray yesterday
[19:07:25] <jmkasunich> about?
[19:07:26] <alex_joni_> he has some ideas about reorganizing hal stuff a bit (hal config files)
[19:07:34] <alex_joni_> * alex_joni_ looks for a log
[19:08:22] <alex_joni_> http://solaris.cs.utt.ro/irc/irc.freenode.net:6667/emcdevel/2006-01-01.txt starting around 1800
[19:08:35] <alex_joni_> 18:25
[19:11:31] <jmkasunich> ok, I started reading it, but I need to go for a couple hours
[19:11:31] <cradek> welcome back jmk
[19:11:39] <jmkasunich> jmkasunich is now known as jmk_away
[19:11:40] <alex_joni_> oh, hi chris
[19:11:45] <cradek> hi alex
[19:11:59] <alex_joni_> jmk_away: no problem, not sure if I'll be around though :)
[19:12:02] <cradek> you're a bad influence on me, I slept 0300-1200
[19:12:07] <alex_joni_> * alex_joni_ hides
[19:12:18] <alex_joni_> I slept 0700-1400
[19:13:11] <alex_joni_> ok, jepler's fix seems to do the trick.. it looks ok now (http://dsplabs.utt.ro/~juve/blog/index.cgi/photography)
[19:33:20] <alex_joni_> cradek: still around?
[20:09:39] <SWPadnos> hey cradek - you're a shell script guy, right?
[20:22:01] <SWPadnos> hey alex
[20:22:12] <alex_joni_> hey swampy
[20:22:23] <SWPadnos> do you know much about sed and/or awk?
[20:22:30] <alex_joni_> not really :(
[20:22:33] <SWPadnos> ok
[20:22:38] <alex_joni_> but ask away..
[20:22:54] <alex_joni_> I probably won't be much help, yet you never know
[20:23:01] <SWPadnos> well - I'm thinking of making a little utility to print only one section of an ini file
[20:23:24] <alex_joni_> ok..
[20:23:27] <SWPadnos> it would be useful for making hal files that contain lots of stuff, but are executed in a specifieed order
[20:23:47] <SWPadnos> invoke like "inisect EMCMOT
[20:23:50] <SWPadnos> "
[20:24:00] <alex_joni_> keep going..
[20:24:01] <SWPadnos> and it prints all the stuff in the EMCMOT section of the ini file
[20:24:18] <alex_joni_> * alex_joni_ still doesn't see what that is good for
[20:24:28] <SWPadnos> so, you could have a section that has, for instance, a list of other sections to run through halcmd, in order
[20:24:40] <SWPadnos> and you pipe each section into halcmd as needed
[20:25:04] <alex_joni_> why not use the HALCMD's that are in place?
[20:25:09] <alex_joni_> or the HALCOMMAND's ?
[20:25:12] <SWPadnos> halcmd can use ini-style parameter setting, for example (param = value)
[20:25:58] <SWPadnos> I had thought about making a version of halcmd that could read a single section of an ini file (and do other stuff with it as well)
[20:26:06] <SWPadnos> for example, the AXIS_n sections
[20:26:38] <SWPadnos> have the script return AXIS_0 section, with pid.0. prepended to all the settings (matching a certain pattern)
[20:26:50] <alex_joni_> and that pattern exists where?
[20:27:11] <SWPadnos> on the command line or in a separate part of the (ini) file
[20:27:31] <SWPadnos> I'm thinking of ways to accomplish the "phases configuration" of HAL, but not have 162 config files
[20:27:31] <alex_joni_> can't say I'm convinced :(
[20:27:36] <SWPadnos> phased
[20:27:51] <alex_joni_> well.. you'll have 4-5 / config
[20:27:57] <alex_joni_> can't see a reason for more
[20:28:23] <SWPadnos> there's the ini, which has some stuff duplicated in the HAL files
[20:28:53] <SWPadnos> there are core_*, *io, *motion, and now possibly *_cl, *_limits, *_debug
[20:29:02] <SWPadnos> *_pid, etc
[20:29:15] <SWPadnos> (not now, but implied by parts of the discussion you referenced)
[20:29:44] <alex_joni_> I'm still not understanding what you are proposing
[20:29:53] <SWPadnos> essentially, this utility would allow you to have multiple .hal files in a single ini-style file (with sections, at least)
[20:30:14] <alex_joni_> have a script of some kind, called from somewhere with certain command line parameters, which reads an ini and does some hal stuff..
[20:30:17] <alex_joni_> that's all I got
[20:30:24] <SWPadnos> err - OK
[20:30:48] <alex_joni_> so you want to scrap .hal files? and move stuff to the ini?
[20:30:52] <SWPadnos> right now, there is a [HAL] section in the ini file, which contains the names of several hal files
[20:30:56] <SWPadnos> not necessarily
[20:30:59] <alex_joni_> and/or commands
[20:31:18] <SWPadnos> I'd like to make it so that you could have a single .hal file that halcmd only executes a part of
[20:31:22] <SWPadnos> one section at a time
[20:31:29] <SWPadnos> in the order you want
[20:31:47] <SWPadnos> if those sections happen to be in the ini file, that's OK too
[20:31:56] <alex_joni_> if you look carefully at an ini file, you'll see very few sections releated to HAL
[20:32:25] <SWPadnos> almost all sections are related to HAL - all of the axis tuning is, as are the settings for motion (or IO)
[20:32:40] <SWPadnos> grep for [ in the hal files
[20:32:46] <alex_joni_> I can't see why a hal file would have sections called in another order then they were written
[20:33:18] <SWPadnos> it just adds flexibility, and allows you to have non-HAL stuff in the same file (like the ini)
[20:33:42] <SWPadnos> it would allow a single ini file, with sections executed by halcmd
[20:33:52] <SWPadnos> and other sections ignored by halcmd
[20:33:57] <alex_joni_> a single ini file?
[20:34:05] <SWPadnos> yes
[20:34:15] <SWPadnos> though there would still be an nml file, of course
[20:34:44] <alex_joni_> how do you mean a single ini file? there is only one ini file now..
[20:35:01] <SWPadnos> one ini file, plus all the hal files
[20:35:09] <alex_joni_> btw, I grepped for [ in all hal files, and I only found AXIS_xx
[20:35:12] <SWPadnos> I'm saying that with this, you could put the hal files into the ini file
[20:35:23] <SWPadnos> yep, but a lot of them ;)
[20:35:26] <alex_joni_> [22:30] <alex_joni_> so you want to scrap .hal files? and move stuff to the ini?
[20:35:30] <alex_joni_> [22:30] <SWPadnos> not necessarily
[20:35:40] <alex_joni_> now you got me puzzled...
[20:35:43] <SWPadnos> right - it's just one option, but the capability doesn't exist now
[20:36:08] <SWPadnos> that's not the only goal, so I should have said "that's one possibility"
[20:36:10] <alex_joni_> I think what HAL's deficiency right now is, is too much flexibility
[20:36:23] <SWPadnos> yes, and the way we're headed, too many little config files
[20:36:39] <alex_joni_> you could have only one, for what I care
[20:36:46] <alex_joni_> or place the stuff in the ini
[20:36:51] <SWPadnos> you could, but that's not how things are being set up
[20:36:56] <alex_joni_> the user won't be able to use it one way or the other
[20:37:01] <alex_joni_> use/handle
[20:37:26] <SWPadnos> there's a problem in deciding how to do this - on one side, you don't want a 50k config file, on the other side, you don't want 50 1k files either
[20:37:31] <SWPadnos> right
[20:37:35] <alex_joni_> not really
[20:37:50] <alex_joni_> IF you want a user to hand edit these files, then 50 1k files is the way to go
[20:38:09] <SWPadnos> unless they depend on each other, and reference things in other files
[20:38:14] <alex_joni_> IF you want the user to use a tool for that, one 50k file is the way to go
[20:38:15] <SWPadnos> then it becomes more problematic
[20:38:28] <alex_joni_> if you lay it out properly, it should be OK
[20:38:35] <SWPadnos> true either way
[20:38:39] <alex_joni_> like having 45 1k files a user never touches
[20:38:49] <alex_joni_> and 5 1k files the user MIGHT want to change
[20:39:07] <alex_joni_> but it's really a question of semantics
[20:39:15] <alex_joni_> whether it's in a file or in several
[20:39:31] <alex_joni_> some prefer short files, others few files..
[20:39:44] <SWPadnos> it's kind of a mish-mash now - the ini is there, but largely only because that's what was used in emc1
[20:39:50] <alex_joni_> I get dizzy by looking at a 50k file I never saw before
[20:40:00] <SWPadnos> yeah, that's true
[20:40:11] <alex_joni_> The ini has lots of stuff not related to HAL
[20:40:28] <alex_joni_> and a few stuff that are related to hal, and some which are only needed in HAL
[20:40:38] <alex_joni_> so that's a PITA right now..
[20:40:41] <alex_joni_> I agree
[20:40:42] <SWPadnos> yep
[20:41:05] <alex_joni_> but having halcmd run sections from the ini .. don't see how that helps..
[20:41:09] <SWPadnos> it's a bad separation of data
[20:41:14] <SWPadnos> ie, there isn't any ;)
[20:41:20] <alex_joni_> just tossing the dead fish from one place to another
[20:41:36] <SWPadnos> sort of - look at what ray was looking to do
[20:41:43] <SWPadnos> load, then add, then configure
[20:41:50] <SWPadnos> (you or ray or both said that)
[20:42:11] <alex_joni_> ok, only configure MIGHT be interesting in the ini
[20:42:26] <alex_joni_> load and add should not be there (if the user won't change it)
[20:42:36] <SWPadnos> configure can almost be done by the ini, except that halcmd can't ignore the other parts of the file
[20:42:47] <alex_joni_> but then again there are some load's and add's which the user might want to do..
[20:43:12] <SWPadnos> yes, and they do specify what to load as well, by selecting a basic hardware configuration
[20:43:17] <alex_joni_> how do you do common stuff?
[20:43:27] <SWPadnos> how do you mean?
[20:43:33] <alex_joni_> core_stepper.hal
[20:43:41] <alex_joni_> core_servo.hal
[20:43:54] <alex_joni_> replicate that in every ini file?
[20:44:00] <SWPadnos> what does core_servo do? it loads the PID blocks, and sets the parameters from the ini file
[20:44:08] <alex_joni_> exactly
[20:44:29] <alex_joni_> what if tomorrow the naming of the PID block pins changes..
[20:44:40] <SWPadnos> wouldn't that make more sense if there were a [SERVO] section in the ini, which loaded the blocks, then had all the "paramx = y" lines?
[20:44:40] <alex_joni_> you'll get a mess
[20:45:17] <alex_joni_> the whole idea was to have common stuff, so you don't need to replicate them over and over again
[20:45:22] <SWPadnos> but doesn't the config chooser copy the core_* files into the "new" directory?
[20:45:30] <alex_joni_> dunno
[20:45:52] <SWPadnos> I think the consensus was that there had to be a separate copy, else a cvs update would trash any customizations the user had done
[20:46:41] <cradek> that's my understanding too
[20:46:48] <alex_joni_> if the namings change anything will get trashed anyway
[20:46:59] <alex_joni_> but probably that's another topic
[20:47:00] <SWPadnos> that was the counter-argument ;)
[20:47:11] <alex_joni_> ok, so back to the issue
[20:47:19] <alex_joni_> the thing is to stuff hal data in the ini
[20:47:29] <SWPadnos> or in a multi-section hal file
[20:47:37] <alex_joni_> what's a multisection hal file?
[20:48:01] <alex_joni_> how's that different from a big file with comments in it?
[20:48:04] <SWPadnos> one that uses the ini-style section names, and looks like a normal hal file in each section
[20:48:19] <SWPadnos> it allows programmatic separation of the sections
[20:48:28] <alex_joni_> you can do that with comments too :P
[20:48:33] <alex_joni_> grep is your friend
[20:48:49] <SWPadnos> you could, for example, have a single large CORE hal file, and choose whether to execute the [STEPPER] section or the [SERVO] section
[20:48:58] <SWPadnos> (not that I'd advocate fro that)
[20:49:28] <SWPadnos> or have an optional [TEST] section
[20:50:12] <alex_joni_> SWPadnos: I must say I'm not 100% satisfied by the way current configs are
[20:50:24] <alex_joni_> yet I'm not convinced that what you're saying will make it better
[20:50:42] <SWPadnos> I think there's too much configuration to have a perfect solution
[20:50:46] <alex_joni_> you might want to prove me wrong..
[20:51:02] <SWPadnos> well - that's where sed / awk come in
[20:51:19] <alex_joni_> * alex_joni_ silently points to cradek
[20:51:26] <SWPadnos> I can easily construct a regexp that will match a section header
[20:51:28] <alex_joni_> SWPadnos: don't say I sent you
[20:51:40] <SWPadnos> I asked for him first - he ignored me ;)
[20:51:54] <SWPadnos> and another one that will match any other section start
[20:51:57] <alex_joni_> he's busy catching up on sleep :)
[20:52:13] <SWPadnos> it's getting one of those two utilities to print everything in between that's the problem ;)
[20:52:20] <alex_joni_> why not remember the line numbers?
[20:52:35] <alex_joni_> and then use awk to split out inbetween?
[20:52:52] <alex_joni_> possibly not the nicest approach.. but it works
[20:53:00] <alex_joni_> should work anyways
[20:53:20] <SWPadnos> well - awk can be used to find the beginning of the block, then I guess I can set a variable that causes stuff to be printed untile another section is found
[20:53:23] <cradek> who me?
[20:53:29] <SWPadnos> what
[20:53:54] <alex_joni_> SWPadnos: that might work too..
[20:53:55] <SWPadnos> I'm just looking for simple (lazy) answers about sed and/or awk
[20:54:04] <alex_joni_> ask man :P
[20:54:05] <cradek> ah
[20:54:10] <cradek> I'll try
[20:54:44] <SWPadnos> I suspect that it's easier to get awk to do this, rather than sed, since sed seems to need major contortions to let you span lines
[20:54:50] <alex_joni_> one question, I remember I said I'll do a lot of things while on vacation
[20:55:00] <alex_joni_> but bugger me if I remember one of it
[20:55:10] <cradek> SWPadnos: do what? (I haven't been watching)
[20:55:18] <SWPadnos> grep /path/to/irc/logs vacation ;)
[20:55:30] <alex_joni_> cradek: say you have a ini, and you want to print an entire section
[20:55:37] <alex_joni_> that's what SWPadnos wants
[20:55:42] <SWPadnos> find a regexp, then print everything until another regexp is found
[20:56:12] <SWPadnos> possibly with some modification, if the stuff being printed matches another regexp
[20:57:02] <cradek> % awk '/^RAJ/,/^IS_0/' <sim.ini
[20:57:07] <cradek> % awk '/^RAJ/,/^IS_0/' <sim.ini
[20:57:15] <cradek> argh
[20:57:23] <SWPadnos> yes - argh
[20:57:37] <cradek> % awk '/^\[TRAJ\]/,/^\[AXIS_0\]/' <sim.ini
[20:57:42] <cradek> that's what I meant
[20:58:01] <SWPadnos> ok, or even % awk '/^\[TRAJ\]/,/^\[/' <sim.ini
[20:58:01] <cradek> awk has /re1/,/re2/ to act on lines from re1 to re2
[20:58:08] <SWPadnos> ok - cool
[20:58:18] <SWPadnos> I knew there had to be an easier way ;)
[21:00:03] <alex_joni_> SWPadnos: what setup do you have?
[21:00:08] <alex_joni_> kernel & RT ?
[21:00:16] <SWPadnos> BDI 4.30
[21:00:22] <alex_joni_> bugger it
[21:00:26] <SWPadnos> 2.6.12-magma, I believe
[21:00:34] <alex_joni_> ok..
[21:00:38] <SWPadnos> I also have a gentoo machine, but I'm not sure what it's got
[21:00:47] <SWPadnos> it'll also be 2.6 though, I think
[21:00:52] <alex_joni_> any 2.4 anywhere?
[21:01:17] <SWPadnos> don't think so, unless the BDI on my laptop is (around 2.18-2.2x, I think)
[21:01:21] <cradek> me me me
[21:01:30] <alex_joni_> was wondering if anyone wants to look at http://solaris.cs.utt.ro/~emc/emc-1.2.0-rc1.src.tgz
[21:01:44] <alex_joni_> cradek: see, you had to brag :P
[21:01:48] <cradek> arrgh
[21:01:54] <cradek> didn't I already try that?
[21:02:07] <alex_joni_> I changed ini's, so yes you did..
[21:02:15] <cradek> oh good
[21:02:18] <alex_joni_> guess we should put it up as RC..
[21:02:21] <alex_joni_> what do you think?
[21:02:31] <cradek> I wish someone else could test it
[21:02:36] <cradek> someone with a complex machine
[21:02:36] <alex_joni_> I'll ask jmk_away if he can run it on the compile_farm
[21:02:53] <alex_joni_> I'll ask Till if he can..
[21:03:02] <cradek> good idea
[21:03:24] <cradek> alex_joni_: do you remember when you made the spindle turn off when ESC is hit?
[21:03:34] <cradek> in response to my complaining?
[21:03:46] <alex_joni_> I did?
[21:03:53] <cradek> yes, I'm sure it was you
[21:04:30] <cradek> in emc2
[21:04:47] <alex_joni_> ahh yes
[21:04:47] <alex_joni_> I did ;)
[21:05:14] <cradek> I wonder if that change was responsible for also making the spindle turn off when switching to Manual mode
[21:05:45] <alex_joni> cradek: : probably
[21:05:52] <alex_joni> let me look
[21:05:52] <cradek> (bug 1384013)
[21:06:07] <alex_joni> yeah I know, pondered on adressing that a bit earlier
[21:06:15] <cradek> sorry, you were working on emc1 and I interrupted
[21:06:30] <cradek> I was just going to try to fix it, but I bet you can do it much faster
[21:06:35] <ajoni> not really working on emc1
[21:06:41] <ajoni> I can do it.. hang on
[21:07:21] <ajoni> need to read a bit of emc1 io stuff
[21:07:35] <cradek> fun
[21:07:41] <ajoni> cradek: do you have a running emc2?
[21:07:51] <cradek> yes I think so
[21:08:04] <cradek> yes
[21:08:07] <ajoni> what gets sent on Esc?
[21:08:32] <ajoni> EMC_TASK_ABORT
[21:08:46] <ajoni> just parsed tkemc, and emcsh and fount it
[21:10:22] <SWPadnos> the ESC key is "motion abort"?
[21:10:36] <ajoni> all abort
[21:10:42] <SWPadnos> ok
[21:10:50] <ajoni> on mode change EMC_TASK_SET_MODE gets sent
[21:11:15] <cradek> that seems to call EMC_TOOL_ABORT
[21:11:38] <ajoni> right
[21:11:46] <ajoni> and EMC_TOOL_ABORT stops the spindle
[21:11:53] <ajoni> and all other tool relevant stuff
[21:12:00] <cradek> why does SET_MODE call TOOL_ABORT?
[21:12:17] <ajoni> SET_MODE calls taskAbort()
[21:12:31] <ajoni> emcTaskAbort()
[21:12:43] <cradek> you are in a twisty maze of passages
[21:12:57] <cradek> I want some coffee
[21:12:58] <cradek> brb
[21:13:05] <ajoni> to abort all the task was doing? (and that implies emcMotionAbort() and emcToolAbort() )
[21:14:00] <ajoni> I think this is relevant: '16-Feb-1999 FMP changed code for issuing EMC_TASK_SET_MODE to call for
[21:14:01] <ajoni> aborts if the desired mode is manual and we're not in manual
[21:16:23] <ajoni> and the reason you were not seeing this in emc1 is probably because you weren't running bridgeporttask
[21:16:41] <ajoni> because that does exactly the same (sends SPINDLE_ABORT eventually)
[21:17:03] <ajoni> EMC_SPINDLE_ABORT even..
[21:18:06] <ajoni> cradek: say when properly caffeinized
[21:18:27] <cradek> ok, it's brewing
[21:18:35] <ajoni> read back?
[21:18:48] <cradek> yes I was running bridgeporttask
[21:18:53] <cradek> well let me make sure
[21:19:01] <ajoni> and you didn't get an abort? that's ODD
[21:19:20] <cradek> yes bridgeporttask
[21:19:30] <ajoni> strange..
[21:19:49] <ajoni> I followed the path in emc1, and it's basicly the same
[21:19:59] <cradek> let me see if my emc1 will run
[21:20:36] <ajoni> ok..
[21:21:47] <ajoni> EMC_TASK_SET_MODE calls emcTaskAbort();
[21:22:03] <ajoni> when you enter Manual from MDI or AUTO..
[21:23:04] <ajoni> after that emcTaskAbort() calls emcIoAbort(), which sends an EMC_TOOL_ABORT
[21:23:15] <cradek> oh hell
[21:23:18] <cradek> it does
[21:23:22] <cradek> I'm sorry
[21:23:34] <cradek> I could have sworn I tested it
[21:23:45] <ajoni> EMC_TOOL_ABORT is received by bridgeporttool, which sends EMC_SPINDLE_ABORT to the spindle controller
[21:23:59] <ajoni> cradek: no problem, just seemed odd as it follows the same paths ;)
[21:24:06] <ajoni> may I close the tracker?
[21:24:43] <cradek> I bet I tested it in emc1/sim
[21:24:55] <cradek> looks like it works completely differently
[21:25:10] <ajoni> different task controller
[21:25:12] <cradek> for instance you can turn the spindle on AND it leaves the brake on
[21:25:12] <ajoni> I think
[21:25:22] <cradek> yeah
[21:25:29] <ajoni> bleah :(
[21:25:53] <ajoni> yeah, but it doesn't do anything..
[21:26:14] <cradek> emc1's programming style of "copy some files to a new name and hack out parts" causes me nightmares
[21:26:55] <ajoni> yes.. I can't see any good reasons for having that many different files
[21:27:07] <ajoni> for instance a spindle controller which talks NML :(
[21:27:53] <cradek> I guess we should close the bug
[21:28:03] <ajoni> so the tool controller actually talks to some other controllers .. that's overengineered only to show off NML channels
[21:28:19] <cradek> (but I still don't want that behavior)
[21:28:24] <ajoni> ajoni is now known as alex_joni_
[21:28:58] <alex_joni_> cradek: comment out the emcTaskAbort() call in emctaskmain.cc
[21:30:22] <alex_joni_> but this is another classic example of machine logic embedded in the sources :(
[21:31:09] <SWPadnos> unfortunately, if you take it out of the source, you put it into the config file(s) :(
[21:32:26] <cradek> yeah.
[21:32:33] <alex_joni_> SWPadnos: still better
[21:32:47] <SWPadnos> yep - user configurable, once they can find the right options
[21:33:13] <alex_joni_> users don't need to worry about that
[21:33:27] <SWPadnos> integrator-configurable
[21:33:28] <alex_joni_> only a handfull of integrators might
[21:34:06] <alex_joni_> indeed
[21:35:58] <alex_joni_> ok, I'm up for a fight..
[21:36:04] <alex_joni_> the bugs are going down :D
[21:36:29] <SWPadnos> DING DING! round 2 has begun
[21:36:45] <alex_joni_> anyone care to help?
[21:36:53] <alex_joni_> it's not fair 1 against many :D
[21:36:58] <SWPadnos> uh - well, I have this bad back, you see ;)
[21:37:03] <cradek> you can always count me in
[21:37:18] <SWPadnos> I may be able to help later in the week - I'm trying to get all my accounting done, and there's a lot of it
[21:37:45] <cradek> but yuck, I see interpreter-related bugs
[21:38:09] <alex_joni_> ok.. I'm looking from the bottom up
[21:38:11] <alex_joni_> _t naming
[21:38:22] <alex_joni_> do we really need that removed?
[21:38:44] <cradek> I don't care one bit about that
[21:38:53] <alex_joni_> cradek: you've done quite a bit of coding.. what's your advice?
[21:38:58] <SWPadnos> nanming is cosmetic, and therefore unnecessary
[21:39:01] <SWPadnos> naming
[21:39:11] <alex_joni_> ok.. so a feature request at the most
[21:39:17] <alex_joni_> * alex_joni_ closes it
[21:39:18] <SWPadnos> to change - of course, names are needed ;)
[21:39:43] <SWPadnos> can you change it to a feature request?
[21:39:43] <cradek> This has been bumped up in priority as it is now a major
[21:39:43] <cradek> stumbling
[21:39:45] <cradek> block before the bdi-4 branch can be joined to HEAD
[21:39:47] <cradek> ????
[21:40:29] <cradek> oh there's talk about joining bdi4/emc-head in this bug
[21:40:29] <SWPadnos> hmmm - then it may be more important, but for the integration of lathe commands and the like (it's one route, anyway)
[21:40:30] <alex_joni_> yeah, paul's way of stirring up things
[21:40:32] <cradek> that's why it's there
[21:40:46] <alex_joni_> SWPadnos: there is no lathe stuff
[21:41:00] <SWPadnos> G33 is in bdi-4, right?
[21:41:03] <alex_joni_> and if there is, it has nothing to do with _t namings
[21:41:07] <alex_joni_> it is in emc2 too
[21:41:10] <SWPadnos> ok
[21:41:16] <alex_joni_> but that's about it
[21:41:30] <cradek> afaik, the interp accepts some lathe commands but does nothing with them
[21:41:37] <SWPadnos> right
[21:41:43] <alex_joni_> paul said he had some testing code doing lathe threading, but that's not released anywhere..
[21:42:35] <cradek> well I don't know anything about this.
[21:43:18] <alex_joni_> ok, pending now
[21:43:20] <alex_joni_> next!
[21:43:42] <alex_joni_> SWPadnos: where's the DING! DING! ?
[21:43:48] <SWPadnos> DING DING!
[21:44:01] <alex_joni_> ok ;)
[21:44:17] <cradek> ok next one: some doc file somewhere has g20/g21 backwards
[21:44:37] <alex_joni_> right
[21:44:42] <SWPadnos> "In this corner wearing white, from the city of the big shoulders, the number one contender, in a ten-round exhibition for your entertainment"
[21:44:47] <alex_joni_> user something (probably a lyx file somewhere)
[21:44:59] <cradek> I don't have lyx or the lyx files
[21:45:45] <alex_joni_> they are in CVS, I'm looking
[21:45:47] <cradek> I could edit by hand I'm sure, but the bug doesn't give the URLs or even the real file names
[21:45:50] <alex_joni_> take the next one ;)
[21:49:12] <alex_joni_> ok, found it will commit the change in a second
[21:51:04] <alex_joni_> just to make sure G20 = inch, and G21 = mm , right?
[21:51:31] <cradek> Program G20 to use inches for length units. Program G21 to use millimeters.
[21:51:41] <cradek> straight from the spec
[21:51:51] <alex_joni_> right, that's in most of the places like that :)
[21:54:21] <cradek> that's good to know
[21:54:41] <alex_joni_> only one place the other way around ;)
[21:54:54] <alex_joni_> fixed it now.. someone (who knows how) needs to generate new pdf's
[21:55:32] <SWPadnos> DING DING!
[21:55:42] <alex_joni_> :P
[21:55:59] <alex_joni_> the next 2 are cradek's ;)
[21:56:03] <alex_joni_> he submitted them
[21:56:04] <cradek> I changed the segmentqueue bugs to pending
[21:56:06] <SWPadnos> hey - it's the least I can do, with none of my Linux machines running ;)
[21:56:14] <cradek> they'll close eventually and we can forget about them
[21:56:25] <alex_joni_> OK
[21:56:27] <alex_joni_> DING DING
[21:56:32] <alex_joni_> DING DING
[21:56:33] <cradek> does anyone use tool length offset?
[21:56:40] <SWPadnos> DING DING! DING DING! (two rounds)
[21:56:47] <SWPadnos> yes - Tom Hubin does
[21:56:53] <SWPadnos> and I expect to
[21:57:01] <cradek> I mean out of us
[21:57:06] <cradek> does one of us know how it works
[21:57:08] <cradek> (not me)
[21:57:13] <alex_joni_> I think I do..
[21:57:19] <alex_joni_> I added the functionality to emc2 ;)
[21:57:27] <alex_joni_> but don't bet anything on it..
[21:57:30] <SWPadnos> are you talking about the G43 bug?
[21:57:36] <cradek> yes
[21:57:38] <SWPadnos> ok
[21:57:38] <alex_joni_> not the whole functionality, but some was missing
[21:57:55] <alex_joni_> 1205237 might be BDI related
[21:58:27] <cradek> well I'm sure I've never had that problem
[21:58:38] <cradek> but paul says it might be a tkemc bug? so I wouldn't see it
[21:58:44] <alex_joni_> I had it on a PII-233
[21:58:55] <alex_joni_> not tkemc, he means tcl library or something
[21:59:47] <alex_joni_> oh.. I tracked it a while ago
[22:00:00] <alex_joni_> then passed it over to jmk.. and it got suspended :D
[22:00:23] <alex_joni_> cradek: you might trigger it on slow machines if you change modes very quickly
[22:01:03] <cradek> I saw another timing strangeness recently
[22:01:15] <cradek> I could cause an axis to become "unhomed" by jogging twice in rapid succession
[22:01:30] <alex_joni_> oh my.. really?
[22:01:52] <cradek> push the jog arrow quickly down - up - down&hold
[22:02:11] <cradek> then it would fly right by the limit
[22:02:11] <alex_joni_> mIRC is beeping on that..
[22:02:20] <cradek> ?
[22:02:33] <alex_joni_> I just tried down - up down & hold
[22:02:40] <alex_joni_> *stupid grin*
[22:02:59] <cradek> do you understand what I mean?
[22:03:07] <alex_joni_> sure.. just fooling around
[22:03:21] <alex_joni_> I'll try it when I'll have an emc2 handy
[22:03:30] <cradek> let me try it in sim
[22:04:04] <alex_joni_> G43 is probably emc1 related
[22:04:17] <alex_joni_> oh.. category says emc1 :D
[22:04:55] <cradek> I can't immediately reproduce unhome it with sim
[22:04:59] <cradek> s/it//
[22:05:04] <alex_joni_> in emc2?
[22:05:08] <cradek> right
[22:05:23] <alex_joni_> hrmm... might be stepgen related?
[22:05:37] <cradek> let me copy over my real machine's ini
[22:07:35] <cradek> hmm
[22:07:36] <cradek> can't do it now
[22:07:40] <alex_joni_> * alex_joni_ lets you..
[22:07:41] <cradek> I wonder if it's fixed in simple_tp...
[22:07:54] <alex_joni_> huh.. that might be something..
[22:08:08] <cradek> I'm going to commit simple_tp and revert to HEAD
[22:08:09] <alex_joni_> btw, don't loose motion synched IO out of sight with simple_tp ;)
[22:08:22] <alex_joni_> don't you have a second dir?
[22:08:26] <cradek> oh I deleted all that
[22:08:36] <alex_joni_> but commit simple_tp, I want to look at it..
[22:08:48] <alex_joni_> looked at what's in CVS, not really complete I'd say :)
[22:08:54] <cradek> it has a bug with very short motions
[22:10:17] <alex_joni_> that can be fixed I guess ;)
[22:12:19] <cradek> you can go ahead and finish it if you like...
[22:14:41] <ajoni> ajoni is now known as alex_joni_
[22:17:20] <cradek> alex_joni: I can't reproduce the unhome bug
[22:17:29] <cradek> I will go try it on the actual machine
[22:17:34] <cradek> I know I could do it reliably before
[22:17:36] <alex_joni_> might have been a glitch.. :)
[22:17:47] <cradek> no, I did it a lot of times
[22:17:48] <alex_joni_> but commit simple_tp first ;)
[22:17:53] <cradek> I did
[22:17:55] <alex_joni_> * alex_joni_ wants to look..
[22:18:02] <alex_joni_> didn't see a comment..
[22:18:11] <alex_joni_> ok, seen it ;)
[22:18:14] <cradek> I got the email already
[22:19:17] <alex_joni_> yup, me too (got it now)
[22:22:16] <cradek> tpRunCycle virtually ignores time quantization, which turns out to not be good enough
[22:23:33] <alex_joni_> YAY, didn't notice the 1.1 release
[22:23:38] <alex_joni_> you never said anything
[22:26:13] <cradek> jepler did it while I wasn't looking!
[22:26:25] <alex_joni_> yeah sure :P
[22:26:26] <cradek> well forget what I said about the unhome bug - I can't reproduce it now
[22:26:36] <alex_joni_> :( that's frustrating I guess
[22:26:52] <alex_joni_> I know I hate such behaviour
[22:27:04] <cradek> I'm sure it was emc2 but I'm going to try in emc1 too
[22:27:32] <cradek> nope
[22:27:34] <cradek> not there either
[22:27:37] <cradek> oh well
[22:28:46] <alex_joni_> chris: could you add a few more comments on tpRunCycle?
[22:29:07] <alex_joni_> I get it because we talked about it, but someone seeing it for the first time might not..
[22:29:33] <alex_joni_> especially on: drfatrv = 0.5 * pmSq(tc->vel) / tc->accel;
[22:30:11] <cradek> yeah I intend to comment all that stuff
[22:30:54] <alex_joni_> ok then, looks good
[22:31:04] <cradek> well, it doesn't work :-)
[22:31:06] <alex_joni_> how come tcRunCycle isn't there anymore.. what did that do?
[22:31:16] <cradek> no clue
[22:31:23] <cradek> something about blending
[22:32:01] <alex_joni_> I think it did the same you're doing now.. only mixing in the next move too
[22:32:13] <cradek> yeah
[22:32:23] <cradek> but I don't know how tpRunCycle and tcRunCycle worked together
[22:32:37] <cradek> it may or may not have been unncessarily complicated
[22:32:41] <cradek> (remains to be seen)
[22:32:55] <cradek> so much of it seemed like it was obtuse on purpose
[22:33:40] <alex_joni_> lol
[22:33:52] <cradek> looking for a good example
[22:34:09] <cradek> ok like tpAddLine
[22:34:14] <cradek> there are two points, the start and end
[22:34:19] <cradek> I called them ... start and end
[22:34:35] <cradek> they were called goal_tran_pose (start) and tran_pose
[22:34:38] <cradek> (end)
[22:34:47] <cradek> so the START was called "goal"
[22:35:03] <alex_joni_> yeah, seen that..
[22:38:48] <alex_joni_> seems my modem loves me.. it works as long as I'm standing next to it, as soon as I leave it looses the signal :(
[22:39:25] <cradek> ha
[22:39:40] <SWPadnos> alex joni - "Antenna Man!!!"
[22:39:43] <alex_joni_> imagine that..
[22:39:58] <alex_joni_> SWPadnos: actually at 433 MHz you are pretty suitable for an antenna :D
[22:40:04] <alex_joni_> er.. my arm is ;)
[22:40:19] <SWPadnos> it's more likely that the ground plane shifts
[22:40:34] <alex_joni_> not sure ;)
[22:40:45] <SWPadnos> I suspect that a person would need much longer arms, since the conductivity of people isn't so great
[22:41:42] <alex_joni_> * alex_joni_ signs up for longer arms
[22:41:56] <alex_joni_> would be nice to tie my shoelaces without bending over ROFL
[22:43:54] <alex_joni_> SWPadnos: do I hear a DING DING?
[22:44:00] <alex_joni_> * alex_joni_ closed another one ;)
[22:44:03] <SWPadnos> DING DING!
[22:44:19] <alex_joni_> I fixed that when I reverter RUM changes ;)
[22:44:24] <alex_joni_> reverted
[22:45:03] <alex_joni_> ok... think I'll call it a night of fixing bugs..
[22:46:18] <SWPadnos> DING DING!
[22:46:44] <alex_joni_> no I meant I'm going away :D
[22:46:53] <alex_joni_> so that is DING DING DING DING DING
[22:47:04] <alex_joni_> end of match, we'll have a rematch tomorrow :D
[22:49:28] <SWPadnos> ding dong!
[22:50:03] <alex_joni_> marco?