any chance of kill resulting in the program ending unexpectedly?
if it didn't trap SIGTERM ?
hm -- two ideas come to mind: hal could block SIGTERM while it holds the mutex, or halcmd unloadusr could signal only components that are ready
but 'unloadusr' is separate from ready/unready components
whether or not unloadusr all should kill halcmd(s) is a non-trivial question
my first answer is no, it should not
it should probably bypass killing itself
at the very least
btw, that gets into the other issue
the "n <name>" thing
for some user space components you might want to permit two simultaneous instances
dunno about halvcp, but it seems to me we should allow it
but now you get a messy thing: what name do you use if you have multiple instances
and how do you pass it to the "n <name>"
it would suck, but you could tell each instance of halvcp what component name to use
for halcmd and halmeter it doesn't matter because there's little sense in waiting for them -- they don't create pins or parameters
as suckage goes, I've seen worse
for vcp, it would be quite reasonable to add a "name =" attribute to the top level "vcp" object
default value "halvcp"
+$HALCMD loadusr -Wn iocontrol $EMC2_BIN_DIR/$EMCIO -ini $INIFILE
this means that every $EMCIO has to name it hal component 'iocontrol'
is that "OK"?
+$HALCMD loadusr -Wn $EMCIO $EMC2_BIN_DIR/$EMCIO -ini $INIFILE
$EMCIO is 'io'
what alex_joni said
we can change that if needed
because it derived from simio
without the sim
hal name should match executable name unless there's a good reason not to
good reasons: 1) need multiple instances
in that case, get rid of '-n' altogether and change the component name
(but it can be a separate step)
the default for -n is the executable name?
as in this other example: +loadusr -W halvcp halui.vcp
hmm, the entire -n _might_ not be needed
_if_ the loadusr command invokes the executable directly, we could avoid the -n
because fork() returns the child PID to the parent, and on exec() the new program (the user space hal comp) inherits the original (child) PID
but it might not
I thought about that too
in fact, you thought of it the first time too
right, for instance if you loadusr a script that in turn loads the component
hence my "drat"
drat it's late
* alex_joni goes to bed
8:23 pm, and I haven't eaten since lunch
03:29 am here
19:26:36 <alex_joni> 03:29 am here
3 different times :D
all by 3 minutes off
I'm surprised; I thought everybody ran ntp these days
I think ubuntu does an ntpdate on boot
I think I do..
20:25:46 up 26 days, 22:46, 5 users, load average: 2.16, 2.04, 2.05
might have drifted since then
ok.. think now it's 03:29 ;)
9 Jul 03:28:54 ntpdate: step time server 188.8.131.52 offset -191.313279 sec
8 Jul 20:30:13 ntpdate: step time server 184.108.40.206 offset 162.829973 sec
same here ;)
jepler: if you want to commit that change, go ahead
just do incr the HAL_VER first
I will commit it
also with the suicide bug fixed
"commit suicide, bug fixed" - it's all in the punctuation
jmkasunich: in vcp_widgets.c in the struct led_def you have an element init_led; is that a function pointer?
ah - 'init_funct' Pointer to a function that initializes the
i dont think i've ever seen a function pointer before
hal uses 'em too
when you do an addf, you are adding a function pointer to a list
jmkasunich: short paste
20:34 < jepler> $ ./src/emc2/bin/halcmd show param tripo
20:34 < jepler> Parameters:
20:34 < jepler> Owner Type Dir Value Name
20:34 < jepler> 03 float R- 1.00000e+00 tripodkins.Bx
20:34 < jepler> 03 float R- 1.00000e+00 tripodkins.Cx
20:34 < jepler> 03 float R- 1.00000e+00 tripodkins.Cy
20:35 < jepler> I've separated kinematics into separate kernel modules and made
tripodkins have its configuration as parameters
reading that now
[18:22:39] <jepler> http://emergent.unpy.net/index.cgi-files/sandbox/separate-kins.patch
(slightly out of date)
jepler: you don't need the axis to move after homing, but rather that it stays in the same position
you're using loadrt and params, but no pins, right?
the kins code is still called directly from motion, rather than by a hal addf thing?
(still perusing the patch)
jmkasunich: even if pins would add some flexibility, I think it's faster like this
pins would add problems, not flexibility
(because of issues like homing, etc)
the kins code is called from more than one place in motmod
what is the goal here? avoiding the need to select kins at build time?
and passing params to the kins more easily
someone who cares about genhexkins would have to make its configuration into module commandline or hal parameters
the old way (missing from emc2, but existing in emc1), would involve reading the ini by task, then passing to motion which causes some kins functions
jepler: I think both
commandlne for hexapod type (stewart, uf, ingersoll, mini_tetra, ..)
there are a whole boatload of params that are read from the ini by task, then issued as "emcmot_set_foo" commands to the motion module
then hal params for the stuff needed
jmkasunich: yeah, and adding a couple more wouldn't be any fun
I was thinking of going the other way
having _some_ params read from the ini by task and sent thru messages, and _others_ read from ini by hal, seems screwy
how about making them all hal params?
that way you could even alter them while emc is running
that thought crossed my mind some time back... but paul would have shot me
without the need of restarting emc a hundred times till you get it right
* alex_joni passes jmk a bulletproof west
or rather a bs-proof west ;)
need to be a little carefull, because some of them can't simply be changed...
fenn: yeah, but others too
not sure i understand
just a sec
what's the difference between stewart, ingersoll, mini tetra
fenn: arrangement of the struts
isnt that taken care of by the joint offsets?
the genhexkins provides kins for all types, but you need to select your type
no, stacking joints & such
some hexapods use varable length struts, some use fixed length struts and move the "fixed" end fo the strut on a linear rail
here are the existing motion module params that are set by way of task:
EMCMOT_SET_POSITION_LIMITS,/* set the axis position +/- limits */
EMCMOT_SET_BACKLASH,/* set the axis backlash */
EMCMOT_SET_MIN_FERROR,/* minimum following error, input units */
EMCMOT_SET_MAX_FERROR,/* maximum following error, input units */
EMCMOT_SET_VEL,/* set the velocity for subsequent moves */
EMCMOT_SET_VEL_LIMIT,/* set the max vel for all moves (tooltip) */
EMCMOT_SET_JOINT_VEL_LIMIT,/* set the max axis vel */
EMCMOT_SET_JOINT_ACC_LIMIT,/* set the max axis accel */
EMCMOT_SET_ACC,/* set the max accel for moves (tooltip) */
EMCMOT_SET_TERM_COND,/* set termination condition (stop, blend) */
EMCMOT_SET_NUM_AXES,/* set the number of axes */
EMCMOT_SET_WORLD_HOME,/* set pose for world home */
EMCMOT_SET_HOMING_PARAMS,/* sets axis homing parameters */
EMCMOT_SET_DEBUG, /* sets the debug level */
EMCMOT_SET_DOUT, /* sets or unsets a DIO, this can be imediate or synched with motion */
EMCMOT_SET_AOUT,/* sets or unsets a AIO, this can be imediate or synched with motion */
EMCMOT_SET_SPINDLESYNC, /* syncronize motion to spindle encoder */
SEL_VEL is _not_ one that would be converted to a hal param, it changes all the time under control of task
ok, a few don't come from the ini, but are rather used frequently
SET_VEL_LIMIT might be the same way
and others, like SETP_HOMING_PARAMS, actually represent multiple params
all of those would be really nice as hal params for a trivial machine, to make setting up a new machine easier wrt backlash and accels and such
making some of those into hal params would reduce the amount of code in "iniaux" by a lot
and would reduce the amount of code in "command.c"
but require incompatible ini and hal changes
that's what 2.1.x is about
it would require .hal changes, not .ini
the params would remain in the ini file exactly as they are
it would be confusing to have them both places
but the .hal file would do "setp axis.0.max_ferror [AXIS_0]MAX_FERROR"
a few things are more than one number on a line
[TRAJ]HOME for instance
I forgot about those....
I was thinking that all ini params were <name> <value>
I think the traj section is the worst offender that way
the axis section has INPUT_SCALE and (sometimes) OUTPUT_SCALE with multiple values
(the second value was actually an offset)
but it's not used anymore.. right?
so we can drop it
dunno if the iniaxis.cc code is still reading it or not
INPUT_SCALE <float> <float> scale, offset
OUTPUT_SCALE <float> <float> scale, offset
taken from iniaxis.cc
you know, a whole bunch of the stuff in src/emc/ini is obsolete...
I know :)
I'm not sure how radical we want to get though...
I just wanted to get rid of setting the kinematics at compile time
my vision is never grand
jepler: yeah, but it's like a lavine
not sure how that's spelled
the snow thing
yeah, that one
in german it's lawine
a small snow ball triggers it ;)
jmkasunich: inilube, inicool, inispin are all obsolete
still being built, linked, and called though?
think so :)
not sure about called
but even if they are called, the stuff they gather is not used for anything
nope, not called
should go away then
* alex_joni does that now
what me to make it happen?
any idea what this means?
make: Failed to remake makefile `Makefile'.
* jmkasunich points at jepler
* jepler hides
jepler: I think it's a weird error coming from parts I didn't remove yet
found the inilub.ehh re
found the inilube.hh reference in Makefile
that could cause it
'rm -rf depends' may be necessary
I did make clean
it's odd.. though
it compiles cleanly, then after iniaxis.cc it simply stops
no errors or anything
ok, found the problem
but it's odd that make didn't print anything
jepler: it seems it silently fails if it didn't find a .hh in the dependence stage
alex_joni: huh -- I thought it printed an error.
make: *** No rule to make target `emc/ini/inispin.hh', needed by `depends/emc/task/iotaskintf.d'. Stop.
I didn't get it
because it didn't figure out emc/ini/inispin.hh
just try to remove iniaux.cc & .hh
that's what I got after I updated. ^^^
remove iniaux.cc & .hh
then do a make clean && make
jepler: yeah you got that, because you had the old depends
jepler: did you get an error?
alex_joni: yes, but maybe I didn't do the same thing as you did
do you want me to worry about it?
not worth the hassle
_if_ it's a problem, then only developers who mess with files will encounter it
so they should know how to figure it out :)
anybody mind if I check in this kinematics change?
* alex_joni heads to bed
night all :)
see you alex_joni
yup, tomorrow :)
I'll be around 4 more days
then it's vacation time :D
[Global Notice] Hi all. We just lost a main rotation server, so you will have noticed a big bump. It's out of rotation and we're looking at it now. Apologies for the inconvenience.