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