Back
[01:24:36] <cradek> jmk_away: you around?
[01:48:34] <cradek> jmk_away: I just cds up'd and reproduced the twitch. I sent you my configs.
[01:48:40] <cradek> err cvs up'd
[01:57:36] <cradek> hello
[02:44:44] <cradek> hoser
[02:45:12] <jmk_away> hi cradek
[02:45:15] <jmk_away> jmk_away is now known as jmkasunich
[02:45:17] <cradek> hello
[02:45:43] <jmkasunich> oops
[02:45:53] <cradek> me too
[02:45:54] <jmkasunich> got your email
[02:45:58] <cradek> hoser is the name of my other computer
[02:46:11] <cradek> I typed it into the wrong window
[02:46:16] <cradek> did you try the files yet?
[02:46:51] <jmkasunich> just unzipping 'em now
[02:50:22] <cradek> also tonight I tested the change you made to jogging vs. commanded position
[02:50:30] <cradek> it works just fine now, thanks for fixing that
[02:50:44] <jmkasunich> you're welcome - thanks for calling it to my attention
[02:51:06] <cradek> did you see the new bug I put in the tracker? not sure if it's your area or not
[02:52:12] <jmkasunich> yeah, that would be me
[02:52:19] <cradek> sorry :-)
[02:52:23] <jmkasunich> that's probably easier to fix than the other one
[02:52:26] <jmkasunich> * jmkasunich takes a look
[02:54:20] <jmkasunich> I intentionally coded it to abort all motion... I wonder why?
[02:54:53] <cradek> probably because you didn't notice there was an axis specified in the message?
[02:55:25] <jmkasunich> IOW, because the emc1 version was poorly documented
[02:55:51] <cradek> oh say it ain't so
[02:55:53] <jmkasunich> if axis = a legal axis number, it aborts that axis only, otherwise it aborts all axis (sort of)
[02:56:01] <jmkasunich> that's a hack, IMO
[02:56:15] <cradek> sounds like there should be an ABORT_ALL message
[02:56:18] <jmkasunich> there should be ABORT, and ABORT_AXIS, if they want those two different functions
[02:56:26] <cradek> yeah, or that
[02:57:09] <jmkasunich> I wondered why every time I hit the ABORT button on tkemc, there is a burst of 8 or 9 ABORT commands... now I know
[02:57:12] <jmkasunich> (I think)
[02:58:56] <cradek> in emc1:
[02:59:00] <cradek> when I jog (in z)
[02:59:03] <cradek> Issuing EMC_AXIS_ABORT -- (+120,+16, +30, +2,)
[02:59:06] <cradek> when I hit ESC
[02:59:11] <cradek> Issuing EMC_TASK_ABORT -- (+503,+12, +32,)
[02:59:18] <cradek> 30, 32 are the serial numbers
[02:59:27] <cradek> the axis is "unspecified"??
[02:59:34] <cradek> (I don't understand how these debug messages are printed)
[02:59:41] <cradek> OH
[02:59:44] <cradek> different message
[02:59:47] <cradek> TASK_ABORT aborts all
[02:59:53] <jmkasunich> those are printed from user space
[02:59:53] <cradek> AXIS_ABORT aborts one axis
[03:00:04] <cradek> I didn't read it carefully
[03:00:06] <jmkasunich> at the emcmot level, there is only one abort command
[03:00:14] <cradek> oh, ok
[03:00:45] <jmkasunich> I just added a print of the axis to the kernel log, and am trying differnet combos now
[03:01:08] <jmkasunich> ah-ha!
[03:01:55] <jmkasunich> ending a jog sends EMC_AXIS_ABORT (as you noted), which is sent to the RT code as ABORT (axisnum)
[03:01:56] <cradek> ?
[03:02:51] <jmkasunich> hitting the ABORT button sends EMC_TASK_ABORT, which is sent to the RT code as a series of ABORT commands, ABORT(0), (1), (2)---(6),(7),(7)
[03:03:10] <jmkasunich> your guess is as good as mine as to why they send two 7's
[03:03:14] <cradek> haha
[03:04:12] <jmkasunich> * jmkasunich looks for the code that translates EMC_TASK_ABORT into the individual ABORT calls
[03:05:41] <jmkasunich> it's worse than that
[03:05:58] <jmkasunich> emcAxisAbort sets axis and sends an ABORT command to the RT
[03:06:14] <jmkasunich> emcTrajAbort does not set axis and sends an ABORT to the RT
[03:06:26] <jmkasunich> (with axis set to whatever garbage was there before)
[03:06:28] <cradek> ugh
[03:06:39] <cradek> are you sure it doesn't have a default value (somewhere)?
[03:06:41] <jmkasunich> emcMotionSetDebug() does the same
[03:06:57] <cradek> you're talking about emc1 now, right?
[03:07:24] <jmkasunich> emc2 code, but this is in taskintf.cc, where I have done only minimal mucking around
[03:08:27] <jmkasunich> emxMotionAbort() calls emcAxisAbort once for each axis, then calls emcTrajAbort - that explains the second 7
[03:08:39] <cradek> ohhh
[03:08:43] <cradek> yuck
[03:09:40] <jmkasunich> the "proper" solution is separate commands to the RT code for axis aborts and overall aborts
[03:09:53] <jmkasunich> not sure how ugly that will be
[03:10:12] <cradek> I don't see why there can't be a special axis number that means "all"
[03:10:57] <cradek> axis is an int, so there are plenty of extra bits to use
[03:10:59] <jmkasunich> only if it's well documented
[03:11:07] <cradek> sure
[03:11:12] <cradek> (your way is more elegant)
[03:11:19] <jmkasunich> besides, aborting a single axis is fundamentally different than aborting the whole traj planner
[03:11:43] <cradek> the name ABORT has confused several people lately
[03:11:51] <cradek> it sounds like an emergency or error
[03:12:04] <cradek> what you want when you release the jog key is something like STOP
[03:12:09] <jmkasunich> adding another command isn't hard - one line in a enum (motion.h) and one case in a switch (command.c)
[03:12:31] <jmkasunich> more to the point - aborting an axis _only_ makes sense in free mode
[03:12:49] <cradek> so should it be called JOG_STOP?
[03:13:00] <jmkasunich> dunno
[03:13:09] <jmkasunich> other things besides jogs happen in free mode
[03:13:12] <jmkasunich> (like homing)
[03:13:27] <cradek> JOG_CONT
[03:13:29] <cradek> JOG_INCR
[03:13:40] <cradek> JOG_STOP?
[03:13:47] <jmkasunich> I expect that ABORT during a homing sequence would (should) stop the sequence
[03:13:55] <cradek> what other messages happen during homing?
[03:14:11] <jmkasunich> there are actually 3 already, CONT, INCR, and ABS
[03:14:28] <jmkasunich> I don't thing the GUIs ever send ABS, but the motion controller will accept it
[03:14:33] <cradek> huh
[03:14:39] <cradek> yeah, hadn't run into that one
[03:15:11] <jmkasunich> take a look at src/emc/motion/command.c:493
[03:15:23] <cradek> I see it
[03:15:35] <cradek> it's on line 605 for me
[03:15:47] <jmkasunich> lotta duplicated code there, eh?
[03:15:53] <jmkasunich> huh?
[03:16:10] <jmkasunich> oh, that's JOG_ABS
[03:16:22] <cradek> maybe our files are different
[03:16:37] <jmkasunich> JOG_CONT is at 493, and JOG_INCR is at 557
[03:16:48] <cradek> yep
[03:17:59] <jmkasunich> all work exactly the same, they start a free mode move toward a certain point
[03:18:02] <jmkasunich> only the point varies
[03:18:09] <jmkasunich> for incr, it is based on current pos
[03:18:15] <jmkasunich> for abs, it is speficied in the command
[03:18:24] <jmkasunich> for CONT, it is beyond the end of travel
[03:18:42] <cradek> another hack?
[03:18:54] <jmkasunich> all three can be stopped by an abort (but usually you allow abs or incr to go to completion)
[03:19:06] <jmkasunich> not really - I think that is very reasonable
[03:19:32] <cradek> we noticed that two JOG_INCR sent too close will cause you to end up around 1.5*incr
[03:19:59] <cradek> it's possible we are doing something wrong (not polling for the completion of the previous command?)
[03:20:01] <jmkasunich> with emc1 or 2?
[03:20:05] <cradek> 1
[03:20:16] <jmkasunich> that is a known bug in 1, I fixed it in 2
[03:20:17] <cradek> it might be an AXIS bug
[03:20:21] <cradek> aha
[03:20:22] <cradek> cool
[03:20:38] <cradek> let me try it in 2
[03:20:40] <jmkasunich> in 1, when the RT code gets an INCR command, it adds the increment to the current position to get the new target position
[03:20:54] <cradek> that would completely explain it
[03:21:05] <jmkasunich> in 2, when the RT code gets an INCR command, it adds the incr to the _target_ position to get the new target position
[03:21:30] <cradek> you're right, it works
[03:21:32] <cradek> terrific
[03:21:38] <cradek> another bug that's not in AXIS
[03:21:49] <jmkasunich> ;-)
[03:22:02] <jmkasunich> line 581 is the code
[03:23:21] <jmkasunich> fixing it in 1 is non-trivial
[03:23:42] <jmkasunich> they used the coord mode traj planner to plan jogs in emc1, doing some very strange stuff
[03:24:03] <jmkasunich> I truly didn't understand it (and was unaware that it could handle multi-axis jogs at the same time)
[03:24:30] <jmkasunich> I added a very simple "free mode planner" for each axis in emc2, the coord mode planner is never used in free mode
[03:26:13] <jmkasunich> I'm inclined to rename the existing ABORT command to ABORT_ALL
[03:26:27] <cradek> that sounds reasonable to me
[03:26:28] <jmkasunich> and add a new command
[03:26:43] <jmkasunich> the question is exactly what the new one should
[03:26:46] <jmkasunich> should do
[03:26:59] <jmkasunich> if in free mode, it's easy - stop the specified axis
[03:27:06] <jmkasunich> if not in free mode, then what?
[03:27:09] <cradek> emc1 has a bug where if you send JOG_CONT ABORT JOG_CONT too fast, it ignores the second JOG_CONT
[03:27:14] <cradek> emc2 does not have this bug
[03:27:53] <jmkasunich> IMO, ABORT_AXIS should _only_ be sent in free mode, but I'm not gonna count on that happening
[03:28:00] <cradek> can it just give an error?
[03:28:12] <jmkasunich> I guess
[03:28:25] <cradek> I really think it should be STOP_AXIS or JOG_STOP so it doesn't look like an error or emergency
[03:28:41] <jmkasunich> the prob is that right now, errors issued by the motion controller are logged in the kernel log only, and don't appear to the user at all... pretty confusing at best
[03:28:56] <cradek> oh, yeah
[03:29:27] <jmkasunich> I don't know enough about the user space code to address that
[03:30:03] <jmkasunich> IMO, there should be a mechanism for the RT code to send a string back to the user code, which the GUI would then display to the user in a pop-up or something
[03:30:38] <jmkasunich> right now, some (and only some) errors are detected and displayed in user space by ad-hoc code
[03:30:50] <jmkasunich> IOW, the RT code detects the error and shuts down
[03:30:59] <cradek> the interpreter can send those to the gui through the error channel, but I don't know anything about it because Jeff wrote that part
[03:31:04] <jmkasunich> then the user code detects the same error (using duplicate code) and displays it
[03:31:21] <jmkasunich> instead, the detection should be done in only one place
[03:31:37] <jmkasunich> following error is the one I'm thinking about specifically
[03:31:53] <jmkasunich> does AXIS every display a following error message in emc1? emc2?
[03:32:04] <cradek> let me check
[03:33:00] <cradek> emc1: yes
[03:34:04] <cradek> emc2: no
[03:34:07] <jmkasunich> to make a ferror in emc2, open a shell, do bin/halcmd setp stepgen.0.maxfreq 0
[03:34:10] <cradek> emc2 gives an ABORT storm
[03:34:14] <cradek> the error never comes up
[03:34:20] <cradek> (I think that's what you called it)
[03:34:30] <jmkasunich> yeah
[03:34:39] <jmkasunich> I'm not sure what is going on there
[03:34:43] <cradek> I can easily trigger it with the helical arc bug :-)
[03:35:09] <jmkasunich> I think the RT code reports the ferror, and the user space code is using "ABORT" as a "clear faults" command
[03:35:13] <cradek> but the important part is that in emc2 the following error does not pop up.
[03:35:35] <jmkasunich> but the fault doesn't get cleared in emc2, hence the storm as the user space code pounds on it
[03:35:43] <cradek> ugh
[03:35:52] <jmkasunich> fault handling really sucks
[03:36:38] <jmkasunich> I wish the user side was easier to understand, easier to trace the path of execution
[03:36:52] <cradek> being in c++ is what makes it hard for me
[03:36:56] <jmkasunich> IOW, what chunk of code is sending all those aborts
[03:37:00] <jmkasunich> me too
[03:37:28] <cradek> I have the c++ book at work but can't bring myself to read more than about two pages in a sitting
[03:37:59] <jmkasunich> lol... same here, I bought one several months back, forced myself to read about a third of it, but gave up
[03:38:02] <cradek> can't bring myself to care about a language I'll never voluntarily write something in
[03:38:20] <jmkasunich> lololol
[03:38:48] <cradek> I might use the standard containers in a program, but would never write heavy OO stuff in it
[03:39:03] <jmkasunich> in emc1, what tells AXIS to print a following error message?
[03:39:28] <cradek> AXIS sets up an error channel:
[03:39:32] <cradek> NML *c = new NML(emcFormat, "emcError", "xemc", file);
[03:39:32] <jmkasunich> cause whatever it is, it obviously ain't happening in emc2
[03:39:58] <jmkasunich> xemc is the AXIS process?
[03:40:02] <cradek> then polls it with
[03:40:09] <cradek> that->c->read()
[03:40:29] <cradek> umm, that line was probably copied from xemc
[03:40:47] <cradek> so, I guess so
[03:40:54] <jmkasunich> are there distinct messages thru that channel for every error?
[03:42:00] <cradek> ummm
[03:42:24] <jmkasunich> IOW, is the result of that read() go to a god-awful big switch()?
[03:42:26] <cradek> having trouble deciphering the C
[03:42:30] <cradek> yes
[03:42:51] <cradek> jeff wrote a nasty preprocessor thing to condense the god-awful switch() into about 12 lines
[03:42:54] <jmkasunich> the switch is on "type" or something like that
[03:43:08] <cradek> right
[03:43:13] <cradek> type EMC_OPERATOR_ERROR
[03:43:17] <cradek> type NML_ERROR
[03:43:17] <cradek> etc
[03:43:33] <jmkasunich> which type results in the following error message?
[03:44:19] <cradek> trying to figure it out...
[03:45:08] <jmkasunich> bet it's operator error
[03:45:39] <jmkasunich> emc2/src/emc/task/taskintf.cc:1484
[03:46:37] <cradek> I can't figure it out without recompiling
[03:46:47] <jmkasunich> s'ok
[03:47:02] <jmkasunich> I'm tracking it backwards from line 1484
[03:47:29] <jmkasunich> that calls src/emc/motion/usrmotintf.c:273
[03:49:03] <jmkasunich> which calls src/emc/motion/emcmotutil.c:71
[03:49:26] <jmkasunich> another well documented function
[03:49:32] <jmkasunich> :-(
[03:50:46] <cradek> Dec 23 21:26:18 max kernel: 16829: ERROR: joint 2 following error
[03:50:52] <cradek> here's what it looks like in the log, if that helps
[03:50:55] <jmkasunich> apparently there is a ring buffer for error messages
[03:53:49] <cradek> I feel bad for distracting you from the PID work you wanted to do
[03:54:15] <jmkasunich> that is issued in src/emc/motion/control.c:622
[03:54:31] <jmkasunich> that's ok, any debugging is good debugging
[03:54:51] <jmkasunich> and tossing things back and forth can be very productive
[03:55:04] <cradek> aha, you found it
[03:55:16] <jmkasunich> reportError() is busted
[03:55:48] <cradek> /* not to the RCS buffer (at least for now) */
[03:55:52] <cradek> // emcmotErrorPut(emcmotError, error);
[03:56:02] <jmkasunich> just got there ;-)
[03:56:07] <jmkasunich> I wonder why I did that?
[03:56:17] <jmkasunich> only one way to find out
[03:56:23] <cradek> you should put XXX by things like that
[03:56:28] <cradek> then you can grep for them
[03:56:35] <jmkasunich> usually I put a FIXME
[03:56:43] <cradek> that works too
[03:57:00] <jmkasunich> the editor I use most often (kate) automatically highlights FIXME in blue ;-)
[03:57:23] <cradek> vim does that with XXX too
[03:57:33] <jmkasunich> ok, uncommented, let's see what happens
[03:58:55] <jmkasunich> how do you trigger the helical error?
[03:59:03] <cradek> g0x0y0z1
[03:59:09] <jmkasunich> MDI mode?
[03:59:12] <cradek> g3x.1y.1i.005j.005z0
[03:59:14] <cradek> yes
[03:59:20] <cradek> err
[03:59:27] <cradek> g3x.1y.1i.05j.05z0
[03:59:29] <cradek> f10
[03:59:46] <cradek> or you can do it in a program
[04:00:02] <cradek> it's in that bugreport if you want to copy and paste it
[04:00:26] <jmkasunich> got a popup saying "joint 2 following error"
[04:00:31] <cradek> yay
[04:00:31] <jmkasunich> and an abort storm
[04:00:38] <cradek> not so much yay
[04:01:22] <jmkasunich> well that's half the battle
[04:01:34] <cradek> and I also got someone else to see that bug! (Paul couldn't get it)
[04:01:46] <jmkasunich> which bug, the helical one?
[04:01:50] <cradek> yes
[04:02:13] <jmkasunich> that is in the interp or coord mode planner, both of which are pretty much unchanged from emc1
[04:02:47] <cradek> yeah Iit's the planner not considering
[04:02:47] <cradek> err
[04:02:52] <jmkasunich> and neither of which I know very well, which is why I haven't looked into it
[04:02:52] <cradek> yeah I'm sure it's the planner not considering the Z distance when figuring the velocity
[04:03:33] <cradek> it picks velocity based on X,Y and then does Z proportionally (which makes Z way too big)
[04:03:33] <jmkasunich> the planner needs some serious overhauling, but there's so much other stuff to do first
[04:04:11] <jmkasunich> a key goal for me is enhanced modularity, so that the old planner can be popped out and a new one (or modified one) inserted in it's place
[04:04:14] <cradek> it's possible I could fix it - but I haven't looked for it yet
[04:04:36] <jmkasunich> the planner is rather obscure, and poorly commented.
[04:04:56] <cradek> oh that has never stopped me before
[04:04:58] <cradek> :-)
[04:05:01] <jmkasunich> in particular, it's interface to the rest of the program isn't really documented, so it's hare to isolate it
[04:05:12] <jmkasunich> s/hare/hard/
[04:05:33] <jmkasunich> I wonder if we can track down the cause of the abort storm?
[04:05:44] <cradek> I think emc1 does it too
[04:05:57] <jmkasunich> abort storms, or helical bug?
[04:06:01] <cradek> or at least something like it
[04:06:03] <cradek> the abort storm
[04:06:10] <jmkasunich> I wasn't aware of that
[04:06:16] <cradek> let me turn on debug and try it
[04:06:31] <jmkasunich> (I don't actually have a working emc1 installed here)
[04:06:39] <cradek> then you will have to trust me
[04:08:50] <cradek> axis 2 following error
[04:08:51] <cradek> spindleonlytaskintf.cc 1016: !ERROR! Error on axis 2.
[04:08:51] <cradek> Motion id -10 took 0.029790 seconds.
[04:08:51] <cradek> Motion id 0 took -0.000000 seconds.
[04:08:59] <cradek> extDioWrite: index 9 value 0x01
[04:08:59] <cradek> 00000000 00000000 00000010 00000000
[04:08:59] <cradek> extDioWrite: index 9 value 0x01
[04:08:59] <cradek> 00000000 00000000 00000010 00000000
[04:08:59] <cradek> extDioWrite: index 9 value 0x01
[04:09:01] <cradek> ...
[04:09:10] <cradek> ok, it doesn't
[04:09:24] <cradek> but it does write to the parport continuously until you go back into machine-on
[04:10:06] <jmkasunich> at one time I kinda understood the abort storm....
[04:10:17] <jmkasunich> * jmkasunich tries to prod his feeble brain
[04:10:38] <cradek> it should be easy to hook the debugger to emctask and at least see what loop it's in
[04:11:06] <jmkasunich> I think it has to do with the SET_JOINT_ERROR_FLAG() call at control.c:624
[04:11:21] <jmkasunich> that sets a flag to indicate that the joint is faulted
[04:11:38] <jmkasunich> I think the abort storm is the user space code attempting to clear that flag
[04:13:42] <jmkasunich> * jmkasunich has never learned to use the gnu debugger
[04:14:01] <jmkasunich> (ain't very usefull for realtime code)
[04:15:20] <cradek> taskintf.cc:597 is what generates the ABORTs
[04:15:45] <cradek> no, forget it
[04:15:45] <cradek> ack
[04:16:10] <jmkasunich> that sends them to the rt code
[04:16:26] <jmkasunich> it is called when an ABORT NML message is received
[04:16:34] <jmkasunich> but who's sending the message?
[04:17:10] <cradek> so that won't be in emctask?
[04:17:16] <jmkasunich> dunno
[04:17:47] <jmkasunich> the only thing I _really_ understand is the realtime code
[04:17:57] <jmkasunich> I have bits and snippets of the rest
[04:18:22] <jmkasunich> emcAxisAbort can be called from emctaskmain.cc, and taskintf.cc
[04:19:00] <jmkasunich> the one in taskintf.cc is the "emcMotionAbort" one (that calls it eight times)
[04:19:13] <cradek> emctaskmain.cc:1980
[04:19:20] <cradek> this is the caller
[04:19:33] <cradek> so the problem is execState = EMC_TASK_EXEC_ERROR
[04:21:35] <jmkasunich> I think the code around line 1980 assumes that an ABORT will "clear the error", making execState become something other than TASK_EXEC_ERROR
[04:21:48] <cradek> I see that too, but it's not working
[04:22:01] <jmkasunich> but emc2's motion controller doesn't clear the error right away
[04:22:20] <jmkasunich> that might be a philosophical difference I have with the original designers
[04:22:30] <cradek> at line 1999 it does change execState
[04:22:56] <cradek> but somehow it gets right back to EXEC_ERROR
[04:23:40] <jmkasunich> emcStatus is an NML buffer, I think it is getting (indirectly) info from the motion controller
[04:25:30] <jmkasunich> line 2034 can set it to ERROR
[04:25:49] <jmkasunich> and 2079
[04:27:46] <cradek> the states go
[04:27:48] <cradek> EXEC_ERROR
[04:27:49] <jmkasunich> duh... I'm guessing it's 2079
[04:27:50] <cradek> EXEC_DONE
[04:27:54] <cradek> EXEC_WAITING_FOR_MOTION_AND_IO
[04:27:59] <cradek> the EXEC_ERROR again
[04:28:48] <cradek> line 2102 sets it back to EXEC_ERROR
[04:29:20] <cradek> I meant "then" EXEC_ERROR again
[04:29:32] <jmkasunich> if emcStatus->motion.status == RCS_ERROR, then we'll get an abort storm, I bet
[04:30:00] <cradek> exactly
[04:30:31] <jmkasunich> see the code starting at line 2681?
[04:30:49] <cradek> yes
[04:31:04] <jmkasunich> those are the errors that are detected in the user space code, instead of (or in parallel with) being detected by the motion controller and reported to user space
[04:31:26] <cradek> ok
[04:31:43] <jmkasunich> the controller actually has a much longer list of things that can be detected and reported... I dunno why these are treated special
[04:32:16] <jmkasunich> anyway, back to motion.status
[04:32:31] <cradek> I bet if you reset it at line 1999 you will fix the abort storm
[04:32:51] <jmkasunich> not if I don't understand why it's happening
[04:33:06] <jmkasunich> I think the problem is philosophical
[04:34:07] <jmkasunich> the original coders use the code in emctaskmain to reset the fault in the motion controller when the abort happens (without waiting for the user to acknowledge it by closing the fault message dialog)
[04:34:36] <jmkasunich> I think the motion controller should remain in a faulted state until the user explicitly resets it (for example, by closing the fault dialog)
[04:35:16] <jmkasunich> I coded the motion controller accordingly, so it continues to report fault status.... and the loop keeps trying to reset it
[04:35:23] <cradek> well it goes into machine off state
[04:36:31] <cradek> line 2028 is what kicks it out of TASK_EXEC_DONE
[04:37:18] <cradek> emcTaskCheckPreconditions returns the next state
[04:37:35] <jmkasunich> I'm still trying to figure out who writes to emcStatus->motion.status
[04:39:50] <cradek> taskintf.cc:1528
[04:39:57] <cradek> is where it is written
[04:40:10] <cradek> 1527
[04:40:27] <jmkasunich> no wonder my grep couldn't find it
[04:40:36] <cradek> nothing escapes the debugger
[04:40:40] <jmkasunich> (grepping for motion.status, not stat->status)
[04:41:28] <jmkasunich> ok, emcMotionUpdate() (line 1457) reads the emcmot status from shmem
[04:42:06] <jmkasunich> sets "error" to zero (line 1506)
[04:43:21] <jmkasunich> and sets stat->status to ERROR if stat->traj.status or stat->axis[n].status is ERROR
[04:43:47] <cradek> agreed
[04:43:59] <jmkasunich> I'm guessing that stat->traj.status is set by emcTrajUpdate() (called from line 1499)
[04:44:38] <jmkasunich> and axis[n].status by emcAxisUpdate() (which is called from 1498, but only for axis 0... that's odd)
[04:45:39] <cradek> AxisUpdate takes numAxes
[04:45:43] <cradek> it loops
[04:45:45] <jmkasunich> I see - emcAxisUpdate() should be called emcAxesUpdate, it loops
[04:45:51] <cradek> haha
[04:45:57] <cradek> IT LOOPS!
[04:46:10] <cradek> it's almost as if we both noticed that
[04:46:46] <jmkasunich> line 854
[04:47:01] <cradek> yep
[04:47:33] <cradek> my text is going fuzzy - I need to call it a night
[04:47:35] <jmkasunich> gawd this stuff is so convoluted
[04:47:52] <jmkasunich> wow, it is getting late
[04:48:01] <cradek> only 22:30 here but it seems later
[04:48:04] <jmkasunich> where are you anyway?
[04:48:06] <cradek> NE
[04:48:19] <cradek> you?
[04:48:22] <jmkasunich> OH
[04:48:32] <cradek> that's still CST isn't it?
[04:48:36] <jmkasunich> EST
[04:48:39] <cradek> ah
[04:48:42] <cradek> so a little later for you
[04:48:47] <jmkasunich> 11:45
[04:48:59] <cradek> I just went through OH last April
[04:49:06] <cradek> lots of industry there, pretty neat
[04:49:13] <cradek> have you been to Fair Radio Sales?
[04:49:20] <jmkasunich> most of it is shut down and rusting
[04:49:21] <jmkasunich> nope
[04:49:26] <jmkasunich> where is that?
[04:49:33] <cradek> let me ask google
[04:50:02] <cradek> Lima
[04:50:22] <cradek> it's a great place if you like surplus stuff
[04:50:34] <jmkasunich> surplus electronics?
[04:50:41] <jmkasunich> or everything?
[04:50:46] <cradek> electronics
[04:50:49] <cradek> www.fairradio.com
[04:51:17] <jmkasunich> http://www.electronicsurplus.com
[04:51:20] <jmkasunich> is here in cleveland
[04:51:49] <cradek> http://members.cox.net/dalehcook/radios/pages/multi.shtml
[04:51:58] <cradek> look at the end of this page at the "simpson genescope"
[04:52:07] <cradek> I got one of these at fair radio
[04:52:22] <cradek> (in one of my other lives I fix old radios)
[04:52:33] <cradek> it's a sweet piece of equipment
[04:52:38] <jmkasunich> I also visit
http://www.hgrindustrialsurplus.com and
http://www.mckeanmachinery.com fairly often
[04:52:45] <cradek> oh I was at HGR too
[04:52:50] <cradek> that place is amazing
[04:53:00] <cradek> bought my Tek storage scope there
[04:53:16] <cradek> funny idea of a vacation I have, isn't it?
[04:53:30] <jmkasunich> the kind of thing I'd do
[04:53:44] <cradek> you should go to Fair Radio if it's not far
[04:53:48] <jmkasunich> (in fact, I visited HGR and McKean on the first day of my xmas break
[04:54:05] <jmkasunich> I already have too much electronic junk around
[04:54:13] <cradek> well I have that problem too
[04:54:14] <jmkasunich> "I can use that for a project"
[04:54:19] <cradek> "someday"
[04:54:23] <jmkasunich> too many projects, not enough time
[04:55:21] <cradek> well goodnight, hope you have a good christmas
[04:55:25] <jmkasunich> I also shop the dumpster at work - the stuff they throw away is shamefull
[04:55:37] <cradek> yeah I saw your linear motors...
[04:55:49] <jmkasunich> you too... enjoy
[04:55:50] <cradek> I work at a software company so the only junk I get from there is computers
[04:55:58] <jmkasunich> I have some of those too
[04:56:19] <jmkasunich> (but nothing recent... my best is a 600MHz P3
[04:56:29] <cradek> well I wish I had known you in April - don't know when I'll get out that way again.
[04:56:42] <jmkasunich> you planning on going to the fest?
[04:56:55] <cradek> I dunno. will it be chicago you think?
[04:57:11] <jmkasunich> not the city, but I think it's somewhere in IL
[04:57:30] <cradek> not sure. That's a good 8 hour drive for me
[04:58:10] <cradek> through iowa, the most boring state ever
[04:58:35] <cradek> it would be fun, but I'm not sure how much use I could be
[04:58:41] <jmkasunich> tentatively it will be at Cardinal Engineering (Roland Friestad)
[04:58:47] <jmkasunich> in Cameron, IL
[04:59:14] <cradek> I don't know much about emc really...
[04:59:23] <cradek> aha, cameron is only 6.5 hr
[04:59:28] <jmkasunich> what about AXIS?
[04:59:43] <jmkasunich> you know as much about the GUIs as I do about the motion controller
[04:59:57] <cradek> yeah maybe so
[04:59:57] <jmkasunich> (and I know as little about the GUIs as you do about the motion controller)
[05:00:10] <jmkasunich> we'd make a good team ;-)
[05:00:17] <cradek> I think we already are that
[05:00:25] <cradek> so what happens at fest?
[05:00:38] <cradek> I'm not sure what we could do that we can't do here at least as easily (since we have our home equipment at hand)
[05:00:43] <jmkasunich> well, that depends on how well we organize it
[05:01:01] <jmkasunich> it is certainly easier to communicate when you can point at things, draw pictures, etc
[05:01:15] <cradek> probably what would happen is I'd get jealous of all the real machines, and want a big servo thing.
[05:01:22] <cradek> that's true.
[05:01:38] <jmkasunich> face-to-face meetings are really good for planning and deciding the big issues - then you go home to work on the details
[05:01:47] <cradek> maybe I'll go.
[05:01:53] <cradek> when is it?
[05:02:13] <jmkasunich> not firmed up yet, but probably roughly the same time as NAMES, late April
[05:02:42] <cradek> yeah I'll need a vacation by then
[05:02:44] <jmkasunich> * jmkasunich needs to bring it up with the board, we need to get moving
[05:03:07] <cradek> I'd really like to get axis to be accepted as the new default user interface
[05:03:27] <cradek> I think we'd attract users that are turned off by how primitive emc "looks"
[05:03:49] <cradek> showing it at fest might be a big step toward that
[05:03:51] <jmkasunich> perhaps - emc has had several generations of UI so far, maybe it's due for another one
[05:03:56] <jmkasunich> definitely
[05:04:12] <cradek> it has a definite "oh wow" factor that the other interfaces don't
[05:04:13] <jmkasunich> everybody has a different agenda
[05:04:46] <jmkasunich> Ray has made (is making?) custom Tcl GUIs for machine builders who want their own unique front end
[05:05:37] <jmkasunich> but I don't know if the basic tkemc is getting much work, I really don't know what Ray is up to
[05:05:42] <cradek> I know mini was made for sherline - but it still didn't have the "look" we (Jeff and I) were going for
[05:05:55] <jmkasunich> I'm not real interested in learning Tcl (or Python for that matter)
[05:06:08] <jmkasunich> so I'll leave GUIs to you folks
[05:06:20] <cradek> you would be wasting your time in GUIs. We need you to do the thing you're good at
[05:06:37] <jmkasunich> my only GUI stuff to date is halscope and halmeter
[05:06:52] <cradek> well I think those are pretty cool
[05:06:57] <jmkasunich> I would like to revise them, but that will be after the core of HAL is restructured
[05:07:02] <cradek> gtk is a lot more modern than any of this tcl stuff
[05:07:29] <jmkasunich> I chose GTK entirely because it is compatible with plain ol' C
[05:07:45] <cradek> don't blame you one bit
[05:08:00] <cradek> ok now it's really late. talk to you later in the weekend maybe.
[05:08:08] <jmkasunich> ok, goodnight
[05:08:13] <cradek> goodnight
[05:19:36] <CIA-4> 03jmkasunich * 10emc2/src/emc/motion/ (command.c motion.c): fixed a bug that prevented motion controller error messages from making it to the user's screen
[07:03:27] <CIA-4> 03jmkasunich * 10emc2/src/hal/components/stepgen.c:
[07:03:28] <CIA-4> Fixed the slow +/- 1 count dither in the stepgen module. Cause: vel_cmd =
[07:03:28] <CIA-4> pos_cmd - old_pos_cmd, pos_cmd and old_pos_cmd are both float, however pos_cmd
[07:03:28] <CIA-4> was calculated a few lines earlier and was still in the FPU at full 80 bit
[07:03:28] <CIA-4> resolution. When it's previous value (old_pos) at 32 bit resolution was
[07:03:28] <CIA-4> subtracted, there was a small residue even if pos_cmd had not changed. Declared
[07:03:30] <CIA-4> old_pos as double to fix.
[07:03:47] <jmkasunich> and on that note, I'm outta here
[11:10:22] <alex_joni> hello everybody
[11:16:46] <paul_c> Morning Alex
[11:17:23] <alex_joni> hey paul...
[11:17:34] <alex_joni> in the xmas mood yet?
[11:17:47] <paul_c> Stuff it
[11:17:51] <paul_c> ;}
[11:18:32] <alex_joni> I got my tree set up
[11:18:38] <alex_joni> :D
[11:19:01] <alex_joni> * alex_joni reads a lot of discussion between cradek & jmk
[11:19:38] <paul_c> From last night ?
[11:20:06] <alex_joni> yeah
[11:21:31] <paul_c> I'll take a look in a mo...
[11:29:32] <alex_joni> * alex_joni finshed reading through the logs... too much info ;)
[11:29:53] <alex_joni> I lost track ... (perhaps it would have helped to read through the code too...)
[11:48:28] <paul_c> * paul_c notes a lack of understanding of NML & how error messages are passed up from the realtime code.
[11:50:10] <alex_joni> well...I have the NML-description on my holiday reading list ;)
[12:03:45] <alex_joni> anyways...
[12:03:50] <alex_joni> I wish you a Merry Christmas
[12:04:24] <alex_joni> May this holiday season be filled with peace and contentment for all
[12:14:45] <alex_joni> hello Martin
[12:14:59] <Imperator_> Hi Alex
[12:15:35] <alex_joni> Fr�hliche Weihnachten
[12:16:19] <Imperator_> Danke w�nsche ich Dir auch !
[12:16:34] <Imperator_> bin gerade zur�ck vom Geschnekkaufen :-)
[12:17:02] <Imperator_> Geschenke kaufen, wollte ich schreiben
[12:18:17] <Imperator_> was macht man so in Rum�nien an Weihnachten ?
[12:18:50] <alex_joni> tja, das �bliche... Weihnachtsbaum, was Gutes zum Essen, Geschenke, usw.
[12:19:02] <Imperator_> :-)
[12:19:39] <Imperator_> die Familie mal wieder treffen
[12:21:03] <Imperator_> Bin aber kein gro�er Fan von Weihnachten, und Du ?
[12:27:09] <alex_joni> Geht so... die Idee mit den Geschenken gef�llt mir
[12:27:27] <alex_joni> wenn ich derjenige bin, der sie bekommt :D
[12:28:37] <Imperator_> :-)
[12:37:12] <Imperator_> die eine Mail von der c't hatte ich Dir weitergeleited, oder ???
[12:38:13] <alex_joni> yup
[12:40:55] <Imperator_> Danke f�r die Mail, jetzt kenne ich auch die h�lfte aller besitzer einer eMailadresse in Rum�nien
[12:41:37] <alex_joni> huh.. war das cc?
[12:41:45] <Imperator_> jep
[12:41:48] <alex_joni> :-)
[12:41:53] <alex_joni> sollte bcc sein...
[12:41:55] <alex_joni> silly me ;)
[12:41:56] <Imperator_> z z z
[12:42:08] <CIA-4> 03Zathras 07BDI build system * 10Babylon Cluster/Makefile: File changed. New revision:emctaskintf.cc
[12:43:10] <Imperator_> Weihnachtshasen selber gemalt ??
[12:43:56] <paul_c> Que ?
[12:44:14] <Imperator_> Hi Paul
[12:44:47] <paul_c> Afternoon Imperator_
[12:45:17] <Imperator_> Do you have your presents ??
[12:45:38] <paul_c> I am present.
[12:45:40] <Imperator_> is the war over in england ?
[12:45:44] <Imperator_> :-)
[12:47:17] <paul_c> * paul_c sneaks off for a coffee.
[12:47:37] <Imperator_> good idea
[13:00:47] <alex_joni> * alex_joni feels stupid :(
[13:00:57] <alex_joni> that cc glitch really is stupid
[13:01:07] <alex_joni> seems I really am tired
[13:05:57] <alex_joni> * alex_joni wonders if paul changed his email addy?
[13:06:15] <paul_c> No... Why ?
[13:22:30] <paul_c> Looks like you got yourself added to the default spam trap.
[13:23:03] <alex_joni> :(
[13:24:31] <paul_c> html & attachments get filtered out by default, other more restrictive rules kick in after that...
[13:26:56] <alex_joni> so you don't send any attachments?
[13:27:57] <paul_c> Sure, I send attachments
[13:28:37] <paul_c> Incoming attachments get held for approval.
[13:29:49] <paul_c> Going to start filtering on email client before too long....
[13:30:06] <paul_c> and bounce anything from Outlook Express
[13:30:30] <alex_joni> * alex_joni really likes paul's reply
[13:30:54] <paul_c> Note: It is not GPL
[13:31:17] <alex_joni> "This greeting is freely transferable provided that no alteration
[13:31:17] <alex_joni> shall be made to the original greeting and that the proprietary
[13:31:17] <alex_joni> rights of the wishor are acknowledged;
[13:31:27] <alex_joni> sounds GPL-like
[13:35:42] <alex_joni> hello John
[13:35:50] <paul_c> Dinner time
[13:35:50] <jmkasunich> hi alex
[13:36:15] <alex_joni> my best wishes to you and your family
[13:36:28] <jmkasunich> and the same to you and yours
[13:40:14] <alex_joni> any plans for the holidays?
[13:41:00] <jmkasunich> traveling to see my parents and brother on Sunday (about 160km each way), then to visit my wife's parents for the rest of the week (800km each way)
[13:41:24] <alex_joni> seems like a lot to travel ;)
[13:41:29] <jmkasunich> yes
[13:41:51] <alex_joni> * alex_joni plans to go with his family to their mountain cabin (150km away)
[13:42:13] <jmkasunich> mountains = snow?
[13:42:36] <alex_joni> I sure hope so
[13:42:39] <jmkasunich> * jmkasunich will be traveling _away_ from snow!
[13:42:44] <jmkasunich> * jmkasunich hates snow
[13:43:01] <alex_joni> * alex_joni likes it
[13:43:02] <alex_joni> but only it it's enough (> 40 cm)
[13:43:18] <jmkasunich> I spent 3-1/2 hours yesterday clearing snow from driveway and sidewalks
[13:43:26] <alex_joni> * alex_joni hates little snow, that melts and gets dirty
[13:43:55] <jmkasunich> it wasn't even deep - only about 150mm, but very wet and heavy, snowblower got clogged up
[13:44:20] <alex_joni> * alex_joni had no snow this year yet
[13:44:21] <jmkasunich> temp was right around 0C, so it was slushy
[13:44:59] <jmkasunich> today it is about -12C, so all the slush is crunchy now
[13:45:06] <alex_joni> well... it must be cold and sunny ;)
[13:45:13] <jmkasunich> cold and gray
[13:45:21] <alex_joni> a good fire inside
[13:45:35] <alex_joni> in the chimney
[13:45:55] <alex_joni> * alex_joni plans to read the NML stuff over the holidays
[13:46:10] <alex_joni> we can then talk about it next year
[13:46:17] <jmkasunich> OK
[13:46:25] <alex_joni> e.g. continue our discussion about c++ ;)
[13:46:56] <jmkasunich> I had some more teaching about NML from Paul on Sunday, but haven't had time to do anything with it since then
[13:48:10] <alex_joni> * alex_joni goes to check if his tree is ready
[13:48:53] <alex_joni> see you guys... (maybe on sunday)
[13:48:53] <alex_joni> bye
[13:48:58] <jmkasunich> bye
[13:50:31] <paul_c> * paul_c prods jmkasunich
[13:50:44] <jmkasunich> * jmkasunich prods back
[13:50:49] <paul_c> * paul_c reaches for a bigger stick ;)
[13:51:24] <paul_c> I see you've been having fun with the error reporting mechanism
[13:51:44] <jmkasunich> yeah, cradek and I were doing some debugging last night
[13:51:59] <jmkasunich> trying to look into abort storms this morning
[13:54:31] <jmkasunich> I really with the emcmot/user interface was better documented
[13:54:53] <jmkasunich> s/with/wish/
[13:56:40] <paul_c> everything passed to/from emcmot goes through usrmotintf
[13:57:54] <jmkasunich> I know that - I'm talking about "what is EMCMOT_ABORT really supposed to do", "what does it mean when an axis error flag is set", "under what conditions should it be set, and reset", things like that
[13:58:32] <jmkasunich> turns out, EMCMOT_ABORT is _not_ supposed to abort all axis, only the specified one, unless the specified one is illegal, then it resets all axis
[13:58:42] <jmkasunich> at least that's what the emc1 code does
[13:58:52] <jmkasunich> meanwhile, it's never called with an illegal axis
[13:59:31] <jmkasunich> when you hit abort, it's called 9 times, the first 8 with axis = 0 - 7, and the last time it doesn't set axis at all, so the command is issued for 7 again
[14:00:15] <jmkasunich> OTOH, when you do a continuous jog, ABORT is called with the axis number when you release the jog button (only called once)
[14:00:40] <jmkasunich> I'm sure there was some logic behind that, but it sure as hell isn't written down anywhere
[14:01:28] <jmkasunich> <rant off>
[14:06:55] <paul_c> Hmm... EMC_TASK_ABORT and EMC_TASk_ABORT both break down in to EMCMOT_ABORT commands...
[14:07:07] <jmkasunich> ?
[14:07:17] <paul_c> Hmm... EMC_TASK_ABORT and EMC_AXIS_ABORT both break down in to EMCMOT_ABORT commands...
[14:07:28] <jmkasunich> yes, we found that last night
[14:07:35] <paul_c> NML messages...
[14:08:08] <jmkasunich> I was considering adding a new EMCMOT command AXIS_ABORT, so each message would have it's own emcmot command
[14:09:03] <jmkasunich> then the original ABORT would be abort_all, and the loop that sends 9 commands could go away
[14:09:28] <jmkasunich> but I'm tackling one demon at a time - right now it's abort storms
[14:11:39] <paul_c> I must be missing something - I don't see a flood of abort commands
[14:11:57] <jmkasunich> it happens when you get a following error
[14:13:17] <jmkasunich> the state machine at emctaskmain.cc:1968 (emcTaskExecute) goes into a loop where state goes ERROR, DONE, WAITING_FOR_MOTION_AND_IO, ERROR, DONE, etc
[14:14:13] <jmkasunich> each time it goes into state ERROR, it calls emcTaskAbort(), which sends EMC_TASK_ABORT and winds up sending 9 ABORTs to the motion controller
[14:14:28] <jmkasunich> the loop continues until the machine is back in run and happy
[14:22:03] <paul_c> Ah... A flood of usr=>RT abort messages...
[14:22:09] <jmkasunich> yes
[14:22:25] <jmkasunich> sorry, I wasn't clear
[14:29:47] <paul_c> emctaskAbort() eventually calls emcMotionAbort() where emcAxisAbort() is called EMCMOT_MAX_AXIS times, and emcTrajAbort() once.
[14:30:01] <jmkasunich> yes... found that yesterday
[14:30:06] <paul_c> Nine RT commands in all..
[14:30:22] <jmkasunich> the nine isn't what I've been calling a flood
[14:30:34] <jmkasunich> blocks of nine repeated indefinitely is a flood
[14:30:44] <paul_c> Makes sense - Abort all axis, then abort the Traj.
[14:31:32] <jmkasunich> yeah, but why noy just define an emcmot command called ABORT_ALL that does all that in the command.c switch?
[14:31:57] <jmkasunich> instead they overloaded ABORT with two functions, aborting an axis and aborting the traj
[14:33:07] <jmkasunich> look at emc1 emcmot.c:1806
[14:33:47] <jmkasunich> in coord mode, any ABORT command does tpAbort, in teleop mode it sets the desired Vel to 0, and in free mode...
[14:34:28] <jmkasunich> it aborts only the one axis
[14:34:42] <jmkasunich> hmmm... I must have read it wrong yesterday
[14:35:03] <jmkasunich> but anyway, sending nine is a hack
[14:35:27] <jmkasunich> if in coord or teleop, the very first one does everything, and the others are redundant
[14:35:50] <jmkasunich> if in free mode, it takes 8 do abort all 8 axis, and the last one is redundant (it re-aborts the last axis)
[14:36:06] <jmkasunich> s/do/to/
[14:39:50] <paul_c> Perhaps test emcmotDebug->enabling prior to calling emcTaskAbort()
[14:40:08] <jmkasunich> to stop the flood?
[14:41:30] <paul_c> yes - But it would rely on the variable being reset elswhere when the fault is removed or OK'd by the usr
[14:42:21] <jmkasunich> I think the real issue is a difference in the meaning of the fault bit - I wanted it to stay on until removed or reset by the user, I think the original intent was that the ABORT command would reset it immediately
[14:42:26] <jmkasunich> not sure yet, still digging
[14:52:30] <paul_c> in the meantime I'm looking at rationalising the messages & function calls.
[14:53:47] <jmkasunich> good
[14:58:04] <paul_c> Reducing the mutitude of SET_FOO(axis) commands down to a single SET_PARAM(axis, param) will have a significant impact on the code size.
[14:59:45] <jmkasunich> agreed
[15:00:30] <jmkasunich> (are you talking about NML messages, or usr->rt commands, or both?
[15:00:52] <paul_c> Both
[15:23:37] <paul_c> Hmmm...
[15:24:35] <paul_c> Defining command sub-types in emc.hh makes sense for NML commands...
[15:24:56] <paul_c> but if the RT code needs them, emcmot.h makes sense.
[15:25:24] <paul_c> To include emc.hh in emcmot.h is the other option....
[15:25:36] <jmkasunich> NML commands and emcmot commands are two different things
[15:25:53] <jmkasunich> they _may_ map more-or-less one-to-one, but not always
[15:26:06] <jmkasunich> and motion commands are a small subset of the overall list of messages
[15:26:50] <jmkasunich> it means some duplication, but I'd rather keep them as they are - emc.hh has NML, emcmot.h (or motion.h for emc2) has motion controller commands
[15:34:32] <paul_c> subcommands maust always have a one to one mapping - Unless you have code to handle the translation.
[15:35:00] <paul_c> and then you defeat the whole point of having command IDs
[15:35:19] <jmkasunich> subcommands? you mean for different values of "param" in SET_PARAM(axis, param)
[15:36:11] <paul_c> As an example, yes.
[15:36:37] <jmkasunich> so is "param" a big enum in emc.hh?
[15:38:11] <jmkasunich> so the subcommand info is something like:
[15:38:26] <jmkasunich> if param = 1, get/set axis->max_vel
[15:38:39] <jmkasunich> if param = 2, get/set axis->max_accel
[15:38:58] <jmkasunich> if param = 37, get/set axis->home_offset
[15:39:01] <jmkasunich> etc, etc
[15:40:00] <jmkasunich> the mapping between values of param and the actual parameters needs to be somewhere where both the RT code and the NML message senders can get it
[15:40:08] <jmkasunich> (just thinking out loud)
[15:42:40] <paul_c> yes, That's pretty much what I was think of
[15:43:15] <jmkasunich> it's just that there is so much "junk" in emc.hh, I don't really want to include that in motion.h (emcmot.h)
[15:43:32] <jmkasunich> I don't know if the C compiler would like it either
[15:44:04] <jmkasunich> for emc2, is the Java code generator for emc.hh and emc.cc a thing of the past?
[15:45:36] <paul_c> To use emc.hh in plain C sources, a couple of #ifdefs (in emc.hh) would be required.
[15:46:21] <jmkasunich> not too horrible I guess
[15:46:36] <jmkasunich> I was wondering about breaking emc.hh into chunks though...
[15:46:59] <paul_c> #ifdef __cplusplus
[15:47:05] <jmkasunich> a chunk that defines the motion controler related messages, a chunk for io controller msgs, one for task, etc, etc
[15:47:17] <jmkasunich> emc.hh could simply include all the chunks
[15:47:40] <jmkasunich> but each "blocks" messages would be defined in separate files
[15:48:07] <jmkasunich> * jmkasunich is babbeling
[15:48:22] <paul_c> I would advise against splitting up emc.hh
[15:48:47] <paul_c> unless you want to hack java if/when the java tools break
[15:49:05] <jmkasunich> that's why I asked... are the java tools going to remain a part of emc2?
[15:49:08] <paul_c> or write a new emc2 tool
[15:49:45] <jmkasunich> * jmkasunich is not impressed with the fact that a tool is required
[15:50:26] <paul_c> an autogen tool isn't essential
[15:50:32] <jmkasunich> * jmkasunich is also digressing from digging into the abort storm, and will shut up now
[15:51:42] <paul_c> There are other reasons for leaving emc.hh intact....
[17:17:40] <Sparky_> Grettings all
[17:18:05] <Sparky_> Greetings all (darned fingers don't type what I tell them)
[17:19:09] <Sparky_> I've been conversing with Paul about a driver for the card I've bought, and he pointed me toward the srcs.
[17:20:08] <Sparky_> Unforch, the BDI-Live install disk doesn't include those, and the links are all dead, or miss-linked as 'file' instead of http
[17:21:06] <Sparky_> So the next obvious question then, is this a holiday glitch, or where might the compelte src tarball for 2.18 be obtained?
[17:21:51] <paul_c> BDI-Live_rc46 includes the sources as a tarball in /usr/local
[17:22:30] <Sparky_> This is Gene Paul, on the cd you say?
[17:22:47] <paul_c> and on the installed system.
[17:23:11] <paul_c> cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/emc login
[17:23:12] <paul_c>
[17:23:12] <paul_c> cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/emc co
[17:23:12] <Sparky_> Humm, lemme ssh in and look again... rbr
[17:23:27] <paul_c> cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/emc co emc
[17:23:34] <paul_c> cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/emc co rcslib
[17:24:44] <Sparky_> I'll have to go down and mount the cd, brb
[17:27:54] <Sparky_> Humm, I can't find any src tarballs on the cd either Paul
[17:28:47] <paul_c> Booted from the CD ?
[17:29:37] <Sparky_> No, from the hd installation
[17:30:08] <Sparky_> But I've got the cvs comeing into that box now, ain't networking wunnerful?
[17:32:01] <Sparky_> Looks like I have it all now, thanks
[17:32:34] <Sparky_> Did you have a prototype for those 6 or 7 calls you said it needed?
[17:33:34] <paul_c> emc/src/drivers/extppt.c
[17:33:52] <paul_c> emc/src/drivers/extintf.h
[17:34:55] <Sparky_> Gotcha, thanks, and have a very Merry Christmas - From Gene & Dee.
[17:35:22] <Sparky_> Humm, was that me?
[17:35:29] <Sparky_> Nope bye
[17:35:55] <paul_c> He'll be back.
[17:43:29] <danfalck> hi Paul
[17:43:41] <paul_c> Hi Dan
[17:44:08] <danfalck> How are things?
[17:45:01] <CIA-4> 03Zathras 07BDI build system * 10Babylon Cluster/emccommand.c: File changed. New revision:emcmodule.c
[17:45:01] <CIA-4> 03Zathras 07BDI build system * 10Babylon Cluster/Makefile: File changed. New revision:1.18.2.6
[17:45:03] <CIA-4> 03Zathras 07BDI build system * 10Babylon Cluster/emctaskintf.cc: File changed. New revision:1.1.2.2
[17:45:03] <CIA-4> 03Zathras 07BDI build system * 10Babylon Cluster/emc.hh: File changed. New revision:emcglb.h
[17:45:05] <CIA-4> 03Zathras 07BDI build system * 10Babylon Cluster/_shm.c: File changed. New revision:shm.cc
[17:45:17] <paul_c> Slow..
[17:45:58] <danfalck> Are you about to release another CD?
[17:46:24] <paul_c> Yup
[17:46:50] <danfalck> What are the new features?
[17:47:21] <paul_c> 2.6.9 kernel, Debian based, and using the Red Hat installer.
[17:47:47] <danfalck> Deb based -uses Apt get to install new packages?
[17:47:56] <paul_c> yup
[17:48:04] <danfalck> Cool
[17:48:49] <paul_c> Once we can get a repository set up, people can upgrade with minimal hassle.
[17:49:03] <danfalck> that will be very nice!
[17:49:41] <danfalck> I had Fink set up on this machine. It was similar arrangement. I really liked it.
[17:50:37] <danfalck> So, this would make upgrading small portions of EMC very easy.
[17:50:56] <danfalck> Apt-get steppgen....etc...
[17:51:16] <paul_c> yup - I'm looking at splitting the kernel modules off into a seperate package
[17:51:44] <paul_c> apt-get install emc-modules
[17:51:49] <paul_c> apt-get install emc
[17:56:28] <danfalck> Thanks Paul. I have to go buy more wood for the fireplace. I'll talk to you later.
[17:57:00] <paul_c> * paul_c has some carol singers to shoot
[17:57:19] <paul_c> paul_c is now known as Bah_HumBug
[18:59:15] <rayh> Super solstice guys! Twas -35C here this morning.
[19:10:09] <lilo> [Global Notice] Hi all. Happy holiday slash winter break to everyone, and thank you for using freenode. :)
[19:11:16] <lilo> [Global Notice] If you're an active group, project participant or donor, with a cloak, please stop by our holiday channel. Just join #freenode and you'll be forwarded. Thanks! And again, happy holidays! :)
[19:13:20] <asdfqega> Weee!
[19:13:39] <asdfqega> I can only be on here for a few minutes...
[19:14:11] <asdfqega> An icestorm has taken out power, and we're running on generator
[19:14:39] <asdfqega> Somebody tell Ray to be careful when shoveling snow!
[19:16:08] <asdfqega> Were I any further in the backwoods, I'd be typing in Morse Code...
[19:17:58] <Bah_HumBug> Bah_HumBug is now known as paul_c
[19:18:19] <rayh> asd: You must be south a bit.
[19:18:30] <rayh> Hi Paul
[19:18:59] <paul_c> Hi Ray
[19:20:13] <rayh> How goes the BDI battle?
[19:21:03] <paul_c> Just waiting for the Synergy package to be updated
[19:24:36] <paul_c> Oh, and the current ini files for Sherline.
[19:27:17] <rayh> Right. I need to send you current mill_inch and mill_mm.
[19:27:38] <rayh> Matt noted that he had trouble with the cdrom for the release he has.
[19:28:23] <rayh> Craig was wondering if monitor setup is going to be as easy as the old RH "setup" command.
[19:28:43] <paul_c> Can you remember the version number Matt is using ?
[19:34:38] <robin_sz> 666?
[19:39:15] <rayh> I believe that it is 4.2
[19:39:53] <rayh> I was not able to get 4.4 yet.
[19:40:25] <paul_c> Most (if not all) the issues have been resolved, and now up to 4.05
[19:42:22] <rayh> Okay. I'll tell him to look for that version.
[19:44:03] <rayh> Wait. Didn't you ftp the last to him. If yes, do it again.
[19:52:46] <rayh> paul_c: forwarded a note from matt. Gotta get to the fam. Thanks for the update.
[20:15:39] <robin_sz> christmas eve ...
[20:15:53] <robin_sz> and you lot are still hacking emc?
[20:16:04] <robin_sz> tut tut, here, have a sherry and mince pie
[20:16:15] <Imperator_> Hi Robin
[20:16:21] <robin_sz> eveny
[20:16:36] <Imperator_> the chatt is good to escape from that christmas stuff
[20:16:41] <robin_sz> heh
[20:16:49] <robin_sz> im playing with voip here ...
[20:17:09] <Imperator_> voip ??
[20:17:10] <robin_sz> top fun
[20:17:16] <robin_sz> voice over ethernet
[20:17:22] <Imperator_> ah
[20:17:37] <Imperator_> don't have such a big house that i need that
[20:17:51] <Imperator_> or do you use it as a normal fone ?
[20:18:01] <robin_sz> thats the plan
[20:18:25] <Imperator_> over a provider ?
[20:19:50] <robin_sz> thats the plan
[20:20:00] <robin_sz> but finding providers in the UK is not so easy it seems
[20:20:12] <Imperator_> :-)
[20:20:39] <robin_sz> the Big Plan is to run the exchange on my london server
[20:21:03] <robin_sz> and get a whole bunch of us onit
[20:21:12] <Imperator_> here is a big one that sells DSL with voive over IP, they gave you a DSL router which can do Voice over IP
[20:21:43] <Imperator_> in germany
[20:21:50] <robin_sz> yeah, its not an issue really, you can get phones and softphones for voip
[20:22:23] <Imperator_> you want to have it automated
[21:07:05] <jmkasunich> * jmkasunich is back for a while
[21:21:38] <CIA-4> 03jmkasunich * 10emc2/scripts/ (emc.run realtime): added a couple of patches submitted by Paul Fox. The patches improve error handling, and simplify the scripts somewhat. Thanks Paul