Back
[00:03:56] -!-
theorbtwo has quit [Ping timeout: 252 seconds]
[00:04:05] theorb is now known as
theorbtwo
[00:05:13] -!-
robh__ has quit [Ping timeout: 276 seconds]
[00:12:54] -!-
andypugh has quit [Quit: andypugh]
[01:36:05] -!-
JT-Shop has quit [Read error: Connection reset by peer]
[01:36:33] -!-
JT-Shop [
[email protected]] has joined #emc-devel
[01:54:13] -!-
Ze1982 [
[email protected]] has joined #emc-devel
[01:54:37] -!-
John_f_ has quit [Quit: Ex-Chat]
[02:21:37] -!-
mhaberler [
[email protected]] has joined #emc-devel
[02:21:46] -!-
kb8wmc has quit [Quit: ChatZilla 0.9.87 [Firefox 3.6.22/20110905191234]]
[02:50:18] -!-
ve7it has quit [Remote host closed the connection]
[02:51:56] -!-
ries has quit [Quit: ries]
[03:08:04] -!-
Calyp has quit [Quit: Leaving]
[03:19:23] -!-
cevad has quit [Quit: Leaving]
[03:21:23] -!-
chester88 [
[email protected]] has joined #emc-devel
[03:35:27] -!-
theos has quit [Disconnected by services]
[03:40:13] -!-
theos has quit [Disconnected by services]
[04:09:27] -!-
theos has quit [Ping timeout: 252 seconds]
[05:01:37] -!-
psha[work] has quit [Quit: Lost terminal]
[05:07:14] -!-
psha[work] [psha[work]
[email protected]] has joined #emc-devel
[05:15:22] -!-
cevad has quit [Client Quit]
[05:50:08] -!-
mhaberler has quit [Ping timeout: 252 seconds]
[05:52:31] -!-
factor has quit [Read error: Connection reset by peer]
[05:55:28] -!-
mhaberler [
[email protected]] has joined #emc-devel
[05:59:52] -!-
vladimirek [
[email protected]] has joined #emc-devel
[06:17:09] -!-
stormlight has quit [Quit: stormlight]
[06:20:55] -!-
awallin [
[email protected]] has joined #emc-devel
[06:20:58] -!-
awallin has quit [Read error: Connection reset by peer]
[06:32:26] -!-
awallin [
[email protected]] has joined #emc-devel
[06:43:09] -!-
Eartaker has quit [Quit: Leaving]
[06:43:23] -!-
bootnecklad` has quit [Ping timeout: 260 seconds]
[06:43:38] -!-
mhaberler_ [
[email protected]] has joined #emc-devel
[06:47:45] -!-
mhaberler has quit [Ping timeout: 260 seconds]
[06:47:45] mhaberler_ is now known as
mhaberler
[06:51:18] -!-
mhaberler has quit [Quit: mhaberler]
[07:27:02] -!-
mhaberler [
[email protected]] has joined #emc-devel
[07:29:45] -!-
Danimal_garage has quit [Read error: Connection reset by peer]
[07:36:48] -!-
e-ndy [e-ndy!jkastner@nat/redhat/x-owazdgcpxgscljif] has joined #emc-devel
[07:37:44] -!-
mhaberler has quit [Read error: Connection reset by peer]
[07:37:47] -!-
mhaberler_ [
[email protected]] has joined #emc-devel
[07:58:00] -!-
robh__ [
[email protected]] has joined #emc-devel
[08:22:03] -!-
robh__ has quit [Ping timeout: 260 seconds]
[08:27:47] -!-
awallin_ [awallin_!~quassel@2001:708:110:1020:224:7eff:feda:7c7d] has joined #emc-devel
[08:32:12] -!-
mhaberler_ has quit [Quit: mhaberler_]
[08:32:27] -!-
robh__ [
[email protected]] has joined #emc-devel
[08:39:37] -!-
micges_work [
[email protected]] has joined #emc-devel
[10:20:36] -!-
Vq has quit [Ping timeout: 244 seconds]
[10:20:56] -!-
micges_work [
[email protected]] has parted #emc-devel
[10:57:16] -!-
nicko has quit [Ping timeout: 245 seconds]
[11:17:06] -!-
psha[work] has quit [Quit: Lost terminal]
[11:26:25] -!-
psha[work] [psha[work]
[email protected]] has joined #emc-devel
[11:45:51] -!-
Vq has quit [Ping timeout: 244 seconds]
[12:41:32] -!-
psha[work] has quit [Quit: Lost terminal]
[12:55:43] -!-
mhaberler [
[email protected]] has joined #emc-devel
[13:14:27] -!-
Calyp has quit [Remote host closed the connection]
[13:33:09] -!-
psha [
[email protected]] has joined #emc-devel
[14:10:01] -!-
vladimirek has quit [Remote host closed the connection]
[14:23:58] -!-
stormlight has quit [Quit: stormlight]
[14:25:23] -!-
skunkworks has quit [Ping timeout: 260 seconds]
[14:39:43] -!-
Valen has quit [Quit: Leaving.]
[14:40:05] -!-
skunkworks [
[email protected]] has joined #emc-devel
[14:46:40] -!-
syyl has quit [Ping timeout: 260 seconds]
[15:30:48] -!-
Valen has quit [Quit: Leaving.]
[15:39:43] -!-
mhaberler has quit [Quit: mhaberler]
[15:39:46] -!-
e-ndy has quit [Quit: Ex-Chat]
[15:46:58] <CIA-83> EMC: 03cradek 07master * rb8504148536b 10/src/emc/usr_intf/pncconf/ (pncconf.glade pncconf.py): pncconf -make pncconf search sserial pins - change sserial pin names
[15:46:59] <CIA-83> EMC: 03cradek 07master * r0e216d0ab286 10/src/emc/usr_intf/pncconf/ (pncconf.glade pncconf.py): pncconf - add a fourth smart serial tab
[15:47:00] <CIA-83> EMC: 03cradek 07master * rfd2a93589a8c 10/src/emc/usr_intf/pncconf/ (pncconf.glade pncconf.py): pncconf - upgrade firmware array to include smart serial
[15:47:00] <CIA-83> EMC: 03cradek 07master * r6c42f578e5bf 10/src/emc/usr_intf/pncconf/pncconf.py: pncconf -correctly loads the sserial signalname
[15:47:00] <CIA-83> EMC: 03cradek 07master * r0016b5c45ca4 10/src/emc/usr_intf/pncconf/ (pncconf.glade pncconf.py): pncconf -add basic sserial signal loading, selecting, and saving
[15:47:01] <CIA-83> EMC: 03cradek 07master * rf66deaf31363 10/src/emc/usr_intf/pncconf/pncconf.py: pncconf -add sserial support to make_pinname method
[15:47:01] <CIA-83> EMC: 03cradek 07master * r590ffd1c2556 10/src/emc/usr_intf/pncconf/pncconf.py: pncconf - search sserial pins for I/O signals
[15:47:02] <CIA-83> EMC: 03cradek 07master * r3fbd095e2f64 10/src/emc/usr_intf/pncconf/pncconf.py: pncconf -fix make_pinname method
[15:47:04] <CIA-83> EMC: 03cradek 07master * rc1d2fd99b983 10/src/emc/usr_intf/pncconf/pncconf.py: pncconf -add signal blocking and custom signals for sserial
[15:47:04] <CIA-83> EMC: 03cradek 07master * r4c88deb51a85 10/src/emc/usr_intf/pncconf/ (pncconf.glade pncconf.py): pncconf - make window a little smaller height
[15:47:08] <CIA-83> EMC: 03cradek 07master * r6a6f657c3238 10/ (2 files in 2 dirs): pncconf DOC -add info about base frequency and daughter boards
[15:47:09] <CIA-83> EMC: 03cradek 07master * r2a290f07a13f 10/src/emc/usr_intf/pncconf/ (pncconf.glade pncconf.py): pncconf - add sanity check for mesa daughter boards.
[15:47:09] <CIA-83> EMC: 03cradek 07master * ra4ebcd1f2ae0 10/src/emc/usr_intf/pncconf/pncconf.py: pncconf -fix display of GPIO numbers for main mesa pins
[15:47:09] <CIA-83> EMC: 03cradek 07master * rf3a9ff82ef88 10/src/emc/usr_intf/pncconf/pncconf.py: pncconf -fix sanity test and mesa1 page next button
[15:47:10] <CIA-83> EMC: 03cradek 07master * rae43af97eced 10/src/emc/usr_intf/pncconf/pncconf.py: pncconf -fix annoying AXIS .axisrc warning dialog
[15:47:10] <CIA-83> EMC: 03cradek 07master * r726925037b3d 10/src/emc/usr_intf/pncconf/pncconf.py: pncconf -fix sensitivity of GPIO pintypes
[15:47:11] <CIA-83> EMC: 03cradek 07master * rf913090d4b26 10/src/emc/usr_intf/pncconf/pncconf.py: pncconf -fix a crash on new/modify page
[15:47:12] <CIA-83> EMC: 03cradek 07master * r0b30b1b20ba5 10/src/emc/usr_intf/pncconf/pncconf.py: pncconf -remove some development hacks
[15:47:13] <CIA-83> EMC: 03cradek 07master * r5315add92ae6 10/src/emc/usr_intf/pncconf/pncconf.py: pncconf -add up/dpwn PWM mode and fix setting of pwm modes
[15:47:15] <CIA-83> EMC: 03cradek 07master * rb03f6e9c525b 10/ (2 files in 2 dirs): pncconf / DOC - add info about up/down PWM and 7i48 boards
[15:47:15] <CIA-83> EMC: 03cradek 07master * rf07e78ac76fa 10/src/emc/usr_intf/pncconf/pncconf.py: pncconf -have pncconf search a file for custom firmware
[15:47:15] <CIA-83> EMC: 03cradek 07master * r81aaf5c16562 10/src/emc/usr_intf/pncconf/pncconf-help/lathe_diagram.png: pncconf -change lathe diagram's home swicth location
[15:47:17] <CIA-83> EMC: 03cradek 07master * r26f7a181760a 10/src/emc/usr_intf/pncconf/pncconf.glade: pncconnf - change text about lathe diagram home switch
[15:47:17] <CIA-83> EMC: 03cradek 07master * r7b7c319995eb 10/docs/src/config/pncconf.txt: DOC - update info on pncconf
[15:47:18] <CIA-83> EMC: 03cradek 07master * r83c8821d7e1a 10/src/emc/usr_intf/pncconf/pncconf.py: pncconf -fix problems found after RT testing
[15:47:19] <CIA-83> EMC: 03cradek 07master * r1c52f1894b4a 10/src/emc/usr_intf/pncconf/pncconf.py: pncconf -change hal HAL signalname enable to machine-is-enabled
[15:47:20] <CIA-83> EMC: 03cradek 07master * rbc9bef250859 10/src/emc/usr_intf/pncconf/pncconf.py: pncconf -change HAL signal name in_position to in-position
[15:47:21] <CIA-83> EMC: 03cradek 07master * r0d22d99d6d4e 10/docs/src/config/images/pncconf-diagram-lathe.png: DOC - update pncconf lathe diagram - moved home switch position
[15:47:22] <CIA-83> EMC: 03cradek 07master * r9c279e319e24 10/docs/src/drivers/pico_ppmc.txt: merge master update into v2.5_branch the messy way
[15:47:23] <CIA-83> EMC: 03cradek 07master * ref1548711cf4 10/src/emc/usr_intf/pncconf/pncconf.py: pncconf -fix inversion of stepper ouput pins
[15:47:23] <CIA-83> EMC: 03cradek 07master * r1abaaf4271d8 10/src/emc/usr_intf/pncconf/pncconf.py: pncconf - silence debugging messages
[15:47:24] <CIA-83> EMC: 03cradek 07master * rdf93a83e2b64 10/src/emc/usr_intf/pncconf/pncconf.py: pncconf - fix initalization of sserial array
[15:47:25] <CIA-83> EMC: 03cradek 07master * r1ef58691e0fd 10/src/hal/components/bldc.comp: Make it possible to change the bldc output Hall pattern.
[15:47:26] <CIA-83> EMC: 03cradek 07master * r5378a873f4d9 10/ (7 files in 5 dirs): Merge branch 'v2.5_branch'
[16:03:42] -!-
ve7it [
[email protected]] has joined #emc-devel
[16:11:12] <JT-Shop> WOW!
[16:12:26] -!-
awallin_ has quit [Remote host closed the connection]
[16:14:29] <cradek> it's just a merge, but it does tell me that the new git repository works right
[16:14:42] <JT-Shop> that is always good
[16:14:54] <cradek> "error: error in sideband demultiplexer"
[16:15:15] <cradek> the badness of that error makes me laugh
[16:15:44] <JT-Shop> I don't even know what it means
[16:16:09] <JT-Shop> I know what a demultiplexer is I think
[17:25:36] -!-
e-ndy [
[email protected]] has joined #emc-devel
[17:25:47] -!-
e-ndy has quit [Read error: Connection reset by peer]
[17:26:10] -!-
e-ndy [
[email protected]] has joined #emc-devel
[17:28:05] davec is now known as
Guest90626
[17:58:05] <alex_joni> JT-Shop: I thought that too, till I realized that's a git error ;)
[18:00:26] <skunkworks> alex_joni: !
[18:02:18] <archivist> and sidebands too!
[18:02:43] <archivist> some radio engineers joke in git?
[18:03:07] -!-
IchGuckLive has quit [Quit: ChatZilla 0.9.86 [Firefox 3.6.22/20110905191234]]
[18:03:12] -!-
mhaberler [
[email protected]] has joined #emc-devel
[18:07:03] -!-
motioncontrol has quit [Remote host closed the connection]
[18:16:40] -!-
robh__ has quit [Quit: Leaving]
[18:23:50] <alex_joni> skunkworks: hi
[18:28:42] <mhaberler> cradek: are those ok with you for v2.5_branch?
http://git.mah.priv.at/gitweb/emc2-dev.git/shortlog/refs/heads/fix-failed-oword-procedure and
http://git.mah.priv.at/gitweb/emc2-dev.git/shortlog/refs/heads/remove-lazy-close
[18:29:05] <mhaberler> I guess I'll put the task backtrace feature into master
[18:30:45] <cradek> I'm nervous about the second. can you describe how/what you tested?
[18:33:48] <mhaberler> let me see.. it's been a few different themes today..
[18:34:12] -!-
automata has quit [Ping timeout: 252 seconds]
[18:35:15] <cradek> like seb, I'm really unsure that adding exec-gdb into task is the way to handle that
[18:35:36] <mhaberler> ok, regarding backtrace I suggest walk before we run.
[18:36:46] <mhaberler> I dont see anybody taking that ticket yet, and when done - happy to remove. Now: this is fly-by-night
[18:37:07] <cradek> I don't understand what you're saying. can you use plainer language please?
[18:39:58] <mhaberler> My proposal is to have a signal handler for SEGV which tells you something happened. I believe this is way superiour to looking at dmesg to find out what happend. I am not proposing this to be the eventual 'EMC end user crash support tool' - I see it as a stopgap measure until somebody comes around and does something better. That I dont see.
[18:40:30] <mhaberler> This is why I think having something is better than having dmesg until somebody comes around and does that - thats all
[18:41:22] <cradek> if task crashes, I wish emc would just shut down
[18:41:39] -!-
maximilian_h [
[email protected]] has joined #emc-devel
[18:41:47] <cradek> with ulimit I could choose to get a core dump in the normal way
[18:42:04] <cradek> I don't see a trivial way to do that in the emc script, which backgrounds task and runs the ui foreground
[18:42:07] -!-
maximilian_h has quit [Client Quit]
[18:42:16] <mhaberler> that's what it does on a segfault - the only difference
[18:42:19] <mhaberler> oops
[18:42:25] <mhaberler> too fast
[18:43:21] <cradek> in the general case, when handling a serious error, I don't think you're in any state to fork programs, write to files, then send some more nml messages
[18:43:23] <mhaberler> yes: but now the user doesnt even notice task has gone away - axis just hangs
[18:43:39] <cradek> you really risk covering up the real error with "error while handling an error" errors
[18:44:02] <cradek> I agree that needs a fix - the whole program should shut down if any important piece crashes
[18:44:13] <mhaberler> I will make it configurable
[18:44:26] <mhaberler> default off if you like, I dont care
[18:44:42] <cradek> your solution sends an operator message - does anything else happen then?
[18:45:19] <mhaberler> no, that just gets into emcstat which is in shared memory, and that hangs around for a while
[18:45:48] <cradek> causing an exit of UI and HAL would have the added advantage of triggering hardware watchdogs
[18:46:12] <cradek> I think hal/ui still running with task not running is a very unsafe state
[18:46:24] <mhaberler> well, post sigsegv it exits just as well
[18:46:42] <mhaberler> it does NOT continue after a sigsegv or sigfpe
[18:47:09] <cradek> am I misunderstanding? I think task exits, but hal keeps running.
[18:47:37] <mhaberler> I didnt touch any other parts of the emc startup/shutdown process
[18:47:37] <alex_joni> you mean motion?
[18:47:53] <cradek> yes motion/hal
[18:48:08] <mhaberler> conceptually I dont see a difference in calling exit() from as user signal handler and the default signal handler, and that is all that is to it
[18:48:26] <alex_joni> eventually motion should see no more updates from task, I think it checks for them periodically? heartbeats..?
[18:48:35] <mhaberler> actually it triggers emc_shutdown I think, let me see
[18:48:43] <cradek> we feel differently about the problem. I think the problem is that task crashing leaves the machine in an unsafe state AND the user doesn't have any way to notice
[18:49:17] <alex_joni> right, cradek (and me :) are more worried about the first part, mhaberler is more worried about the second part
[18:49:47] <cradek> I don't care about automatically generated backtrace, and I think it might sometimes be a mistake to try to generate it, depending on what caused the crash
[18:50:06] <cradek> yes the first part is by far the important one I think
[18:50:06] <mhaberler> cradek: this code does exactly the same as the sigterm handler: setting done=1 to let task shut down as it shuts down when you hit ^C
[18:51:15] <cradek> ok, so the real question is how can motion/hal be made to exit whenever/however task crashes?
[18:51:15] <mhaberler> I think we habe some fundamental misunderstanding here.
[18:52:59] <mhaberler> My code does *exactly* the same as the code executed when task gets a SIGTERM. It sets the variable done = 1 to let task shutdown the way it always shuts down. Hence I am at loss to understand what you are talking about. you are talking about a different problem.
[18:55:42] <mhaberler> please see line 143 of
http://git.mah.priv.at/gitweb/emc2-dev.git/blob/b7e5d1d8d6d8ef60eb51997581136a83cc33a4c5:/src/emc/task/emctaskmain.cc and line 43 of
http://git.mah.priv.at/gitweb/emc2-dev.git/blob/b7e5d1d8d6d8ef60eb51997581136a83cc33a4c5:/src/emc/task/backtrace.cc
[18:57:54] <mhaberler> Actually handling sigsegv is a precondition to shut down in a more intelligent way, but that is not in that patch
[18:59:35] <cradek> I agree we are talking about two different things
[19:00:05] <mhaberler> what's on your mind regarding HAL/UI shutdown?
[19:00:07] <cradek> but I think I explained my thoughts plainly in "we feel differently..." and "I don't ..." above
[19:00:38] <cradek> I think you are solving a nonproblem, possibly adding harm doing it, and missing the very real problem
[19:01:07] <cradek> my thoughts are that a task crash should stop the machine by causing a full exit of hal/motion so watchdogs trigger
[19:02:36] <mhaberler> ok. let us assume we are at v2.5_branch before my patch. Something segfaults and task just goes away. How is that better than notifying the user and then going away? I do not understand your concern just yet.
[19:03:19] <mhaberler> run emc, and send a sigseg to milltask. see what happens.
[19:03:27] <mhaberler> sigsegv
[19:03:33] <cradek> my thoughts are that a task crash should stop the machine by causing a full exit of hal/motion so watchdogs trigger
[19:04:18] <mhaberler> do I get you right: are you saying task is supposed to continue after a segfault?
[19:04:23] <cradek> any other solution to the problem of task silently failing is not really a solution
[19:04:38] <cradek> no, I am not saying that
[19:04:51] <mhaberler> then there is no difference
[19:05:48] -!-
syyl_ has quit [Quit: Verlassend]
[19:06:21] <mhaberler> actually a segfault right now does NOT trigger shutdown (!)
[19:06:32] <cradek> I KNOW THAT
[19:06:34] <cradek> that is the problem
[19:06:38] <cradek> you are not fixing it
[19:07:10] <mhaberler> make me understand why this is the problem
[19:07:14] <cradek> sorry but I don't know how to be more clear
[19:08:03] <mhaberler> are you saying an exit(), which is the default on sigsegv, is better than triggering emc_shutdown()? well if it is, let's do that
[19:08:57] <cradek> the fix to the actual problem (machine becomes unsafe when task crashes) will probably require code outside task
[19:09:17] <cradek> in fact by definition no amount of code inside task alone can fix it
[19:09:56] <mhaberler> I took the analogy from sigterm, but I wasnt aware shutting down like in emctask_quit is an issue
[19:10:06] <cradek> the problem you saw (developer is confused because task crashed and developer didn't notice right away) is not the problem I see at all (when task crashes, the machine can harm itself/something/someone)
[19:10:27] <mhaberler> aha
[19:10:43] <mhaberler> so what would be the best way to safely shut down?
[19:11:06] <cradek> cause motion/hal to exit so hardware watchdogs trigger, causing estop
[19:13:36] <cradek> brb
[19:17:38] -!-
Loetmichel has quit [Ping timeout: 260 seconds]
[19:21:49] -!-
psha has quit [Quit: Lost terminal]
[19:25:04] <mhaberler> so if I understand you correctly: what you're concerned about: messages are in say, motion queue, task exits, motion keeps executing commands because it doesnt notice task went away
[19:26:12] <mhaberler> I dont see a reason why task cant have a HAL pin which is part of the estop chain
[19:27:07] <mhaberler> actually I did that with my experiments in removing iocontrol, and replacing it with Python code which does have creates a HAL component in task - works fine
[19:30:25] -!-
theos has quit [Disconnected by services]
[19:41:09] <mhaberler> hardware has these charge-pump input signals - if transitions stop on charge-pump, estop triggers
[19:44:54] <mhaberler> task could create a task.charge-pump signal in the main loop; transitions would stop on crash. whats missing is a hal component which can act on loss of transitions on a charge-pump type pin
[19:51:16] <mhaberler> actually its not missing. what about using the watchdog component and a task HAL pin?
[20:04:07] -!-
micges_work [
[email protected]] has joined #emc-devel
[20:04:13] -!-
micges_work has quit [Quit: Leaving.]
[20:10:27] -!-
isssy has quit [Quit: Visitor from www.linuxcnc.org]
[20:15:05] -!-
mozmck has quit [Ping timeout: 260 seconds]
[20:16:49] -!-
mozmck [mozmck!~moses@client-173.225.233.241.dfwtx.partnershipbroadband.com] has joined #emc-devel
[20:18:11] <mhaberler> if I would be concerned about motion and HAL not noticing task went away, I would follow several strategies in parallel:
[20:18:11] <mhaberler> 1. add a task.charge-pump HAL pin which definitely, positively stops when task goes away, and connect a watchdog component
[20:18:11] <mhaberler> 2. add a task.estop HAL pin which is immediately toggled in a signal handler and evaluate that in parallel - it might be a bit faster
[20:18:12] <mhaberler> 3. I'd also try to flush NML queues
[20:18:12] <mhaberler> 4. I'd try to send a error channel message to the UI, so at least there's a chance of a notice.
[20:18:12] <mhaberler> 1. always works, possibly a bit late. 2. is likely to work if base address and offset arent destroyed yet. just a shared memory write in the signal handler. One could use a signature to verify base and offset to improve chances. 3. might work. 4. would be nice.
[20:18:13] <mhaberler> Am I missing something? I just notice none of the above has ever been tried in task.
[20:38:27] <cradek> I've heard discussions of it (particularly your #1) several times before
[20:39:17] <mhaberler> where's the fault?
[20:40:17] <cradek> there may not be one
[20:40:45] <cradek> I wish there was a way to make sure the hardware watchdogs bite, but that's probably my mesa-centric thinking
[20:44:44] <mhaberler> a single one might help me understand flaws in my approach; has any of this ever been tried? any pointers to history? what did fail? sorry being a nuisance
[20:52:08] <cradek> I don't think anyone tried it. I remember talking about it in person, so it was probably at an emcfest with no written record
[20:52:31] <cradek> I recall swpadnos being involved, fwiw
[20:54:34] <mhaberler> ok
[20:54:37] <mhaberler> thanks
[20:57:50] <mhaberler> by 'make sure the hardware watchdogs bite', do you mean 'are able to detect a loss of a charge-pump type signal'?
[20:58:26] <mhaberler> or some other kind of timeout?
[20:58:31] <cradek> several smart hardwares have a watchdog that disables (stuff) when the periodic hal read/write stops
[20:58:49] <cradek> this is important especially for pwmgen/stepgen because they'll keep you going at that velocity if something goes wrong otherwise
[20:59:32] <mhaberler> sure, that's what I meant with the task.charge-pump out pin - connect to hw or a watchdog component to make sure exitus is notices
[20:59:33] <mhaberler> d
[21:03:24] <cradek> in the devices I'm thinking about, I think you can't trigger it except by stopping the hal threads
[21:04:04] <cradek> which is why I was saying earlier that maybe hal/motion should just exit if any part of emc crashes
[21:04:53] <mhaberler> I'm not very familiar with HAL internals, are these userland or kernel?
[21:05:26] <cradek> the realtime hal funcs are all in kernel land
[21:05:51] <mhaberler> are they stopped by module unload?
[21:06:40] <cradek> can you unloadrt while hal is running?
[21:07:01] <cradek> 'halcmd stop' would do it if unloading doesn't
[21:07:26] <cradek> weird - what if hal had a hal pin that stopped hal?
[21:07:34] <mhaberler> I'd need to read the code
[21:07:47] <mhaberler> well, I was thinking about that kill pin.
[21:08:58] <mhaberler> if I understand you correctly you're mostly concerned with time-to-kill
[21:11:33] <mhaberler> wa
[21:11:42] -!-
FinboySlick has quit [Quit: Leaving.]
[21:11:51] <mhaberler> what the world needs is HAL exceptions;)
[21:13:38] <mhaberler> the kill pin is in-band signalling, and that usually isnt a great idea
[21:13:57] <mhaberler> the telcos have learned that hard way
[21:15:24] <cradek> bbl, yay, it's a weekend now
[21:15:32] <cradek> mhaberler: thanks for thinking about this
[21:15:35] <mhaberler> I think it would be helpful to translate this issue into a requirement statement. Cu
[21:15:47] <mhaberler> enjoy
[21:19:52] -!-
syyl has quit [Quit: Leaving]
[21:29:33] -!-
ries has quit [Ping timeout: 260 seconds]
[21:42:46] -!-
e-ndy has quit [Quit: Ex-Chat]
[21:53:23] -!-
Fox_Muldr has quit [Ping timeout: 260 seconds]
[22:00:26] -!-
servos4ever has quit [Quit: ChatZilla 0.9.85 [SeaMonkey 2.0.11/20101206162726]]
[22:12:49] -!-
robh__ [
[email protected]] has joined #emc-devel
[22:14:22] -!-
atom1 has quit [Quit: Leaving]
[22:16:48] -!-
odiug has quit [Ping timeout: 260 seconds]
[22:49:03] -!-
grommit has quit [Remote host closed the connection]
[23:02:52] -!-
mhaberler has quit [Quit: mhaberler]
[23:13:55] -!-
roberth_ [
[email protected]] has joined #emc-devel
[23:15:38] -!-
robh__ has quit [Ping timeout: 260 seconds]
[23:39:38] -!-
roberth_ has quit [Ping timeout: 252 seconds]
[23:58:13] -!-
PCW has quit [Quit: ChatZilla 0.9.87 [Firefox 3.6.13/20101203075014]]