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