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