Back
[00:00:00] -!- Nick001-Shop has quit [Remote host closed the connection]
[00:06:16] -!- sumpfralle has quit [Ping timeout: 245 seconds]
[00:08:41] -!- asdfasd has quit [Ping timeout: 252 seconds]
[00:12:03] -!- thesisb has quit [Read error: Operation timed out]
[00:14:01] -!- thesisb_ has quit [Ping timeout: 256 seconds]
[00:18:04] -!- andypugh has quit [Quit: andypugh]
[00:18:29] -!- servos4ever has quit [Quit: ChatZilla 0.9.85 [SeaMonkey 2.0.11/20101206162726]]
[00:18:45] -!- Oafed has quit [Quit: Page closed]
[00:22:59] -!- syyl_ has quit [Quit: Leaving]
[00:30:02] -!- skunkworks has quit [Ping timeout: 255 seconds]
[00:40:58] -!- tmcw has quit [Ping timeout: 245 seconds]
[00:53:35] -!- PCW has quit [Quit: ChatZilla 0.9.90 [Firefox 20.0.1/20130409194949]]
[01:00:48] -!- micges has quit [Quit: Leaving]
[01:26:28] -!- hdokes has quit [Quit: HydraIRC -> http://www.hydrairc.com <- In tests, 0x09 out of 0x0A l33t h4x0rz prefer it :)]
[01:31:34] Bojangle1 is now known as Bojangles
[01:35:40] -!- joe9 has quit [Remote host closed the connection]
[01:43:37] -!- thesisb has quit [Quit: Leaving...]
[01:48:22] <cradek> I'm still regularly seeing people on the forum fail to install 10.04, but 8.04 works fine
[01:49:03] <cradek> that makes me sad
[01:49:29] <cradek> I guess it's only 5 years old though... not like it's prehistoric
[01:58:17] -!- jfire has quit [Quit: Leaving.]
[02:03:02] -!- jfire has quit [Client Quit]
[02:03:06] -!- stsydow has quit [Remote host closed the connection]
[02:15:13] -!- Valen has quit [Quit: Leaving.]
[02:26:58] -!- maximilian_h1 [maximilian_h1!~bonsai@g228079002.adsl.alicedsl.de] has joined #linuxcnc-devel
[02:28:17] -!- largecheesepuff has quit [Ping timeout: 246 seconds]
[02:29:04] -!- maximilian_h has quit [Ping timeout: 272 seconds]
[02:29:36] -!- blommer has quit [Ping timeout: 245 seconds]
[02:31:48] -!- krusty_ar has quit [Ping timeout: 245 seconds]
[02:36:28] <jepler> so I found a USB joystick and ran hal_input for a few hours (2.5, userspace sim). it's still working 3 1/2 hours later.
[02:37:47] <jepler> when I unplugged it, I got a kernel message
[02:37:47] <jepler> Apr 29 21:37:05 babs kernel: [174306.390458] usb 1-1: USB disconnect, device number 4
[02:38:03] <jepler> and a Python traceback on the terminal
[02:38:03] <jepler> File "/usr/src/linuxcnc/lib/python/linux_event.py", line 123, in read
[02:38:04] <jepler> buf = os.read(f, cls.size)
[02:38:04] <jepler> OSError: [Errno 19] No such device
[02:39:01] <jepler> and of course the hal pins disappeared because the component exited.
[02:42:08] <jepler> so particularly in the case of IchGuckLive's report where the device disappearance goes along with turning on an RF source, I am going to treat this as a hardware problem (and take no further action) until more information is furnished that contradicts that theory.
[02:45:48] -!- thesisb has quit [Quit: Leaving...]
[02:46:14] <jepler> A patch to have hal_input wait for a lost device to "come back" is something I'm definitely not going to write, something I think is a bad idea (you want to keep running your machine when the pendant goes walkabout?), but would review a patch if someone submitted it.
[02:49:03] <jepler> now that I think about it, though, it is too bad there's not a straightforward way to make a lost pendant cause an estop condition
[02:49:13] <jepler> that's the patch I'd rather see
[02:49:51] <seb_kuzminsky> jepler: that's a good idea
[02:49:55] <jepler> way back in the day swp talked about a component that would monitor the "health" of various components and estop if any of them went south; that sounds like a good idea right about now
[02:50:08] <jepler> but I don't think it ever got implemented
[02:51:32] <jepler> hmm
[02:51:56] <pcw_home> Didn't SWP make a watchdog comp
[02:52:53] <jepler> ah yes there is a standalone watchdog component (hal/components/watchdog.c) apparently without documentation
[02:52:54] <seb_kuzminsky> there's a watchdog comp
[02:52:59] <seb_kuzminsky> it's got a manpage
[02:53:23] <seb_kuzminsky> http://linuxcnc.org/docs/2.5/html/man/man9/watchdog.9.html
[02:53:25] <pcw_home> ideally it would get a heartbeat (or heartbeats) from a number of internal sanity checks
[02:53:38] <jepler> oh there it is
[02:53:47] <jepler> I was typing "man 3" because my brain's failing
[02:54:05] <jepler> so yes I guess hal_input should grow an output that is suitable for feeding to watchdog.input-# pin
[02:54:15] <seb_kuzminsky> heh, i'm used to typing "find" then "man -l"
[02:54:31] <seb_kuzminsky> in my repo
[02:54:51] <jepler> I wrote man 3 wa<tab>
[02:55:15] <jepler> anyway .. 'night folks
[02:55:25] <pcw_home> GUI HB, Task HB, Motion HB
[02:55:50] <seb_kuzminsky> goodnight jeff
[02:56:03] <pcw_home> 'nite
[02:58:37] <seb_kuzminsky> the shuttlexpress component uses usb, so it's vulnerable to that same spurious disconnect problem
[02:59:08] -!- Keknom has quit [Quit: Leaving.]
[03:05:48] <pcw_home> If it disconnects in the middle of a jog, what stops the machine?
[03:48:47] -!- Felix29 has quit []
[03:50:42] -!- jfire has quit [Quit: Leaving.]
[04:01:09] -!- tmcw has quit [Remote host closed the connection]
[04:26:41] -!- FinboySlick has quit [Quit: Leaving.]
[04:30:06] -!- gabewillen has quit [Ping timeout: 264 seconds]
[04:33:31] -!- tjb1 has quit [Quit: tjb1]
[04:39:43] -!- tmcw has quit [Ping timeout: 245 seconds]
[04:52:45] -!- Tecan has quit [Changing host]
[04:56:30] Tecan is now known as zXz
[05:00:49] -!- scottdavis has quit [Remote host closed the connection]
[05:06:32] -!- ve7it has quit [Remote host closed the connection]
[05:24:09] -!- automata [automata!~automata@122.169.56.44] has joined #linuxcnc-devel
[05:24:15] zXz is now known as Tecan
[05:31:55] -!- mhaberler [mhaberler!~mhaberler@macbook.stiwoll.mah.priv.at] has joined #linuxcnc-devel
[05:36:48] -!- tmcw has quit [Ping timeout: 245 seconds]
[05:50:16] -!- automata has quit [Read error: Connection reset by peer]
[05:51:07] -!- automata [automata!~automata@122.169.56.44] has joined #linuxcnc-devel
[06:14:10] -!- a-l-e has quit [Ping timeout: 256 seconds]
[06:23:32] -!- r00t4rd3d has quit [Read error: Connection reset by peer]
[06:26:53] -!- jfire has quit [Quit: Leaving.]
[06:27:56] Real-Genius is now known as GammaX
[06:28:04] -!- GammaX has quit [Changing host]
[06:37:58] -!- tmcw has quit [Ping timeout: 272 seconds]
[06:57:12] -!- Loetmichel has quit [Ping timeout: 264 seconds]
[06:58:21] -!- Tom_itx has quit [Ping timeout: 245 seconds]
[07:06:53] Cylly is now known as Loetmichel
[07:11:00] -!- chron0 has quit [Ping timeout: 264 seconds]
[07:17:33] -!- psha[work] [psha[work]!~psha@195.135.238.205] has joined #linuxcnc-devel
[07:17:42] -!- rob_h [rob_h!~rob_h@94.2.180.164] has joined #linuxcnc-devel
[07:27:46] -!- mhaberler has quit [Quit: mhaberler]
[07:37:19] -!- mhaberler [mhaberler!~mhaberler@macbook.stiwoll.mah.priv.at] has joined #linuxcnc-devel
[07:38:02] -!- tmcw has quit [Ping timeout: 256 seconds]
[07:57:02] -!- kizer has quit [Ping timeout: 256 seconds]
[07:59:31] cevad is now known as Guest46583
[08:03:14] -!- odogono has quit [Read error: Connection reset by peer]
[08:12:38] -!- GammaX-Laptop has quit [Ping timeout: 245 seconds]
[08:14:52] -!- Tecan has quit [Ping timeout: 256 seconds]
[08:15:06] -!- kizer has quit [Changing host]
[08:24:56] -!- kizer has quit [Ping timeout: 246 seconds]
[08:37:43] -!- Tecan has quit [Ping timeout: 264 seconds]
[08:38:28] -!- tmcw has quit [Ping timeout: 245 seconds]
[08:40:01] -!- Farthen has quit [Ping timeout: 248 seconds]
[08:50:23] -!- mhaberler has quit [Quit: mhaberler]
[08:54:00] -!- thesisb has quit [Quit: Leaving...]
[08:55:44] -!- kizer has quit [Ping timeout: 246 seconds]
[09:03:56] -!- Tom_itx has quit [Ping timeout: 255 seconds]
[09:13:57] -!- kizer has quit [Changing host]
[09:19:49] -!- Valen00 has quit [Remote host closed the connection]
[09:38:53] -!- tmcw has quit [Ping timeout: 245 seconds]
[09:40:24] -!- mhaberler [mhaberler!~mhaberler@macbook.stiwoll.mah.priv.at] has joined #linuxcnc-devel
[10:20:28] -!- blommer has quit [Quit: bye]
[10:21:48] -!- GammaX-Laptop has quit [Ping timeout: 245 seconds]
[10:25:15] -!- kanzure has quit [Ping timeout: 276 seconds]
[10:39:18] -!- tmcw has quit [Ping timeout: 245 seconds]
[10:45:39] -!- UncleG has quit [Quit: Page closed]
[10:48:33] -!- b_b has quit [Changing host]
[11:02:42] -!- fomox has quit [Ping timeout: 272 seconds]
[11:05:56] -!- skunkworks [skunkworks!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[11:08:16] -!- stsydow has quit [Remote host closed the connection]
[11:23:16] -!- Valen has quit [Quit: Leaving.]
[11:26:10] -!- carper64_lb [carper64_lb!~quassel@2.120.120.24] has joined #linuxcnc-devel
[11:31:59] -!- asdfasd has quit [Read error: Connection reset by peer]
[11:38:50] -!- hdokes has quit [Quit: HydraIRC -> http://www.hydrairc.com <- The alternative IRC client]
[11:40:42] -!- tmcw has quit [Ping timeout: 272 seconds]
[11:54:46] -!- stsydow has quit [Remote host closed the connection]
[11:55:38] -!- dhoovie has quit [Read error: Connection reset by peer]
[11:59:10] -!- stsydow has quit [Remote host closed the connection]
[12:04:55] -!- Felix29 [Felix29!Felix@c-71-193-105-131.hsd1.in.comcast.net] has joined #linuxcnc-devel
[12:07:39] -!- KimK has quit [Ping timeout: 260 seconds]
[12:13:08] -!- mhaberler has quit [Quit: mhaberler]
[12:18:04] -!- zlog has quit [Remote host closed the connection]
[12:18:10] -!- Tom_itx has quit []
[12:20:33] -!- KimK [KimK!~Kim__@wsip-184-176-200-171.ks.ks.cox.net] has joined #linuxcnc-devel
[12:40:52] -!- tmcw has quit [Ping timeout: 272 seconds]
[12:44:29] -!- psha[work] has quit [Quit: leaving]
[13:07:21] -!- tmcw has quit [Remote host closed the connection]
[13:09:39] -!- Felix29 has quit []
[13:17:58] -!- gonzo__ has quit [Ping timeout: 248 seconds]
[13:26:10] -!- mle has quit [Excess Flood]
[13:26:11] -!- syyl has quit [Ping timeout: 252 seconds]
[13:26:36] -!- syyl_ws has quit [Ping timeout: 276 seconds]
[13:49:50] -!- skorasaurus has quit [Ping timeout: 252 seconds]
[13:57:15] -!- riz_ [riz_!62dd7d6e@gateway/web/freenode/ip.98.221.125.110] has joined #linuxcnc-devel
[13:58:12] <riz_> Quick question. Is there a M99 return command in linuxcnc? I couldn tfind it on the standard M-code list.
[13:58:56] <cradek> what kind of motion are you trying to get?
[13:59:56] <riz_> I just want the g-code program to repeat at the end of the file
[14:00:08] <riz_> not canned motion though
[14:00:14] <riz_> I know I use m99 on fanuc
[14:00:47] <cradek> there is O-repeat that will run the enclosed code some number of times
[14:01:13] <riz_> OK. Ill check that out
[14:01:16] -!- ravenlock has quit [Ping timeout: 245 seconds]
[14:03:51] <riz_> I guess I can just make a user defined M-code if I want M99?
[14:09:58] -!- Valen has quit [Quit: Leaving.]
[14:20:22] <cradek> if M99 means "start running the program again from the top" then I am not sure. is that what it means?
[14:21:38] -!- Blorb has quit [Read error: Operation timed out]
[14:22:05] <riz_> yes
[14:23:16] <skunkworks> M99 in fanuc speak I thought is return to calling program
[14:23:43] <skunkworks> (it has been a while since I have played with fanuc)
[14:24:08] <cradek> beware that a program that runs forever (or almost forever) is a bad idea to load into the AXIS preview. you can use a magic (AXIS,stop) comment to make it stop generating the preview.
[14:27:21] <riz_> It might just be for fanuc
[14:27:55] <cradek> well aside from M2 we don't have any M-based flow control. Our flow control uses O words.
[14:28:17] <riz_> oh ok
[14:28:19] <cradek> so how fanuc does it doesn't matter much to us - but if you're trying to accomplish a certain behavior maybe we can advise
[14:28:21] -!- kanzure has quit [Remote host closed the connection]
[14:28:37] <cradek> repeating some gcode a bunch of times is what O-repeat is for in our dialect
[14:29:19] <cradek> I notice O-repeat isn't in the quickref. I will fix that.
[14:29:24] <riz_> I was just looking for the functionality really. My postprocessor is for fanuc, so it would have just been easier
[14:29:43] <riz_> oh ok. That would be good
[14:31:18] <seb_kuzminsky> o-repeat *is* in the main o-code docs:
http://linuxcnc.org/docs/2.5/html/gcode/o-code.html#_repeat
[14:32:13] <cradek> yes just not in the quickref
[14:32:42] <riz_> So, you actually have to specify how mnay times you want it to run???
[14:32:51] <cradek> yes
[14:32:56] <riz_> hmmm
[14:33:40] <jepler> O while [1] creates an infinite loop
[14:34:09] <riz_> Oh ok. much better haha
[14:35:06] <jepler> O while [it's not beer-thirty yet]
[14:36:52] -!- vladimirek [vladimirek!~vladimire@95.105.250.72] has joined #linuxcnc-devel
[14:37:33] -!- _vitin has quit [Ping timeout: 245 seconds]
[14:40:04] <KGB-linuxcnc> 03chris 05v2.5_branch 1860a4f 06linuxcnc 10docs/ 10html/gcode.html 10src/gcode/o-code.txt * Document o-repeat in the quickref
[14:44:10] <riz_> I am a little confused as to what the purpose of these "unwind_call"s are for. Can anyone shed some light on the purpose of them?
[14:44:39] <riz_> They seem to be in reset() calls in the interpreter
[14:59:34] <jepler> cradek: any concerns for inclusion in 2.5? emergent.unpythonic.net/files/sandbox/heartbeat.patches.mbox
[15:02:15] <jepler> .. and is the documentation adequate?
[15:02:17] <cradek> your code and log don't match - I'm confused by the whole halui/hal_input change
[15:02:51] <jepler> oops the commit message is wrong
[15:02:54] <jepler> it should say hal_input: ...
[15:03:34] <cradek> the doc sentence is confused too
[15:04:26] <cradek> An input that ... This output
[15:04:33] <jepler> yeah it's an output
[15:04:54] <jepler> .B input.heartbeat bit out
[15:04:54] <jepler> An output that toggles at a rate of >1Hz in normal operation. (nominally,
[15:04:57] <jepler> 100Hz). In the case of an I/O error with any input device, hal_input will exit
[15:05:00] <jepler> and this pin will stop toggling. This output is intended to be connected to an
[15:05:03] <jepler> input of the \fBwatchdog\fR component.
[15:05:10] <cradek> can you give me a fresh mbox please
[15:05:21] <jepler> yes but I have a meeting first
[15:05:26] <cradek> heh ok
[15:05:29] <jepler> thanks for looking, I should have reviewed a bit harder myself
[15:05:38] <cradek> np, 's my job
[15:23:38] -!- jpk has quit [Ping timeout: 272 seconds]
[15:25:51] -!- Bojangles has quit [Ping timeout: 245 seconds]
[15:30:25] -!- ve7it [ve7it!~LawrenceG@S01060014d19d0b68.pk.shawcable.net] has joined #linuxcnc-devel
[15:31:23] -!- Tom_itx has quit [Disconnected by services]
[15:31:27] Tom_garage is now known as Tom_itx
[15:37:14] -!- ler_hydra has quit [Remote host closed the connection]
[15:39:36] -!- Tom_itx has quit [Ping timeout: 245 seconds]
[15:41:23] -!- zlog has quit [Ping timeout: 260 seconds]
[15:55:26] -!- jpk has quit [Client Quit]
[15:57:06] -!- automata has quit [Ping timeout: 245 seconds]
[16:00:54] -!- mhaberler [mhaberler!~mhaberler@193.228.47.195] has joined #linuxcnc-devel
[16:17:12] -!- omgbbqhax has quit [Client Quit]
[16:28:39] <jepler> I'm still concerned that my description paragraph for hal_input is not accurate
[16:29:29] <jepler> what happens is, hal_input exits; the input.heartbeat pin disappears, and so the connected signal (if any) stops having a connected output and so the watchdog.input-# pin stops seeing toggles on its input
[16:30:33] -!- toner has quit [Ping timeout: 276 seconds]
[16:34:36] -!- jfire has quit [Quit: Leaving.]
[16:35:29] <cradek> I have never thought of disappearing pins
[16:35:44] -!- Nick001 has quit [Ping timeout: 255 seconds]
[16:35:45] <cradek> does that get handled in some kind of sane way?
[16:39:43] <jepler> yes. if a component dies cleanly (e.g., python exception, or kill -TERM) it unlinks all its pins, then destroys the pins
[16:39:46] -!- karavanjoW has quit [Quit: KVIrc 4.0.4 Insomnia http://www.kvirc.net/]
[16:40:22] <jepler> if it dies uncleanly (e.g., kill -9) the pins and component linger until the hal session ends
[16:40:22] <cradek> I'm both happy and surprised that that works
[16:41:04] <jepler> things that read or write signals that were attached to those pins work just fine, because it's all in the shared memory area and remains mapped memory until the hal session ends
[16:41:52] <jepler> anyway, the reports I have say that hal_input's pins disappear so presumably it's exiting cleanly (I observed it exiting with a Python exception when I manually unplugged my input device)
[16:42:11] <jepler> but given all this I'm not sure how to write the description of the pin
[16:42:29] -!- andypugh [andypugh!~andy2@cpc16-basl9-2-0-cust685.20-1.cable.virginmedia.com] has joined #linuxcnc-devel
[16:42:54] -!- largecheesepuff has quit [Ping timeout: 276 seconds]
[16:45:07] -!- micges [micges!~micges@aecj119.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[16:50:20] <jepler> patch finally updated:
http://emergent.unpythonic.net/files/sandbox/heartbeat.patches.mbox
[16:50:57] <cradek> thanks
[16:51:02] -!- largecheesepuff has quit [Ping timeout: 255 seconds]
[16:52:08] -!- fllr has quit [Quit: leaving]
[16:52:23] <seb_kuzminsky> looks good jeff
[16:52:53] -!- kmrhb has quit [Ping timeout: 252 seconds]
[16:52:56] <jepler> riz_: unwind_call seems to have to do with exiting active "O call" blocks in the case of a gcode error, but that's just my interpretation of the comment above the implementation of Interp::unwind_call...
[16:53:48] -!- tmcw has quit [Remote host closed the connection]
[16:55:43] <cradek> I guess there's no bootstrap problem if the postgui hal file has to run before you can come out of estop
[16:56:20] <cradek> it seems a little hard to get the watchdog component running and reset when some of the inputs it's monitoring appear "late"
[16:57:01] <cradek> I'm not saying there's a problem with this patchset, I'm just puzzling out how to successfully use it
[16:57:47] <cradek> the watchdog docs (watchdog.enable-in) must be wrong
[16:57:52] <cradek> it makes no sense
[16:58:07] <cradek> I mean watchdog manpage
[16:59:14] <jepler> I have to admit I haven't actually tried to incorporate this into a working setup
[16:59:57] <jepler> I assumed that it would work to connect axisui.heartbeat in POSTUI_HALFILE and as long as axisui.heartbeat is toggling by the time you hit F1 to exit estop it would be fine
[17:00:31] <cradek> if watchdog ever has timed out, it locks in the not-ok state until you reset it by twiddling enable-in
[17:00:58] -!- mackerski has quit [Ping timeout: 245 seconds]
[17:01:01] <cradek> so maybe your postgui hal file can reset it with sets/setp once it's hooked the last thing up
[17:01:42] <cradek> or I guess you'd only enable it then, which would work fine if AXIS is the last thing to appear
[17:01:55] <jepler> I think it would be
[17:02:48] <jepler> > Marie Skłodowska-Curie, often referred to as Marie Curie or Madame Curie (7 November 1867 – 4 July 1934), was a female Polish female physicist and lady chemist, working mainly in woman-France, who is girl-famous for her pioneering chick research on radioactivity.
[17:03:21] <jepler> (hm, should it be edited to refer to gynoradioactivity? what's the proper term?)
[17:03:28] <cradek> what
[17:03:31] <mhaberler> cradek: see the devlist archives, watchdog is dangerously broken
[17:03:38] -!- sumpfralle has quit [Ping timeout: 246 seconds]
[17:03:54] <mhaberler> I had an exchange with swpadnos on it, its very long since though
[17:04:03] <mhaberler> it can give fals positives (!)
[17:04:11] <cradek> do you have a fix?
[17:04:12] <mhaberler> let me see if I can find it
[17:04:15] <cradek> ok thanks
[17:04:35] <zultron> Hey jepler, I'm looking at modifying the build system to handle the universal binary.
[17:04:38] <cradek> I'm pretty sure at least the docs are wrong :-)
[17:04:44] <jepler> http://mid.gmane.org/A9F666CA-814E-4FD7-A746-1EC5924234E6%40mah.priv.at http://mid.gmane.org/A1B190F8-ECE7-4B70-9374-69436B625CC4%40mah.priv.at
[17:05:02] <jepler> (didn't read them, just found 'em in my mail archive)
[17:05:12] <cradek> jepler: thanks
[17:05:16] <zultron> It looks easiest to run make once per flavor, like 'make THREADS=xenomai-user'.
[17:05:42] <cradek> nooooooooo
[17:05:58] <jepler> cradek is being a bit theatrical, but let's just say it would be preferable to avoid that :-P
[17:06:01] <mhaberler> http://www.mail-archive.com/emc-developers@lists.sourceforge.net/msg04843.html
[17:06:25] <zultron> Trouble is that flavor-specific stuff is all in configure.in, so when config.h gets touched, a whole lot of unnecessary stuff is recompiled/relinked.
[17:06:33] <mhaberler> (no, I dont have a fix)
[17:07:31] <zultron> I'm thinking a solution is to split configure.in: the current configure.in & config.h remains, but flavor-specific parts are moved into rtapi/configure.in and rtapi/config.h.
[17:08:14] -!- dway has quit [Quit: NOOOOOOooooooooo……]
[17:08:18] <zultron> When 'make THREADS=xenomai-user' is run, there's a rule to run 'rtapi/configure --with-threads=xenomai-user'.
[17:08:28] <riz_> thanks jepler
[17:08:43] <zultron> Think that makes sense?
[17:08:57] <jepler> ifeq ($(HAVE_XENOMAI_USER_FLAVOR),yes)
[17:08:58] <jepler> rules for "xenomai user" flavor including setting CFLAGS for specific object fil
[17:09:01] <jepler> es
[17:09:03] <jepler> default: xenomai-targets
[17:09:05] <jepler> install: xenomai-install
[17:09:08] <jepler> endif
[17:09:10] <jepler> .. and so on for each flavor
[17:09:25] <jepler> now configure just needs to set HAVE_XENOMAI_USER_FLAVOR when appropriate, and whatever other variables it's sensible to set like XENOMAI_CFLAGS, XENOMAI_LIBS...
[17:10:34] <mhaberler> cradek: see thread here
http://emc.mah.priv.at/irc/%23emc-devel/2011-09-23.html#07:04:36
[17:10:40] <jepler> bbl, lunchtime here
[17:10:43] <mhaberler> never materialized into a patch
[17:11:52] <zultron> You mean make configure detect all flavors in its single run, and generate a config.h controlled by HAVE_FOO_FLAVOR?
[17:12:33] -!- sumpfralle has quit [Read error: Connection reset by peer]
[17:12:57] <cradek> mhaberler: I agree it looks all screwy, thanks for stopping me before I blindly started "fixing" the docs
[17:13:47] <mhaberler> I think it should either be fixed or removed, that's a bit on the dangerous side
[17:14:07] <mhaberler> blind and lame watchdog ;)
[17:14:08] <cradek> I don't think this is necessarily a reason to decline jepler's patch, but OTOH I'd not want to encourage people to use the watchdog component in its current state
[17:14:20] -!- sumpfralle1 has quit [Read error: Operation timed out]
[17:14:26] <cradek> are you interested in fixing it? I'll be happy to review.
[17:14:34] <mhaberler> oh, didnt read back that far - great if there's a patch
[17:14:37] <mhaberler> let me see
[17:14:38] <cradek> I don't think it's necessary to talk to swp about it before fixing it
[17:15:28] <cradek> hmm, I wonder about breaking "running" (but maybe not perfectly protected) configs, for instance if we make bootstrap harder
[17:16:00] <cradek> jepler's patch is not to watchdog; it adds heartbeats you might want to hook to watchdog
[17:17:12] -!- sumpfralle2 has quit [Ping timeout: 252 seconds]
[17:17:55] <zultron> jepler, no, I think what you mean is generate everything needed from one run of ./configure and build all flavors from one 'make' run.
[17:18:11] <mhaberler> that makes a lot of sense to have such live signals; I added one to task too at the time for an experiment
[17:18:24] <cradek> yes
[17:18:43] <mhaberler> charge-pump its usally called methinks
[17:19:19] <zultron> That's the 'right' way to do it, I think, but I was feeling intimidated by my past experiences with Makefile.
[17:19:22] <mhaberler> I think I had a stab at that, let me dig
[17:20:05] <cradek> perhaps chargepump would have been a better name for watchdog
[17:21:25] <mhaberler> no, I mean the type of square signal which disables things if no transitions are seen for a certain period; watchdog should have such detector inputs
[17:21:52] <mhaberler> and those would be linked to chargpump-type hal pins of critical periodic components
[17:22:01] <mhaberler> one of those hangs - estop
[17:22:37] <pcw_home> Absolutely, We need to add one to sserial as well
[17:22:44] <cradek> a charge pump is the device that takes these changing inputs, not the name of the changing signal
[17:22:56] <mhaberler> not sure if we have such a transition detector code somewhere to start from
[17:23:12] <mhaberler> a retriggered monoflop basically
[17:23:29] <mhaberler> ah, so it's the detector really
[17:23:42] <cradek> yes, usually a piece of simple hardware
[17:24:17] -!- sumpfralle has quit [Read error: Connection reset by peer]
[17:24:30] <mhaberler> that possibly should be a separate comp
[17:25:01] <cradek> watchdog (except for being broken) is exactly like a multi-input charge pump
[17:25:05] <pcw_home> Thats what the watchdog comp is supposed to do (with software module sanity heartbeats)
[17:25:22] <cradek> it just needs to be fixed
[17:26:22] <mhaberler> yes it is
[17:27:33] -!- riz_ has quit [Ping timeout: 245 seconds]
[17:28:08] -!- sumpfralle1 has quit [Ping timeout: 246 seconds]
[17:28:14] <mhaberler> I think one thing it should do is: after positive edge on enable-in, ok-out may not go high until all inputs are known to have a valid signal
[17:28:58] <mhaberler> and negative edge on enable-in must disable immediately
[17:29:16] <pcw_home> Yes that makes sense never OK unless all dogs are fed
[17:29:21] <mhaberler> yeah I think thats the laundry list
[17:29:23] <cradek> I agree with #1
[17:29:47] <cradek> might think the opposite of #2. if it is disabled it ought to have the all-is-ok output high for bootstrapping reasons
[17:30:09] <mhaberler> oh my gawd ;)
[17:30:34] <mhaberler> you mean bypass the wd?
[17:31:13] <mhaberler> well if you really need this, you should go the extra mile and add an or after the wd, just to make sure everybody is aware what they are doing
[17:31:27] <cradek> well possibly, I'm weighing it
[17:31:40] <mhaberler> wrrrrrr…click… chamber was empty, lucky you
[17:32:03] <cradek> in this alternate setup, while disabled you should be watching the inputs so when you enable, you don't get a brief "not ok" output
[17:32:39] <cradek> (the external "or" can't accomplish that)
[17:32:40] <mhaberler> thats fine
[17:33:06] <cradek> so you'd get the protection as soon as you "enable" it, with no bootstrap problems
[17:33:30] <pcw_home> is machine-on a reasonable watchdog enable signal?
[17:33:33] -!- vladimirek has quit [Read error: Operation timed out]
[17:33:47] <mhaberler> so you mean: constant monitoring of transitions, resulting in an internal 'ok' signal; out-ok = or of all internal-ok signals plus positive edge on enable-in
[17:34:31] <cradek> I forgot about the latch-in-not-out-ok state feature
[17:34:32] <mhaberler> I think it was intended as a latch-on-positive-edge only, not level
[17:35:18] <mhaberler> I guess the difference is it wont rearm if enable-in stays high
[17:35:19] <cradek> oh god, we've also got a charge_pump component that generates a stupid square wave
[17:35:28] <mhaberler> yess
[17:35:31] <cradek> sigh
[17:36:49] <cradek> propose: out_ok <= !enable or (all internal timers have not timed out since rising edge of enable)
[17:36:59] <mhaberler> I think the remaining question is whether enable-in ors with the internal-ok signals, or it is a latch which is cleared on negative edge of out-ok
[17:38:26] <mhaberler> that would mean enable drives a latch high on enable-in positive edge, and low on (or of internal-ok's going low)
[17:38:39] -!- vladimirek [vladimirek!~vladimire@95.105.250.72] has joined #linuxcnc-devel
[17:38:44] <mhaberler> meaning enable must be toggled to rearm
[17:39:11] -!- FinboySlick has quit [Ping timeout: 245 seconds]
[17:39:29] <cradek> not quite following you - which are you talking about?
[17:39:59] <mhaberler> well you wrote a formula. but you also say rising edge of enable, so enable does have internal state
[17:40:14] <mhaberler> meaning it isnt just a pin
[17:40:27] <pcw_home> If you use something like machine-on for enable, the OK bit would become true after a watchdog bite
[17:40:30] <cradek> yes you would have to track the "last" value to detect edge
[17:40:56] <mhaberler> not just that
[17:41:08] <pcw_home> maybe you want a separate clear WD input
[17:41:28] <mhaberler> what you'd have is: an internal enable value, an enable-in pin with edge detection on it
[17:41:30] <cradek> pcw_home: true - and that would let you reenable with another machine-on
[17:41:45] <mhaberler> positive edge on enable-in: set internal enable to true
[17:42:15] <mhaberler> if (enable and negative-edge-detect on or of interal-ok-signals, clear internal enable variable
[17:42:48] <pcw_home> all I'm saying is that you may not want WD enable low or just falling edge of WD enable to force WD OK true
[17:43:23] <mhaberler> I think we better have a has-bitten pin to debug this..
[17:43:44] <mhaberler> well yes, that is fatal
[17:44:52] <cradek> I sympathize with that feeling wrong, but I think it might be pragmatic for bootstrapping real setups and it makes a certain sense ("I don't want watchdog's protections, so I disable it")
[17:45:31] <cradek> adding a secondary has-bitten-since-rising-enable-edge is fine with me, so you can have both options
[17:46:15] <pcw_home> Yeah thats fine, but if you ever enable it, I dont think removing enable not clear it
[17:46:37] <cradek> say again please?
[17:46:43] <pcw_home> i dont think removing enable should clear it is waht I meant
[17:46:50] <cradek> clear what?
[17:47:06] <mhaberler> I think we are lacking the wd state in the discussion
[17:47:15] <pcw_home> sorry make WDOK true again
[17:47:56] <mhaberler> one thing is the enable trigger logic, the second is clearing the wd, the third is having it bite; enable trigger and wd clear ar disjoint methinks
[17:51:42] -!- automata [automata!~automata@42.105.101.164] has joined #linuxcnc-devel
[17:51:52] <mhaberler> cradek: can you explain your bootstrapping concerns? not sure I understand the issue
[17:54:33] <cradek> I'm thinking of is-ok as just another NC switch in a hardwired estop chain. other things wired together are like motor overloads and limit switches
[17:55:04] <cradek> all those things have to be closed in order for "estop reset" to happen
[17:55:33] <cradek> perhaps this is just incompatible with the latching inside the watchdog component
[17:55:48] <pcw_home> are all software modules up and running at the point in machine start-up?
[17:56:04] <pcw_home> at that point
[17:56:12] <cradek> yes I think so
[17:57:16] <cradek> in a real machine you'd send is-ok to an opto that's wired in with the other series NC estop stuff
[17:57:37] <mhaberler> well assume wd is an NC chain
[17:57:39] -!- GammaX-Laptop has quit [Ping timeout: 276 seconds]
[17:58:07] <mhaberler> are you concerned about chicken-and-egg issues like no charge-pump signals before estop reset?
[17:58:10] <cradek> yes, and it really is
[17:58:17] <mhaberler> that'd be a bummer
[17:58:19] <cradek> yes exactly
[17:58:24] <mhaberler> duh
[17:59:00] <cradek> at estop reset you'd enable the watchdog component and start getting its protection (meaning its ability to break the chain when it senses a failure)
[17:59:03] <mhaberler> well sorry, then the cp signal generator is wrong and must be chained too before wd
[17:59:11] <mhaberler> so they come up in sequence
[17:59:25] <mhaberler> that would get around it
[18:00:04] <mhaberler> see what I mean? cp's or cp-like comps would have an enable-in and enable-out too
[18:00:32] <cradek> no, I don't follow you
[18:00:42] <cradek> CP doesn't have latching or any other complexity
[18:01:10] <mhaberler> no latching - let me see the cp doc
[18:02:30] <mhaberler> we are talking estop reset or machine on here for the chain? I assume estop?
[18:02:39] <cradek> yes estop
[18:03:18] <mhaberler> so the estop-reset toggle feeds enable=true into the chain then?
[18:03:19] <cradek> instead of WD->opto in estop chain, you could have WD->CP (always enabled as is the default)->real hardware charge pump in estop chain
[18:03:53] <mhaberler> and if ok falls out of the estop chain, estop is cleared
[18:04:45] <cradek> brb
[18:06:33] <mhaberler> bbl, too
[18:15:57] -!- mhaberler has quit [Quit: mhaberler]
[18:16:11] <jepler> makes me regret bringing it up
[18:17:45] -!- mozmck1 [mozmck1!~moses@client-204.235.45.161.wcfltx.partnershipbroadband.com] has joined #linuxcnc-devel
[18:19:17] -!- IchGuckLive has quit [Quit: ChatZilla 0.9.87 [Firefox 20.0/20130329043827]]
[18:20:24] -!- syyl_ws_ has quit [Quit: Verlassend]
[18:20:58] -!- ktchk has quit [Ping timeout: 268 seconds]
[18:20:58] -!- mozmck has quit [Ping timeout: 268 seconds]
[18:20:58] -!- sumpfralle has quit [Ping timeout: 268 seconds]
[18:20:58] -!- cherry_lin has quit [Ping timeout: 268 seconds]
[18:20:59] -!- L33TG33KG34R has quit [Ping timeout: 268 seconds]
[18:21:01] -!- toxx has quit [Ping timeout: 268 seconds]
[18:21:59] kalmar is now known as kmrhb
[18:24:17] -!- holgi has quit [Quit: ChatZilla 0.9.90 [Firefox 20.0/20130329043827]]
[18:32:16] <cradek> http://timeguy.com/cradek-files/emc/estop-chain.jpg
[18:32:27] <cradek> here's the situation I've been handwaving about
[18:32:47] <cradek> UEO/URE are the iocontrol outputs user-enable-out and user-request-enable
[18:33:16] <cradek> BRB is big red button, the rest should be obvious
[18:33:33] <cradek> I guess this is how I see it being used
[18:34:05] <jepler> we give this example in the documentation:
http://linuxcnc.org/docs/html/ladder/ladder_examples.html#_external_e_stop
[18:34:19] <jepler> cradek: |^| is rising-edge?
[18:34:22] <cradek> yes
[18:35:00] <cradek> the lower rung in my terrible picture is what would actually be hardwired in the machine
[18:36:22] <cradek> if WD is open at /ENAB you can't ever come out of estop
[18:36:59] <cradek> if you set WDENAB=true all the time (remove that top rung) you can never reset after a bite
[18:37:28] <jepler> because WDENAB is edge triggered (not shown)
[18:37:38] <jepler> ?
[18:38:13] <cradek> no, because the WD would be open in the lower rung, making it impossible to turn on (ESTOP), which in turn makes it impossible to enable WD
[18:39:15] <cradek> I guess you could wrap URE around WD
[18:39:59] <jepler> you'd need to stretch URE's rising edge for as long as it takes for WD to go TRUE after WDENAB goes true
[18:40:06] <cradek> but you need WD to be ready instantly upon enable (which I have already said)
[18:40:23] <cradek> yes the watchdog component really needs to monitor the inputs while it's disabled, so it can enable right away
[18:40:39] <cradek> otherwise you've got a real mess
[18:40:46] <jepler> at which point you're morally back where you started, with the machine able to come out of estop for a length of time equal to the longest WD timeout
[18:41:00] <jepler> even if something that is hooked up to the watchdog isn't petting it
[18:41:18] <cradek> no! it just has to watch while disabled
[18:41:35] <cradek> it should have an internal "everything's ok" that it's ready to present to the outside world when asked
[18:43:22] <jepler> so none of the square waves into the watchdog are themselves gated by ESTOP?
[18:43:36] <jepler> (they sure weren't in the two instances I wrote earlier this morning)
[18:43:38] <cradek> no
[18:43:50] <cradek> they shouldn't be
[18:44:33] <cradek> IMO those signals mean software things are happening as expected
[18:46:34] <cradek> darnit, mhaberler is gone
[18:46:41] -!- sumpfralle1 has quit [Ping timeout: 245 seconds]
[18:47:59] <cradek> I think I'm convinced that WD out-ok can be low when ENABLE is low, without causing a bootstrap problem, IF it's ready to make out-ok true immediately on enable if the history of the inputs is ok
[18:48:03] -!- tjb1 has quit [Ping timeout: 245 seconds]
[18:48:16] <cradek> I'd just have to change the bottom rung a bit
[18:48:37] <cradek> just move /WD inside the ^URE
[18:49:09] <cradek> errr no
[18:49:15] <cradek> that's wrong
[18:49:43] <cradek> in that case, even if the history of the WD inputs is bad, that would let it incorrectly enable the chain for as long as ^URE was on
[18:49:59] <cradek> grnrngnrrhh
[18:50:57] -!- JesusAlos has quit [Quit: ChatZilla 0.9.90 [Firefox 20.0.1/20130409194949]]
[18:57:19] <andypugh> Can any real machine do anything bad inside a typical charge-pump timeout?
[18:57:58] <andypugh> In other news, I have a new HAL component. Should I push it?
[18:58:01] <jepler> not sure how far you read back, but in the docs I wrote for proposed heartbeat pins of hal_input and axisui I wasn't courageous enough to promise a toggle-rate of more than 1Hz
[18:58:26] <cradek> probably, what is it?
[18:58:43] <andypugh> 1-D interpolation
[18:59:51] <cradek> is it just a comp or is it more complex?
[19:00:10] <andypugh> Here is the context, and the code:
http://www.linuxcnc.org/index.php/english/forum/10-advanced-configuration/26465-changing-pid-parameters-on-the-fly#33424
[19:00:15] -!- morfic- has quit [Ping timeout: 272 seconds]
[19:00:59] <cradek> ah a comp with built-in docs, no packaging troubles, push away
[19:03:56] <jepler> I take it you've satisfied yourself that i can never get out of range
[19:04:16] <andypugh> Another thing I am looking at is a more general purpose mux.
[19:05:28] <andypugh> jepler: Let me try the obvious, exceeding the range od "personality"
[19:06:13] <cradek> I don't know comp I guess. I don't see it reading "in" or writing to "out" or "io"
[19:06:15] <andypugh> OK, so I need to put the limit back in :-)
[19:06:32] <cradek> oh x is in, y is out
[19:06:59] <cradek> shouldn't you read x atomically (just once per run)?
[19:07:00] <andypugh> Yes, perhaps in and out would make more sense?
[19:07:26] <jepler> cradek: yes that would be a good idea
[19:07:31] <andypugh> And again, good point.
[19:09:14] <cradek> why the heck are pid's gains IO?
[19:10:15] <cradek> so many asides...
[19:10:16] <andypugh> I have no idea
[19:10:19] <jepler> cradek: shoddy conversion from parameters back in the day
[19:10:50] <andypugh> They were parameters, and got turned into pins. A lot of parameters became IO pins at that time, and it has always puzzled me.
[19:10:58] <cradek> sigh
[19:11:11] <cradek> and that was the change that took like seven tries to get "right"
[19:11:13] <jepler> when they were parameters it was OK for the component to set them internally (e.g., cap Pgain at 1e6)
[19:11:21] <jepler> that's not OK for a pin unless its direction is IO
[19:11:27] <jepler> .. which means you can't usefully connect it to much
[19:11:45] <cradek> you can set the initial value of an input pin, but not change it afterward
[19:11:48] <cradek> ?
[19:11:56] <jepler> yes
[19:12:08] <jepler> it's not so much the initial value as the value when no signal is connected
[19:12:12] <andypugh> tristate_float is one dodge.
[19:12:41] <cradek> well shoddy is right, I guess.
[19:12:45] <cradek> oh well
[19:13:22] -!- wboykinm has quit [Remote host closed the connection]
[19:19:27] -!- mhaberler [mhaberler!~mhaberler@macbook.stiwoll.mah.priv.at] has joined #linuxcnc-devel
[19:19:57] <cradek> mhaberler: hi, please read back for more WD discussion
[19:20:32] <mhaberler> ok
[19:21:58] <cradek> bbl, going home
[19:22:04] -!- thesisb has quit [Quit: Leaving...]
[19:36:16] <cradek> back, didn't get wet, yay
[19:43:09] <jepler> does this capture what is needed, or does it make some obvious mistake? I'm still not sure I've grokked the right design.
http://emergent.unpythonic.net/files/sandbox/watchdog2.txt
[19:44:42] <jepler> I think it would work with a ladder almost like cradek's, except that instead of ESTOP -| |---( ) WDENAB you'd have ESTOP -|/|---( ) WDREQ
[19:44:54] <andypugh> Do you recall someone a while ago (years) complainign that the e-stop latch function was borked too?
[19:49:01] <jepler> I try never to recall anything.
[19:57:53] -!- KGB-linuxcnc has quit [Ping timeout: 256 seconds]
[19:58:27] -!- gonzo_ has quit [Ping timeout: 256 seconds]
[19:58:27] -!- hdokes has quit [Ping timeout: 256 seconds]
[19:59:19] -!- KGB-linuxcnc [KGB-linuxcnc!~kgb-linux@git.linuxcnc.org] has joined #linuxcnc-devel
[20:00:03] -!- _vitin has quit [Ping timeout: 245 seconds]
[20:00:09] -!- skunkworks has quit [Quit: Leaving]
[20:02:17] <cradek> jepler: after many readings I think I understand your manpage
[20:02:47] <jepler> I struggled through many writings and still don't understand what I wrote, so you are ahead of me.
[20:02:48] <cradek> the "When ..., drive ..." are things you're telling me (the user) to do in order to use the component
[20:02:55] <jepler> yes
[20:03:17] <cradek> I didn't get that for a while, and was totally befuddled. I thought it was describing the behavior.
[20:04:20] <cradek> I think this design does work
[20:05:33] <cradek> the whole point of request-reset is that ok-out stays off long enough for the machine to estop, even if it starts getting adequate input edges again?
[20:06:06] -!- V0idExp has quit [Ping timeout: 272 seconds]
[20:06:18] <jepler> roughly yes, and also because I wanted something to put where you had WDENAB
[20:06:41] <cradek> I guess I wonder what happens if you get rid of the enable and request-reset. all estop chains are locking and a momentary failure opens them
[20:06:44] <jepler> if classicladder runs at 100ms and watchdog2 runs at 1ms, you do need something to ensure that
[20:07:12] <cradek> oh maybe so
[20:07:28] <cradek> I'm still picturing a hardware estop chain
[20:07:55] <cradek> ok-out would have to be low long enough for the relay to pop open
[20:08:18] <jepler> without request-reset it could be low as little as 1 period
[20:08:44] <cradek> yes if your timeouts are really short
[20:09:10] <jepler> if your timeout is 1s and the edge comes at 1s+1ms then you could have just 1ms of out-ok being false
[20:09:16] -!- adb [adb!~IonMoldom@178.211.237.94] has joined #linuxcnc-devel
[20:09:29] <cradek> the time for ->ok could be many times as long as ->/ok
[20:09:48] <cradek> (a real charge pump probably has that property)
[20:10:54] <jepler> hm
[20:11:13] <jepler> my proposed component sure doesn't.
[20:11:16] <cradek> so you've removed any latching inside watchdog, making it the user's responsibility
[20:11:56] <cradek> ... I think that's probably sane, and we were having problems with the design in the first place because we had latching in too many places
[20:12:06] <jepler> bbl
[20:12:28] <mhaberler> I think that's the better design even if its lower level and more logic needed, but no guesswork on usage assumptions
[20:12:42] <cradek> which is the better design?
[20:12:48] <mhaberler> jeffs
[20:13:02] <cradek> I'm pretty sure I agree
[20:13:05] <mhaberler> no state inside wrt enable
[20:13:23] <cradek> but it makes me sad to have watchdog (broken) and also watchdog2 (with different api)
[20:13:34] <cradek> I wish we could just "fix" the one we have
[20:13:39] <mhaberler> I guess we dont know yet how its being used, so better not assume too much
[20:14:29] <mhaberler> we need usage spyware… coded dns lookups..
[20:14:50] <cradek> great idea, let's get on it
[20:15:08] <mhaberler> you go first then ;)
[20:15:16] <andypugh> How very annoying: error: Your local changes to 'configs/sim/gscreen/sim_mm.tbl' would be overwritten by merge. Aborting.
[20:15:24] <cradek> we also need a walled garden for hal components
[20:15:34] <mhaberler> git stash ; merge,; git stash pop
[20:15:45] <cradek> to ensure uniform quality
[20:16:12] <mhaberler> you mean no reporting leaks out?
[20:26:33] -!- i_tarzan has quit [Read error: Connection reset by peer]
[20:28:25] <KGB-linuxcnc> 03andy 05master 44a04df 06linuxcnc 03src/hal/components/lincurve.comp * Add a linearisation curve / 1D lookup table component.
[20:29:22] -!- jfire has quit [Read error: Connection reset by peer]
[20:30:27] <mhaberler> andypugh: why didnt you do a polynomial fit?
[20:30:42] <mhaberler> no discontinuities
[20:31:06] -!- L84Supper has quit [Remote host closed the connection]
[20:31:19] <andypugh> it seems computationally wasteful.
[20:32:03] <andypugh> And a linear interpolation allows you to have sharp steps, given very closely-spaces breakpoints
[20:32:30] <andypugh> There are curves a polynomial won't fit.
[20:32:53] -!- L84Supper [L84Supper!~Larch@unaffiliated/l84supper] has joined #linuxcnc-devel
[20:33:30] <andypugh> This kind of discrete curve (and the 2D version) are used by the thousand in the car ECUs
[20:33:33] -!- skunkworks [skunkworks!~chatzilla@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[20:33:46] <mhaberler> I'm sold
[20:34:03] <mhaberler> and out, since it's time - cu!
[20:34:13] -!- mhaberler has quit [Quit: mhaberler]
[20:37:06] <cradek> if (personality < 1) personality = 2;
[20:37:08] -!- vladimirek has quit [Remote host closed the connection]
[20:37:15] <cradek> andypugh: is that what you meant?
[20:37:54] <andypugh> Perhaps not.
[20:38:25] <andypugh> Though arguably the 1-element case is useful for creating an IO pin.
[20:38:49] <cradek> I'm not saying it's wrong; I have no idea how comp works. but it looked weird.
[20:38:57] <andypugh> But I decided to insist on 2, then forgot to change the condition.
[20:39:10] <jepler> yeah I would expect both numbers to be the same number
[20:39:14] <andypugh> No, it's mildly wrong.
[20:39:26] <jepler> personality = max(2, personality)
[20:40:22] -!- hardwire has quit [Read error: Operation timed out]
[20:41:14] <jepler> except not sure whether we have max()
[20:41:29] <andypugh> No, that was about to be my question
[20:42:33] -!- jef79m has quit [Quit: ZNC - http://znc.in]
[20:45:47] <KGB-linuxcnc> 03andy 05master c8ad668 06linuxcnc 10src/hal/components/lincurve.comp * Make limit on mumber of elements consistent.
[20:46:07] -!- sumpfralle has quit [Ping timeout: 264 seconds]
[20:46:16] -!- gabewillen has quit [Ping timeout: 256 seconds]
[20:49:44] -!- stsydow has quit [Remote host closed the connection]
[20:53:04] -!- automata has quit [Read error: Connection reset by peer]
[20:53:46] -!- automata [automata!~automata@1.38.100.230] has joined #linuxcnc-devel
[20:57:38] <jepler> totally untested source for "watchdog2":
http://emergent.unpythonic.net/files/sandbox/watchdog2.comp
[20:59:02] <jepler> I think cradek's comments about asymmetry are good but it doesn't fit with what I've written so far
[20:59:45] <jepler> you'd want what .. a way to specify that at least N rising edges are seen before an input is deemed good again? and then you set N appropriately and dispense with request-reset...
[21:03:43] -!- micges has quit [Quit: Leaving]
[21:04:35] micges_ is now known as micges
[21:08:21] -!- DJ9DJ has quit [Quit: bye]
[21:11:35] -!- sumpfralle has quit [Ping timeout: 255 seconds]
[21:11:38] <andypugh> Would this suit a vehicle-style fault count and heal system? You increment a fault counter until a threshhold, and decrement the count when there is no fault. By setting threshold and inc and dec values you can achieve a wide range of behaviours.
[21:21:53] -!- FinboySlick has quit [Quit: Leaving.]
[21:24:30] -!- micges has quit [Quit: Ex-Chat]
[21:33:12] -!- chillly has quit [Quit: Leaving]
[21:38:27] -!- gabewillen [gabewillen!~Thunderbi@d26-76.rb.gh.centurytel.net] has joined #linuxcnc-devel
[21:39:32] -!- PCW [PCW!~chatzilla@99.88.10.65] has joined #linuxcnc-devel
[21:40:51] -!- JesusAlos has quit [Quit: ChatZilla 0.9.90 [Firefox 20.0.1/20130409194949]]
[21:44:50] <jepler> for this one I have to rely on others to say what it is that is needed. sounds like you're suggesting an entirely different scheme with different merits ..
[21:45:08] * jepler wanders off again
[22:07:00] -!- odogono has quit [Quit: odogono]
[22:09:52] -!- Wildhoney has quit [Ping timeout: 256 seconds]
[22:12:13] -!- kmrhb has quit [Ping timeout: 252 seconds]
[22:19:20] -!- largecheesepuff has quit [Ping timeout: 246 seconds]
[22:19:59] -!- sumpfralle1 has quit [Ping timeout: 255 seconds]
[22:22:40] -!- andypugh has quit [Quit: andypugh]
[22:33:19] -!- tmcw has quit [Remote host closed the connection]
[22:34:35] -!- automata has quit [Ping timeout: 252 seconds]
[22:40:28] -!- Valen has quit [Quit: Leaving.]
[22:44:20] -!- bedah has quit [Quit: Ex-Chat]
[22:52:29] -!- stsy has quit [Client Quit]
[22:54:18] -!- servos4ever has quit [Quit: ChatZilla 0.9.85 [SeaMonkey 2.0.11/20101206162726]]
[23:09:26] -!- largecheesepuff has quit [Ping timeout: 248 seconds]
[23:12:18] -!- rob_h has quit [Ping timeout: 272 seconds]
[23:25:43] -!- kmrhb has quit [Ping timeout: 260 seconds]
[23:38:03] -!- syyl_ has quit [Quit: Leaving]
[23:38:51] -!- zzolo has quit [Quit: zzolo]
[23:51:48] -!- kmrhb has quit [Ping timeout: 264 seconds]
[23:55:15] -!- Guest46583 has quit [Quit: Leaving]
