#emc | Logs for 2005-11-14

Back
[00:00:06] <jmkasunich> yeah, like so:
[00:00:13] <jmkasunich> bin/halcmd -f
[00:00:17] <jmkasunich> reads from stdin
[00:00:23] <jmkasunich> bin/halcmd -f filename
[00:00:27] <lerman> Well, then the line numbers printed by halcmd wouldn't related to the original source (assuming you piped it thru m4 or some other processor).
[00:00:27] <jmkasunich> reads from filename
[00:00:28] <SWPadnos> no - explicitly halcmd < foo.hal, not halcmd -f foo.hal
[00:00:49] <jmkasunich> -f with no name uses stdin
[00:00:53] <jmkasunich> so you can do:
[00:01:03] <jmkasunich> cat foo.hal | halcmd -f
[00:01:07] <jmkasunich> etc
[00:01:27] <jmkasunich> without the -f, it assumes a single command on the command line
[00:01:42] <jmkasunich> with -f, it assumes one or more commands at stdin or a file
[00:01:47] <SWPadnos> OK, so you could theroetically spawn a halcmd process, piped from a controller program that uses haldmc to do HAL stuff
[00:02:01] <SWPadnos> halcmd, of course (oops)
[00:02:07] <jmkasunich> yeah
[00:02:32] <alex_joni> wow.. this is cool : http://web.media.mit.edu/~kimiko/iobrush/
[00:02:34] <SWPadnos> OK, in that case I'd forego the extra macro-type functionality, and just make sure it's a complete interface to HAL setup, discovery, and control
[00:02:35] <jmkasunich> in fact, I've sometimes done halcmd -kf for a interactive hal
[00:03:03] <jmkasunich> was thinking about adding a switch so it would actually print a prompt in that mode
[00:03:32] <SWPadnos> what is -k ?
[00:03:46] <jmkasunich> (-k just means keep going after errors, without it halcmd terminates if any command fails)
[00:03:50] <SWPadnos> ok
[00:04:05] <alex_joni> SWPadnos: keep going
[00:04:09] <SWPadnos> o-k
[00:04:22] <SWPadnos> keep going where?
[00:04:24] <anonimasu> hm
[00:04:35] <anonimasu> the mill I have will do 6400rpm with the milling head I have..
[00:04:37] <anonimasu> nice
[00:04:37] <anonimasu> :D
[00:05:02] <jmkasunich> the problem with the -kf version as an interactive hal is that you don't have history
[00:05:20] <SWPadnos> so the only other thing (6, I guess) is the "owned by" filter on list and show commands
[00:05:26] <SWPadnos> does tee help there?
[00:05:37] <jmkasunich> it's actually easier to invoke bin/halcmd <somecmd> many times than it is to invoke bin/halcmd -kf once and then enter many commands
[00:05:39] <lerman> Do you need history, or do you need state? Can hal output its state?
[00:05:40] <SWPadnos> (from a script I guess it would, but not "manually")
[00:05:57] <SWPadnos> not necessarily for a program, but it might be
[00:06:01] <jmkasunich> the history saves typing
[00:06:07] <jmkasunich> for instance, suppose I'm tuning
[00:06:15] <jmkasunich> I do bin/halcmd setp pid.0.Pgain 100
[00:06:19] <SWPadnos> Linux is pretty lightweight for process creation
[00:06:19] <jmkasunich> then I want to try 150
[00:06:34] <jmkasunich> with bash history, I do up-arrow, and change the 100 to 150, hit enter
[00:06:46] <SWPadnos> ise readline instead of fgets
[00:06:48] <SWPadnos> use
[00:06:48] <jmkasunich> with the -kf version I need to retype "setp pid.0.Pgain"
[00:07:01] <alex_joni> jmkasunich: but adding that functionality would be great
[00:07:08] <alex_joni> * alex_joni also thinks of autocompletion :D
[00:07:15] <alex_joni> that saves a lot of time/nerves
[00:07:39] <SWPadnos> yep - I think readline gives you that as well (not sure though)
[00:07:51] <lerman> Look at a picture in the gui, click on the pid, pgain pin. Type the number.
[00:08:07] <SWPadnos> O - where's the gui again? ;)
[00:08:13] <jmkasunich> lerman, yes, that is the ultimate goal
[00:08:15] <lerman> Oh, did I leave out the :-)
[00:08:17] <SWPadnos> (where's ValarQ when you need him)
[00:08:29] <alex_joni> that's the ultimate GUI, not goal ;)
[00:08:30] <jmkasunich> but the script/text version is important too
[00:08:31] <SWPadnos> I want crapplication, dammit
[00:08:38] <rayh> do we know where he is with his work?
[00:08:44] <SWPadnos> the script / text version lets you make the gui version
[00:09:04] <SWPadnos> I asked him last week, and he said that he'd been asked to commit. I haven't seen the message
[00:09:18] <SWPadnos> I think he said that he hadn't had time to do much on it
[00:09:21] <rayh> k
[00:09:28] <lerman> BTW: how do I subscribe to the commit list?
[00:09:40] <jmkasunich> man readline looks very interesting
[00:09:50] <rayh> The tcl interface I was working on was mostly for display at this time.
[00:10:00] <lerman> Yes. readline is the right idea.
[00:10:03] <SWPadnos> cool - it does support completion
[00:10:04] <rayh> Though it could be made to allow some interaction.
[00:10:06] <jmkasunich> lerman: stand by 1, I'll find the URL
[00:10:38] <alex_joni> lerman: go to sourceforge.net/projects/emc
[00:10:47] <alex_joni> then lists, and emc-commit
[00:10:47] <SWPadnos> http://lists.sourceforge.net/mailman/listinfo/emc-commit
[00:11:25] <jmkasunich> subscribe with your sf address, so your commits don't bounce
[00:11:33] <rayh> when we get the time, I'd like to talk more about connectors between emc and hal?
[00:11:45] <jmkasunich> if you want to get the messages at another addy, subscribe with that one too, and turn off delivery on the sf one
[00:11:47] <alex_joni> like fenn's did.. (jmk: did you let it through?)
[00:11:58] <jmkasunich> nope
[00:12:06] <jmkasunich> checking that now
[00:12:06] <alex_joni> ok. so still bouncing..
[00:12:21] <alex_joni> oh.. btw, very nice message from CIA today..
[00:12:43] <anonimasu> rm -fR
[00:12:43] <anonimasu> :D
[00:12:50] <alex_joni> [19:04] <CIA-5> * emc/: rm -fR emc*
[00:12:51] <alex_joni> [19:06] <alex_joni> CIA-5: what's that?
[00:12:51] <alex_joni> [19:06] <SWP_Away> yeah - that's an odd message
[00:13:40] <alex_joni> * alex_joni tries an checkout on emc1
[00:13:55] <SWPadnos> hmmm - readline only supports filename completion, not completion from a provided list of possibilities
[00:14:01] <SWPadnos> (from what I've read so far)
[00:14:32] <jmkasunich> seems like we have four modes for halcmd
[00:14:41] <jmkasunich> bin/halcmd <one command>
[00:14:43] <SWPadnos> nevermind - there's a menu-complete mode
[00:14:51] <jmkasunich> bin/halcmd -f <some-file>
[00:15:04] <jmkasunich> bin/halcmd -f (read from stdin, no promts or anything)
[00:15:35] <jmkasunich> bin/halcmd -pf (reads from stdin with readline,prints a "hal>" prompt or something like that
[00:16:05] <SWPadnos> it may be good to have a separate mode like number two, that always prints something (handshake mode)
[00:16:32] <jmkasunich> there are also options -Q -q -v -V
[00:16:41] <jmkasunich> differing amounts of quietness or verbosity
[00:16:51] <SWPadnos> make QqvV the handshake mode :)
[00:16:58] <jmkasunich> -V acknowledges every command (and I think -v does too)
[00:17:03] <jmkasunich> -q only prints errors
[00:17:07] <jmkasunich> -Q prints nothing
[00:19:10] <jmkasunich> just approved fenns commit msg
[00:20:00] <jmkasunich> looks like he subscribed, so he should be ok in the future
[00:20:14] <alex_joni> yup.. probably subscribed too late..
[00:21:32] <SWPadnos> it looks like -v or -V are a bit too verbose
[00:21:44] <alex_joni> -vvva
[00:21:58] <SWPadnos> lspci -vvvxxx
[00:22:06] <jmkasunich> not too verbose if you are tracing bugs
[00:22:10] <jmkasunich> the default is -q
[00:22:43] <SWPadnos> true - the reason I mentioned a handshake mode was for interactive-to-other-program use
[00:23:10] <SWPadnos> so the other program will always get a response, and knows to continue
[00:23:28] <SWPadnos> also, at the end of something like a list, there needs to be an END marker of some sort
[00:23:48] <SWPadnos> (unless it's expected that people will just pipe to a file or something, then parse from there)
[00:24:19] <jmkasunich> good point
[00:24:43] <jmkasunich> hmm, maybe the "interactive" version (with a prompt) is appropriate for program use
[00:24:51] <jmkasunich> the prompt would be the handshale
[00:24:57] <SWPadnos> maybe - then the EOT is just the prompt
[00:25:01] <SWPadnos> right ;)
[00:26:39] <SWPadnos> for multiline comments, just use cpp ;)
[00:26:51] <SWPadnos> (as long as you don't care about line numbers)
[00:30:13] <SWPadnos> so - do we want to make <[parent:]name> selection work?
[00:30:35] <jmkasunich> probably
[00:30:43] <jmkasunich> only question is syntak
[00:30:46] <jmkasunich> only question is syntax
[00:30:59] <SWPadnos> right - any concerns there?
[00:31:03] <SWPadnos> here's what I envision:
[00:31:04] <jmkasunich> somebody mentioned the other day the possibility of selecting on things other than owner
[00:31:10] <SWPadnos> yes
[00:31:11] <jmkasunich> like type, for example
[00:31:25] <SWPadnos> type is already there (unless you mean HAL_TYPE)
[00:31:49] <jmkasunich> I mean, "show me all bit signals that start with foo"
[00:31:59] <jmkasunich> or all float signals, etc
[00:32:04] <SWPadnos> yep - very useful
[00:32:19] <jmkasunich> today I do that with bin/halcmd show sig foo | grep bit
[00:32:49] <SWPadnos> incidentally - it looks like halcmd requires lower case commands - is that true?
[00:32:54] <jmkasunich> not bulletproof, if a float signal contains bit anywhere
[00:33:13] <jmkasunich> might, I'd have to check the code
[00:33:24] <SWPadnos> right - you can't do everything with text after the fact
[00:33:25] <jmkasunich> names are case sensitive, I suspect commands are too
[00:33:37] <SWPadnos> OK - I didn't notice any tolower()'s in there
[00:34:00] <SWPadnos> and the token comparisons are strcmp, some others are strcasecmp
[00:34:09] <jmkasunich> hmmm
[00:34:19] <jmkasunich> it's been a while since I dived into that code
[00:34:23] <SWPadnos> quit and exit are case insensitive
[00:34:35] <SWPadnos> as are teh type names
[00:34:37] <SWPadnos> the
[00:34:57] <SWPadnos> TRUE, FALSE
[00:34:57] <jmkasunich> ahh, that is because if some poor person gets into that interactive mode, I wanted them to be able to get out even if they didn't know what they were doing
[00:35:04] <SWPadnos> heh
[00:35:18] <SWPadnos> good plan (is CTRL-C captured?)
[00:35:20] <jmkasunich> the whole thing needs going over
[00:35:29] <jmkasunich> yeah (I think so)
[00:35:43] <jmkasunich> SIGTERM and one other
[00:35:46] <jmkasunich> * jmkasunich opens an editor
[00:35:51] <SWPadnos> SIGINT
[00:36:22] <jmkasunich> gotta be carefull killing a HAL thing, if it has the mutex when you kill it it can get messy
[00:36:54] <SWPadnos> yep
[00:37:38] <jmkasunich> gonna be leaving in about 30 mins
[00:37:40] <SWPadnos> were you trying to keep library dependencies to a minimum?
[00:37:48] <A-L-P-H-A> swampy. sup?
[00:37:51] <jmkasunich> yeah
[00:38:02] <jmkasunich> * jmkasunich doesn't like dependencies
[00:38:05] <SWPadnos> ok - I had wondered about no strtok use
[00:38:18] <jmkasunich> strtok is pretty standard
[00:38:34] <SWPadnos> hi A-L-P-H-A
[00:38:36] <jmkasunich> dependencies isn't why I didn't use it
[00:38:43] <SWPadnos> ok
[00:38:44] <A-L-P-H-A> shoot, I came online for a reason.
[00:38:49] <A-L-P-H-A> i can't remember why now.
[00:39:02] <jmkasunich> I can't recall why I didn't use strtok either
[00:39:12] <SWPadnos> ah - quotes and single quotes
[00:39:48] <dmess> hi alpha.. ;)
[00:39:53] <jmkasunich> yep, quoted strings that might include strtok delimiters
[00:40:16] <SWPadnos> though that may be OK, since you can change the delimiter list
[00:41:21] <SWPadnos> the manpage for strtok is funny
[00:41:25] <SWPadnos> under bugs:
[00:41:38] <SWPadnos> Never use these functions. If you do, note that: (...)
[00:41:40] <jmkasunich> never use these functions
[00:41:50] <jmkasunich> I think that might have been another reason I didn't ;-)
[00:42:04] <SWPadnos> heh - no, really, it's safe
[00:43:47] <SWPadnos> OK - for the ':' syntax, how about making it attribute:name pairs?
[00:44:28] <SWPadnos> like list pin owner:motmod type:bit foo
[00:44:32] <jmkasunich> IOW, "show pin type:bit owner:blocks name:foobar"
[00:44:45] <SWPadnos> wth name implied if there's no colon
[00:44:51] <jmkasunich> yeah
[00:45:48] <SWPadnos> most of the checking could be done in parse_cmd, so the individual functions would just inherit a block of pre-parsed constraints
[00:46:18] <SWPadnos> if constraints->owner!=NULL (this must match the owner)
[00:46:22] <SWPadnos> etc.
[00:46:45] <jmkasunich> yeah
[00:46:58] <jmkasunich> I like the term filter instead of constraint, but thats a nitpick
[00:47:06] <SWPadnos> OK - filter it is
[00:47:15] <SWPadnos> if filter->owner!=NULL (this must match the owner)
[00:47:17] <SWPadnos> done!
[00:48:10] <SWPadnos> there may need to be a second struct defined, so that the different listable types (pin, comp, etc) can have flags showing which filters are valid for that type
[00:48:24] <SWPadnos> (ie, a component has no HAL_TYPE)
[00:48:52] <A-L-P-H-A> hi dmess.
[00:48:55] <A-L-P-H-A> Now I REMEMBER!
[00:49:07] <SWPadnos> no more tach questions! :)
[00:49:38] <A-L-P-H-A> 2+2-1=3
[00:49:39] <A-L-P-H-A> :)
[00:49:52] <SWPadnos> excellent - here's your diploma
[00:50:59] <alex_joni> A-L-P-H-A: you sure?
[00:51:12] <alex_joni> * alex_joni knows that 2+2=5 for very large 2's
[00:51:34] <SWPadnos> yes, and 1=2, for very small values of 2
[00:51:52] <SWPadnos> jmk - do you expect to be around tomorrow?
[00:51:53] <jmkasunich> so the filters would apply to all "list" and "show" commands
[00:52:01] <jmkasunich> yeah, at least part of the day
[00:52:05] <SWPadnos> ok
[00:52:10] <jmkasunich> this evening my wife has other plans ;-)
[00:52:16] <SWPadnos> yes, I'm not sure they make sense for anything other than discovery
[00:52:24] <SWPadnos> good for you!
[00:52:38] <alex_joni> yeah.. ditto
[00:53:20] <SWPadnos> unless it involves a Vacuum cleaner or lawnmower
[00:55:04] <SWPadnos> hmmm - this seems wrong:
[00:55:24] <SWPadnos> localhost:/Project/emc2# bin/halcmd help show
[00:55:26] <SWPadnos> RTAPI: ERROR: could not open shared memory
[00:55:27] <SWPadnos> HAL: ERROR: rtapi init failed
[00:55:29] <SWPadnos> halcmd: hal_init() failed
[00:55:31] <SWPadnos> NOTE: 'rtapi' kernel module must be loaded
[00:55:42] <SWPadnos> help shouldn't need RTAI
[00:55:46] <jmkasunich> realtime isn't loaded
[00:55:50] <SWPadnos> help shouldn't need RTAI
[00:55:56] <SWPadnos> :)
[00:55:59] <jmkasunich> yeah
[00:56:02] <alex_joni> SWPadnos: change it
[00:56:04] <jmkasunich> that should be fixed
[00:56:11] <alex_joni> SWPadnos: fix it
[00:56:12] <SWPadnos> ok
[00:56:15] <SWPadnos> ok
[00:56:16] <SWPadnos> ok
[00:56:20] <alex_joni> :P
[00:56:21] <SWPadnos> ok, already :)
[00:57:18] <SWPadnos> I guess help should be case insensitive as well :)
[00:57:29] <jmkasunich> I think that is because I don't parse commands until I've connected to the HAL
[00:57:50] <SWPadnos> hmmm - this may be more than a 1.6 minute fix :)
[00:58:20] <jmkasunich> you don't want to parse one line, connect to hal, execute, disconnect, parse next line, connect, etc, etc
[00:58:21] <SWPadnos> maybe help should be available under -h as well (halcmd -h cmd)
[00:58:47] <jmkasunich> yeah
[00:59:41] <SWPadnos> that I can do
[01:00:41] <jmkasunich> -h should ignore all other flags and commands, print the help, and exit
[01:01:05] <jmkasunich> help in a file (or from stdin) should print the help and continue to the next line
[01:01:14] <SWPadnos> it seems to now (it returns from main)
[01:01:33] <jmkasunich> hmm, never tried help in a multi-line file
[01:01:55] <SWPadnos> as long as do_help_cmd prints a message, I can just pass the next token to it
[01:02:09] <jmkasunich> face it, halcmd needs a deep cleaning
[01:02:14] <SWPadnos> ah - I misunderstood you before
[01:02:21] <SWPadnos> I agree ;)
[01:02:34] <jmkasunich> it wasn't designed, it evolved
[01:02:41] <SWPadnos> it works, so messing with it isn't a high priroity
[01:02:48] <jmkasunich> some beneficial mutations, some not so beneficial
[01:02:50] <SWPadnos> but as we add more to it, it'll be more and more necesary
[01:02:52] <alex_joni> jmkasunich: didn't see you on frappr..
[01:03:00] <jmkasunich> frappr?
[01:03:13] <SWPadnos> look @ channel descrption
[01:03:20] <alex_joni> http://www.frappr.com/emctheenhancedmachinecontroller
[01:04:01] <jmkasunich> I tried that once (might have been at work on a doze box with IE) and it didn't work
[01:04:23] <alex_joni> works ok on what I tried so far..
[01:04:32] <alex_joni> opera, firefox, ie..
[01:04:36] <jmkasunich> maybe PBKAC
[01:04:44] <Jacky^> linx
[01:04:45] <SWPadnos> uh - that could be a problem???
[01:04:55] <alex_joni> SWPadnos: what?
[01:04:57] <Jacky^> lynx*
[01:05:00] <SWPadnos> |<--ChanServ has left freenode (Shutting Down)
[01:05:07] <Jacky^> hehe
[01:05:09] <Jacky^> :)
[01:05:14] <jmkasunich> I just went to that page with konqueror, no map
[01:05:23] <Jacky^> chanserv goes to sleep ? :/
[01:05:27] <SWPadnos> needs java
[01:05:30] <SWPadnos> I think
[01:05:31] <fenn> konqueror doesn't support evil nasty java
[01:05:38] <SWPadnos> try Firefox
[01:05:40] <jmkasunich> nice Konqueror
[01:05:45] <jmkasunich> not tonight
[01:05:58] <jmkasunich> wife is waiting, we're going out for dinner and music
[01:06:00] <Jacky^> firefox its better :P
[01:06:10] <SWPadnos> have fun. see you part of tomorrow
[01:06:21] <jmkasunich> firefox takes a frickin week to load compared to Konqueror
[01:06:27] <Jacky^> bye SWPadnos
[01:06:30] <jmkasunich> (so does mozilla, etc)
[01:06:34] <SWPadnos> yeah, but once loaded, it's *FAST*
[01:06:37] <alex_joni> night guys..
[01:06:41] <alex_joni> * alex_joni goes to bed too
[01:06:44] <Jacky^> night alex_joni
[01:06:44] <jmkasunich> bye
[01:06:51] <jmkasunich> jmkasunich is now known as jmk_away
[01:06:52] <SWPadnos> hey - why is everyone lweaving? :)
[01:06:58] <SWPadnos> leaving, even
[01:07:02] <fenn> party's over dude
[01:07:08] <jmk_away> it's gawd-awful o'clock where alex is
[01:07:12] <SWPadnos> maybe I should have used deodorant
[01:07:45] <alex_joni> SWPadnos: you should
[01:07:56] <SWPadnos> can you smell me from there? :)
[01:08:10] <SWPadnos> (maybe it's the marinated garlic I just ate)
[01:08:12] <alex_joni> what time you got there?
[01:08:21] <alex_joni> * alex_joni loves marinated garlic..
[01:08:28] <alex_joni> so don't think it's that :D
[01:08:38] <SWPadnos> there's a type from the local supermarket, where they marinate with hot peppers - mmmmm
[01:09:24] <alex_joni> ok.. 2:30 am here
[01:09:26] <alex_joni> going to BED
[01:09:27] <SWPadnos> night
[01:09:30] <alex_joni> night all
[01:15:39] <Jacky^> website can save a life: http://www.worstpills.org/
[01:15:50] <Jacky^> probably, already know ..
[01:16:52] <rayh> * rayh moves phone to another box.
[01:17:24] <SWPadnos> phone, phone, phone - oh yeah, people used to use those for internet access :)
[01:17:35] <Jacky^> use skype !
[01:17:38] <fenn> what's a phone?
[01:17:39] <Jacky^> freee :P
[01:18:02] <Jacky^> oh. not for internet access :)
[01:18:10] <Jacky^> free from pc to pc
[01:18:36] <Jacky^> and very low cost from all the world calls
[01:18:36] <fenn> wonder why it costs less to go from internet to phone than to get dialup
[01:18:55] <fenn> could you hook up a modem and call it via skype for cheap dialup?
[01:19:11] <Jacky^> no ..
[01:19:25] <Jacky^> who use dialup yet ?
[01:19:45] <Jacky^> just rayh ?
[01:19:48] <Jacky^> :)
[01:20:06] <Jacky^> well, if theres no dsl
[01:20:08] <SWPadnos> yes, just ray
[01:20:12] <SWPadnos> :)
[01:20:41] <SWPadnos> actually, the US has just about the lowest usage of broadband in the developed (as even some of the undeveloped) world
[01:21:22] <fenn> doing things the wrong way is good for the economy
[01:21:58] <SWPadnos> thank you mr George "nukular" Bush. :)
[01:22:03] <alex_joni> * alex_joni is back
[01:22:06] <SWPadnos> get back to bed!
[01:22:12] <alex_joni> seems there's a problem..
[01:22:13] <SWPadnos> or is this the other machine>
[01:22:14] <SWPadnos> ?
[01:22:20] <alex_joni> nope.. same one
[01:22:21] <SWPadnos> too much caffeiene
[01:22:27] <alex_joni> seen a mail to emc-devel
[01:22:39] <alex_joni> I'm afraid I might have borked something.. came back to test
[01:23:04] <alex_joni> the make install stuff I've been messing with..
[01:23:25] <SWPadnos> ah. I noticed that mail, and assumed that it might be a path thing (relative param file or something)
[01:24:01] <alex_joni> damn.. can't reproduce it..
[01:24:36] <alex_joni> ok.. now I could..
[01:25:34] <alex_joni> weird stuff... :(
[01:27:07] <alex_joni> what the hell is a relocation error?
[01:27:58] <SWPadnos> hmmm - asking for a specific memory address, and not being able to be relocated there?
[01:28:13] <alex_joni> think it's lib related
[01:28:38] <SWPadnos> when does it occur?
[01:28:52] <alex_joni> when inivar gets run
[01:28:59] <alex_joni> after I moved the whole emc2 dir
[01:29:14] <SWPadnos> mmm - can't be of much help there, atm
[01:33:46] <CIA-5> 03swpadnos * 10emc2/ (docs/man/man1/halcmd.1 src/hal/utils/halcmd.c): added command specific help to -h command line option
[01:34:23] <SWPadnos> ok - where's the inivar stuff?
[01:34:51] <alex_joni> src/libnml/
[01:35:00] <SWPadnos> eek - nml again :)
[01:35:31] <alex_joni> src/libnml/inifile
[01:36:53] <SWPadnos> I suppose I should make install for thi, huh?
[01:36:56] <SWPadnos> this
[01:37:11] <alex_joni> no.. I get it without make install
[01:37:32] <SWPadnos> hm. I can run emc2, it seems (I haven't fiddled with the ini file though)
[01:37:54] <alex_joni> SWPadnos: try renaming the emc2 dir
[01:38:02] <alex_joni> then run ./configure again
[01:38:03] <SWPadnos> ok
[01:38:04] <alex_joni> also make
[01:38:25] <SWPadnos> rename the dir, or make sure it's somewhere other than ~/emc2
[01:38:33] <alex_joni> yes
[01:38:53] <SWPadnos> it's already somewhere else (/Project/emc2
[01:38:54] <SWPadnos> )
[01:40:07] <SWPadnos> ok - emctwo doesn't work as a dirname (smae dir, renamed)
[01:40:15] <SWPadnos> same, not smae
[01:40:16] <Jacky^> gnignt
[01:40:21] <SWPadnos> hignt Jacky^
[01:40:25] <SWPadnos> night, I mean
[01:40:25] <Jacky^> Jacky^ is now known as Jacky^afk
[01:40:30] <Jacky^afk> :) bye
[01:41:23] <SWPadnos> localhost:/Project/emctwo# scripts/emc.run
[01:41:24] <SWPadnos> Can't find variable PARAMETER_FILE in section [RS274NGC] of file /Project/emctwo/configs/emc.ini.
[01:43:09] <alex_joni> SWPadnos: go to emctwo/src/libnml
[01:43:16] <alex_joni> make clean && make -s
[01:43:18] <SWPadnos> yep
[01:43:40] <alex_joni> does it work then?
[01:44:29] <SWPadnos> hold on - this is the celeron 500 we're talking about :)
[01:45:01] <SWPadnos> what is the -s option?
[01:45:06] <alex_joni> silent
[01:45:07] <alex_joni> :)
[01:45:30] <alex_joni> only prints warnings, errors, and messages
[01:45:32] <SWPadnos> it's anything but - I got a few dozen screens of suff (though not the Leaving DIR ***)
[01:45:54] <SWPadnos> yep - that fixed it
[01:46:07] <alex_joni> strange..
[01:46:12] <SWPadnos> though it couldn't run the RT stuff, so emc didn't run
[01:46:12] <alex_joni> * alex_joni has no idea why.. yet
[01:46:19] <alex_joni> couldn't run?
[01:46:22] <alex_joni> how so?
[01:46:57] <SWPadnos> not sure why, dmesg is inconclusive for me (no errors)
[01:47:16] <SWPadnos> couldn't load hal_lib
[01:47:44] <SWPadnos> hmmm - can't find the RT stuff
[01:48:01] <SWPadnos> maybe I should make clean && make the whole thing?
[01:48:08] <alex_joni> probably best
[01:48:22] <SWPadnos> (this worked before the dir move and configure / compile)
[01:48:32] <alex_joni> I know .(
[01:48:35] <SWPadnos> heh
[01:48:57] <SWPadnos> this will take a few minutes
[01:49:23] <SWPadnos> back in a minute - I'm going to make some tea
[01:49:28] <alex_joni> ok
[01:50:19] <SWPadnos> is it normal to get hundreds of warnings about RTAPI functions not found?
[01:50:38] <SWPadnos> sorry - module stuff - I think it's OK
[01:50:51] <alex_joni> yes
[01:55:28] <SWPadnos> ok - I'm back, still compiling
[01:56:46] <SWPadnos> see why I want to install on a non-RT or a VMWare system? :)
[01:56:56] <SWPadnos> woohoo - done
[01:57:22] <anonimasu> hm, I guess a vmware system would work just fine
[01:57:28] <SWPadnos> OK - it works after a full make clean, make
[01:57:42] <alex_joni> same here
[01:57:49] <SWPadnos> unfortunately not for a BDI - there's a problem with installation on SCSI systems, which is what VMWare emulated for the HD
[01:58:03] <alex_joni> seems the only logical explication is that he renamed the folder
[01:58:10] <alex_joni> and inivar didn't recompile properly
[01:58:11] <SWPadnos> after the make
[01:58:54] <SWPadnos> well, inivar shouldn't depend on the location
[01:59:22] <SWPadnos> but even if it does, configure should have modified any headers that it used, so make should have recompiled it
[01:59:27] <SWPadnos> (but you knew that)
[02:00:23] <alex_joni> not sure it uses any headers that get rebuilt...
[02:00:30] <SWPadnos> by the way, I did *not* rerun configure after make clean
[02:00:59] <SWPadnos> so - configure then make doesn't work, make clean then make does work
[02:01:39] <SWPadnos> though I didn't rename anything between configure and the second make
[02:06:47] <alex_joni> what's the difference between .a and .so ?
[02:07:11] <SWPadnos> good question
[02:07:26] <SWPadnos> .so is sharable, whereas .a may not be (I'm unsure about that though)
[02:11:42] <SWPadnos> well - at least I get the same problem from the command line, and regardless of which ini var I ask for
[02:12:00] <SWPadnos> cd bin
[02:12:02] <SWPadnos> oops
[02:16:57] <SWPadnos> well - isn't that interesting
[02:17:04] <alex_joni> what?
[02:17:11] <SWPadnos> run ldd -r bin/inivar (from emc2 or whatever it's called now)
[02:17:34] <SWPadnos> then rename the dir, and there are 4 undefined symbols
[02:17:39] <SWPadnos> no recompile or anything
[02:17:53] <SWPadnos> rename the emc2 dir, that is
[02:17:57] <alex_joni> yes.. because at compile time it gets rpath..
[02:18:02] <alex_joni> where it should find the lib
[02:18:12] <SWPadnos> that's bad
[02:18:18] <SWPadnos> (icky :) )
[02:18:54] <alex_joni> $(CXX) $(TMP_DIR)/inivar.o -L$(LIB_DIR) -lnml -Wl,-rpath,$(LIB_DIR) -o $@
[02:19:11] <SWPadnos> ah
[02:24:33] <SWPadnos> what's the reason for inivar and halcmd being the only uses of rpath?
[02:24:44] <alex_joni> no idea
[02:26:16] <alex_joni> probably the only ones using code from the libs
[02:26:25] <SWPadnos> could be
[02:26:45] <alex_joni> makes me wonder.. if I install inivar to /usr/local/bin
[02:27:01] <alex_joni> then it shouldn't work.. even if I copy libnml.so to /usr/local/lib
[02:27:02] <alex_joni> right?
[02:27:10] <SWPadnos> no good unless it's compiled for that location, I'd bet
[02:27:28] <SWPadnos> it's not relative, or it would work in any directory name
[02:30:31] <SWPadnos> I'm confused - there's no rpath option for g++, which is what CXX is on my machine.
[02:30:51] <alex_joni> yes there is..
[02:30:55] <alex_joni> only it's not in man
[02:31:00] <SWPadnos> well that helps :)
[02:31:09] <alex_joni> * alex_joni goes to bed
[02:31:15] <SWPadnos> good night
[02:31:17] <alex_joni> can't keep my eyes open any longer
[02:31:18] <alex_joni> night
[02:31:20] <SWPadnos> (morning)
[02:31:36] <alex_joni> yeah
[02:42:20] <anonimasu> :)
[02:51:36] <fenn> i like josh seaton's idea on the users' list
[02:52:05] <SWPadnos> his kinematics / error compensation stuff?
[02:52:17] <fenn> basically he's talking about doing a nurbs-based interpolator, i think
[02:52:47] <SWPadnos> I didn't read those too closely :)
[02:53:16] <fenn> you give a parametric equation to the servo thread, and it evaluates it in realtime
[02:53:28] <SWPadnos> not likely, I'd imagine.
[02:53:34] <fenn> why not?
[02:53:58] <SWPadnos> there are problems with servoing that aren't proportional to the curve being followed
[02:54:21] <fenn> huh?
[02:54:34] <SWPadnos> (sorry - had to let the cat in)
[02:54:35] <fenn> can you give me an example?
[02:55:03] <SWPadnos> constant contouring - that's related to the curve length you cover in a servo period
[02:55:28] <SWPadnos> so you have to be able to calculate length, derivatives (for all axes), extent (for error checking), etc.
[02:55:42] <SWPadnos> it's not as simple as just following an iterative equation
[02:56:24] <fenn> * fenn switches to Bach so he can think about math
[02:56:44] <SWPadnos> I don't fully understand the math, but when I was looking into TP stuff earlier in the year, I remember seeing a lot of dsicussion about curve length calculations
[02:57:02] <SWPadnos> and how they're very difficult with certain types of equations
[02:57:20] <fenn> the parameter that you "parameterize" is the distance along the curve
[02:57:28] <fenn> x(u) where u is distance
[02:57:44] <fenn> or joint1(u)
[02:57:53] <SWPadnos> well - then you need to be able to derive the axis motions from that parameter, which may not be easy
[02:58:18] <fenn> you just evaluate the equation (in the servo thread)
[02:58:31] <fenn> or you mean coming up with it in the first place?
[02:58:35] <SWPadnos> yes, but the equation may require 6000 FP calculations per axis...
[02:58:56] <anonimasu> argh..
[02:59:03] <SWPadnos> and coming up with it could be hard too (it would be for me, at any rate)
[02:59:06] <fenn> * fenn hits anonimasu with a wet hairball
[02:59:18] <anonimasu> * anonimasu slaps fenn with a stick
[03:00:01] <SWPadnos> * SWPadnos goes to find the wet noodle supply
[03:00:06] <skullworks> * skullworks takes 2 more asprine
[03:02:47] <anonimasu> :)
[03:04:10] <skullworks> noob question
[03:04:26] <SWPadnos> noob answer
[03:05:00] <SWPadnos> possibly even n00b!
[03:05:04] <skullworks> Is there a way to run EMC2 without a machine hookup - an emulator of sorts?
[03:05:21] <fenn> depends what you want to do
[03:05:37] <SWPadnos> the default ini will use steppers on parport 0, which will do nothing if there's nothing connected
[03:06:11] <fenn> you can't simulate an external and expect it to work when there's nothing there
[03:06:22] <fenn> er, simulate an external switch
[03:06:44] <skullworks> want to try to rewrite some existing programs for emc - check out the backplot
[03:07:05] <fenn> that should work
[03:07:18] <SWPadnos> you'll have to deal with estop though
[03:07:41] <fenn> and following errors ;)
[03:08:03] <fenn> it wont be able to draw the part faster than it would be able to actually turn the motors
[03:08:11] <SWPadnos> not with stepper motion
[03:08:18] <SWPadnos> right :)
[03:08:36] <fenn> can you do servo's without feedback? havent tried it yet
[03:08:42] <SWPadnos> no
[03:08:47] <SWPadnos> well - sort of
[03:08:57] <fenn> maybe there should be a simulator hal block
[03:09:03] <SWPadnos> if you use geckos or the like, then ye, because EMC thinks you're using steppers
[03:09:11] <SWPadnos> yes, not ye
[03:09:12] <fenn> that's not what i mean
[03:09:29] <SWPadnos> ?
[03:09:39] <skullworks> well I'm working on refitting a Hurco with servos
[03:10:02] <fenn> i guess axis solves this problem.. but i cant get axis to work on my dev box
[03:10:16] <fenn> so i have to turn up the feed override and then it gives me errors :P
[03:10:34] <fenn> otherwise it takes forever to backplot a part
[03:11:36] <fenn> skullworks: what servo card are you using?
[03:11:43] <anonimasu> night all
[03:11:54] <SWPadnos> night
[03:11:55] <fenn> night anon
[03:12:05] <skullworks> not using one
[03:12:18] <fenn> gecko step-servo stuff?
[03:12:42] <skullworks> was likely to use the PPMC rack from Pico systems
[03:12:56] <fenn> yeah those are cool
[03:13:11] <skullworks> EMC to rack via parallel
[03:13:20] <fenn> i'm gonna build something along those lines with a bunch of avr's
[03:13:32] <skullworks> then use existing servos amps pws etc.
[03:16:05] <skullworks> machine has like a 30mm ball screws on X/Y - and 19mm on Z if I recall correctly
[03:17:30] <skullworks> with the 1987 era 8086/8087 controller it had 250 IPM rapids and 100 IPm feedrates possible.
[03:17:33] <SWPadnos> don't bet on it, fenn :)
[03:17:44] <fenn> swp party poop
[03:17:50] <SWPadnos> the AVR A/D converters are probably not fast enough
[03:18:01] <SWPadnos> yep - I'm a party pooper - sorry :)
[03:18:38] <SWPadnos> for step generation, you could do it but servo would be more difficult
[03:19:21] <fenn> could you go into more detail about why the a/d isn't fast enough?
[03:19:39] <SWPadnos> I suppose it depends on jus twhat you'd want to do with it
[03:19:51] <skullworks> I'm also looking to build a router system - most likely stepper based.
[03:19:57] <SWPadnos> but the AVR A/D needs roughly 60 microseconds per conversion IIRC
[03:20:23] <SWPadnos> regardless of processor speed - you have to use higher dividers on faster processors
[03:20:46] <fenn> 16Khz... hmmm
[03:21:05] <SWPadnos> skullworks, note that there aren't drivers for the PPMC stuff under emc2 yet. they're being worked on, but not generally available yet
[03:21:11] <SWPadnos> yeah - that's max.
[03:21:25] <fenn> good enough for me
[03:21:26] <SWPadnos> also, I've found that they aren't really 10 bit
[03:21:32] <skullworks> oh really?
[03:22:05] <SWPadnos> skullworks, PPMC - yes. I have a USC board from Jon, so I'm quite interested there :)
[03:22:08] <skullworks> I was under the impression there was an existing patch
[03:22:33] <SWPadnos> there was wone work done this April, and it's starting up again right now, but I don;t think there's a HAL driver for it
[03:22:40] <fenn> there are drivers under emc1..
[03:22:49] <SWPadnos> there are drivers for emc1, and BDI4 (which is essentially emc1 under kernel 2.6)
[03:23:16] <skullworks> well - I'm not in a rush
[03:23:24] <SWPadnos> fenn, are you planning on using the AVR for PID control at the servo rate (1-2 kHz)?
[03:23:36] <fenn> on PID of current
[03:23:40] <SWPadnos> me either - I have yet to build servo mounts for my Bridgeport :)
[03:24:04] <SWPadnos> OK - are you subscribed to the CAD-CAM-EDM-DRO yahoo group?
[03:24:22] <skullworks> I'm still trying to coax the owner into selling it to me - even though its just sat dead for almost 5 years now.
[03:24:29] <SWPadnos> heh
[03:24:29] <fenn> SWPadnos: was planning to run it in current-mode
[03:24:42] <SWPadnos> run what? emc?
[03:24:49] <fenn> the amplifier board
[03:25:05] <SWPadnos> ok good - there's hardware downstream from the AVR :)
[03:25:25] <SWPadnos> what board are you planning?
[03:25:29] <fenn> maybe i'm not making sense
[03:25:37] <SWPadnos> heh - could be me ;)
[03:25:51] <fenn> emc outputs torque commands via parallel port to the "master" avr
[03:26:03] <fenn> which then talks to the attiny's for each axis
[03:26:32] <SWPadnos> and it's all analog between the tinys and the amplifiers?
[03:26:43] <SWPadnos> (D/A out and analog feedback in)
[03:26:52] <fenn> pwm out and analog feedback
[03:27:12] <SWPadnos> OK - any reason why you wouldn't just use a PCI or ISA analog I/O card?
[03:27:42] <fenn> only about $900 every time i want to make a servo machine
[03:27:55] <SWPadnos> what kind of cards are you looking at?
[03:28:02] <SWPadnos> motenc and the like?
[03:28:07] <fenn> haven't really looked
[03:28:31] <fenn> a lot of this stuff is much more hi-performance than i really need
[03:28:32] <SWPadnos> I'm talking about stuff from ComputerBoards - $200-$300 for the speed and accuracy you need
[03:28:51] <SWPadnos> sorry - measurement computing now
[03:28:56] <SWPadnos> http://www.measurementcomputing.com/
[03:29:43] <SWPadnos> OK - looks like they've gone up a little since I last bought any :)
[03:29:51] <fenn> that's only half of the equation too
[03:30:06] <fenn> gotta have encoder reader and pwm
[03:30:07] <SWPadnos> sure, but I'd bet the PC processor is the other half :)
[03:30:35] <SWPadnos> you'll need external hardware for encoders on the ATTinys, I think (have to think about it a little)
[03:30:46] <fenn> you mean like signal conditioning?
[03:31:03] <SWPadnos> no, for the quadrature decoding
[03:31:12] <fenn> everyone says that and i dont understand why
[03:31:51] <SWPadnos> well, one thing I think about when designing a microcontroller board is what interrupt sources I have, and which is (are) the most important
[03:32:09] <SWPadnos> the AVR has no priority scheme, so you can't do things that way
[03:32:33] <fenn> the way i designed it there's only one interrupt for each micro
[03:32:36] <SWPadnos> so you have to pick one interrupt source as the most important, and make absolutely sure that it will be serviced in time
[03:32:54] <SWPadnos> then how do they get new commands, or send position data back up the chain to EMC?
[03:33:00] <fenn> the master takes care of EPP communication
[03:33:16] <fenn> they talk via an spi (?)
[03:33:21] <SWPadnos> and the slaves (which have the encoder reading duty)
[03:33:27] <fenn> which is like a fifo right?
[03:33:38] <SWPadnos> first, there's only one SPI port on an AVR
[03:33:46] <SWPadnos> it's a fifo of one :)
[03:33:47] <icee> be careful that everything works out via SPI, fenn
[03:34:00] <icee> swp: sure, but you can have as many chip selects as you want
[03:34:15] <SWPadnos> since there's only one port, you have to share the comm channel between the three (or more) slaves and the master
[03:34:23] <SWPadnos> yes - hold on :)
[03:34:32] <fenn> well, i might have 6 "master" chips
[03:34:39] <fenn> er, one master chip per axis
[03:34:45] <SWPadnos> all talking on the parallel port?
[03:34:48] <fenn> yeah
[03:34:51] <SWPadnos> no
[03:35:02] <fenn> heh talk to icee about that :)
[03:35:36] <SWPadnos> I suspect that you'd be ebtter off with a motenc card, once you're done (or one of the Measurement computing or any of the others)
[03:35:48] <skullworks> it would be nice if there was a decent PCI based motion controller card available at a good price...
[03:36:06] <SWPadnos> note also that Jon Elson had to do very nasty things to get the USC / PPMC boards working on the parallel port under RT
[03:36:27] <SWPadnos> remember that you can't use normal kernel drivers, so you have to write your own handshake code
[03:36:33] <SWPadnos> which is not trivial
[03:36:46] <icee> the hardware does handshaking for EPP.
[03:36:53] <icee> you just write / read from the correct ports
[03:36:56] <icee> and check the timeout bits
[03:37:09] <SWPadnos> not if you can't use the EPP hardware, and you have to fake it in software
[03:37:19] <icee> and why would you want to do that?
[03:37:30] <icee> almost everything has EPP, and EPP cards are only $20 or less
[03:37:46] <SWPadnos> it's not the hardware, it's the RTAI problem
[03:38:00] <icee> And why is there a problem with RTAI with using the hardware?
[03:38:11] <icee> e.g. the axis stuff already does exactly what I'm saying.
[03:38:21] <SWPadnos> which axis stuff?
[03:38:30] <icee> er, sorry, pico systems stuff.
[03:38:45] <icee> i always get the words 'axis' and 'pico' flipped for some reason.
[03:39:14] <SWPadnos> ah - OK - JonE had mentioned that there's a lot of hackery in his drivers to get the hardware to work (parport hardware, that is)
[03:39:30] <SWPadnos> it may be that he just copied parts of the Linux epp driver, I'm not sure
[03:39:38] <icee> swp: I'm doing stuff from user space in linux, just reading/writing from ports
[03:39:39] <icee> and it's very simple.
[03:39:49] <SWPadnos> and not applicable to RTAI
[03:39:56] <SWPadnos> in RT threads
[03:39:58] <icee> Yah. It's even easier in kernel space.
[03:40:04] <icee> no need to call ioperm() :P
[03:40:17] <SWPadnos> no, because you can't use kernel device drivers under RTAI in RT threads
[03:40:25] <icee> I'm not -using- kernel device drivers
[03:40:26] <SWPadnos> heh - outb is your friend
[03:40:33] <icee> ONCE AGAIN: I'm reading/writing from the i/o ports
[03:40:36] <icee> inb(), outb()
[03:41:02] <SWPadnos> (sorry - port is an overloaded wordre: parports)
[03:41:12] <icee> write to the epp data port, and the EPP hardware does a handshaked data strobe
[03:41:19] <icee> write to the EPP address port, and the same
[03:41:37] <icee> read from either, it asserts the strobe, waits for WAIT to go high, then reads the data and deasserts it
[03:41:45] <icee> http://lyle.org/~mlyle/epp.c
[03:41:48] <SWPadnos> and how long does that take?
[03:41:50] <icee> should work very nicely under rtai.
[03:41:56] <icee> a couple microseconds
[03:42:11] <SWPadnos> which is a couple thousand CPU cycles on a modern CPU
[03:42:23] <icee> yah.
[03:42:26] <SWPadnos> oops
[03:42:57] <SWPadnos> (not oops(), just oops )
[03:44:14] <SWPadnos> JonE mentioned that his unit takes around 50 uS to do a 4-axis update
[03:44:41] <SWPadnos> that's with an FPGA on the other side, so it's a bit faster than an AVR would be (for the same amount of data)
[03:45:11] <icee> this is with a dsPIC.
[03:45:24] <SWPadnos> your project?
[03:45:30] <icee> yah.
[03:45:37] <icee> 30MIPs.
[03:45:47] <icee> we have it working-- the communications stuff
[03:45:50] <SWPadnos> do those not divide by 4 like the normal PICs
[03:46:04] <icee> they do, but the clock is up to 120MHz
[03:46:09] <SWPadnos> that's a fast PIC
[03:46:23] <icee> it has a 17x17 multiplier and quadrature decoder, too
[03:46:28] <SWPadnos> that helps
[03:47:00] <SWPadnos> fenn, to look again at the encoder / interrupt thing, think about what has to happen every time there's a change on the pins
[03:47:26] <SWPadnos> at best, you need roughly 8-10 CPU cycles to figure out what happened (increment or decrement)
[03:47:46] <SWPadnos> add to that the 7 cycles for an interrupt vetor and return (could be 9, I don't remember)
[03:48:22] <SWPadnos> then add in the fact that you'll probably need to use multibyte math for the counter, do noise checking, and save/restore registers (as well as the count)
[03:48:25] <icee> swp: i've written plenty of embedded code, thanks
[03:48:30] <fenn> could i just do: checkEncoder(); checkStuff1(); checkEncoder(); checkStuff2()
[03:48:40] <icee> the quadrature decoder already has digital filters
[03:48:48] <SWPadnos> (aimed at fenn - that last was :) )
[03:48:51] <icee> and special handling for TOP/underflow
[03:49:04] <SWPadnos> yoda speaking am I now
[03:49:14] <icee> oh yah, fenn's stuff is a little scary-- trying to do everything in sfotware
[03:49:29] <SWPadnos> fenn, I hope you're paraphrasing, and not actually thinking that you can use C...
[03:49:40] <fenn> yes that was pseudocode
[03:49:44] <SWPadnos> phew ;)
[03:50:29] <SWPadnos> that may be possible. you'll just have to see what the maximum encoder rate you can get is, relative to clock speed
[03:50:55] <SWPadnos> I'll bet that you can't reliably get faster than 1/100 the clock, probably slower if you have other interrupts on
[03:51:02] <fenn> i shouldn't have to to multibyte math if i'm only talking to the master controller
[03:51:14] <fenn> since there's less time for buffer overruns
[03:51:22] <fenn> er a 1-byte buffer :)
[03:51:31] <SWPadnos> multibyte stuff will be absolutely necessary for PID
[03:51:34] <icee> fenn: be careful-- you may not be able to do SPI cycles as quickly as you think
[03:51:47] <SWPadnos> (I was savign that :) )
[03:51:49] <icee> swp: well, if his update rate is fast enough, he ca ndo what i'm doing-- 2's complement math and extend
[03:51:50] <SWPadnos> saving
[03:52:15] <SWPadnos> the AVR is good at multibyte math (it knows what a carry is, after all ;) ), but it still adds cycles
[03:52:59] <fenn> what do i need to look out for as far as noise and glitches?
[03:53:04] <SWPadnos> if the variables are in registers, then multibyte math is one cycle per byte of precision for add or subtract
[03:53:34] <SWPadnos> well, there are only two valid transitions from any given state, and one invalid one (or the same value, meaning no motion)
[03:53:45] <SWPadnos> you need to see if both bits flip simultaneously
[03:54:11] <icee> fenn: well, there's transient bit flips just due to noise
[03:54:16] <SWPadnos> and you probably want to insure that the pulse width "makes sense" (external filtering is the way to go for that)
[03:54:20] <icee> you need to filter that somehow
[03:54:28] <icee> to an extent, real analog filtering on the differential lines can help you
[03:54:38] <SWPadnos> (assuming it's differential)
[03:55:26] <fenn> what's a differential? :)
[03:55:31] <SWPadnos> oh yeah - if you allow differential connections, then you also should check to be sure that the complements are actually opposite, else there's a problem
[03:55:51] <SWPadnos> that's the thing that lets you steer without wearing out your tires prematurely :)
[03:55:55] <icee> fenn: the encoder hookups.. there's an A signal, then a not-A
[03:56:06] <fenn> hmm.. not on my encoders there aint
[03:56:07] <icee> you usually use something like a differential line receiver to compare them
[03:56:16] <fenn> is that to help with noise?
[03:56:22] <icee> yah
[03:56:33] <icee> the idea is that noise should couple into both signals identically
[03:56:40] <icee> so the difference should still be valid
[03:56:54] <SWPadnos> (it's the same difference - har har)
[03:57:15] <icee> you can still put a RC network on the encoder lines to smooth things out, along with a schmitt trigger buffer
[03:58:32] <icee> you'll pick the time constant of the RC network to be some fraction of the highest pulse rate you anticipate
[03:58:35] <SWPadnos> incidentally, I believe that the ATTINy line has no multiply instruction, and you'll need that for PID
[03:58:52] <icee> yah, only ATMEGA
[03:58:56] <SWPadnos> you need a MEGA for that
[03:58:58] <icee> and long multiplies are expensive
[03:59:33] <fenn> the idea was that the attiny would only do encoder and i/o reads
[03:59:46] <SWPadnos> I have a 23-cycle 16x16, and a 43 cycle 16x32 multiply
[03:59:58] <SWPadnos> including call+ret
[03:59:58] <fenn> and the master would do PWM, io write, and talk to epp
[04:00:40] <icee> fenn: just use a CPLD or an application-specific part to do the quadrature decoding
[04:00:45] <icee> it's much harder to go wrong
[04:00:50] <fenn> how critical is current-PID?
[04:01:01] <icee> not critical.
[04:01:21] <SWPadnos> ??? why not?
[04:01:36] <icee> swp: plenty of low end controllers don't do closed-loop control of current
[04:02:14] <SWPadnos> like which? (ie, controllers that do current control, but not closed loop)
[04:02:16] <icee> f: it means you can't be as aggressive/get as much torque
[04:02:36] <icee> swp: plenty just generate PWM, open loop-- voltage control
[04:02:48] <icee> if you have feedback, closed loop, to control current, then you have current control
[04:02:48] <SWPadnos> that's not current control though
[04:03:01] <icee> OK...
[04:03:08] <SWPadnos> sure - it could be position control, too
[04:03:20] <icee> yes, by definition, without closed loop control of current, you don't have current control
[04:03:52] <SWPadnos> there's a difference between controlling in torque mode and velocity mode, which is the difference between current and voltage control
[04:04:07] <icee> Yes, I'm aware of that.
[04:04:32] <icee> I was just telling fenn it isn't the end of the world if he controls it in voltage mode (which isn't -quite- velocity mode) instead
[04:04:33] <fenn> what if you programmed the motor characteristics into EMC and ran voltage command to the amp :)
[04:04:43] <SWPadnos> regardless, whichever mode you choose, you need to be able to produce a result every servo cycle
[04:04:47] <icee> f: yah, plenty of low end systems, you do that
[04:05:02] <SWPadnos> fenn, you'd have to program in the charisteristics of the machine, tool, and material as well :)
[04:05:46] <fenn> not really
[04:05:54] <fenn> you get feedback about the speed of the motor
[04:06:01] <SWPadnos> OK - sure. the net effect is that if the PID params are correct, then the position will eventually be correct as well
[04:06:09] <fenn> that's the only parameter that affects motor current right?
[04:06:22] <SWPadnos> current provides torque
[04:06:27] <SWPadnos> voltage provides speed
[04:07:13] <SWPadnos> higher voltage than that produces by the motor back EMF induces current, which produces torque, which accelerates the motor to higher speed
[04:07:15] <icee> f: You won't be able to use all the torque under all operating conditions without current feedback and a current control loop
[04:07:39] <fenn> whats an example of one?
[04:07:56] <SWPadnos> note that a Gecko servo drive has a current control loop
[04:08:32] <SWPadnos> an example of a situation icee described?
[04:08:45] <icee> f: you're dealing with a second or third derivative, instead of a direct observation of it; inherently you're going to be lagged
[04:08:51] <fenn> * fenn is feeling dumb and cant visualize current not catching up
[04:09:20] <SWPadnos> you have a 1-ohm motor at rest, and you apply 50V to it. you get 50A through the motor, and a lot of torque
[04:09:25] <icee> and you need safety margin in your parameters so that current doesn't get -ahead- when you hit resistance and you provide too much current to it
[04:09:29] <SWPadnos> possibly also a lot of smoke as the wires melt
[04:09:42] <SWPadnos> ok - headroom
[04:09:44] <skullworks> Hold on - doesn't the regulator in the servor amp act as a sort of feedback in that it is sensing load?
[04:09:56] <SWPadnos> yep
[04:10:00] <SWPadnos> maybe
[04:10:31] <SWPadnos> it senses current, not load (if it's a current limiting drive)
[04:11:25] <fenn> so.. the amount of time i have to cut back the current depends on the thermal characteristics of the motor and drive amps, and the amount of headroom i give myself
[04:11:38] <icee> thermal/electrical characteristics
[04:11:50] <icee> the motor winding resistance, inductance, drive voltage, and rated current
[04:12:58] <SWPadnos> fenn, look at the Motorola 56F800 series DSPs. It's a lot closer to what you might need for a motor controller (and can directly control a motor, with a suitable H-bridge)
[04:13:23] <SWPadnos> they're designed for motor control, unlike the average AVR
[04:13:34] <icee> too bad the at90pwm* parts aren't out yet
[04:13:38] <SWPadnos> yeah
[04:13:43] <SWPadnos> no kiding :)
[04:13:46] <SWPadnos> kidding
[04:14:00] <skullworks> well later all - I have to go return some DVD's
[04:14:01] <SWPadnos> they have the lighting control ones listed as well - not sure if they're available
[04:14:07] <SWPadnos> see ya :)
[04:14:20] <SWPadnos> have you seen the ARM chips from Atmel?
[04:14:33] <icee> yah, i've used them.
[04:14:36] <icee> and lpc21xx
[04:14:49] <icee> decent parts, though poorly documented in places
[04:15:08] <SWPadnos> they have some amazingly cheap new ones with things like USB and ethernet (32-bitters for $3-$5)
[04:16:00] <icee> i've used the at91sam7s128 and family
[04:16:21] <SWPadnos> OK - those are one of the inexpensive lines - how did you like them?
[04:16:32] <icee> other than the missing docs that cost me a day of troubleshooting and requiring a wire on my board
[04:16:37] <icee> they're nice parts
[04:16:41] <SWPadnos> heh
[04:17:00] <icee> if you're using the USB self programming, they require you dedicate a pin to control whether the pos lead of the usb bus is pulled up to trigger enumeration
[04:17:08] <icee> they tell you what pin to use in the datasheet
[04:17:12] <icee> and have a sample schematic elsewhere
[04:17:21] <SWPadnos> different, no doubt
[04:17:22] <icee> turns out the polarity of the signal is the -opposite- of what the sample schematic assumes
[04:17:51] <icee> so.. i had to replace my npn transistor with a PNP, and ghetto up a resistor on the collector
[04:18:11] <SWPadnos> bummer
[04:18:13] <SWPadnos> one of the guys from my old business just gave me a couple of tester boards with the AT91RM72S64 (or whatever I put there - it's unpopulated), so I may experiment a little
[04:18:31] <SWPadnos> he was frustrated because he hadn't read all the docs on the "fully configurable I/O
[04:19:00] <SWPadnos> didn't realize that each pin has a short list of possible functions, not a full crossbar for I/O
[04:19:07] <icee> heh heh
[04:19:16] <SWPadnos> so he's got a few spare boards :)
[04:19:20] <icee> It's really unfortunate.. the parts have the same good engineering that makes the avr nice
[04:19:29] <icee> but the documentation which is perfect for the avr parts
[04:19:36] <icee> is severely lacking for the atmel arm parts
[04:19:52] <SWPadnos> I gather that the devtools are also lacking from Atmel - ie, you need to buy third-party tools
[04:20:00] <SWPadnos> (or use gcc, as I plan)
[04:20:04] <icee> swp: well, you can target it with gcc
[04:20:12] <SWPadnos> good plan :)
[04:20:16] <icee> and their samba bootloader software is free
[04:20:26] <icee> I have linker scripts, and a crt0 that i wrote if you want them
[04:20:30] <SWPadnos> cool. any BSP-type support
[04:20:37] <SWPadnos> great - I'd love to see them
[04:20:47] <icee> swp: send me your email address and i'll send them over later
[04:21:01] <SWPadnos> spadnos at sover dot net
[04:21:10] <icee> sure thing
[04:21:21] <SWPadnos> (just to fool the spammers, who can't figure that out :) )
[04:21:29] <SWPadnos> thanks
[04:21:51] <SWPadnos> I'm designing a digital camera array, and looking for a suitable supervisor micro in the camera
[04:22:09] <SWPadnos> the ARMs look good, but I may need more horsepower
[04:22:23] <SWPadnos> and it's gotta be fast ethernet
[04:23:20] <SWPadnos> I might just stick one in an FPGA
[04:24:06] <icee> swp: have you looked at the analog devices blackfin?
[04:24:13] <SWPadnos> not in depth
[04:24:23] <icee> the parallel interface is very nice for interfacing to cmos imagers or ADCs
[04:24:24] <SWPadnos> (heard of it, seen it at a show, that's about it)
[04:24:29] <SWPadnos> hmm
[04:24:48] <icee> and it has lots of MIPs and I think a lot of family members have fast ethernet MAC
[04:24:59] <SWPadnos> I don;t have full specs for the camera yet, so I don't know the level of processing that'll need to happen there
[04:25:59] <SWPadnos> a fast parallel port (DMS-ish) would be good, but there also has to be a fast (and separate) memory port, since the network can't keep up with the data from the chip during readout
[04:26:10] <SWPadnos> DMA-ish, not DMS
[04:29:19] <icee> swp: yah, there's a SDRAM controller on there
[04:29:39] <icee> swp: i used the blackfin for my image processing board on the autonomous helicopter i built
[04:29:55] <SWPadnos> oh - cool
[04:30:18] <icee> along with a FPGA to interleave the data/synchronize it from two image sensors (stereo)
[04:30:41] <SWPadnos> interesting
[04:31:03] <SWPadnos> I'm making an array of roughly 100 cameras, 5MP each
[04:31:05] <SWPadnos> should be fun
[04:31:12] <icee> neat
[04:31:13] <icee> what for?
[04:31:28] <SWPadnos> thanks for the files - they just arrived
[04:31:36] <SWPadnos> ever seen "The Matirx"?
[04:31:46] <SWPadnos> Matrix (man - it's late)
[04:31:47] <icee> swp: use caution.. many registers are in different locations on the part you're using
[04:32:00] <SWPadnos> I will use no part before its time
[04:32:02] <icee> and.. i never checked the registers i typed in, other than the ones i was actually using
[04:32:08] <icee> swp: sure
[04:32:33] <SWPadnos> well - we developed a film camera to do "bullet time" before they made that movie
[04:32:42] <SWPadnos> I'm making a digital one now
[04:33:30] <SWPadnos> look at http://www.bigfreeze.com/ if you have a flash-enabled browser
[04:33:56] <SWPadnos> (I hate the site organization, but it's for artistic types, so I don't complain)
[04:34:36] <fenn> now if you can just figure out how to make the cameras invisible..
[04:34:58] <SWPadnos> heh - that is a problem
[04:35:11] <SWPadnos> but digital makes it easier, since they're a llot smaller
[04:35:22] <SWPadnos> like - a 2 inch cube or thereabouts
[04:35:27] <SWPadnos> (plus lens)
[04:35:58] <SWPadnos> I've considered other applications as well, even something like an X-Y scale on a milling machine :)
[04:38:43] <fenn> like a visual measuring device?
[04:38:47] <SWPadnos> yep
[04:39:12] <SWPadnos> with reasonable optics and 2.2 micron pixels, I'd think that a reasonable measuring device could be made
[04:39:57] <fenn> i read about something like that in "design of accurate instruments and mechanism" from lindsay books
[04:40:13] <fenn> except they used film of course
[04:40:24] <SWPadnos> for 3-d scanning, or for position measurement (like optical mice)?
[04:40:33] <fenn> this is from like 1900
[04:40:39] <SWPadnos> ah - neither :)
[04:40:48] <SWPadnos> I'm thinking more like a really accurate optical mouse
[04:41:11] <SWPadnos> but one that can give a machine controller its position via ethernet from time to time
[04:41:44] <SWPadnos> I also know of a company that does 3-d scanning, using a number of digital imagers around an object - they get something like 0.0001" resolution
[04:41:51] <fenn> there's a device that works like that, based on interferometry with a holographic grid
[04:42:00] <fenn> (not the 3d scanning)
[04:42:14] <SWPadnos> this is just visible light digital cameras - no lasers needed
[04:42:26] <fenn> http://www.mmsonline.com/articles/049601.html
[04:44:05] <SWPadnos> interesting
[04:44:33] <SWPadnos> It's bedtime for me though - good night, all
[04:44:39] <SWPadnos> SWPadnos is now known as SWP_Away
[09:46:06] <fenn> mhmmm.. prelink hogs 99% of the cpu and makes the computer all sluggish after recently make-installing emc2.. or it could be kde 3.4 i just installed
[09:46:41] <fenn> this is the first time cron.daily has run since installing either of them
[10:07:45] <anonimasu> morning
[12:14:58] <Jacky^afk> Jacky^afk is now known as Jacky^
[12:20:34] <fenn> * fenn is pretending to write an EPP hal module..
[12:50:40] <anonimasu> hm
[12:50:44] <anonimasu> nice
[12:50:50] <anonimasu> Ive got pics of my mills
[12:50:55] <anonimasu> going to post them later
[12:51:04] <anonimasu> Ive measured the broken mill now
[12:51:09] <anonimasu> to see if its better to convert it to cnc
[12:51:35] <anonimasu> my dial gauge is too crude to show anything ;/
[12:53:24] <fenn> you need a dial test indicator
[12:54:56] <fenn> this ppmc protocol is really wacky
[12:55:29] <anonimasu> ppmc?
[12:55:34] <anonimasu> the one jon elson uses?
[12:55:46] <fenn> yeah.. wacky is a bit strong.. just not suited for what we're doing
[12:56:03] <anonimasu> are you writing a driver for emc2?
[12:56:23] <fenn> maybe
[12:56:46] <anonimasu> if you want I could help you out..
[12:56:47] <anonimasu> if you are..
[12:57:03] <fenn> i'm trying to figure out how to implement all this serial stuff in hal
[12:57:25] <fenn> like loading position data into the ppmc? wtf
[12:58:17] <anonimasu> its kind of cool the tolerances for the >50 year old mill are better then my chineese mill.. thats a few years
[12:58:21] <fenn> maybe i'm misunderstanding this document
[12:58:29] <anonimasu> what doc?
[12:58:37] <fenn> http://pico-systems.com/univpwm_regs.html
[12:59:33] <anonimasu> ah
[12:59:39] <anonimasu> its the same as the usc isnt it?
[12:59:43] <anonimasu> thats what I have..
[12:59:46] <fenn> probably
[13:02:24] <fenn> oops heh i was looking at the wrong thing ths whole time
[13:04:53] <anonimasu> :)
[13:05:23] <fenn> now i'm really confused.. is the universal pwm controller just a board that plugs into the ppmc?
[13:08:18] <Imperator_> on emc fest i began to help Jon to write a emc2 driver
[13:08:36] <fenn> for which board?
[13:09:36] <Imperator_> it was nearly working i had only one problem to solve. I asked John K, and he looked at the code and began to delete half of teh code, because he said that this is no good code :-)
[13:09:49] <fenn> uh oh :)
[13:09:54] <anonimasu> *sigh
[13:10:18] <Imperator_> that was realy cool to see how jmk is coding
[13:10:47] <fenn> the reason i am wanting to write a coder is to control the p5 driver and also a cheapie driver i am designing
[13:10:58] <fenn> s/coder/driver
[13:11:09] <Imperator_> at the evening jmk started a long coding session at jons room but the driver wasent finished
[13:12:08] <Imperator_> what kind of driver do you design ?
[13:12:53] <fenn> basically a lower performance version of the p5 driver, but for brushed servos
[13:13:12] <fenn> making a desktop sized hexapod
[13:13:29] <fenn> i have these 6 little servos with 2000 ppr encoders
[13:14:13] <fenn> no need to throw tons of money at it
[13:14:46] <fenn> anyway, i was looking around to see what i needed to consider as far as flexibility
[13:14:51] <Imperator_> p5 driver ???
[13:15:04] <fenn> http://forums.donniebarnes.com/viewforum.php?f=16
[13:15:10] <fenn> surpluscenter motors
[13:21:45] <Imperator_> you want to use the parallel port to communicate with your driver
[13:21:51] <fenn> yes
[13:22:04] <Imperator_> which protocoll dou you want to use ?
[13:22:11] <fenn> EPP
[13:22:23] <Imperator_> that is no protocoll
[13:22:27] <fenn> bah
[13:22:35] <fenn> what do you mean "which protocol"
[13:22:48] <Imperator_> i mean do you want to tranfer speed values or direction and clock or ....
[13:23:19] <fenn> probably current commands
[13:23:27] <fenn> "torque mode"
[13:23:33] <Imperator_> ok fine
[13:23:44] <fenn> easier on the microcontroller that way
[13:23:51] <Imperator_> why don't you want to use the mesa card ?
[13:24:14] <fenn> i have no idea
[13:24:28] <fenn> i think it's past my bedtime.. i'm feeling dumb
[13:25:03] <fenn> i would much rather make my own electronics
[13:25:27] <Imperator_> a realy professional approach would be if you have PWM output form the FPGA and a digital current feedback from the controller board
[13:25:36] <Imperator_> and of cause encoder feedback
[13:26:05] <fenn> why use an fpga?
[13:26:22] <fenn> i mean, i understand that that's what the mesa card does, but..
[13:26:53] <Imperator_> fpga's are extremly fast and you can do what ever you want with it
[13:27:46] <Imperator_> and if the FPGA is no more deliverable you can load the code in other FPGAs. the code for microcontroller is much more product specific
[13:31:21] <fenn> this driver design started out in my head as (per axis) a comparator, a latch, and an a/d converter
[13:31:36] <fenn> costing maybe $3.00/axis
[13:32:06] <fenn> i have absolutely no idea how to use an fpga
[13:32:19] <Imperator_> we are making some breakout boards here for the mesa card one is a encoder feedback card, and a other one is a quad dac card. If you change the DAC card to a ADC card you can use it for current feedback, and half of the hardware is done
[13:33:44] <Imperator_> forgett that calculation, when you are finished you have spend abourt 200-1000$, beieve me
[13:33:57] <fenn> that's what everyone says.. sheesh
[13:34:23] <Imperator_> maybe it is true
[13:35:07] <fenn> maybe i should just go take out a loan and buy a haas.. maybe i should just get a job at Eli lilly
[13:36:09] <Imperator_> we wanted to build up our own ISA fpga card with encoder input and a dac and so on. the fpga is about 20$. when we had finished the design we found that mesa card for 200$ and we skipped the ISA board, because we thought that is much cheaper at the end
[13:36:10] <fenn> i can't believe that it is that hard to control 6 motors with a computer
[13:36:42] <CIA-5> 03 07 * 10rcslib/: rm -fR *
[13:36:46] <Imperator_> it depends on what do you want to have
[13:37:03] <fenn> looks like cia is deleting the repository again :)
[13:37:16] <fenn> anyway.. my point is all this stuff is way way way overkill for what i am diong
[13:37:17] <Imperator_> :-)
[13:37:53] <Imperator_> that dsPic stuff is as complicated as a FPGA
[13:37:54] <fenn> my encoders will never go over 150khz..
[13:38:52] <Imperator_> if you only want to turn a motor you can do it like the guys in that german forum, they are making a controller with a ATMEL but without a current controller, only encoder feedback
[13:39:10] <fenn> which forum is this?
[13:39:17] <Imperator_> it's like a gecko, but i think they have a current controller
[13:39:39] <Imperator_> http://5128.rapidforum.com/area=122
[13:40:33] <Imperator_> it is that UHU controller
[13:40:47] <Imperator_> you need to register yourself first
[13:40:51] <fenn> right
[13:41:33] <Imperator_> and you need some german knowlege
[13:43:31] <fenn> i seem to be picking up german from reading about cnc stuff :)
[13:47:54] <fenn> hmm i'm logged in and it still says i need to log in..
[13:49:49] <fenn> ah n/m
[14:00:59] <fenn> this sounds very much like what i'm doing... is there an "overview"? everything i see is stuff like "changed this" or "order your boards next week' kinda stuff
[14:14:14] <anonimasu> hmn
[14:14:19] <anonimasu> *grabs pics of the mill*
[14:14:57] <fenn> yuck.. it's step/dir
[14:17:30] <fenn> * fenn goes to bed..
[14:17:37] <fenn> sad way to end the day
[14:22:50] <anonimasu> http://www.io23.net/tmp/
[14:24:19] <anonimasu> that's the mill :)
[14:27:00] <anonimasu> now with a vise mounted
[14:29:30] <Imperator_> hm i try to find the zip file where all is included, one moment
[14:30:10] <anonimasu> hm
[14:30:40] <Imperator_> hm nice old mill. It lokks like that it is in good condition
[14:31:46] <Imperator_> http://www.gertronik.de/cncecke/servo.zip
[14:42:22] <alex_joni> morning...
[14:43:28] <Imperator_> Hi alex
[14:43:50] <alex_joni> hey Martin
[14:44:25] <anonimasu> hello ale
[14:44:25] <anonimasu> x
[14:44:26] <anonimasu> :)
[14:44:47] <alex_joni> what's up?
[14:45:09] <anonimasu> been out in the shop all morning
[14:45:09] <anonimasu> :)
[14:55:01] <lerman> Just thought I'd let you guys know that I won't be available for todays meeting. I have a martial arts seminar to attend, today.
[14:55:23] <alex_joni> cool..
[14:55:35] <lerman> Let the record show, though, that lerman DID complete his assignment from last week.
[14:55:37] <alex_joni> in a few weeks lerman is gonna kick our butts
[14:55:37] <alex_joni> * alex_joni giggles
[14:55:59] <alex_joni> lerman: indeed you did.. time for a new one :P
[14:56:08] <alex_joni> kidding ;)
[14:56:53] <lerman> I'll have to find an appropriate one. I do seem to remember, though, that you volunteered to test my work.
[14:57:19] <alex_joni> I did
[14:57:25] <alex_joni> it's on my todo-list
[14:57:45] <lerman> Thanks, it is really appreciated. Gotta go.
[14:58:13] <alex_joni> right after finishing the STG driver, redoing hal_lib (the drivers part), more work on iocontrol, make install, make deb
[14:58:40] <alex_joni> ;-)
[15:12:26] <alex_joni> morning rayh
[15:12:37] <rayh> Hi alex.
[15:13:19] <rayh> what's with the \malex\ on my list of folk here.
[15:13:30] <alex_joni> \malex\ ?
[15:13:52] <alex_joni> no idea.. just another user
[15:14:00] <rayh> That name is right under my ChanServ
[15:14:12] <alex_joni> yes.. beacuse \ is before letters
[15:14:37] <rayh> when I ask whois I get my own info
[15:15:25] <rayh> Got a topic?
[15:15:51] <alex_joni> what topic?
[15:18:02] <rayh> If you've got time, tell me about how iocontrol does it's work.
[15:18:25] <rayh> I see that pressing a mist coolant on changes a pin there.
[15:18:47] <rayh> Does it also report back to emc that mist is on?
[15:18:48] <alex_joni> well pressing the mist coolant on sends a NML message
[15:19:00] <alex_joni> no it doesn't.. but that's not hard to do..
[15:19:25] <alex_joni> the only problem is:
[15:19:34] <rayh> pressing mist on -> NML command -> ??
[15:19:43] <rayh> is the next thing task
[15:20:02] <alex_joni> NML command -> task -> NML command -> iocontrol -> HAL pin changed
[15:20:24] <rayh> Where along that line does the status get updated?
[15:20:39] <alex_joni> in iocontrol
[15:20:46] <alex_joni> iocontrol sends a status message back
[15:20:58] <alex_joni> and that status message can either be RCS_DONE (all ok)
[15:21:10] <alex_joni> or RCS_EXEC (still working on it, like on the toolchanging)
[15:21:26] <alex_joni> then when the action is DONE it needs to send a RCS_DONE marked message
[15:21:39] <alex_joni> until then further IO messages get stacked, not actually sent
[15:22:10] <rayh> Okay. Then we could let iocontrol immediately send theRCS_EXEC
[15:22:29] <rayh> but wait for a pin change to send the RCS_DONE
[15:22:32] <alex_joni> yes
[15:22:41] <alex_joni> the problem is sending messages out of line..
[15:23:01] <rayh> I presume that these carry a unique number that relates to the initial NML message?
[15:23:02] <alex_joni> for example coolant starts..
[15:23:13] <alex_joni> of course.. and you're not allowed to mess that out .(
[15:23:19] <alex_joni> so that's a real PITA
[15:24:02] <alex_joni> the more I think of it I think iocontrol should talk through emcCommand too
[15:24:07] <alex_joni> emcStatus is only for ack's
[15:24:16] <alex_joni> you can't easily push status through there...
[15:24:31] <alex_joni> and most changes will be noticed only on the next NML from GUI
[15:24:39] <alex_joni> as those aren't periodic...
[15:24:44] <rayh> I know that on the other end, emcsh and iosh...
[15:25:03] <alex_joni> can this wait for a bit?
[15:25:08] <rayh> we compiled them together for a test thing
[15:25:14] <alex_joni> * alex_joni has some php to debug :(
[15:25:15] <rayh> certainly.
[15:25:36] <alex_joni> will let my left brain half chew on it
[15:25:42] <alex_joni> while the other is doing php ;)
[15:26:11] <rayh> catch you in a bit.
[15:27:30] <alex_joni> alex_joni is now known as alex_joni_busy
[15:28:11] <anonimasu> bblk
[15:57:36] <SWP_Away> SWP_Away is now known as SWPadnos
[15:57:47] <SWPadnos> hi folks
[15:59:14] <SWPadnos> hey Alex_
[15:59:22] <alex_joni_> hello
[15:59:38] <alex_joni_> brb, a bit busy hacking some php :(
[15:59:45] <SWPadnos> so I read :(
[16:01:00] <alex_joni_> it's an awfull language ;)
[16:01:21] <SWPadnos> I think most of the "web" languages are awful
[16:02:40] <alex_joni_> well.. I am trying to modify a navigation tree
[16:02:47] <alex_joni_> that's in a mysql database
[16:02:59] <SWPadnos> have fun :)
[16:03:00] <alex_joni_> and it's using recurrent php functions
[16:03:02] <alex_joni_> yuck
[16:03:08] <SWPadnos> it should be easy, right?
[16:06:38] <rayh> brb reboot
[16:38:58] <jmk_away> jmk_away is now known as jmkasunich
[16:39:16] <SWPadnos> hi John
[16:39:27] <jmkasunich> morning
[16:39:40] <alex_joni_> alex_joni_ is now known as alex_joni
[16:39:43] <SWPadnos> oh yeah (I was trying to ignore that fact)
[16:39:43] <alex_joni> morning
[16:39:45] <jmkasunich> you guys had quite a talk last night
[16:39:48] <SWPadnos> heh
[16:39:52] <jmkasunich> (w/fenn about servo stuff)
[16:39:57] <SWPadnos> yep
[16:41:05] <SWPadnos> I'm not sure his project will end up being less expensive than off-the-shelf, but at least he'll have fun doing it
[16:41:31] <jmkasunich> yeah, I used to think that way, when I was young and actually had time to do such things
[16:41:47] <SWPadnos> heh - I'm not even counting the value of his time
[16:42:05] <anonimasu> * anonimasu nods
[16:42:10] <SWPadnos> I still think "it should be so easy" from time to time
[16:42:21] <SWPadnos> then I have more coffee, and look for something to buy
[16:44:03] <SWPadnos> we were discussing the save part of linkpp (ie, outputting a signal named for a connected pin as linkpp)
[16:44:09] <anonimasu> the fun factor is always nice
[16:44:11] <jmkasunich> yeah
[16:44:29] <anonimasu> but when you get older and working pays you more then you save when building your own stuff
[16:44:32] <anonimasu> :)
[16:44:42] <jmkasunich> I'm still catching up on mail to see what you guys did last night
[16:45:08] <SWPadnos> and you find new ways to have fun (like going to a beach in the tropics, rather than fiddling with motors in your basement)
[16:45:11] <alex_joni> they actually did something last night?
[16:45:19] <SWPadnos> no - we did nothing
[16:45:28] <anonimasu> SWPadnos: that's when I get really old ^_^
[16:45:37] <alex_joni> * alex_joni is reliefed..
[16:45:44] <SWPadnos> you (alex) and I talked about the issues
[16:45:45] <alex_joni> thought something very bad has happened
[16:45:50] <alex_joni> :)
[16:45:54] <SWPadnos> then tried to figure out the make / link problem
[16:45:55] <alex_joni> SWPadnos: just kidding..
[16:45:56] <jmkasunich> I guess I'm pretty sick - I think I would enjoy fiddling with motors instead of sitting idly on the beach
[16:46:06] <jmkasunich> * jmkasunich doesn't enjoy idleness
[16:46:10] <SWPadnos> you don't have to be idle on the beach :)
[16:46:37] <SWPadnos> and you can always bring some electronice to fiddle with when you get bored
[16:46:43] <SWPadnos> electronics
[16:47:55] <anonimasu> agreed :D
[16:48:09] <Jymmm> jmkasunich: Just make yourself a small robot and paint "BOMB SQUAD" on the side of it and take it to the beach.
[16:48:40] <SWPadnos> then search every corner and crevice
[16:48:48] <SWPadnos> (for bombs, of course)
[16:48:58] <SWPadnos> make sure the camera is high res though
[16:49:23] <jmkasunich> ;-)
[16:50:16] <SWPadnos> so - a default emc.run / emc.ini has a lot of pins exported
[16:50:32] <SWPadnos> like 124 of them
[16:50:49] <alex_joni> cool
[16:50:50] <alex_joni> :D
[16:51:07] <SWPadnos> I'd love to see what the mazak config has :)
[16:51:10] <jmkasunich> thats not a lot - I dunno how many the mazak has, but it is at least twice that
[16:51:18] <SWPadnos> bin/halcmd list pin | sed -e 'y/ /\n/' | wc -l
[16:51:33] <SWPadnos> (sed probably isn't needed there)
[16:51:48] <SWPadnos> yep - it is :)
[16:51:58] <jmkasunich> bin/halcmd list pin | wc -w
[16:52:18] <jmkasunich> list prints only the names
[16:52:22] <SWPadnos> hmmm - maybe it's only 123
[16:52:40] <SWPadnos> there's probably a space after the last one, which got converted to a blank line
[16:52:44] <jmkasunich> also try bin/halcmd status mem
[16:53:26] <SWPadnos> that wlso works ;)
[16:53:28] <SWPadnos> also
[16:54:30] <jmkasunich> hmm, I wonder how close the mazak is to running out of shared memory
[16:54:47] <SWPadnos> heh - I'm at about half with the defaults
[16:55:00] <SWPadnos> (3/8, I guess)
[16:55:01] <jmkasunich> 24892 out of 65500
[16:55:05] <SWPadnos> yep
[16:55:49] <jmkasunich> it would be kinda cool (but mui dangerous) to be able to ssh into the mazak ;-)
[16:55:58] <jmkasunich> make it easy to check things like this
[16:55:59] <anonimasu> haha
[16:56:16] <SWPadnos> heh - as long as the external estop is on, it might be OK :)
[16:56:37] <jmkasunich> better yet leave the main 240V 3phase power breaker off
[16:56:51] <SWPadnos> that would also suffice
[16:57:11] <jmkasunich> (eventually that will also power the PC, but currently the PC is separately powered)
[16:58:22] <SWPadnos> hmmm - the main 240 should probably be killed in an estop, and you wouldn't necessarily want the PC to die as well
[16:58:39] <jmkasunich> we don't kill the 240 on estop
[16:58:41] <SWPadnos> depends on brakes and the like, though
[16:59:04] <alex_joni> * alex_joni kills everybody on estop
[16:59:06] <jmkasunich> the 240 feeds a control power transformer, with 3 independent 120V secondaries
[16:59:12] <rayh> 31072 used here on step_cl the way I've got it now.
[16:59:36] <alex_joni> 65k is pretty ok (not much)
[16:59:42] <SWPadnos> interesting - 8k of shmem for cl
[17:00:00] <SWPadnos> what other modules are you using that aren't in the default ini/hal files?
[17:00:08] <jmkasunich> right now, one feeds the PC, one feeds a 24V supply, and the third feeds all other 120V loads (like contactor coils for the motor starters, solenoid valves, etc)
[17:00:19] <jmkasunich> estop kills that third 120V winding
[17:00:46] <SWPadnos> ah - ok. the second is used for brakes
[17:00:54] <SWPadnos> (24V, right?)
[17:00:55] <jmkasunich> the reason for 65500 is that I thought at some point that shmem blocks over 64K could cause problems
[17:00:59] <rayh> We could easily argue "proper" estop till the cows come home.
[17:01:04] <SWPadnos> no
[17:01:06] <SWPadnos> thanks
[17:01:11] <SWPadnos> ;)
[17:01:16] <jmkasunich> the only brakes are on Z screw and head lift/lower
[17:01:30] <jmkasunich> both are spring applied, electrical release
[17:01:32] <SWPadnos> right - where things might fall if not "clamped"
[17:01:49] <rayh> alex_joni: Did your "left brain" come to any conclusions?
[17:02:05] <alex_joni> no, but my right one did ;)
[17:03:07] <alex_joni> so I'll be able to share that part soon too
[17:03:23] <rayh> jmkasunich: When the Mazak got warmed up, the quill would drop enough to cause a following error between power off and the brake grabbing.
[17:03:59] <alex_joni> right, we talked about that back then..
[17:04:08] <SWPadnos> the brake and motor enavles go through CL, right?
[17:04:10] <alex_joni> I suggested a timer for amp-off
[17:04:13] <SWPadnos> enables
[17:04:23] <SWPadnos> hey - I was going to say that :)
[17:04:33] <alex_joni> the signal from emc goes directly to brake, but through a timer to amp-off
[17:05:11] <rayh> I think that is the spindle on off rather than quill brake.
[17:05:42] <rayh> IMO what we needed was a cl off delay timer on the z enable.
[17:05:58] <alex_joni> that's what I was saying..
[17:06:08] <rayh> oh okay.
[17:06:25] <alex_joni> talking about z-axis, although that probably wasn't fully clear
[17:06:28] <rayh> only problem with that has to do with what else pulls the enables.
[17:06:59] <rayh> btw got homes, limits, and lube level hooked up to step_cl here.
[17:07:16] <jmkasunich> where is here?
[17:07:23] <alex_joni> his machine
[17:07:28] <rayh> my basement
[17:07:37] <alex_joni> his machine in his basement
[17:07:41] <alex_joni> *grin*
[17:07:46] <SWPadnos> Crystal Falls, MI
[17:07:47] <alex_joni> ok.. back to iocontrol
[17:07:58] <jmkasunich> I didn't know you had a big mill (I know you have big lathes)
[17:08:01] <alex_joni> jmkasunich: care to talk about that?
[17:08:15] <jmkasunich> I'll talk about anything ;-)
[17:08:40] <alex_joni> ok.. little red ridinghood
[17:08:53] <SWPadnos> big bad wolf
[17:08:59] <rayh> iocontrol?
[17:09:01] <alex_joni> kidding.. ok, iocontrol
[17:09:06] <jmkasunich> lol
[17:09:18] <alex_joni> we have some commands from GUI (like lube, coolant, etc)
[17:09:26] <alex_joni> those all go to iocontrol eventually
[17:09:30] <jmkasunich> yep
[17:09:34] <alex_joni> and iocontrol sets some hal pins accordingly
[17:09:42] <alex_joni> now the problem is feedback..
[17:09:49] <alex_joni> or status ..
[17:10:00] <alex_joni> I see 2 possibilities
[17:10:18] <alex_joni> before I talk about those, some background ;)
[17:10:22] <alex_joni> you get this for free today ..
[17:10:26] <jmkasunich> ok
[17:10:33] <alex_joni> iocontrol talks to task through emcStatus
[17:10:37] <alex_joni> but I guess you know that
[17:10:47] <alex_joni> that means, task sends a command, and iocontrol ack's it
[17:10:55] <alex_joni> and in the Ack it includes the current status
[17:11:17] <alex_joni> task looks at that status, also GUI looks at that status to decide button names, etc
[17:11:29] <alex_joni> now the problem/issue
[17:11:49] <alex_joni> if anything changes to the status, it will be visible to task or gui only on the next handshake
[17:12:09] <jmkasunich> question:
[17:12:09] <alex_joni> that is bad.. but there are 3 ways around that
[17:12:13] <alex_joni> ok.. shoot
[17:12:44] <jmkasunich> in the picture I've seen of the overall setup, there is one set of NML buffers (cmd,stat,err) between GUI and task, and another between task and IO
[17:12:48] <jmkasunich> is that true?
[17:13:04] <alex_joni> no cmd between iocontrol and task
[17:13:05] <jmkasunich> if so, then GUI can't directly read stat as written by IO, task has to pass it along
[17:13:17] <alex_joni> on the stat stuff you are correct
[17:13:33] <alex_joni> task does the message handling
[17:13:40] <alex_joni> the pass on..
[17:14:05] <jmkasunich> * jmkasunich is looking for the pic
[17:16:06] <jmkasunich> http://home.att.net/~jmkasunich/EMC_Docs/EMC_Control_SM.gif
[17:16:34] <jmkasunich> according to that, cmds from GUI to IO go thru task as wekk
[17:16:36] <jmkasunich> well
[17:16:39] <jmkasunich> is that true?
[17:16:41] <alex_joni> yes
[17:16:46] <alex_joni> both directions
[17:16:50] <alex_joni> go through task
[17:16:57] <alex_joni> that picture is still accurate
[17:17:12] <jmkasunich> ok
[17:17:31] <alex_joni> no back to the 3 ways of sending data from iocontrol to task
[17:17:36] <alex_joni> now back to the 3 ways of sending data from iocontrol to task
[17:17:56] <jmkasunich> iocontrol is in a polling loop waiting for either a cmd message from task or a change to a HAL pin, right?
[17:18:11] <alex_joni> 1. push it (like I did for estop), that uses a different message number
[17:18:31] <jmkasunich> and GUI is in a polling loop waiting for either user input or a change in NML status?
[17:18:53] <alex_joni> 2. when the initial command has been received, ack it with RCS_EXEC, then after the hal pin settled send the final RCS_DONE
[17:19:34] <alex_joni> 3. make the data exchange between task and iocontrol periodical (then we won't mind what gets sent, on the next message it will be corrected)
[17:19:42] <alex_joni> ok.. now to your questions:
[17:19:55] <alex_joni> iocontrol is currently waiting for a NML command
[17:20:22] <alex_joni> if the command is received it should send back a RCS_EXEC, and when it finished doing that send a RCS_DONE
[17:20:30] <alex_joni> that's the case for toolchanging
[17:20:36] <jmkasunich> EXEC and DONE are NML messages?
[17:20:51] <alex_joni> no, they are states in the status message
[17:21:06] <alex_joni> telling the state of the subordinate
[17:21:07] <jmkasunich> ok
[17:21:08] <rayh> Exec must correspond to emc_wait_received
[17:21:22] <alex_joni> task is the master and iocontrol is the slave
[17:21:24] <jmkasunich> that means they apply to the previous command
[17:21:27] <alex_joni> rayh: probably yes..
[17:21:30] <rayh> and dome must corrempond to emc_wait_done
[17:21:38] <jmkasunich> and no new command can be issued until DONE comes back
[17:21:48] <alex_joni> jmkasunich: yes, but you need to remember the command number, and furtheon send the RCS_DONE to the same command nr.
[17:22:08] <alex_joni> they shouldn't be issued..
[17:22:20] <alex_joni> if GUI issues a new command, task is holding it back
[17:22:30] <alex_joni> until RCS_DONE is received, then sends it.
[17:22:45] <alex_joni> but the whole thing is prioritized
[17:23:00] <alex_joni> so certain messages get sent, even if iocontrol is in RCS_EXEC
[17:23:11] <alex_joni> for instance change between MDI/Manual/Auto
[17:23:28] <alex_joni> so it's very easy to lose track of what's going on :/
[17:23:31] <jmkasunich> so iocontrol needs to be prepared to get a new command even if it is still executing the previous one
[17:23:33] <SWPadnos> so you can change to MDI in the middle of a toolchange?
[17:23:55] <alex_joni> SWPadnos: yes, but that sends an IO_ABORT iirc
[17:24:03] <rayh> through emcsh you can ask for either reaction for idivon an individual
[17:24:29] <SWPadnos> idivon?
[17:24:39] <rayh> and that reaction can be applied to individual commands or to all commands.
[17:24:43] <rayh> sorry.
[17:25:33] <SWPadnos> (sorry - I couldn't parse that - this isn't my area of expertise)
[17:25:54] <rayh> I don't see any way around making iocontrol multitasking.
[17:25:58] <jmkasunich> I'm a little confused by the status messages
[17:26:12] <alex_joni> jmkasunich: read some more, then you'll be even more confused
[17:26:21] <alex_joni> ok.. I wouldn't chose way 1
[17:26:24] <jmkasunich> command messages are about one thing, and contain only a limited amount of info
[17:26:29] <alex_joni> err 2
[17:26:46] <jmkasunich> status messages contain a fairly complete snapshot of a large chunk of stuff, right?
[17:27:03] <SWPadnos> but they arrive at semi-random times
[17:27:35] <SWPadnos> ie, whenever some subordinate decides to send a status message, not on a set schedule
[17:27:45] <jmkasunich> IOW, you have a command "change tool", but you don't have a reply "tool changed", you just get a status snapshot, and one of the things in that snapshot shows you that the tool is changed
[17:27:56] <jmkasunich> (or not changed)
[17:28:08] <alex_joni> jmkasunich: yes
[17:28:17] <jmkasunich> later you send "start mist" and you get another snapshot of the same stuff
[17:28:23] <alex_joni> but not 100%
[17:28:35] <alex_joni> the reply contains a main state information
[17:28:50] <alex_joni> so iocontrol is either RCS_DONE (the command has been accomplished)
[17:28:57] <alex_joni> or RCS_EXEC (still working on it)
[17:29:13] <jmkasunich> tagged with the command number
[17:29:15] <alex_joni> so task decides what to do next based on the state and status
[17:29:17] <alex_joni> yes
[17:30:07] <jmkasunich> if you send "change tool (cmd #1) and get "EXEC #1", then send "start mist (cmd #2)", without waiting for "DONE #1", what happens?
[17:30:29] <alex_joni> you beeing GUI ?
[17:30:33] <jmkasunich> task
[17:30:40] <alex_joni> task doesn't do that
[17:30:57] <jmkasunich> because if it did it would break iocontrol?
[17:30:58] <alex_joni> it has further logic in it not to do that
[17:31:04] <alex_joni> probably yes
[17:31:19] <jmkasunich> IOW we are relying on task not to ask IO to do two things at once
[17:31:44] <alex_joni> I think so..
[17:31:46] <rayh> rayh points a finger at "further logic"
[17:32:04] <alex_joni> * alex_joni points a M16 at "further logic"
[17:32:11] <jmkasunich> * jmkasunich is with alex
[17:32:43] <rayh> Somehow we've got to get run time control of further logic.
[17:32:45] <alex_joni> this is very undocumented :(
[17:32:46] <jmkasunich> seems like IO should handle that - maybe reply "sorry, busy" when task asks it to do something before the previous one is finished
[17:32:59] <alex_joni> yes.. you can do that
[17:33:11] <alex_joni> simply send RCS_ERR.. fsck off ;)
[17:33:31] <rayh> Only if there is some need not to initiate a second when the one before is still in progress.
[17:33:44] <jmkasunich> but it's not an "error" as in "you can't do that", its more like "try again later"
[17:33:52] <SWPadnos> that's got to be configurable somehow
[17:34:05] <alex_joni> SWPadnos: it is very configurable
[17:34:06] <jmkasunich> rayh: exactly, which is why the decision should be made in IO, not task
[17:34:33] <alex_joni> only you need: 1). lots of programming experience, 2). lots of indepth information of how it works, 3).time to rework task
[17:34:53] <SWPadnos> ok - end-user configurable ;)
[17:34:53] <rayh> If that were the case we would not need a task controller except to interpret a few canonical commands from interp.
[17:35:18] <alex_joni> this leads to some major rework
[17:35:32] <alex_joni> probably more than what jmk did on motion..
[17:35:44] <alex_joni> lots more..
[17:35:48] <jmkasunich> nasty
[17:35:53] <rayh> If all of the raw commands were passed to hal and cl,
[17:35:54] <alex_joni> yes indeed
[17:36:04] <jmkasunich> gotta step away for a couple mins, I'll be back
[17:36:12] <alex_joni> then you wouldn't need the raw commands anymore :/
[17:36:15] <rayh> it would be possible to reproduce most of the task functionality there.
[17:37:05] <rayh> We spoke about loopback a bit ago. The ack of a command.
[17:37:23] <SWPadnos> so - can we discuss the concept of task vs. io vs. motion?
[17:37:42] <rayh> I have to do this now with estop.
[17:37:43] <SWPadnos> and whether it's still a necessary separation
[17:38:21] <rayh> The way it is written, estop wakes up in reset
[17:38:25] <alex_joni> http://www2.b3ta.com/merrychristmas/
[17:38:47] <rayh> you can move from there to machine on but not from there to estop.
[17:39:00] <rayh> unless there is a loopback in hal or cl.
[17:41:26] <rayh> Hi tom
[17:41:49] <tomp> Hi Ray, Hi All
[17:41:49] <alex_joni> jmkasunich: when you get back lets talk about estop a bit
[17:41:53] <alex_joni> hello Timbo
[17:41:56] <alex_joni> darn tab
[17:42:00] <alex_joni> hello tomp
[17:42:08] <tomp> Hi Alex
[17:42:33] <rayh> darn PC ought to know what we mean.
[17:42:54] <alex_joni> yes.. wth do we need a keyboard for?
[17:43:01] <alex_joni> * alex_joni thinks a lot faster than he types
[17:43:12] <rayh> Right.
[17:43:15] <alex_joni> at least I assume that..
[17:43:40] <tomp> read last nite a bit about pre&post conditions. the idea is in the code already.
[17:43:53] <Timbo> alex_joni: hi ;)
[17:43:53] <alex_joni> yes it is, but hardcoded
[17:44:13] <alex_joni> Timbo: nice to see you joining the conversation ;)
[17:44:55] <tomp> yaeh, but read(fp, var) could be hacked in, and a file format for the parms agreed on.
[17:45:23] <alex_joni> tomp: we were just discussing ripping task apart
[17:45:29] <alex_joni> and redoing it completely
[17:45:35] <tomp> ok, quiet mode
[17:45:45] <alex_joni> nah.. feel free to add your 2cents
[17:46:42] <alex_joni> the thing is nowadays all of emc is done starting from some assumptions
[17:46:47] <alex_joni> 1. gcode
[17:46:49] <alex_joni> 2. milling
[17:47:00] <alex_joni> 3. certain machine specific pre/post conditions
[17:47:12] <alex_joni> 4. certain order in actions..
[17:47:37] <SWPadnos> out of curiosity, what the heck do "postconditions" do for us (software-wise)
[17:47:51] <SWPadnos> most of them were stubbed out, IIRC
[17:47:52] <alex_joni> start some actions
[17:48:14] <rayh> I tend to think of task as getting a stack of cards
[17:48:26] <rayh> when it encounters a card that requires IO
[17:48:27] <jmkasunich> * jmkasunich is back
[17:48:39] <alex_joni> jmkasunich: lets talk a bit about estop
[17:48:46] <SWPadnos> uh-oh
[17:48:50] <rayh> it looks at the specific command, and adds cards before and after.
[17:48:56] <jmkasunich> let ray finish about cards, I think I like where he's going
[17:49:20] <rayh> the before are preconditions the after postconditions.
[17:49:44] <rayh> for a tool change, it add in tool prep
[17:50:01] <alex_joni> rayh: if needed..
[17:50:04] <SWPadnos> I guess I'm looking for an example of where postconditions are used, and they can't be replaced by what you like to call "machine logic"
[17:50:06] <rayh> for a tool change it adds in move to tool change and such as pre
[17:50:17] <alex_joni> SWPadnos: it all is machine logic..
[17:50:22] <SWPadnos> and back to wherever it was as a post - OK
[17:50:22] <jmkasunich> one idea that was mentioned at Fest (and Fred agreed with) was that instead of the interp queueing only the action "card", and requiring task to decide if it has pre or post conds, that the pre and post "cards" should be in the queue as well
[17:50:29] <rayh> Both pre and post are machine logic IMO
[17:50:38] <SWPadnos> ok - that's what I thought
[17:50:57] <alex_joni> so basicly.. we have GUI sending some actions
[17:51:11] <jmkasunich> to task - not directly to IO
[17:51:11] <alex_joni> based on those someone decides what to do before, during and after
[17:51:12] <SWPadnos> "conditions" is a bad name, "actions" might be better (though the actions set up conditions for further things to happen)
[17:51:32] <alex_joni> likewise how to wait for done
[17:51:35] <jmkasunich> well today they are also conditions
[17:52:02] <SWPadnos> ok - this implies that we need a "tristate" hal pin mode
[17:52:10] <jmkasunich> task reads thru the queue, normal actions are issued immediately, even if prior ones haven't been finished (that's how you get multiple motions on the motion queue)
[17:52:27] <jmkasunich> but if task sees a pre or post, it stops issuing until all prior ones are finished
[17:52:42] <jmkasunich> SWP: I wouldn't go that far
[17:52:56] <jmkasunich> you can have request and response pins - two wire handshaking
[17:52:56] <SWPadnos> heh - it does take a couple of steps in the logic chain :)
[17:53:27] <jmkasunich> or a single tri-state pin, request sets it, response clears it - one wire hand shaking
[17:53:28] <SWPadnos> but you have many things that may require gui or task or io to pause, and another group that doesn't.
[17:53:31] <jmkasunich> that is a HAL issue
[17:53:53] <SWPadnos> state from any of the group that need "exclusive" use would all be sent to an "inhibit further commands" pin
[17:53:58] <jmkasunich> (two or one wire handshaking is a HAL issue, I mean)
[17:54:04] <SWPadnos> yes
[17:54:24] <SWPadnos> tristate as in multiple "outputs" driving a single input
[17:54:33] <jmkasunich> ah
[17:54:35] <SWPadnos> this can be accomplished with AND or OR as well
[17:54:49] <alex_joni> jmkasunich: how would you feel if we had something like HAL
[17:54:51] <alex_joni> called SAL ;)
[17:54:53] <SWPadnos> we do ;)
[17:54:58] <SWPadnos> MAL
[17:55:02] <alex_joni> MAL?
[17:55:09] <rayh> tristate is going to confuse the .... outa me.
[17:55:11] <jmkasunich> what does the S (or M) stand for
[17:55:14] <SWPadnos> Machine Abstraction Library (and mean :) )
[17:55:17] <alex_joni> s=software
[17:55:19] <jmkasunich> I agree with way about tristate
[17:55:27] <jmkasunich> I agree with ry about tristate ;-)
[17:55:29] <jmkasunich> dammit
[17:55:33] <SWPadnos> OK elmer ;)
[17:55:33] <tomp> sounds more like a jk flip flop, with set reset and clock, not tristate (on off float/ignore)
[17:55:38] <alex_joni> ok.. you agree with ray
[17:55:40] <jmkasunich> I agree with ray about tristate ;-)
[17:55:44] <jmkasunich> lol
[17:55:54] <alex_joni> how about a jmk flip flop?
[17:56:02] <alex_joni> ;-)
[17:56:11] <alex_joni> ok. back to SAL/MAL
[17:56:18] <alex_joni> hmm.. maybe SMAL
[17:56:20] <SWPadnos> SAL has been touched upon as far back as Fest, at least
[17:56:35] <jmkasunich> if multiple sources want to inhibit something, that is a job for AND (or the ladder equivalent, contacts in series)
[17:56:40] <alex_joni> Software Machine Abstraction Language
[17:56:46] <alex_joni> but what I want to get at..
[17:56:55] <SWPadnos> SMALL - Software / Machine Abstraction Linking Language :)
[17:56:59] <alex_joni> have gui export some paths (not necessarely pins)
[17:57:09] <alex_joni> same for task and io
[17:57:20] <alex_joni> and you would be able to link those, just like with HAL
[17:57:28] <SWPadnos> sounds a bit like NML
[17:57:32] <alex_joni> * alex_joni isn't clear what/how that helps
[17:57:47] <jmkasunich> neither is /me
[17:58:12] <SWPadnos> well - look at the GUI problem this way
[17:58:17] <alex_joni> but it would be nice/usefull to have different stuff coming from GUI
[17:58:21] <alex_joni> based on what machine you are controlling
[17:58:22] <rayh> I do tend to favor something related to task that handles configurable pre and post conditions
[17:58:31] <alex_joni> same on task and io
[17:58:43] <SWPadnos> there are a bunch of controls, and each essentially presents a command (or set of commands) to the user.
[17:58:50] <alex_joni> rayh: if it's configurable like HAL you might even put a CL between them
[17:58:56] <alex_joni> and let CL take care of the logic..
[17:59:14] <rayh> If we can run cl at that level at the same time we do it in rt.
[17:59:31] <alex_joni> maybe a different cl would be best
[17:59:36] <alex_joni> not to mix the two
[17:59:41] <rayh> At NIST we had a page where logic was indicated by circles all over the page.
[17:59:43] <alex_joni> it doesn't need to be RT
[17:59:59] <rayh> Right.
[18:00:02] <SWPadnos> doesn't need to be, but may be
[18:00:18] <SWPadnos> (ie, you can have extra rungs in the RT section that do this stuff)
[18:00:19] <rayh> My only need for cl in rt is for stuff like limits, homes, probes and such.
[18:00:41] <jmkasunich> and estop related things
[18:00:59] <SWPadnos> or stop, depending on how you look at it ;)
[18:01:02] <rayh> SWPadnos: prefers to call those things stop rather than estop but yes.
[18:01:14] <rayh> let
[18:01:25] <jmkasunich> CL has something called sections - not well documented, but I think it means separate ladders that can run at different rates
[18:01:35] <rayh> s not get ourselves sidetracked with the semantics
[18:01:41] <SWPadnos> one quick clarification on estop, then I can be done with it :)
[18:01:50] <SWPadnos> (or not, if you prefer)
[18:01:51] <rayh> NO
[18:01:59] <SWPadnos> ok, I guess you prefer ;)
[18:02:48] <rayh> estop carries with it such a load of baggage that varries from person to person and app to app and country to country that we can bog down in that bog.
[18:03:10] <SWPadnos> ok - let's keep that one in reserve for some other time
[18:03:12] <rayh> Having said that SWPadnos say what you need to say. I did
[18:03:16] <jmkasunich> all the more reason to let the machine builder defines what it does
[18:03:20] <SWPadnos> heh - thanks
[18:03:44] <SWPadnos> the clarification I wanted to make is that there are actually 3 different things done by estop in emc:
[18:03:48] <SWPadnos> 1) prevent start
[18:03:53] <SWPadnos> 2) allow run
[18:03:55] <SWPadnos> 3) stop
[18:04:26] <SWPadnos> none of those are "emergency related", except possibly stop
[18:04:46] <SWPadnos> ie, there is no emergency if you haven't allowed the machine to start yet
[18:04:49] <rayh> If you look at the tristate in the emc that is related to stop
[18:05:07] <Jymmm> * Jymmm taps SWPadnos on the shoulder...
[18:05:08] <rayh> it is stopped, ready, run
[18:05:11] <SWPadnos> (3 should have been "request stop"
[18:05:14] <SWPadnos> )
[18:05:43] <rayh> Thank you alex for pointing out the tristate.
[18:05:53] <jmkasunich> a very strongly worded request - IOW one that must never be ignored or delayed
[18:06:34] <Jymmm> jmkasunich IOW ?
[18:06:37] <SWPadnos> but in a real emergency, the machine should already be off (or stopping) reagrdless of whether emc has noticed that yet
[18:06:42] <jmkasunich> in other words
[18:06:43] <SWPadnos> in other words
[18:06:44] <rayh> Hell for me, that output pin of the emc-pc pulls a dry contact in the estop chain.
[18:07:00] <Jymmm> SWPadnos: What in the case of a malfunction
[18:07:02] <rayh> period, no need for further discussion concerning the way I'd use it.
[18:07:32] <SWPadnos> anyway - that's enough estop soapbox for one day. we can go on to other important things.
[18:07:41] <jmkasunich> the request can come from many places - external, GUI, etc
[18:07:50] <rayh> If emc doesn't pull it then the machine aint gonna get outa estop.
[18:08:04] <jmkasunich> one last thing about estop, more of a food for thought: http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl/emcinfo.pl?RunLevels
[18:08:05] <SWPadnos> it's not a request from the estop chain, it's a COMMAND!!!
[18:08:17] <SWPadnos> it's only a request from software-based systems
[18:08:40] <rayh> its a Normall open dry contact to an outside system
[18:08:43] <rayh> damnit5
[18:08:45] <alex_joni> SWPadnos: that's semantics ;) but yes
[18:08:45] <jmkasunich> why is it only a req from there? if I hit the estop button on the GUI screen, that is every bit as critical
[18:09:02] <SWPadnos> but not anywhere near as dependable as a big red switch
[18:09:07] <jmkasunich> right
[18:09:13] <alex_joni> jmkasunich: now that you mention it I remember why SMAL..
[18:09:16] <SWPadnos> hence, not "E" stop
[18:09:22] <rayh> Okay past how it's done and how it's named, we have some real serious issues with what happens inside the emc
[18:09:31] <alex_joni> that should imho cover the build of an hardware GUI
[18:09:33] <SWPadnos> yes - I'm happy to go on
[18:09:34] <alex_joni> buttons, etc
[18:10:07] <tomp> isnt most ( maybe all of ) the 'real-time' in estop is done in hardware? isnt that the basis of international machine safety codes?
[18:10:10] <Jymmm> Ok, I really dont mean to be a smartass here... but instead of ESTOP (being EMERGENCY STOP), can all this be renamed to maybe FSTOP (Frantic Stop) or something. I *REALLY* hate the term 'EMERGENCY' being used like it has.
[18:10:27] <rayh> SWPadnos: is not going to be content with anything that we call emergency stop inside the pc, the hal, the cl.
[18:10:31] <alex_joni> tomp: yes it is, but we are talking about the emc part of it
[18:10:35] <SWPadnos> (damn - worms, meet open air)
[18:10:37] <jmkasunich> Jymmm: you are trying to reverse years of usage
[18:10:42] <tomp> the importrant (life threatening) stuff has to be done in hdwr, and the rest is... nice for us, not so critical.
[18:10:43] <alex_joni> the machine NEEDS to have a proper ESTOP outside
[18:10:52] <alex_joni> but emc should also interact with that hardware
[18:11:05] <SWPadnos> pandora - here's a nice box ;)
[18:11:07] <Jymmm> jmkasunich: Gotta start somewhere, just becasue someone fubarred years ago is nto my fault.
[18:11:07] <rayh> So it really matters not how we connect estop like buttons to cl they are not "real"estop.
[18:11:12] <alex_joni> have an relay in the estop chain.. so it can stop the hardware just like a estop button would
[18:11:18] <rayh> so lets get to the internal emc issues.
[18:11:34] <alex_joni> likewise estop should be sensed by the external estop so that it can stop internally
[18:11:46] <rayh> That issue is how emc handles those signals.
[18:11:54] <alex_joni> yes
[18:12:05] <SWPadnos> internally, regarding estop (or stop), there needs to be an inhibit input, and a stop request output
[18:12:06] <jmkasunich> two things: 1) EMC (the GUI really) needs to be able to initiate an emergency stop, just like any other external source, and 2) EMC needs to know about an emergency stop, regardless of where it was initiated, so that it can prepare to restart cleanly
[18:12:39] <rayh> I'm okay with that description jmkasunich
[18:12:59] <alex_joni> same here
[18:13:01] <jmkasunich> maybe part of our problem is that we mix 1 and 2 together too much
[18:13:14] <SWPadnos> I don't call a GUI button estop, because it's not fail-safe. ie, if the mouse cable gets unplugged, there will be no stop command
[18:13:14] <rayh> SWPadnos: would be okay with it if you left the estop out of the first.
[18:13:31] <rayh> We hear you swp
[18:13:42] <SWPadnos> (sorry -I was trying to whisper :) )
[18:13:46] <rayh> and we understand your concern for the safety of the end user
[18:14:00] <rayh> but we must go into the emcs understanding of the problem
[18:14:05] <SWPadnos> nah - they can kill themselves if they want
[18:14:51] <jmkasunich> even if you don't have an Estop button on the GUI, EMC still needs to be able to initiate an emergency stop
[18:14:54] <rayh> What should happen when jmk'1 presents itself
[18:15:07] <jmkasunich> suppose somebody hits ctrl-C and kills the GUI
[18:15:12] <jmkasunich> I'd like the machine to stop
[18:15:20] <SWPadnos> as far as EMC is concerned, an inhibit input, possibly a ready input (may not need to be separate, but probably useful if it is), and a machine stop output are needed - anything else necessary?
[18:15:28] <rayh> I press the button on the gui that connnects to that signal
[18:15:58] <rayh> It is called estop in the emc -- sorry swp we aint gonna change that today
[18:16:11] <SWPadnos> no problem - let's move on to important stuff
[18:16:26] <rayh> okay we press an emc-stop
[18:16:41] <jmkasunich> if all sources of estop are maintained contacts, it is pretty simple
[18:16:52] <rayh> where does it go and how does it get akwed
[18:16:57] <SWPadnos> and I guess those 3 inputs are now estop-in and estop-out, and ready is !estop-in
[18:17:30] <jmkasunich> but if some are momentary, then there needs to be a latching action somewhere, and thus a way to reset the latch before you start
[18:17:53] <rayh> don't think in terms of the kind of contact being made
[18:18:08] <rayh> think now in terms of the signal being sent and received
[18:18:09] <SWPadnos> OK - you have an estop latch component (which could just be a generic latch, attached to estop)
[18:18:18] <jmkasunich> I absolutely hate names like estop-in and estop-out
[18:18:24] <jmkasunich> because their sense isn't clear
[18:18:26] <rayh> Right.
[18:18:56] <SWPadnos> we had discussed renaming to "request" and "status" or something like that
[18:19:16] <rayh> let me for a moment describe the problem as I see it in the HAL and CL now
[18:19:24] <jmkasunich> * jmkasunich shuts up
[18:19:28] <SWPadnos> in general, the name "in" or "out" only makes sense for a hardware driver that connects directly to a pkysical input or output
[18:19:34] <SWPadnos> physical
[18:19:44] <rayh> there are three pins in iocontrol related to this
[18:20:28] <rayh> estop in and estop out must be looped back one for one or emc starts and remains in reset rather than stopped
[18:20:51] <jmkasunich> what state is "reset"?
[18:21:01] <rayh> estop off
[18:21:17] <SWPadnos> "no internal or external estop request"
[18:21:19] <jmkasunich> IOW the most "safe" state?
[18:21:19] <rayh> no stopped condition -- ready for a machine on
[18:21:36] <jmkasunich> ok, the 2nd most safe state
[18:21:42] <rayh> No the most safe state would be for emc to be estopped.
[18:21:48] <jmkasunich> right
[18:21:52] <SWPadnos> right - "prevent start" would be the most safe
[18:22:12] <rayh> Right now I or that loopback in hal with a cl coil
[18:22:24] <jmkasunich> ok, for this discussion can I suggest some names: "estopped", "ready", "running"
[18:22:26] <rayh> that is pulled by an external estop pin
[18:22:59] <alex_joni> jmkasunich: sounds ok...
[18:23:30] <rayh> when I pull that external pin low, the display says estop.
[18:23:49] <rayh> but the iocontrol pin that shows estop state does not come on.
[18:24:11] <rayh> so as soon as I release my external button emc switches to ready
[18:24:23] <jmkasunich> right - because you didn't request an estop from within emc
[18:24:42] <rayh> I would prefer to be able to set that internal pin any way I please.
[18:25:11] <jmkasunich> from where? CL? GUI?
[18:25:19] <SWPadnos> that would need to be hardcoded, I think
[18:25:21] <rayh> Cl would be great.
[18:25:31] <jmkasunich> I don't understand you
[18:25:32] <SWPadnos> given the current pins available
[18:26:12] <SWPadnos> right now, the terms estop-in and out have a special meaning to the humans that read them, but they have different meanings to IOControl
[18:26:13] <jmkasunich> estop-out from iocontrol says "EMC is asserting an estop, you cannot run", or "EMC is happy, you can run"
[18:26:17] <rayh> the iocontrol.0.emc-reset pin doesn't do anything unless you are running your hal estop module
[18:27:03] <SWPadnos> ray - you have to look at the estop out pin as the state of emc's internal estop request
[18:27:03] <rayh> You aren't hearing me, as soon as I release the iocontrol.0.emc-in pin
[18:27:17] <jmkasunich> estop-in to iocontrol says "someone (internal or external) has asserted an estop, EMC should stop everything (some things will be stopped in HW, some in SW)"
[18:27:18] <rayh> I immediately get a estop reset.
[18:27:20] <SWPadnos> not whether it's in stop mode or inhibited motion
[18:27:59] <rayh> I would like to be able to press the external contact and have emc respond with an "I'm estopped.
[18:28:28] <SWPadnos> that would be soem combination of motion.enable and possibly other stuff right now
[18:28:33] <jmkasunich> yes - that is what the estop-in pin is supposed to be for
[18:28:57] <jmkasunich> * jmkasunich 's head hurts
[18:28:59] <SWPadnos> what would have to be hardcoded is that emc should request an estop whenever it receives an estop request
[18:29:18] <SWPadnos> (ie, if an estop is received, prevent start until told not to)
[18:29:39] <rayh> We have some logic in iocontrol that says when estop-in is 0 we are estopped
[18:29:47] <rayh> and when it is 1 we have reset
[18:30:02] <jmkasunich> yes
[18:30:07] <RonB> * RonB thinks about the ignorant individuals working around the estop... as will be done anyway
[18:30:31] <alex_joni> jmkasunich: can I try to explain this to you?
[18:30:39] <alex_joni> I already went through this with rayh
[18:30:39] <jmkasunich> shoot
[18:30:45] <alex_joni> 1. set ESTOP from emc
[18:30:57] <alex_joni> estop-out activates
[18:30:57] <jmkasunich> * jmkasunich is looking at iocontrol code to try to understand it
[18:31:07] <jmkasunich> stop, backup
[18:31:09] <SWPadnos> step away from the code
[18:31:14] <jmkasunich> "set estop from EMC"
[18:31:21] <alex_joni> ok. whatever..
[18:31:27] <SWPadnos> user presses button on GUI
[18:31:30] <jmkasunich> does that mean emc is requesting an estop, or responding to an external one
[18:31:30] <alex_joni> machine is estoped
[18:31:33] <jmkasunich> ok, requesting
[18:31:36] <alex_joni> requesting
[18:31:45] <alex_joni> now.. machine is estopped
[18:31:51] <rayh> phone brb
[18:31:57] <alex_joni> next an external estop is received
[18:32:09] <alex_joni> emc doesn't need to do anything..
[18:32:17] <alex_joni> because it already is in ESTOP condition
[18:32:23] <alex_joni> next external estop goes away..
[18:32:27] <jmkasunich> EMC doesn't even see it, since it is in series with emcs estop out that is already off
[18:32:38] <jmkasunich> ditto, emc doesn't even see it
[18:32:41] <alex_joni> emc automatically goes to estop_reset
[18:32:48] <jmkasunich> why?
[18:32:51] <alex_joni> that's what's happening now
[18:32:56] <jmkasunich> then it's busted
[18:32:57] <alex_joni> don't know why.. you did that
[18:32:58] <alex_joni> :P
[18:32:58] <jmkasunich> ;-)
[18:33:08] <jmkasunich> the I did it wrong
[18:33:09] <alex_joni> try removing the loopback
[18:33:19] <alex_joni> and run it like that
[18:33:32] <alex_joni> the estop-in will dictate how emc's internal state is
[18:33:37] <alex_joni> no matter of estop-out
[18:33:37] <jmkasunich> removing the loopback will probably result in a machine that can't be stopped
[18:33:42] <alex_joni> yes
[18:33:58] <jmkasunich> that is only because of the fscked up meaning of the word "estop"
[18:34:03] <SWPadnos> :)
[18:34:13] <jmkasunich> IMO, the signals should be enable out and enable in
[18:34:27] <SWPadnos> and disabled out
[18:34:30] <jmkasunich> enablein must be true to run, if it goes false everything stops
[18:35:00] <jmkasunich> enable-out means "emc's red mushroom switch (implemented in the GUI) is pulled out"
[18:35:15] <jmkasunich> connect them with a simple loopback, you have a basic machine
[18:35:38] <SWPadnos> and disabled-out means "emc is not doing anything with the machine"
[18:35:38] <jmkasunich> connect them with other real red mushrooms (thru CL) and you have a real estop (should be called enable) chain
[18:36:15] <SWPadnos> so disabled-out would be the output that Ray wants to monitor to set the correct color for the stop button on the GUI
[18:36:19] <jmkasunich> enable-out TRUE = GUI's mushroom switch is pulled out, enable-out = FALSE means somebody hit the GUI's pannic button
[18:36:21] <alex_joni> on my robots there are 2 distinctive chains
[18:36:36] <alex_joni> 1 = estop (lots of mushrooms, and other safety stuff like air pressure)
[18:36:38] <jmkasunich> the IN is the one that is monitored for setting the overall state
[18:36:44] <alex_joni> 2 = power on/off
[18:37:02] <alex_joni> power on/off is commanded by user and results in turning on a big relay
[18:37:18] <alex_joni> under PC logic
[18:37:22] <SWPadnos> stop and enable are distinct items
[18:37:31] <alex_joni> in series is another relay is one controlled by estop
[18:37:47] <alex_joni> both are needed for juice to reach the motors
[18:38:08] <alex_joni> but that's probably OT
[18:39:12] <tomp> alex described a security chain with 1 contact controlled by logic, rest by hardware. sounds right.
[18:39:16] <rayh> You guys are doing lots better without me.
[18:39:29] <alex_joni> rayh: not really ;) you started this..
[18:39:43] <alex_joni> rayh: jmk's conculsion, you are not allowed to remove the loopback ;)
[18:40:09] <alex_joni> if you do.. you are busting it ;)
[18:40:21] <jmkasunich> that is because with the current convention, TRUE = stop, FALSE = let 'er rip
[18:40:34] <jmkasunich> which is back asswards for estop chains
[18:40:43] <alex_joni> probably because of the implicit value of the hal pin
[18:40:44] <Jymmm> i was just gonna say
[18:40:56] <jmkasunich> with a missing loopback the input is FALSE by default, and the machine can run
[18:41:05] <SWPadnos> the trouble is that the estop-out isn't an indicator of EMCs internal stop state - it's an indicator of whether emc is asking for a stop
[18:41:09] <Jymmm> jmkasunich or a loose cable
[18:41:16] <alex_joni> let's make it TRUE by default, and external needs to pull it low when it's the case
[18:41:17] <jmkasunich> if the signal was treated as an enable, then FALSE = stop, TRUE = let it run
[18:41:35] <alex_joni> probably that's more correct
[18:41:50] <jmkasunich> SWP: you hit it right on the head
[18:41:51] <SWPadnos> stop-in, stop-out, and stopped are the needed pins
[18:41:52] <rayh> now my head hurts
[18:41:58] <alex_joni> even estop is usually 24V on, so if it breaks.. you're estoped
[18:42:05] <SWPadnos> fail-safe
[18:42:12] <SWPadnos> wire breaks, machine stops
[18:42:15] <jmkasunich> that is how it is done in hardware - missing wire stops it
[18:42:35] <rayh> so can we say missing signal stops it.
[18:42:37] <Jymmm> NC momentary
[18:42:45] <jmkasunich> but somehow we've gotten to "estop on" means STOP on the softward side
[18:43:04] <jmkasunich> which implies estop-off (or missing) = let it run
[18:43:14] <jmkasunich> that's like using NO contacts for estop
[18:43:33] <SWPadnos> it doesn't matter whether the on or off state means stop, it isn't "automatically" updated depending on the state of the software
[18:43:43] <rayh> That is why I said a while ago forget the contact notion here.
[18:43:53] <SWPadnos> it has to be explicitly set to one or the other state, so the sense doesn't matter
[18:44:06] <jmkasunich> it does if you don't connect the loopback
[18:44:11] <jmkasunich> unconnected signals are false
[18:44:22] <SWPadnos> only because it happens to be initialized to the "emabled" state
[18:44:26] <rayh> when there is no loopback there is not ready
[18:44:42] <jmkasunich> its a hal pin - all hal pins default to false, and that shouldn't change
[18:45:00] <alex_joni> ok.. then iocontrole needs to invert it
[18:45:06] <SWPadnos> ray - you need a "stopped" output - that would solve your GUI / stop issues
[18:45:10] <rayh> The problem is that there is a reply to emc status that is wrong.
[18:45:15] <jmkasunich> alex: and rename it
[18:45:36] <SWPadnos> no it's not - the estop out isn't an indicator of estop state, it's a request for stop
[18:46:00] <rayh> I need an iocontrol pin that does exactly what the gui estop command does.
[18:46:02] <SWPadnos> so there's a missing signal - stopped
[18:46:05] <jmkasunich> SWP is right - it is one (of possibly many) requests for stop
[18:46:10] <rayh> sets the whole thing in a stopped condition
[18:46:31] <jmkasunich> estop-in is the driven by ALL of those requests, external or interna;l
[18:46:31] <rayh> Then I need a button that shows the current status of estop
[18:46:42] <jmkasunich> if you make estop-in go false, EMC should shut down
[18:46:43] <rayh> and a pin that resets estop from HAL
[18:47:07] <jmkasunich> reset is only needed when you have momentary estops that need latched...
[18:47:13] <SWPadnos> OK - you need an output that tells you if emc is stopped
[18:47:25] <SWPadnos> (from the perspective of iocontrol)
[18:47:28] <jmkasunich> we're having enough troubler right now, let's ignore latchine, assume everything is maintained
[18:47:36] <SWPadnos> you need an input that tells emc to stop
[18:47:49] <rayh> fam is calling for dinner -- back in 30
[18:47:54] <SWPadnos> you need an output that emc can use to ask for a stop
[18:47:55] <jmkasunich> that lase one is the one that is missing
[18:48:16] <jmkasunich> dammit, the second one, not the last one (your too fast)
[18:48:18] <SWPadnos> the input that tells emc to stop?
[18:48:22] <SWPadnos> sorry
[18:48:26] <jmkasunich> ;-)
[18:48:37] <SWPadnos> estop-in should do that, no?
[18:48:53] <jmkasunich> 1) input that tells EMC to stop
[18:48:58] <jmkasunich> 2) output that says EMC is stopped
[18:49:11] <jmkasunich> 3) output EMC (GUI probably) uses to ask for stop
[18:49:17] <Jymmm> jmkasunich #1 - like monitoring the big red button?
[18:49:23] <jmkasunich> 1) we have, estop-in
[18:49:27] <jmkasunich> 2) we don't have now
[18:49:31] <jmkasunich> 3) we have - estop-out
[18:49:45] <SWPadnos> yep - then we can add in the other stuff, like machine on and the like
[18:49:51] <SWPadnos> (whic I see as separate)
[18:49:54] <SWPadnos> which
[18:50:25] <jmkasunich> jymmm: 1 should be driven by a logical OR of 3 and external buttons
[18:50:47] <jmkasunich> if 3 OR an external button says stop, assert 2 to cause the stop
[18:50:48] <SWPadnos> externally, via blocks / CL, etc
[18:50:53] <jmkasunich> right
[18:51:09] <jmkasunich> I agree that we should add #2
[18:51:25] <jmkasunich> my main gripe is that the polarity is backwards
[18:51:54] <Jymmm> There's so much abiguity, I still fell that non EMERGENCY stop be renamed to something like SSTOP (System Stop)
[18:52:00] <jmkasunich> it should be "if 3 is OK, AND all other (externals) are OK, then assert 1 so EMC can run
[18:52:26] <jmkasunich> that AND should be a CL rung
[18:52:30] <SWPadnos> Jymmm, I think everyone understands teh real difference between estop and stop, it's just been called the wrong thing for 10 years
[18:52:48] <jmkasunich> in the simplest case where there are no externals, then the AND is just a loopback
[18:53:11] <jmkasunich> but if you leave the loopback out (or the CL rung), the result is a machine that won't start
[18:53:15] <SWPadnos> yes - an input that tells emc what may be done, and an output that tells the rest of HAL what state emc is in
[18:53:37] <SWPadnos> I'm adding stop_state to iocontrol right now
[18:53:51] <jmkasunich> question: when would 2 not match 1?
[18:54:04] <jmkasunich> cause if the answer is never, then why have 2?
[18:54:12] <SWPadnos> emc may be stopped after all external estop conditions have been reset
[18:54:24] <SWPadnos> and emc is the last in the chain to be re-enabled
[18:54:33] <jmkasunich> clarify
[18:54:37] <jmkasunich> if emc
[18:54:40] <jmkasunich> oops
[18:54:42] <jmkasunich> if emc's
[18:54:44] <jmkasunich> dammit
[18:54:46] <SWPadnos> heh
[18:55:04] <jmkasunich> if emc's "red button" is still pressed in then 3 is false, so 1 is false
[18:55:32] <SWPadnos> what if someone hit a big red switch
[18:55:42] <jmkasunich> when you pull out the "button", 3 becomes true, and if the external stuff is ON, then 1 becomes true
[18:55:42] <SWPadnos> that causes emc to go into stop mode
[18:56:24] <SWPadnos> that's hard-coded machine logic, and should probably be left out
[18:56:25] <jmkasunich> then pulling out the GUI button causes 3 to become true, but 1 remains false, thanks to CL (which has the physical button in series with the link between 3 and 1)
[18:56:46] <SWPadnos> hold on - start with a running machine
[18:57:18] <SWPadnos> external button gets hit, causing the machine to stop, and emc to stop (because the stop chain is connected somehow to estop-in)
[18:57:23] <jmkasunich> ok, 3 is true, (GUI estop is happy), 3 goes to a CL rung, where it passes thru other contactds driven by external buttons
[18:57:36] <SWPadnos> now, nobody has pressed any buttons on the gui
[18:57:42] <jmkasunich> nope
[18:57:47] <jmkasunich> stop a minute, let me type
[18:57:50] <SWPadnos> ok
[18:57:54] <alex_joni> * alex_joni approaches a button...
[18:58:08] <jmkasunich> 3 is driven ONLY by the GUI button
[18:58:13] <jmkasunich> in CL we have:
[18:58:51] <jmkasunich> ---| 3 |-----| / |-----| / |------( 1 )----
[18:59:02] <jmkasunich> where the |/| ones are external buttons
[18:59:21] <jmkasunich> if an external button opens, 1 goes false, EMC stops
[18:59:34] <jmkasunich> if the GUI button is hit, 3 goes false, EMC stops
[18:59:48] <jmkasunich> only when all are OK, does 1 go true, EMC can start
[19:00:05] <jmkasunich> that middle line should read:
[19:00:22] <jmkasunich> if the GUI button is hit, 3 goes false, which makes 1 go false, EMC stops
[19:00:36] <jmkasunich> phew
[19:00:42] <jmkasunich> * jmkasunich rests his typing fingers
[19:00:48] <SWPadnos> only if they're connected to each other, which shouldn't be required
[19:00:51] <SWPadnos> it's restarting that would need disticnt pins
[19:01:05] <jmkasunich> only if who are connected to each other, how?
[19:01:21] <SWPadnos> look at the standard motor interlock (as used, eg, with an A-B 100-C series contactr :) )
[19:01:42] <jmkasunich> your cheating, you are bringing momentary and latching into the picture
[19:01:53] <SWPadnos> gotta speak the language :)
[19:01:58] <jmkasunich> don't do that until we are all comfortable with the behavior with maintained contacts
[19:02:08] <SWPadnos> ok
[19:02:37] <jmkasunich> I agree that latching and reseting makes it even messier, but if we aren't happy with maintained yet, we don't wanna go there
[19:02:51] <SWPadnos> I meant that (1) only goes fals *automatically* if it's connected via a ladder rung like you showed
[19:02:57] <SWPadnos> false
[19:03:14] <SWPadnos> ie, you still have both pins on the iocontroller
[19:03:21] <jmkasunich> yep
[19:03:43] <SWPadnos> the output that shows enc being stopped is a status, not a command, nor a request
[19:03:59] <jmkasunich> you mean 2?
[19:04:09] <gezr> howdy yall
[19:04:16] <SWPadnos> it's only if you hard-code an "automatic restart" into the iocontroller that (2) and (1) are identical
[19:04:39] <SWPadnos> also note that the request doesn't guarantee instant completion of the command
[19:04:49] <jmkasunich> with maintained contacts, "automatic restart" is implied
[19:05:07] <SWPadnos> it shouldn't be, and that's not how it works now (with emc1)
[19:05:07] <jmkasunich> agreed about delay
[19:05:40] <SWPadnos> that's the thing - on some machines, you want automatic restart, and on others you wouldn't
[19:05:52] <SWPadnos> distinct pins allows that decision to be made external to iocontrol
[19:05:53] <jmkasunich> restart is a bad word anyway
[19:06:05] <SWPadnos> sure - re-enable might be better (only slightly)
[19:06:12] <jmkasunich> we're not talking about moving to "machine on", just moving out of "estopped"
[19:06:16] <jmkasunich> to "ready"
[19:06:22] <SWPadnos> ok
[19:06:41] <SWPadnos> remember that emc may not be the "master" in all setups
[19:06:57] <jmkasunich> I agree that at least sometimes you don't want to move out of estopped to ready even when input 1 says all is well, until you get a user request
[19:07:18] <SWPadnos> so it may be necessary to tell emc to "get ready", and have an external process verify that it actually *is* ready
[19:07:41] <SWPadnos> (process being software, plc, lights, etc - whatever)
[19:07:42] <jmkasunich> 1 = all external + the GUI estop switch are ready
[19:07:49] <dmess> hi all
[19:07:52] <jmkasunich> hi
[19:07:53] <SWPadnos> hi
[19:07:57] <jmkasunich> if not, then 1 should be false
[19:08:12] <jmkasunich> (using CL or whatever)
[19:08:23] <SWPadnos> right - it's not changed internally to iocontrol
[19:08:33] <dmess> 0 true for dead man stop cabability
[19:08:51] <SWPadnos> (2) is changed internally to iocontrol, and not by any external forces
[19:08:52] <jmkasunich> yes dmess, we've been there already
[19:09:13] <dmess> ok
[19:09:16] <jmkasunich> what do you want to use 2 for?
[19:09:26] <SWPadnos> it can be used to allow someone (like Ray) to make a GUI that accurately reflects wheher emc is stopped or ready
[19:09:52] <dmess> read signal??
[19:09:56] <SWPadnos> which is the initial problem that Ray had (maybe due to a bug / misconfiguration in iocontrol)
[19:10:36] <jmkasunich> huh? 2 reflects the internal state of EMC, which comes from NML.... ray has direct access to NML, why is he looking for a HAL pin?
[19:10:43] <SWPadnos> realize that there's another inherent problem here - that the button in ray's GUI is both an indicator and a control
[19:10:57] <SWPadnos> because he's a convert :)
[19:11:03] <jmkasunich> the button in ray's GUI is an indicator and at least 2 controls
[19:11:11] <SWPadnos> yes -there is that
[19:11:16] <jmkasunich> maybe 4 (in the case of tkemc)
[19:11:20] <SWPadnos> stop / reset / state indicator
[19:11:26] <SWPadnos> on / off
[19:11:53] <anonimasu> http://www.io23.net/tmp/firstpart.jpg
[19:11:58] <dmess> it would need io from hal to know the h/w is ok... i believe
[19:12:00] <anonimasu> ^_^
[19:12:02] <SWPadnos> but the command it sends is dependent on the "indicator state", which needs to come from emc (else you keep toggling between stop and reset commands)
[19:12:20] <SWPadnos> when you should maybe be sending a lot of stop commands ...
[19:12:21] <jmkasunich> ideally we would have a maintained contact red mushroom called estop, and a momentary called "estop reset"
[19:12:41] <SWPadnos> ther's no such thing as a maintained software "contact"
[19:12:47] <SWPadnos> not in an X GUI anyway
[19:12:57] <jmkasunich> toggle button
[19:12:59] <anonimasu> the black one is the first part :)
[19:13:08] <anonimasu> jmkasunich: yes
[19:13:10] <rayh> looks to me like we are working to hard applying much to much logic to
[19:13:16] <rayh> a system that could be simple.
[19:13:37] <SWPadnos> I say put in (1), (2) and (3), and let the integrator deal with the rest :)
[19:13:44] <rayh> I would like to see only one internal estop state.
[19:13:50] <jmkasunich> still doesn't deal with latching
[19:13:52] <dmess> it should be a bunch of little bites... not 1 big cluster f#$$%^
[19:14:01] <SWPadnos> latching is a machine logic question
[19:14:05] <rayh> latchin is external. I can do that in cl
[19:14:14] <jmkasunich> how do you reset it then?
[19:14:26] <rayh> I can't do it now. without the hal estop module
[19:14:31] <dmess> latcht the i to an o
[19:14:59] <jmkasunich> actually the hal estop module should probably go away, latching can be done in ladder, in a more transparent way
[19:14:59] <SWPadnos> button on GUI that says "reset estop", which tells *ladder* to de-assert the estop-in (to Iocontrol)
[19:15:21] <dmess> correct
[19:15:23] <jmkasunich> SWP: that would be my choice, but that depends on the GUI preferences
[19:15:31] <rayh> * rayh reads back more
[19:15:45] <SWPadnos> it can be the same GUI as now, but the estop-reset command goes to a different pin - on ladder instead of iocontrol
[19:15:49] <jmkasunich> using one button for both stop and reset reduces clutter, even if it makes a purist cringe
[19:16:16] <jmkasunich> let me try to draw a latching ladder
[19:16:16] <SWPadnos> that's an integrator question, if the functions in IOcontrol are kept simple
[19:16:31] <SWPadnos> no need - it can be done, therefore the problem is solved :)
[19:16:47] <jmkasunich> drawing it is a proof that it can be done ;-)
[19:17:03] <jmkasunich> assume that 4 is an external estop input
[19:17:06] <Jymmm> jmkasunich when you say " using one button for both stop and reset reduces clutter" do you mean press once for stop, press again for reset?
[19:17:08] <SWPadnos> bah! as my mother would say "you engineers - always looking for numerical answers"
[19:17:21] <jmkasunich> yeah, like the existing guis do
[19:17:34] <SWPadnos> Jymmm, look at the current tkemc functionality - one button for all estop and machine on functions
[19:18:18] <jmkasunich> ----| 3 |-----| 4 |------| 1 |-------(1)----
[19:18:40] <jmkasunich> -------|3/\|---------------+
[19:18:45] <Jymmm> I dont feel thats proper functionality. Have you ever been in a personal "panic mode" and hit the stop/die/cancel button a zillion times becasue it wasn't responding the first time you hit it.
[19:18:46] <jmkasunich> well that sucks
[19:19:30] <SWPadnos> the trouble with the GUI as it sits is that the f1 or estop click means different things depending on machine and emc state
[19:19:42] <jmkasunich> and it is wrong anyway ;-)
[19:19:46] <SWPadnos> hehe
[19:20:06] <alex_joni> but hitting F1 a million time still won't turn the machine on
[19:20:22] <alex_joni> it will only toggle between estop and estop_reset (as it is now)
[19:20:30] <rayh> if emc is in #4 machine running and you press the estop button it moves to #1 estopped.
[19:20:44] <rayh> That isn't ambiguous.
[19:20:53] <Jymmm> Guys, I know I keep repeating myself of the term "EMERGENCY STOP" as well as hows it implemented. But I never said why, I will now....
[19:21:08] <jmkasunich> +---| 3 |----| 4 |--+--| 1 |---+----(1)----+
[19:21:08] <jmkasunich> | | | |
[19:21:08] <jmkasunich> | +--|3/\|---+ |
[19:21:11] <SWPadnos> only after selecting the appropriate option from the popup menu (using the mouse)
[19:21:17] <rayh> I do have machine logic behind that button in the gui (shame on me) that says when you press it again it comes out of estop
[19:21:56] <rayh> could you describe the meaning of 1,3,4 for me
[19:22:14] <jmkasunich> Jymmm: the issue here is not about whether the existing one-button implementation is correct or safe
[19:22:15] <rayh> sorry I don't seem to be able to get that from the text above.
[19:22:23] <SWPadnos> 1) input that tells EMC to stop
[19:22:25] <SWPadnos> 2) output that says EMC is stopped
[19:22:26] <SWPadnos> 3) output EMC (GUI probably) uses to ask for stop
[19:22:37] <SWPadnos> (not sure what 4 is)
[19:22:44] <jmkasunich> it is how to provide a framework where the integrator can chose the existing implementation OR one with a separate estop-reset button
[19:22:53] <jmkasunich> 4 is an external estop contact
[19:23:07] <Jymmm> I used to work in the machine shop at General Dynamics. There was an incident when one guy was messing around with the controls behind a punch press. In doing so be bypassed a safety interlock and the girl that was operating reached in to clear a part and her hand got cut off. When you see something like this, it dramatically changes your view of EMERGENCY in a heartbeat.
[19:24:00] <Jymmm> So, even though the term ESTOP (wrongly) is used to mean "oh shit" now, is really should be change to it's proper definition IMO.
[19:24:19] <dmess> i too have seen light curtains on presses flake out
[19:24:21] <rayh> Let's look only at the pins we need available from iocontrol
[19:24:32] <SWPadnos> ray has already agreed to use the term stop sometimes, so that's progressing :)
[19:24:45] <jmkasunich> Jymmm: understood, estop means "there ain't no way this thing should be able to move unless this button has been pulled back out" and by definition that doesn't apply to any software button
[19:25:00] <rayh> if 1 tells emc it is stopped.
[19:25:06] <jmkasunich> but we need to cover both man-eating machines and sherlines
[19:25:19] <rayh> does the absence of 1 tell emc it is not stopped?
[19:25:23] <dmess> could there be a cycle stop??
[19:25:34] <jmkasunich> cycle stop is a completely different beast
[19:25:40] <SWPadnos> I was thinking that absence of 1 would mean that emc isn't required to be stopped
[19:25:46] <jmkasunich> yes
[19:25:47] <Jymmm> jmkasunich: Personally, I dont think the murshroom button has to be twisted. It should be treated as momentary button. Just in case the operator didn't hit it hard enough to lock in place.
[19:25:57] <rayh> dmess: cycle start tends to be a toggle.
[19:26:01] <SWPadnos> but it may still need operator intervention to go back to ready state
[19:26:16] <Jymmm> SWPadnos: s/may/must/
[19:26:19] <jmkasunich> that is latching vs. maintained - again, we need to be able to support both, let the integrator decide whether to latch or not
[19:26:30] <rayh> I think that we need to allow for any combination of buttons in cl.
[19:26:44] <rayh> if we do not, then we are creating this same discussion again.
[19:26:46] <SWPadnos> no Jymmm not must - that's dependent on external factors which are machine-specific
[19:26:48] <jmkasunich> did that ladder I posted make any sense?
[19:27:00] <SWPadnos> nope - not in proportional spacing :)
[19:27:13] <jmkasunich> change fonts (I had to do the same here)
[19:27:32] <rayh> Imagine three pins, but they are only defined at one state change each.
[19:27:43] <Jymmm> SWPadnos: For safety suck, it MSUT require operator intervetion. You cannot trust system .
[19:28:03] <Jymmm> s/suck/sake/
[19:28:07] <rayh> The first 1 above tells emc to estop
[19:28:26] <rayh> the second 2 above tells hal the state of estop
[19:28:29] <SWPadnos> Jymmm, the operator may need to presss a big green reset button on an external panel, not the GUI button
[19:28:53] <rayh> 3 switches emc from stopped to ready.
[19:29:07] <jmkasunich> question: should we even trust CL for estop? answer: I don't think so
[19:29:27] <SWPadnos> later, jmk (that's what ray and I debated for hours on end ;)
[19:29:30] <rayh> This is swp and others notions.
[19:29:40] <rayh> we need to concentrate on the internals of emc.
[19:29:53] <dmess> e-stop HAS to be externally wired for any machine in CANADA to be made
[19:29:58] <jmkasunich> true - and note that any rung that can be implemented in CL can also be implemented with real relays
[19:30:01] <Jymmm> You know the quick resolution to all this.... stick your hand in the machine, run some code you've never seen before, and see if you "TRUST" the system to stop.
[19:30:04] <SWPadnos> I can forward parts of the Semi-S2 spec (an old version) if some are interested (limited though)
[19:30:09] <rayh> remember to me emc is just another normally open relay in the estop chain
[19:30:29] <Jymmm> rayh N/O ?
[19:30:33] <jmkasunich> I wish that was true Ray
[19:30:34] <rayh> if emc is ready to run then it says so.
[19:30:57] <SWPadnos> right - I think we all agree that the machine needs hardware to stop it in an emergency, it's just what we call the pretty GUI buttons that's at issue
[19:31:03] <rayh> if the rest of the machine is also ready to run then it runs.
[19:31:11] <jmkasunich> so no latching
[19:31:33] <dmess> its a machine ready signal... then
[19:31:33] <SWPadnos> emc alone can not make the machine move - there are external interlocks implied
[19:31:39] <rayh> shut the fuck up on naming. We need signal logic not agreement on what you name a fucking button.
[19:31:58] <SWPadnos> exactly - we all know what's needed - let's move on
[19:32:07] <dmess> 3 pin
[19:32:08] <rayh> * rayh shuts up now
[19:32:15] <jmkasunich> Jymmm: if you don't like the GUI button being called ESTOP, then when youbuild a machine, rename it
[19:32:45] <SWPadnos> (ray - you're right here - let;'s not worry about the stupid buttons, but what's needed in iocontrol to make them *work*)
[19:32:51] <rayh> and goes back to twiddling the gdamned estop software that will not permit an estop cause the logic is all wrong.
[19:32:57] <jmkasunich> what we're trying to come up with here is a way to let you build the estop chain that meets your needs without shoving that logic down the throats of others with different needs
[19:33:37] <jmkasunich> what I wouldn't give right now for a fast and easy way to exchange pictures (like ladders)
[19:33:48] <SWPadnos> so - if you can tell iocontrol to stop, and find out whether it's stopped, and it can ask the rest of the world to stop, that should be all you need
[19:34:15] <jmkasunich> I still have reservations about 2, and what it implies
[19:34:24] <jmkasunich> it implies that you are using iocontrol to do latching
[19:34:27] <SWPadnos> in fact, the "ask the world to stop" may not be needed from iocontrol
[19:34:42] <anonimasu> hm, if you want to have a software way to toggle the estop circuit..
[19:34:45] <jmkasunich> IOW, 1 goes false, so iocontrol stops, then 1 goes true, but iocontrol doesn
[19:34:51] <Jymmm> jmkasunich it's not a labeling convention that I have an issue with. It's ppl's view/definition of "ESTOP".
[19:34:58] <jmkasunich> doesn't restart until the operator says so
[19:35:19] <jmkasunich> and when the operator does say so, that is indicated by 2
[19:35:23] <SWPadnos> Jymmm, please drop taht for now - it's been gone over a lot lately, and isn't germane to the current discussion any more
[19:36:21] <jmkasunich> SWP: did you follow what I just said?
[19:36:26] <SWPadnos> OK jmk, It's possible that iocontrol only needs stop control, and that everything else is doable outside iocontrol
[19:36:29] <SWPadnos> I think so
[19:36:43] <jmkasunich> "ask the world to stop" is very much needed
[19:36:49] <jmkasunich> and "stopped" is not (IMO)
[19:37:06] <SWPadnos> when would iocontrol ask the world to stop for purely internal reasons
[19:37:09] <SWPadnos> ?
[19:37:13] <jmkasunich> because "the world" is where any latching should be implemneted
[19:37:25] <rayh> na I'd latch in cl.
[19:37:25] <jmkasunich> iocontrol gets a stop message that originated at the GUI
[19:37:34] <rayh> but latch on not off
[19:37:49] <SWPadnos> why does iocontrol get that message? why can't it go to CL or other "machine logic" ?
[19:37:55] <jmkasunich> rayh: perspective, CL can be the world, if you are looking at it from iocontrol's perspective
[19:38:05] <rayh> k
[19:38:09] <jmkasunich> HAL pin direct from the GUI?
[19:38:24] <jmkasunich> that means no remote guis
[19:38:45] <SWPadnos> if iocontrol is the interface between the GUI and emc, then it needs all three pins, or it just needs to blindly pass GUI requests to named pins, and have no internal logic
[19:38:45] <jmkasunich> GUI -> NML -> task -> NML -> iocontrol -> HAL -> CL or real relays
[19:39:08] <jmkasunich> iocontrol is the interface between EMC (task) and HAL
[19:39:32] <SWPadnos> ok - no problem, in that case, it should be just that - an interface (or translator), and should contain no other logic
[19:39:45] <jmkasunich> 3 passes along a GUI stop request to the "world" (either CL or real relays)
[19:39:54] <SWPadnos> signal 1 comes in from the gui, gets routed to halpin(1)
[19:40:00] <jmkasunich> the "world" shuts things down, and uses 1 to tell EMC what happened
[19:40:27] <SWPadnos> other stuff happens,. and eventually halpin(17) goes on, which the GUI gets as an nml message, and interprets as "stopped"
[19:40:38] <jmkasunich> yep
[19:40:56] <SWPadnos> obviously, names are important, but as a concept, it should just translate, and do nothing else
[19:40:58] <jmkasunich> nothing I've said implies any logic in iocontrol
[19:41:10] <jmkasunich> the logic is in CL
[19:41:15] <SWPadnos> ok
[19:41:26] <jmkasunich> that's why I want to be able to show ladders
[19:41:36] <jmkasunich> you can make a ladder that implements latching, or not
[19:42:06] <jmkasunich> you can make one that requires a separate reset button, or one that resets on the rising edge of the GUI estop button
[19:42:46] <jmkasunich> you can make one that ignores the GUI button (which means you better not have a GUI estop button) and only uses real buttons, for both stopping and resetting
[19:42:50] <SWPadnos> ok - so how is the "is emc stopped right now" question to be answered for the GUI?
[19:43:02] <SWPadnos> realizing that it doesn't quite work in the current implementation
[19:43:05] <jmkasunich> from what we've been calling "1"
[19:43:43] <jmkasunich> which is the exact same coil that should actually render the machine safe, but dropping out physical contactors, etc
[19:43:52] <jmkasunich> s/but/by/
[19:44:52] <rayh> I think the gui is a sidetrack here.
[19:44:54] <SWPadnos> out of curiosity, exactly what is "stopped" by estop in emc (ie, where does the question "can I do anything now" get asked)
[19:45:18] <jmkasunich> probably a bunch of places
[19:45:20] <alex_joni> SWPadnos: task is
[19:45:23] <rayh> As it is now we have to write a loopback in cl in order to get estop.
[19:45:25] <jmkasunich> some redundant
[19:45:27] <alex_joni> the main switch for messages
[19:45:31] <SWPadnos> ok
[19:45:39] <alex_joni> so everything else you ask of emc will fail
[19:45:44] <SWPadnos> motion as well, I'd hope
[19:45:51] <alex_joni> be it GUI interaction, or other stuff
[19:45:53] <alex_joni> motion sure
[19:46:17] <jmkasunich> but not instantly - user space code is involved
[19:46:50] <rayh> alex_joni: pretty much everything you ask of emc will error
[19:47:16] <SWPadnos> rayh, yes - that's like jumpering the estop chain to make it work (the CL loopback)
[19:47:40] <SWPadnos> if you actually have switches (machine logic components), you connect it there instead
[19:47:45] <jmkasunich> BTW, that's why I added a HAL pin "motion.enable" to the motion controller
[19:48:10] <jmkasunich> that should be connected to the "1" signal, so that motion IMMEDIATELY shuts down when the CL rung turns off 1
[19:48:15] <SWPadnos> the trouble is that there's adifference between "enable" and "stop
[19:48:18] <rayh> But if the loopback isn't there, emc goes to ready rather than estop.
[19:48:28] <rayh> It does the wrong thing if the loop is broken.
[19:48:36] <alex_joni> rayh: we are aware of that
[19:48:37] <SWPadnos> right - that's an error in the code as it is now
[19:48:39] <jmkasunich> ray: that comes from the logic sense that is used for estop
[19:48:41] <alex_joni> and that will be fixed
[19:48:50] <alex_joni> polarity needs inversion
[19:49:11] <rayh> okay. rayh slaps himself around a bit for beating a dead horse again.
[19:49:12] <jmkasunich> the signals should be called enable-out and enable-in, and in both cases, TRUE should mean ready to run
[19:49:32] <SWPadnos> or "not-default"
[19:49:36] <alex_joni> I'm good with that
[19:49:40] <rayh> oh that sounds nice.
[19:50:00] <alex_joni> how about emc-enable-out and emc-enable-in
[19:50:04] <jmkasunich> then if the loopback is missing... you get FALSE, and the machine stubbornly sits there
[19:50:04] <rayh> That would look nice on the cl display as well.
[19:50:15] <rayh> exactly.
[19:50:39] <jmkasunich> in CL you connect it in series with other enables
[19:50:51] <jmkasunich> estops are just enables (if you use the NC contact)
[19:51:22] <rayh> This is for emc2 so HAL will be in the loop.
[19:51:41] <jmkasunich> question: we are about to require just about every machine (except those with no external estops at all) to use CL
[19:51:48] <rayh> the loopback can be a normal part of core hal
[19:51:50] <jmkasunich> is everybody OK with this?
[19:52:14] <jmkasunich> rayh: yes, the default configs should connect it
[19:52:38] <rayh> I'm good. At least as far as I understand it.
[19:52:39] <jmkasunich> a default CL config would connect it to CL and include a minimal rung
[19:53:03] <jmkasunich> will requiring CL bother the average amateur integrator?
[19:53:18] <rayh> Oh. Are we expecting to run CL on every install?
[19:53:28] <jmkasunich> that's where we seem to be going
[19:53:29] <SWPadnos> so - can this be fixed by changing this line:
[19:53:33] <SWPadnos> emcioStatus.aux.estop = *(iocontrol_data->estop_in); //check for estop from HW
[19:53:33] <SWPadnos> to this:
[19:53:41] <jmkasunich> at least any one that doesn't just use the loopback
[19:53:41] <SWPadnos> emcioStatus.aux.estop = !(*(iocontrol_data->estop_in)); //check for estop from HW
[19:53:48] <anonimasu> jmkasunich: yeah, I think that's a good idea
[19:53:48] <jmkasunich> if it has external estops, it will need CL
[19:53:58] <rayh> IMO, I'd d put the loopback up in HAL and let the integrator add cl and break that loopback.
[19:53:59] <anonimasu> if you can point the pins at the parport/io card..
[19:54:12] <anonimasu> whatever that talks to a real plc
[19:54:55] <alex_joni> so we agree that what we have (except naming and polarity) pretty much is what is needed ?
[19:55:12] <SWPadnos> heh - if only we had known ;)
[19:55:24] <jmkasunich> emc1's bridgeport config had external estop.... are we willing to say that if you want that functionality, you need to use CL to get it?
[19:55:28] <jmkasunich> (I am)
[19:55:28] <alex_joni> SWPadnos: it's nice to get to that conclusion..
[19:55:33] <dmess> sound very good to me..
[19:55:35] <SWPadnos> yes
[19:55:36] <alex_joni> jmkasunich: ditto
[19:55:49] <anonimasu> hm, I have a question.
[19:55:56] <alex_joni> because the average user doesn't know what CL means, and doesn't need to see it even..
[19:56:02] <SWPadnos> CL may not be needed - AND or OR can do the job for some simple cases
[19:56:05] <anonimasu> If I would like to bypass cl, Could I just have a real plc to do the logic for me?
[19:56:06] <rayh> We could produce the bridgeportio in hal itself
[19:56:08] <alex_joni> SWPadnos: that too..
[19:56:10] <rayh> without cl
[19:56:24] <alex_joni> rayh: don't wanna go there..
[19:56:31] <jmkasunich> rayh: how? using hal's AND blocks and such?
[19:56:32] <alex_joni> bridgeport.ini yes, but bridgeportio no
[19:56:37] <jmkasunich> those are messy
[19:56:46] <rayh> Okay.
[19:56:56] <dmess> doable though
[19:57:00] <jmkasunich> anon: yes, you could route the signals to real I/O pins, and use an external PLC
[19:57:05] <anonimasu> or would all my logic still go through cl
[19:57:08] <jmkasunich> or even real relays
[19:57:18] <rayh> Can we do a similar thing with coolant. Two pins one command one status.
[19:57:25] <anonimasu> * anonimasu nods
[19:57:30] <dmess> lets
[19:57:34] <anonimasu> as long as that is possible I have no objections at all..
[19:57:37] <rayh> and lube
[19:57:45] <anonimasu> as long as you can throw cl out, and replace it with hardware stuff
[19:57:50] <anonimasu> * anonimasu trusts a real plc more then a pc
[19:57:59] <alex_joni> anonimasu: no reason why you shouldn't
[19:58:06] <jmkasunich> I think most everything should have a "request" and "status" HAL pin
[19:58:16] <jmkasunich> simplest case, you just loop em back
[19:58:21] <alex_joni> anonimasu: the pins that go to cl can go to a real PLC, no sweat there..
[19:58:27] <anonimasu> alex_joni: nice..
[19:58:36] <alex_joni> jmkasunich: thought about that.. but that means lots of loop-bakcs
[19:58:43] <alex_joni> loopbacks even
[19:59:00] <jmkasunich> complex case, the status might be a rung that says "motor is running, AND pressure is OK, AND frisbin is active AND interlocks are OK, etc"
[19:59:04] <dmess> does any one have some HAL language avai??
[19:59:23] <alex_joni> dmess: how do you mean that?
[19:59:27] <rayh> Yes it does but it also allow the integrator to intepose stuff betwen lube on and lub up.
[19:59:27] <SWPadnos> there is the possibility of doing auto-loopback, based on a module parameter, or have a "simple" and a "complex" iocontrol module
[19:59:42] <anonimasu> I dont see integrating cl into the default emc is a problem for the integrator..
[19:59:57] <rayh> IMO this would be a good place for linkpp.
[20:00:11] <rayh> five or six of these and you've got it covered.
[20:00:16] <anonimasu> linkpp?
[20:00:21] <alex_joni> anonimasu: yup
[20:00:21] <anonimasu> sorry I havent been following too much
[20:00:25] <SWPadnos> dmess, cd emc2/docs/man, then man -W `pwd` halcmd
[20:00:45] <alex_joni> SWPadnos: make install && man halcmd
[20:00:47] <alex_joni> :P
[20:01:09] <dmess> emc2 box is stin in pcs..
[20:01:10] <SWPadnos> sorry - -M there, not -W
[20:01:10] <rayh> It's a pin to pin link with the signal being derrived from the name of the first pin
[20:01:16] <anonimasu> ah
[20:01:17] <anonimasu> yeah
[20:01:45] <dmess> i like the sounds of that... boolean and or??
[20:01:50] <jmkasunich> a shorthand way of doing "newsig somename bit"; "linksp somename, pin1" ; "linksp somename pin2"
[20:01:52] <alex_joni> yeah.. most of them
[20:02:25] <dmess> works dor me.. ;)
[20:02:30] <dmess> for
[20:03:15] <rayh> If the loopbacks were all in the hal file it would fall to the integrator to connect them to parport pins and or CL.
[20:03:22] <jmkasunich> the default HAL file could have linkpp commands for each IO thing, with a comment
[20:03:29] <rayh> and still provide a consistent model for handling io.
[20:04:02] <dmess> yes...
[20:04:49] <SWPadnos> now the big question - what "named" io should iocontroller support?
[20:05:03] <SWPadnos> we have G-code, which has explicit commands for certain types of IO
[20:05:27] <jmkasunich> at present, we're limited by the NML vocabulary
[20:05:28] <SWPadnos> and aux commands for "other" I/O
[20:05:52] <dmess> how many aux commands available??
[20:05:53] <rayh> I gotta say that I think this work above is a huge leap. Thanks for your patience with me.
[20:06:32] <alex_joni> rayh: thanks for bringing it up
[20:06:35] <SWPadnos> always fun
[20:06:36] <alex_joni> and clarifying it..
[20:06:36] <SWPadnos> or not ;)
[20:06:37] <alex_joni> :)
[20:06:41] <rayh> swp brings up a good point. there are special cases where io and motion need tight coordination
[20:06:43] <dmess> could we have 300 custom M codes???
[20:06:45] <alex_joni> so.. do we vote?
[20:06:49] <alex_joni> who does the changes?
[20:06:51] <SWPadnos> aye
[20:06:54] <alex_joni> * alex_joni could..
[20:06:55] <SWPadnos> nay
[20:07:01] <rayh> we have 99 or 100 now.
[20:07:10] <rayh> can we use these?
[20:07:11] <jmkasunich> ray: there are commands to the motion controller for coordinated I/O
[20:07:19] <jmkasunich> stubbed out right now
[20:07:21] <SWPadnos> does the one-line change I put up previously fix the estop thing (other than docs)?
[20:07:36] <jmkasunich> I think G-sixtysomething drives them
[20:07:38] <alex_joni> SWPadnos: there needs to be the naming changed
[20:07:45] <SWPadnos> ok - that's not a problem
[20:07:46] <alex_joni> 64 iirc
[20:07:53] <alex_joni> and the loopbacks
[20:08:14] <SWPadnos> I thought there were M61-69 and M51-59 or something for aux on and off
[20:08:24] <jmkasunich> I can change motion so it exports some pins that are driven by those G60something commands
[20:08:44] <alex_joni> jmkasunich: do that..
[20:08:48] <anonimasu> hm
[20:08:49] <jmkasunich> there is no provision for feedback on the motion synchronized I/O
[20:08:50] <anonimasu> nice
[20:08:50] <alex_joni> that's needed
[20:08:52] <alex_joni> imho
[20:09:05] <dmess> those are exact stop and the likes correct...??
[20:09:14] <alex_joni> needed (= that you add them, not the feedback)
[20:09:25] <SWPadnos> no - it's "turn this on when this motion is done"
[20:09:26] <alex_joni> dmess: no, those are trajectory related, not motion synced io
[20:09:39] <SWPadnos> or off
[20:09:43] <dmess> no provision YET for rigid tapping either..
[20:09:49] <SWPadnos> different issue
[20:09:57] <rayh> There is also the special case of a hardwired control panel.
[20:10:09] <SWPadnos> with modal controls on it
[20:10:26] <jmkasunich> stop, stop! my head is going to explode\
[20:10:30] <alex_joni> rayh: that's the other issue
[20:10:32] <SWPadnos> *boom*
[20:10:35] <rayh> if modal, then we need a way to switch the lot out of operation
[20:10:39] <alex_joni> -----------------------------------------------------------------------------------
[20:10:42] <jmkasunich> splat, drip, dribble
[20:10:45] <anonimasu> * anonimasu gives jmk a bottle of coke
[20:10:47] <SWPadnos> actually, if modal - boom!
[20:10:49] <alex_joni> -----------------------------------------------------------------------------------
[20:11:02] <Jymmm> * Jymmm hands jmkasunich a case of "pop rocks"
[20:11:04] <SWPadnos> because when you enable the panel, all those things may suddenly change
[20:11:09] <alex_joni> can I say something without beeing interrupted?
[20:11:13] <anonimasu> yes
[20:11:14] <SWPadnos> yes
[20:11:17] <alex_joni> ok
[20:11:19] <jmkasunich> can we back up to motion synced I/O?
[20:11:20] <SWPadnos> go ahead
[20:11:23] <rayh> perhaps we could leave much of this for another day. After the current changes are tested.
[20:11:23] <jmkasunich> (after alex talks)
[20:11:28] <alex_joni> ISSUE 1
[20:11:43] <alex_joni> estop (think we clarified what we need to do, I'll do it)
[20:11:45] <alex_joni> ISSUE 2
[20:11:56] <rayh> * rayh starts to rewire his basement to the new configuration!
[20:12:14] <alex_joni> motion synced I/O (that's pretty clear in emc1, needed for laser and other machines, jmk said he'll do it)
[20:12:24] <alex_joni> those are clear and out of the way
[20:12:30] <jmkasunich> I need to discuss more, but lets cover the issues first
[20:12:39] <alex_joni> if anyone has anything to add to those.. should speek now ;)
[20:12:45] <alex_joni> * alex_joni has another topic to talk about
[20:12:59] <jmkasunich> can we cover synced IO?
[20:13:11] <alex_joni> but that's completely different thing (hardware control panel)... (ISSUE 3 for later)
[20:13:23] <alex_joni> * alex_joni changes topic to ISSUE 2
[20:13:36] <alex_joni> motion synced IO .. let's hear it
[20:13:39] <SWPadnos> and for way later, support for non G-code machines
[20:13:47] <anonimasu> I'll be right back I need to go to the kiosk
[20:13:50] <alex_joni> SWPadnos: that is in the back of my head..
[20:13:51] <jmkasunich> ok, my understanding of it is from the lowest level, looking up
[20:13:54] <SWPadnos> (issue 6)
[20:14:01] <jmkasunich> I need a high level perspective
[20:14:07] <jmkasunich> at the low level...
[20:14:24] <jmkasunich> there are EMCMOT comamnds called EMCMOT_SET_AOUT, and EMCMOT_SET_DOUT
[20:14:25] <rayh> we do have canterp for non g-code but it acts just like the end of interp.
[20:14:26] <alex_joni> jmkasunich: on what? (high level)
[20:14:58] <jmkasunich> in the motion controler, they currently do nothing, that;s what I need to fix
[20:15:08] <rayh> I didn't think they were implemented.
[20:15:10] <jmkasunich> but I have no idea what g-code causes them to be issued
[20:15:18] <alex_joni> jmkasunich: I know, the used to turn I/O on synced with motion
[20:15:20] <jmkasunich> nor what options they have
[20:15:24] <alex_joni> G64 iirc..
[20:15:28] <alex_joni> * alex_joni looks
[20:15:43] <etla> g64 is blended motion
[20:15:54] <jmkasunich> there appears to be a choice of taking immediate action, or queueing it in the TP to take effect when the previous motion finishes
[20:15:55] <etla> what would one use AOUT and DOUT for ?
[20:16:13] <jmkasunich> there is also an index that selects what I/O device is driven
[20:16:36] <jmkasunich> DOUT - turn on a laser when movement starts
[20:16:46] <jmkasunich> AOUT - vary laser power based on feedrate?
[20:16:53] <jmkasunich> I'm sure there are other uses
[20:17:18] <alex_joni> I'm reading the code now.. but it seems those are used for something else
[20:17:26] <jmkasunich> anyway, SET_AOUT and SET_DOUT are currently commented out in motion
[20:17:35] <jmkasunich> I can put code in motion to make them do stuff
[20:17:45] <jmkasunich> but I don't know how to invoke them, so I cant test
[20:18:06] <alex_joni> EMC_MOTION_SET_AOUT_TYPE;304;sets an analog output value coordinated with motion;;SET_MOTION_OUTPUT_VALUE (emccanon.cc);emcTaskIssueCommand (emctaskmain.cc) calls emcMotionSetAout (minimill | bridgeporttaskintf.cc) which sends EMCMOT_SET_AOUT;"emccanon.cc currently lacks this in emc2; not used in emc2, needs to go to HAL";index;unsigned char;start;double;end;double;now;unsigned char
[20:18:06] <alex_joni> EMC_MOTION_SET_DOUT_TYPE;305;sets an digital output value coordinated with motion;;SET_MOTION_OUTPUT_BIT (emccanon.cc);emcTaskIssueCommand (emctaskmain.cc) calls emcMotionSetDout (minimill | bridgeporttaskintf.cc) which sends EMCMOT_SET_DOUT;"emccanon.cc currently lacks this in emc2; not used in emc2, needs to go to HAL";index;unsigned char;start;double;end;double;;
[20:18:14] <alex_joni> this is what my documentation says ;)
[20:18:34] <jmkasunich> the index is worrisome - can you say SET_DOUT(output43, TRUE)?
[20:18:49] <jmkasunich> in which case motion would need to export at least 43 hal pins... nasty
[20:18:59] <alex_joni> yeah.. nasty :)
[20:19:14] <jmkasunich> thats why I need higher level info
[20:19:22] <jmkasunich> what is the G-code syntax
[20:19:34] <jmkasunich> how is the index and value specified?
[20:19:36] <SWPadnos> there needs to be a way of saying "I understand, but can't comply"
[20:19:43] <rayh> I'm not convinced there is any g-code
[20:19:59] <SWPadnos> so you can have a machine with 16 DOUTs, and it says "no-go" if it gets a command for output #17
[20:20:04] <jmkasunich> oh, just found a couple more
[20:20:16] <jmkasunich> EMCMOT_SET_INDEX_BIT and EMCMOT_READ_INDEX_BIT
[20:20:32] <jmkasunich> with a comment saying "needed for M62/M63"
[20:20:39] <SWPadnos> I don't see any I/O related G-code stuff in the RS274 manual (still looking)
[20:20:42] <jmkasunich> so it's M60something, not G60something
[20:20:51] <SWPadnos> (not this kind of IO, at least)
[20:21:12] <jmkasunich> SWP: remember these DOUTs are hal pins from the motion controller, can be routed anywhere after that
[20:21:17] <jmkasunich> so it's not a machine parameter
[20:21:38] <jmkasunich> are M62/63 documented anywhere?
[20:21:39] <SWPadnos> I understand - look at it like blocks "loadrt motion DOUT=16"
[20:21:55] <SWPadnos> not in my manual
[20:22:28] <SWPadnos> encounter a request for pin 43, and this machine (as configured) can't comply
[20:23:03] <jmkasunich> I don't like adding insmod time parameters, but that might be the best approach
[20:23:17] <etla> "M62 sets an output coordinated with motion "
[20:23:19] <jmkasunich> maybe have a default of 8 or something
[20:23:27] <etla> "M63 clears an output coordinated with motion"
[20:23:32] <etla> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl/emcinfo.pl?Gcode
[20:23:41] <SWPadnos> maybe I have an older manual
[20:24:23] <jmkasunich> etla: thanks... unfortunately those descriptions are about 5 lines too short
[20:24:56] <SWPadnos> is there a revision of RS274NGC_3 from later than August 17, 2000?
[20:25:58] <alex_joni_busy> want an explanation? "RUM User_m flagged g/m-codes that require a letter index are
[20:25:58] <alex_joni_busy> now handled by setting that letter index to -1 from the function
[20:25:58] <alex_joni_busy> which reads that particular user_m flagged g/m-code.
[20:25:58] <alex_joni_busy> Default index is 0. (handled as equivalent to no letter index.)
[20:25:58] <alex_joni_busy> M62-M65 currently are the only codes affected.
[20:25:59] <alex_joni_busy> Added 1 error message.
[20:26:00] <alex_joni_busy> Modified read_user_m(), read_p(), read_q(), convert_m()
[20:27:28] <alex_joni_busy> kidding..
[20:27:35] <alex_joni_busy> M62 Pxx -> sets pin on
[20:27:43] <alex_joni_busy> M63 Pxx -> clears pin xx
[20:28:11] <alex_joni_busy> M64 Pxx -> sets pin xx (not synced with motion)
[20:28:17] <alex_joni_busy> M65 Pxx -> clears pin xx (not synced with motion)
[20:28:55] <jmkasunich> what about analog?
[20:29:19] <alex_joni_busy> don't see it in the interpreter
[20:29:38] <alex_joni_busy> emccanon.cc has it, but the interpreter doesn't
[20:29:44] <alex_joni_busy> so probably it's not done..
[20:29:50] <alex_joni_busy> (this info is from emc1)
[20:29:55] <alex_joni_busy> looking at emc2 now
[20:31:11] <alex_joni_busy> in emc2, the code is in the interpreter (M62-65), but it's commented out
[20:31:23] <alex_joni_busy> emccanon.cc (emc2) doesn't have the code at all
[20:31:40] <alex_joni_busy> jmkasunich: enough information? or you need something more specific?
[20:31:50] <dmess> looking like an adaptive control system to me...
[20:32:02] <alex_joni_busy> dmess: what is?
[20:32:29] <jmkasunich> looks like I will implement the digital ones only, at least for now
[20:32:46] <dmess> monitor certain conditions ... and varies others in accordance to some RULES...
[20:34:04] <SWPadnos> funny - with HAL, you can just use PID or the like to vary e.g. laser power with motion speed
[20:34:04] <etla> eg varying the analog laser intensity is very much like gearing (rigidtapping/threading) you only take the input from speed instead of pos
[20:34:47] <jmkasunich> SWP: would be a little tricky to turn laser on for some lines, off for others, using only HAL
[20:35:09] <SWPadnos> yes, but spindle on/off would take care of that in most cases
[20:35:20] <SWPadnos> and speed can be used for laser power anyway
[20:35:23] <SWPadnos> (spindle speed)
[20:35:33] <jmkasunich> too slow, spindle on/off goes thru iocontrol in user space
[20:35:54] <SWPadnos> ah - but on/off would likely be fast enough
[20:36:04] <dmess> need a spindle up to speed input
[20:36:06] <jmkasunich> with lasers, you might be doing dozens of moves per second, with laser on for some and off for others
[20:36:28] <jmkasunich> better to queue the laser on and off commands with the motion commands
[20:36:40] <SWPadnos> nonetheless, it can be approximated with existing HAL for some cases, which is a testament to HALs flexibility
[20:36:40] <Jymmm> CO2 Laser "power" is usally PWM controlled.
[20:36:43] <dmess> m-code
[20:37:01] <jmkasunich> SWP: true ;-)
[20:37:11] <dmess> with a ready signal
[20:37:25] <SWPadnos> peole just have to think in little blocks, like an erector set
[20:37:50] <dmess> thats all the BIG ones are
[20:37:58] <jmkasunich> and the blocks have to be designed with flexibility in mind, like we just worked thru for iocontrol
[20:38:03] <alex_joni_busy> * alex_joni_busy thinks SWPadnos is an erector set
[20:38:23] <alex_joni_busy> alex_joni_busy is now known as alex_joni
[20:38:42] <dmess> yes... minimalistic approach to the big hurrdles
[20:38:48] <SWPadnos> I am, but only for the ladies - no, wait :)
[20:39:00] <anonimasu> iab
[20:39:41] <Jymmm> SWPadnos "- no, wait" ?????????????????? Is there something that you've been meaning to mention to your wife?
[20:39:57] <jmkasunich> I always do a double take when I see a crane or truck with "Quality Erection" painted on the door
[20:40:09] <anonimasu> lol
[20:40:35] <dmess> DOH... ; )
[20:41:13] <jmkasunich> http://www.allcraneloadcharts.com/
[20:41:36] <SWPadnos> Jymmm, just trying not to think about "erect" females :)
[20:42:00] <alex_joni> ok.. jumping at iocontrol now
[20:42:06] <alex_joni> any last wishes?
[20:42:08] <alex_joni> ;)
[20:42:26] <SWPadnos> yeah - can you supersize that?
[20:42:27] <jmkasunich> http://www.modelcityerection.com/
[20:42:32] <alex_joni> SWPadnos: what?
[20:42:50] <anonimasu> so who wants some candy?
[20:42:50] <SWPadnos> this just in - there's been an erection at Model City
[20:43:01] <SWPadnos> kidding, A_J
[20:43:09] <anonimasu> * anonimasu throws foam santa calauses at everyone
[20:43:30] <SWPadnos> I think the only other pressing discussoin was extension of ahlcmd
[20:43:35] <Jymmm> * Jymmm grabs the acetone squirt gun and says.... PULL!
[20:43:43] <SWPadnos> halcmd
[20:43:55] <alex_joni> * alex_joni throws http://www2.b3ta.com/merrychristmas/ at anonimasu
[20:44:04] <SWPadnos> * SWPadnos throws up
[20:44:16] <alex_joni> ok.. ISSUE 3
[20:44:20] <anonimasu> alex_joni: where do you find horrid stuff like that?
[20:44:25] <rayh> The discussions these last two weeks have been huge. We've made a lot of progress.
[20:44:26] <alex_joni> :-P
[20:44:28] <dmess> guy grab a pillow
[20:44:39] <alex_joni> ok. back to ISSUE 3
[20:44:44] <rayh> Thanks to all of you guys who have been doing the coding work behind this.
[20:44:49] <alex_joni> hardware GUI's
[20:44:52] <jmkasunich> * jmkasunich is probably glad he doesn't have Flash and didn't see that last one
[20:45:23] <anonimasu> jmkasunich: it gives a nice christmas feeling ;)
[20:45:35] <alex_joni> ok.. so if iocontrol would have the stuff emcsh supports, then you might build Hardware GUI's
[20:45:51] <rayh> How about a separate ioInterface.cc
[20:46:00] <alex_joni> yeah.. fine too
[20:46:28] <SWPadnos> that's a better name for iocontrol, actually
[20:46:40] <rayh> If we connect a hardware pin through HAL to say mode auto.
[20:46:41] <alex_joni> nah.. interface
[20:46:42] <dmess> probably a necessary evil..
[20:46:44] <jmkasunich> emcsh ~= interface between TCL and NML, right?
[20:46:55] <alex_joni> jmkasunich: yes, between GUI and NML
[20:47:03] <alex_joni> iosh ~= iocontrol
[20:47:07] <rayh> It doesn't need a status variable, does it.
[20:47:12] <alex_joni> emcsh ~= iointerface
[20:47:14] <dmess> make it flow boys..
[20:47:20] <SWPadnos> halcmd is being readied as an interface between GUI (or CLI) and HAL
[20:47:30] <rayh> Task is going to get the NMl and decide if it can go into auto mode.
[20:47:34] <alex_joni> SWPadnos: how so?
[20:48:00] <jmkasunich> can a tcl program simultaneously interact with emcsh to send/get NML and with halcmd to access hal pins?
[20:48:06] <SWPadnos> to allow GUI or cli determination of HAL status, and to effect changes in HAL in user-only code
[20:48:24] <SWPadnos> ... user-space ...
[20:48:34] <jmkasunich> this is for TCL code
[20:48:47] <jmkasunich> ordinary C code can access HAL directly, no need to go thru halcmd
[20:49:04] <rayh> I was imagining a switch that selected man auto mde handwheel
[20:49:23] <rayh> Notice I said handwheel which isn't an emc mode.
[20:49:32] <SWPadnos> neither is mde :)
[20:49:40] <jmkasunich> nitpick
[20:49:43] <SWPadnos> * SWPadnos ducks
[20:49:53] <rayh> mdi.
[20:50:19] <dmess> handwheel is io confroled feedback... should be easy
[20:50:30] <rayh> I'm still in the NIST camp when it comes to hard wired control.
[20:50:34] <dmess> controlled
[20:50:36] <SWPadnos> this raises the question of whether all possible paths in HAL need to be set up at start
[20:50:53] <rayh> Yes. Handwheel will require manual mode and a HAL connection to something.
[20:50:54] <SWPadnos> this raises the question of whether all possible paths in HAL need to be set up at start time, or whether things should be reconfigurable during run
[20:51:21] <jmkasunich> currently HAL allows configuration during run, but I'm not sure if we really want to go there
[20:51:28] <alex_joni> SWPadnos: that screams for a rework..
[20:51:36] <jmkasunich> handwheel can be done without that
[20:51:40] <alex_joni> module reconfiguration.. :)
[20:51:47] <dmess> rungs to the ladder should only be out by 1 cycle at most in hal
[20:51:50] <SWPadnos> ok - that has implications for gearing, and changing between GUI and pendant control
[20:51:51] <jmkasunich> HAL handwheel position is read by the GUI, which issues NML jog commands
[20:51:56] <jmkasunich> no reconfig neeed
[20:51:57] <alex_joni> jmkasunich: so currently we have NML -> iocontrol -> HAL
[20:52:00] <jmkasunich> no reconfig needed
[20:52:09] <alex_joni> how about HAL -> iointerface -> NML ?
[20:52:24] <alex_joni> jog buttons, lube, spindle, etc
[20:52:33] <SWPadnos> that implies that all possible paths be set up at initial configuration time
[20:52:33] <alex_joni> what usually is on a GUI.. just on a hardware panel
[20:52:40] <alex_joni> SWPadnos: yes
[20:53:09] <jmkasunich> if you are talking about letting a (G)UI read physical buttons instead of screen ones, I would think the GUI should access HAL directlky for those
[20:53:15] <SWPadnos> and that any component has all the connections to support any (reasonable) configuration
[20:53:34] <rayh> There will be buttons for things like spindle jog at a predetermined speed.
[20:53:35] <alex_joni> jmkasunich: that means a). rewrite one GUI or b). rewrite all GUI's
[20:53:45] <rayh> Those are available as NML for the most part.
[20:53:47] <alex_joni> also.. the GUI might be on a different machine than HAL
[20:54:10] <SWPadnos> that's a separate question though
[20:54:19] <SWPadnos> ah - nevermind
[20:54:25] <jmkasunich> that alternative is to extend NML to allow it to send button presses all over the place
[20:54:29] <rayh> IMO in the long run this is where task will need to be extended.
[20:54:32] <jmkasunich> s/that/the/
[20:54:33] <dmess> lets restrict to the same for now
[20:54:36] <alex_joni> it doesn't need extension
[20:54:48] <rayh> Now it doesn't.
[20:55:06] <jmkasunich> I don't understand
[20:55:08] <alex_joni> jmkasunich: you don't need to extend NML for what I am proposing
[20:55:12] <jmkasunich> or maybe I do
[20:55:17] <alex_joni> you know what emcsh does?
[20:55:28] <alex_joni> it provides tcl hooks for all the GUI related stuff
[20:55:38] <jmkasunich> this "iointerface" will read HAL inputs (buttons, knobs) and send NML messages like JOG, or whatever?
[20:55:44] <alex_joni> yes
[20:55:56] <alex_joni> just like any other GUI would
[20:56:00] <jmkasunich> then it is really "halgui" or perhaps "halui"
[20:56:08] <alex_joni> ok.. halgui then
[20:56:16] <alex_joni> halhui
[20:56:20] <dmess> you task alex??
[20:56:21] <rayh> I like the halui
[20:56:26] <dmess> your
[20:56:27] <jmkasunich> has nothing to do with I/O as we normally consider it (machine I/O), instead is is operator panel I/O
[20:56:42] <SWPadnos> but somewhere, there needs to be the ability to swap between e.g. tkemc and iointerface
[20:56:43] <rayh> halgui implies something about looking into hal with a point and click
[20:56:43] <alex_joni> jmkasunich: yes, that's what I'm talking about all along
[20:56:50] <jmkasunich> or halemc
[20:56:59] <alex_joni> nah.. halui or halhui :)
[20:57:08] <rayh> As it is now, several gui's can live at the same time.
[20:57:08] <alex_joni> hal - hardware user interface ;)
[20:57:10] <SWPadnos> HALlicunate
[20:57:14] <jmkasunich> I was hoping to use the name halgui for the GUI counterpart of halcmd - a generic thing
[20:57:15] <rayh> as long as one of them is NOT Axis.
[20:57:16] <SWPadnos> no - HALlucinate
[20:57:29] <alex_joni> ROFL
[20:57:31] <SWPadnos> halcfngui
[20:57:34] <rayh> some of axis can live with mini or tkemc but not all of it.
[20:57:40] <SWPadnos> gah! halcfggui
[20:57:51] <rayh> that's a nice name.
[20:57:56] <alex_joni> halmut ?
[20:58:05] <SWPadnos> cryptic enough for even UNIX users
[20:58:21] <rayh> I'll name my ext dog.
[20:58:25] <rayh> next
[20:58:30] <jmkasunich> what you guys are talking about is an emc gui that uses hal for buttons (and maybe lights)
[20:58:31] <SWPadnos> halfsck
[20:58:34] <alex_joni> anyways.. something to think about, not necessarely now..
[20:58:41] <alex_joni> jmkasunich: yes
[20:59:03] <jmkasunich> the thing is, I strongly doubt that you'll want all the buttons and lights to be physical
[20:59:09] <jmkasunich> some will still be on the screen
[20:59:21] <SWPadnos> unimplemented ones are ignored, or generate no commands
[20:59:22] <alex_joni> jmkasunich: ideally you'll have them duplicated
[20:59:35] <rayh> If this hal interface were written so that it's NML behaved like emcsh does, then there would not
[20:59:38] <alex_joni> that doesn't mean you need to use them all
[20:59:41] <jmkasunich> I'm starting to catch on
[20:59:51] <jmkasunich> I was thinking of mini OR this hal thing
[20:59:56] <rayh> be any intrinsic conflict between it and a gui like mini
[21:00:01] <jmkasunich> you are thinking of mini AND this hal thing
[21:00:06] <alex_joni> jmkasunich: YES
[21:00:07] <rayh> yes
[21:00:11] <SWPadnos> gotta be
[21:00:20] <alex_joni> mini AND tkemc AND this hal thing ;)
[21:00:23] <SWPadnos> that's where the reconfiguration comes in, IMO
[21:00:28] <alex_joni> each one on a different computer
[21:00:31] <rayh> One additional thing needs to happen though.
[21:00:51] <SWPadnos> you don't want to have 162 N-way muxes for all possible GUI commands
[21:00:53] <rayh> if the hardware panel builder chooses to use maintained switches.
[21:01:17] <rayh> there will need to be a way to bypass those so the NIST directive is still alive
[21:01:19] <alex_joni> rayh: his problem
[21:01:29] <jmkasunich> interesting - if the halemc thing was on a remote computer, that means any hal connected user interface buttons or lights would connect to the remote computer too
[21:01:35] <alex_joni> he needs to use some software component to disregard that..
[21:01:42] <SWPadnos> that's a tough nut (the modal switch thing)
[21:02:03] <alex_joni> jmkasunich: if you set up hal on another computer, you can have the hardware UI there
[21:02:16] <alex_joni> and another HAL (for motion) on the computer controlling the machine
[21:02:22] <jmkasunich> right - two completely independent hals
[21:02:27] <alex_joni> between them NML
[21:03:38] <alex_joni> what do you think? sounds ok?
[21:03:59] <jmkasunich> I guess so
[21:04:11] <alex_joni> but that's for later..
[21:04:18] <alex_joni> now I'm working on enable ;)
[21:04:22] <rayh> I believe that it would also be well to provide access to some state variables for this
[21:04:29] <alex_joni> how about that estop-reset.. can I drop that?
[21:04:31] <rayh> in much the same way emcsh does
[21:04:40] <jmkasunich> and I'm playing with M62 and friends
[21:04:41] <alex_joni> CL can take over what the estop hal module does..
[21:05:03] <jmkasunich> estop-reset - good question
[21:05:40] <jmkasunich> the issue is: if you implement estop latching in CL (which I think you should, to allow for things like momentary estop buttons, and machines that ride over the estop limit switch)
[21:05:48] <jmkasunich> how do you reset the latch
[21:06:07] <SWPadnos> remember - all X buttons are momentary
[21:06:07] <alex_joni> you can reset any latch if it's designed to be reset..
[21:06:28] <jmkasunich> some folks will say "use the rising edge of the GUI enable output (IOW, when you "pull out" the GUI mushroom switch)
[21:06:39] <jmkasunich> that can be done in CL
[21:06:43] <alex_joni> right
[21:06:57] <jmkasunich> but what about the folks that want a distinct estop-reset button on the GUI
[21:07:17] <jmkasunich> (if they want a physical reset button that is easy, route to CL)
[21:07:22] <alex_joni> let them worry
[21:07:25] <SWPadnos> they need CL to do that, unless estop--reset is kept
[21:07:33] <jmkasunich> but if its on the GUI, how does it get to iocontrol, and then to CL?
[21:07:45] <alex_joni> let them ask for it, and I'll add it
[21:07:50] <rayh> I think I favor the estop-reset as the route to moving from stopped to ready from cl.
[21:07:56] <SWPadnos> well - there should be some generic inputs and outputs in iocontrol
[21:08:17] <rayh> rather than a signal held low for one state and up for the other.
[21:08:19] <SWPadnos> so I can add a "pallet change" button to my GUI, and not have to issue the G-cde to do that
[21:08:24] <jmkasunich> SWP, the problem isn't lack of HAL pins in iocontrol, it's the lack of NML messages to drive gtem
[21:08:26] <jmkasunich> them
[21:08:54] <SWPadnos> there are I/O messages, they're just not connected to the interpreter ATM (is that right?)
[21:09:07] <jmkasunich> ray: I want to separate out the state of the imaginary red mushroom and the estop reset switch
[21:09:35] <jmkasunich> then if a GUI writer wants to actually use the same screen widget for both, they can, and another GUI can use two distinct widgets
[21:09:43] <rayh> Okay.
[21:09:51] <jmkasunich> seems like we need a "request estop reset" NML message
[21:10:12] <jmkasunich> which pulses a HAL pin, that in turn can be used to unlatch a CL rung
[21:10:26] <rayh> No I think that we can just use the estop-reset iocontrol pin to reset it if we want from the hardware.
[21:10:38] <rayh> It should reset anyway from the gui.
[21:10:43] <jmkasunich> then when you "pull out the mushroom", the GUI can send ESTOP_OFF, followed by "REQUEST_RESET"
[21:10:58] <rayh> If the user wishes.
[21:11:10] <jmkasunich> ray: I don't understand what you just said
[21:11:22] <alex_joni> short question : enable-in or emc-enable-in
[21:11:29] <rayh> press the red button and you get an estop throughout the system.
[21:11:32] <SWPadnos> io-enable-in
[21:11:35] <jmkasunich> enabled
[21:11:38] <rayh> all of the state variables go to it.
[21:11:49] <jmkasunich> GUI red button?
[21:11:52] <rayh> pull it out and nothing happens.
[21:12:04] <rayh> NO gui button
[21:12:08] <jmkasunich> that's not the way todays GUIs work
[21:12:15] <rayh> This is the one sitting on my desk that says estop
[21:12:21] <jmkasunich> ok, real button
[21:12:36] <rayh> Doesn't matter we can fix guis
[21:12:37] <jmkasunich> gawd this is a poor way to communicate
[21:12:49] <SWPadnos> FallFest, anyone ;)
[21:12:49] <rayh> real red button
[21:12:54] <anonimasu> jmkasunich: agreed
[21:12:57] <rayh> press it and you get estop throughout emc
[21:13:01] <jmkasunich> I'm all out of vacation days :(
[21:13:03] <alex_joni> ok.. so ray is saying: push external estop (real button), emc goes to stopped state
[21:13:07] <rayh> release it and nothing happens
[21:13:14] <anonimasu> yep
[21:13:15] <jmkasunich> because it is latched
[21:13:15] <alex_joni> rayh: then what?
[21:13:21] <jmkasunich> the latching is done in CL
[21:13:29] <anonimasu> then you push the OK key and the latch gets reset
[21:13:32] <rayh> several possibilities
[21:13:37] <rayh> that one.
[21:13:42] <dmess> yup
[21:13:45] <rayh> or f1 on the gui
[21:13:58] <alex_joni> f1 translates to what?
[21:14:08] <jmkasunich> "the OK key", that is another physcial thing?
[21:14:10] <rayh> or put a second out on that button in cl and pull the reset pin
[21:14:12] <alex_joni> you're in ESTOP..
[21:14:49] <anonimasu> jmkasunich: or well it might be the estop button..
[21:15:02] <anonimasu> jmkasunich: or a key to reset the estop condition
[21:15:04] <alex_joni> grrr.. I'm lost
[21:15:09] <alex_joni> <rayh> or put a second out on that button in cl and pull the reset pin
[21:15:10] <jmkasunich> me too
[21:15:12] <alex_joni> what button?
[21:15:16] <SWPadnos> ray - I'm not getting what you're asking for (or telling us :) )
[21:15:21] <anonimasu> the schools here do it that way
[21:15:49] <rayh> press the external estop button and you get estop throughout the software.
[21:15:50] <alex_joni> anonimasu: 2 ways to reset the estop latch
[21:16:13] <alex_joni> rayh: go on..
[21:16:15] <anonimasu> *listens*
[21:16:25] <rayh> Hold that pin or button in the pressed state and the system will NOT come out of estop no matter how hard we try elsewhere.
[21:16:33] <alex_joni> rayh: go on..
[21:16:42] <SWPadnos> he's typing ;)
[21:16:51] <jmkasunich> +---| A |----| B |--+--| C |---+----(C)----+
[21:16:52] <jmkasunich> | | | |
[21:16:52] <jmkasunich> | +--| D |---+ |
[21:16:56] <rayh> Release that button or pin and nothing appears to happen.
[21:17:09] <rayh> but you can now come out of estop by pressing f1
[21:17:28] <alex_joni> ok.. so what does F1 send? ESTOP_RESET?
[21:17:29] <rayh> or pulling the estop-reset pin from iocontrol
[21:17:36] <rayh> Yes
[21:17:48] <rayh> It is a toggle however.
[21:17:49] <anonimasu> rayh: so even if the big red button is pushed you can override it from software=
[21:17:54] <jmkasunich> A is GUI's "mushroom button", B is an external button, C is the main ESTOP relay/contactor that kills everything (and EMC gets the same signal to kill internal stuff)
[21:17:57] <jmkasunich> D is the reset
[21:18:01] <rayh> We can fix that in the gui if we need to.
[21:18:32] <anonimasu> jmkasunich: seems sane
[21:18:34] <jmkasunich> asserting D cannot energise C unless A and B are OK
[21:18:45] <jmkasunich> A and D come from iocontrol
[21:18:53] <jmkasunich> B is the outside world
[21:19:03] <jmkasunich> C is in CL, and drives both the outside world, and iocontrol
[21:19:07] <alex_joni> jmkasunich: where is enable-on in that picture?
[21:19:15] <jmkasunich> A
[21:19:22] <SWPadnos> are you looking for a way to use that external switch as a "pause" - ie, emc is stopped when it's held, and ready (not stopped) when it's not held?
[21:19:24] <jmkasunich> I think, enable-on isn't much better as a name
[21:19:46] <alex_joni> enable-out.. sorry
[21:19:52] <alex_joni> enabled?
[21:19:54] <jmkasunich> ok, that is A
[21:19:57] <jmkasunich> enabled is C
[21:20:01] <rayh> Not pause. That gets us all wrapped up with the state of the interpreter and scale and such
[21:20:05] <SWPadnos> emc-is-enabled-at-the-moment-out
[21:20:35] <SWPadnos> OK - but outside of naming, is that the functionality you're asking about?
[21:20:39] <anonimasu> hm I'd like a pause button..
[21:20:50] <alex_joni> anonimasu: wth are you talking about?
[21:20:52] <jmkasunich> stick to topic at hand
[21:20:52] <SWPadnos> damn - sorry for the name choice
[21:20:58] <dmess> feed hold??
[21:21:01] <anonimasu> yeah..
[21:21:02] <rayh> me to but that is the hardware operator panel interface
[21:21:20] <alex_joni> that has ABSOLUTELY nothing to do with estop
[21:21:21] <jmkasunich> drop it - we're talking about estop reset here
[21:21:53] <rayh> I don't want c to be a reset button
[21:22:04] <jmkasunich> C isn't, D is
[21:22:26] <SWPadnos> so you want auto-estop-reset?
[21:22:29] <jmkasunich> C is what enables or disables the entire machine
[21:22:33] <rayh> good.
[21:22:51] <rayh> D or f1 enables
[21:22:57] <alex_joni> D is F1
[21:22:57] <jmkasunich> to enable the machine (energise C), you must assert D
[21:23:15] <jmkasunich> F1 doesnt exist out here in CL land
[21:23:16] <alex_joni> F1 goes to iocontrol which asserts D
[21:23:21] <jmkasunich> right!@
[21:23:43] <jmkasunich> and if you want a physical one, you can do that instead
[21:23:54] <rayh> ah but what then changes the state of estop to enable from the cl land?
[21:24:20] <alex_joni> the same one
[21:24:25] <alex_joni> but driven by a pin
[21:24:26] <jmkasunich> question is ambiguous
[21:24:29] <SWPadnos> logic dependent
[21:24:42] <SWPadnos> estop has only two states - asserted or not asserted
[21:24:54] <jmkasunich> C is either energise or its not
[21:24:54] <alex_joni> jmkasunich: can you have 2 writers to one pin?
[21:25:03] <jmkasunich> not in general
[21:25:07] <alex_joni> only with OR I think..
[21:25:16] <jmkasunich> (gets into tri-state, don't wanna go there0
[21:25:21] <SWPadnos> been there ;)
[21:25:26] <alex_joni> so D is OR(iocontrol-F1, external-estop-reset)
[21:25:31] <rayh> What I don't want to happen the moment I release the big red external button
[21:25:41] <rayh> is have emc come out of estop.
[21:25:44] <jmkasunich> right
[21:25:48] <alex_joni> rayh: got that
[21:26:02] <jmkasunich> which is why the C contact and D exist
[21:26:03] <SWPadnos> you need ladder or blocks for that
[21:26:07] <rayh> I have to be able to release that button and go somewhere else and reset the estop
[21:26:13] <jmkasunich> exactly
[21:26:14] <alex_joni> maybe OR is not right NAND is (to pulse high)
[21:26:21] <jmkasunich> "that button" is B
[21:26:40] <jmkasunich> alex: lets not use and and or, just the ladder for a moment
[21:26:50] <alex_joni> ok.. in terms of ladder
[21:26:50] <rayh> so writing out your ladder in plain english says
[21:26:50] <jmkasunich> pulling out B when C is off, C remains off
[21:27:10] <SWPadnos> "pulling out" means making contact
[21:27:14] <jmkasunich> yes
[21:27:15] <alex_joni> may I say what I got so far?
[21:27:32] <jmkasunich> * jmkasunich shuts up (for a few nanoseconds)
[21:27:35] <SWPadnos> OK by me
[21:27:43] <alex_joni> ok.. so we got a working machine
[21:27:52] <alex_joni> A, B, C energized give (c)
[21:28:09] <jmkasunich> C contact and C coil are the same relay
[21:28:18] <alex_joni> that (c) goes to external stuff (driving power sources and whatever) and to emc (so emc knows everything is ok)
[21:28:24] <jmkasunich> yep
[21:28:29] <rayh> Ah then they can't be in the same line
[21:28:38] <jmkasunich> the heck they cant
[21:28:49] <SWPadnos> yes they can, as long as there's a parallel line to the contact
[21:28:50] <alex_joni> rayh: cl semantics is unimportant now
[21:29:14] <alex_joni> you can implement that with 2 lines, or only one should not matter..
[21:29:15] <rayh> I didn't see a parallel line
[21:29:18] <jmkasunich> rayh: are you using a fixed font? D is in parallel with C
[21:29:30] <SWPadnos> substitute A-B-D-(c) then put |c| on the lower line
[21:29:39] <SWPadnos> he did a standard latching relay line
[21:29:46] <jmkasunich> exactly
[21:29:47] <alex_joni> [22:37] <jmkasunich> +---| A |----| B |--+--| C |---+----(C)----+
[21:29:48] <alex_joni> [22:37] <jmkasunich> | | | |
[21:29:48] <alex_joni> [22:37] <jmkasunich> | +--| D |---+ |
[21:29:52] <jmkasunich> fscking fariable fonts
[21:30:12] <alex_joni> -A-B-C-(c)
[21:30:24] <alex_joni> and D in parallel with C
[21:30:27] <jmkasunich> yep
[21:30:31] <jmkasunich> assume all open to start
[21:30:33] <alex_joni> A = emc enabled
[21:30:35] <jmkasunich> close A, nothign happens
[21:30:39] <jmkasunich> close B, nothing happens
[21:30:48] <alex_joni> B = all external stuff enabled (= no estop)
[21:31:01] <jmkasunich> momentarily close D (estop reset), C closes and latches closed because C bypasses D
[21:31:03] <alex_joni> C only closes if it's driven, to drive it you need to enable D
[21:31:05] <rayh> Ah but if A is enabled, we are not in estop any more anyway.
[21:31:08] <jmkasunich> open D, C remains on
[21:31:22] <jmkasunich> momentarily open A or B, and C drops out, and remains out
[21:31:26] <SWPadnos> ding! race condition applies, I think
[21:31:32] <alex_joni> yes SWPadnos
[21:31:36] <alex_joni> A won't go on..
[21:31:49] <alex_joni> because it's driven by (C)
[21:31:58] <jmkasunich> A is NOT NOT NOT driven by emc's internal state
[21:32:07] <alex_joni> then by whom?
[21:32:14] <jmkasunich> A ONLY represents the state of the estop button on the GUI
[21:32:20] <rayh> but A's state is determined by B
[21:32:21] <SWPadnos> ah
[21:32:30] <jmkasunich> A means that a user has requested a stop by pressing that red button
[21:32:31] <jmkasunich> it
[21:32:37] <jmkasunich> it's just like any other red button
[21:32:40] <SWPadnos> no - it's another switch, just a "software" switch (chain)
[21:32:56] <SWPadnos> strike chain from that
[21:33:06] <jmkasunich> B is external button(s), could be many of them in series
[21:33:19] <alex_joni> jmkasunich: so when a user presses F1 (that ray likes) A and D get turned on
[21:33:23] <rayh> IMO
[21:33:41] <jmkasunich> A turns on, D momentarily turns on
[21:33:44] <rayh> we have three lines through iocontrol
[21:33:46] <SWPadnos> A turns on, and D outputs a strobe
[21:33:50] <jmkasunich> yes
[21:34:10] <rayh> forget strobes and complex interrelationships
[21:34:16] <alex_joni> right.. ok back to the running machine
[21:34:19] <jmkasunich> although I'd prefer that A on/off and D pulse are two separate NML messages
[21:34:33] <alex_joni> A,B,C enabled
[21:34:43] <alex_joni> now there's an external estop event, B goes low
[21:34:53] <alex_joni> automatically C goes low, and emc enters stopped mode
[21:34:58] <jmkasunich> "B opens" (using relay terms)
[21:35:08] <alex_joni> when B closes, nothing happens
[21:35:27] <alex_joni> only when user presses F1 to shortly enable D, C will close too
[21:35:48] <alex_joni> that short signal to enable D might come from hardware too (enable button on the hardware panel)
[21:35:54] <jmkasunich> right
[21:36:23] <jmkasunich> and somebody like Jymm who doesn't want to see an estop on the GUI at all, would eliminate A, but still let F1 drive D
[21:36:31] <rayh> I'm totally disconnected by A above
[21:36:52] <alex_joni> rayh: you need to split the F1 button into 2 different things
[21:37:03] <rayh> no problem
[21:37:17] <alex_joni> one is the status of emc (enabled or not)
[21:37:29] <alex_joni> and the other is the user pressing enable or disable
[21:37:31] <rayh> f1 sends either a stop the damn thing or start the damn thing
[21:37:40] <alex_joni> yes
[21:37:51] <jmkasunich> F1 sends either stop the damn thing, or TRY to start the damn thing
[21:37:59] <alex_joni> but that relates to two things..
[21:38:01] <jmkasunich> external estops (B) can still prevent ths tart
[21:38:04] <rayh> If we are talking about stop the damn thing then lets do it the easiest way from either gui or cl
[21:38:07] <jmkasunich> s/ths/the/
[21:38:08] <alex_joni> stop the damn thing = brake A
[21:38:15] <jmkasunich> exactly
[21:38:16] <alex_joni> start the damn thing = issue D
[21:38:31] <jmkasunich> close A if open, then issue D
[21:38:38] <alex_joni> yes
[21:38:44] <alex_joni> even more precise
[21:38:56] <rayh> and holding down "stop the damn thing" prevents d or start the damn thing from doing anything
[21:38:57] <jmkasunich> if you stopped it with F1, A will be open, if it stopped due to external estop, A is still closed
[21:39:04] <jmkasunich> right
[21:39:17] <alex_joni> so if user presses F1, A is open
[21:39:24] <alex_joni> no external button can switch it on
[21:39:28] <rayh> so how does a get reset so that the rest of the chain can come alive
[21:39:33] <alex_joni> err.. strike that
[21:39:56] <jmkasunich> if C is on, and user presses F1, A goes off
[21:40:09] <rayh> <alex_joni> no external button can switch it on ---- this is exactly what we have now and is causing much of the problem
[21:40:11] <jmkasunich> if C is off, and user presses F1, A goes on, and D is issued
[21:40:34] <alex_joni> rayh: not really.. different thing
[21:40:54] <alex_joni> let's try this with a different approach..
[21:41:08] <alex_joni> rayh: can you think of a scenario? and we'll say if it works or not
[21:41:12] <jmkasunich> rayh: remember, D is a CL contact, we've been talking as if it is controlled only by F1, but you could use an external reset buttin instead of F1, or in parallel with the exsiting D
[21:41:45] <rayh> Okay. Then we do not need D in the estop chain drawn above.
[21:41:59] <alex_joni> it is NOT in the estop chain
[21:42:06] <alex_joni> it is used only for enabling C
[21:42:08] <jmkasunich> without D, you can never turn C on
[21:42:24] <rayh> Why do we need C then if A can do the job
[21:42:37] <alex_joni> A cannot do the job..
[21:42:44] <alex_joni> A is a precondition to turning C on
[21:42:48] <alex_joni> same is B
[21:42:48] <rayh> when is a on or off
[21:42:51] <jmkasunich> but not the only condition
[21:43:05] <alex_joni> rayh: lets rewind again
[21:43:10] <rayh> Hold it. I think we are lost in ladder here.
[21:43:31] <rayh> What turns A on or off?
[21:43:41] <alex_joni> the USER
[21:43:45] <alex_joni> F1 on / off
[21:43:53] <rayh> And that is all?
[21:43:55] <jmkasunich> iocontrol, in response to NML messages sent by the GUI when the user hits F1
[21:44:01] <alex_joni> yes
[21:44:07] <jmkasunich> (me is being detailed)
[21:44:32] <alex_joni> hmmm.. A also needs turned off by emc status
[21:44:40] <jmkasunich> why?
[21:44:50] <rayh> Why does A not turn off in response to an estop from external
[21:44:52] <alex_joni> no it doesn't ..
[21:44:59] <rayh> why
[21:45:03] <alex_joni> because A is not the status of EMC estop
[21:45:06] <jmkasunich> because A represents a red mushroom that is part of the GUI
[21:45:10] <alex_joni> A is only the wish of the user
[21:45:17] <alex_joni> if the USER wants estop or not
[21:45:24] <jmkasunich> just because someone else hits a different mushroom, doesn't mean the GUI one gets pressed
[21:45:32] <alex_joni> the status of EMC is actually the output from C
[21:45:36] <SWPadnos> A is the equivalent of e.g., a coolant low sensor - just another switch in the stop chain
[21:45:42] <jmkasunich> yep
[21:45:43] <SWPadnos> it
[21:46:03] <alex_joni> rayh: let's take it again one by one..
[21:46:05] <SWPadnos> it's just there to explicitly separate GUI or other user controls from machine-related controls
[21:46:07] <rayh> Then I don't need A
[21:46:18] <rayh> cause I've got NML to set c for me.
[21:46:28] <SWPadnos> you do if you want a stop button in your GUI
[21:46:29] <alex_joni> C is not output from EMC
[21:46:31] <rayh> and if the external red button could do the same
[21:46:33] <jmkasunich> no, C is a CL coil, NML can't fsck with it
[21:46:33] <alex_joni> C is input
[21:46:44] <alex_joni> ok.. rewind everybody..
[21:46:51] <alex_joni> * alex_joni starts from scratch
[21:46:54] <rayh> You just said that c was the emc's estop state.
[21:46:57] <alex_joni> listen for a while
[21:47:01] <rayh> k
[21:47:12] <jmkasunich> emc gets its state from C
[21:47:15] <alex_joni> A = button state from the USER (user wants stop or not)
[21:47:16] <jmkasunich> but C is real
[21:47:30] <alex_joni> ----------------------------------------------------------------------------------
[21:47:32] <alex_joni> A = button state from the USER (user wants stop or not)
[21:47:56] <alex_joni> B = external estop stuff (anything else wants stop or not, including estop mushrooms and whatever)
[21:48:11] <alex_joni> C = sustained contact
[21:48:23] <jmkasunich> C = a relay, not a contact
[21:48:53] <alex_joni> C = relay (sorry)
[21:49:02] <rayh> We are working much to hard on this.
[21:49:08] <alex_joni> (C) = output from the chain will give emc it's estop status
[21:49:22] <jmkasunich> and will turn off everything in hardware
[21:49:27] <rayh> We are designing stuff that need not be around at all
[21:49:36] <jmkasunich> I disagree
[21:49:40] <rayh> What is the simplist way to set the estop state in emc
[21:49:55] <alex_joni> rayh: yes.. what is it? I haven't seen a simple way..
[21:50:05] <jmkasunich> wth do you mean when you keep saying "set the estop state in emc"?
[21:50:25] <alex_joni> GUI doesn't set estop state
[21:50:29] <alex_joni> iocontrol does
[21:50:32] <rayh> I seem to remember something about a state variable with three possible states 1, 2, 4
[21:50:39] <jmkasunich> frankly emc's internal estop state is an afterthought - you MUST turn off an external relay to stop things, then at your leisure you can tell emc what happened
[21:50:58] <rayh> k
[21:51:03] <jmkasunich> yeah, I rememver that state varaible
[21:51:06] <alex_joni> rayh: and input to that state variable is (C) above
[21:51:10] <rayh> you do and I'll see if I can break it.
[21:51:15] <alex_joni> not C, not B, not A, not D
[21:51:16] <jmkasunich> if C is off, that state is forced to 1
[21:51:26] <alex_joni> (C)
[21:51:32] <jmkasunich> if C is on that state goes to 2 (and later to 4 on "machine on")
[21:51:38] <rayh> NO
[21:51:51] <jmkasunich> why not?
[21:51:52] <alex_joni> rayh: what no?
[21:51:52] <rayh> That is exactly the problem we have with it now.
[21:52:05] <jmkasunich> wtf are you talking about
[21:52:12] <alex_joni> rayh: right now the polarity is inversed
[21:52:12] <rayh> Releassing the external estop should not reset state at all
[21:52:19] <alex_joni> and I am about to change that...
[21:52:25] <rayh> It is more than a polarity reversal.
[21:52:34] <alex_joni> releasing the external estop won't reset the state
[21:52:36] <rayh> I should have to press something to get estop to reset
[21:52:38] <jmkasunich> and it doesn't, if you have a ladder rung as shown
[21:52:39] <SWPadnos> looking at emc.hh, there are exactly two estop-related messages
[21:52:41] <alex_joni> to reset (C) you need to turn D on
[21:52:45] <SWPadnos> ESTOP_ON, and ESTOP_OFF
[21:52:48] <alex_joni> SWPadnos: shush for a while pleas
[21:52:53] <SWPadnos> k
[21:52:55] <alex_joni> we know that..
[21:53:09] <alex_joni> rayh: if you have :
[21:53:24] <alex_joni> the ladder that jmk did above...
[21:53:27] <rayh> but d only exists in the ladder
[21:53:37] <alex_joni> what do you mean?
[21:53:45] <alex_joni> D is a pin that comes from the GUI
[21:53:45] <jmkasunich> D is a ladder contact, driven by an output from iocontrol
[21:53:49] <alex_joni> or from hardware
[21:53:59] <rayh> lets just do the reversal of the two pins and see what comes of it.
[21:54:12] <rayh> rather than trying to get our heads around this.
[21:54:23] <alex_joni> rather than trying to get your head around this :P
[21:54:40] <jmkasunich> yeah ;-)
[21:54:44] <alex_joni> rayh: you know how a self sustained relay works..
[21:55:00] <rayh> * rayh knows nothing
[21:55:09] <alex_joni> imagine this:
[21:55:10] <jmkasunich> standard two button motor starter
[21:55:23] <jmkasunich> NO start button, NC stop button
[21:55:29] <alex_joni> 24V----|A|-----|B|------|C|-----(C)
[21:55:35] <jmkasunich> NO aux on the contactor in parallel with start
[21:55:47] <jmkasunich> press start, contactor closes, aux bypasses start, you can release start
[21:55:56] <jmkasunich> press stop, contactor drops out
[21:56:02] <jmkasunich> you've seen a million of em
[21:56:17] <jmkasunich> A and B are stops
[21:56:28] <alex_joni> 24V----|A|----|C|----(C) to make it simpler
[21:56:30] <jmkasunich> contact C is the NO aux on the contacor
[21:56:38] <jmkasunich> coil C is the contactor
[21:56:42] <jmkasunich> D is the NO start
[21:56:51] <rayh> The latching systems I've seen are two lines not one but go ahead.
[21:57:09] <jmkasunich> the ladder I sent was two lines
[21:57:14] <alex_joni> the second line is missing in that picture
[21:57:15] <jmkasunich> if you only see one, that explains a lot
[21:57:20] <alex_joni> [22:37] <jmkasunich> +---| A |----| B |--+--| C |---+----(C)----+
[21:57:20] <alex_joni> [22:37] <jmkasunich> | | | |
[21:57:20] <alex_joni> [22:37] <jmkasunich> | +--| D |---+ |
[21:57:39] <jmkasunich> alex, that wraps, let me send the original
[21:57:40] <jmkasunich> +---| A |----| B |--+--| C |---+----(C)----+
[21:57:40] <jmkasunich> | | | |
[21:57:41] <jmkasunich> | +--| D |---+ |
[21:57:53] <rayh> Ido I have access to font change on the fly with ksirc?
[21:58:02] <jmkasunich> yes
[21:58:10] <jmkasunich> go to the server control window
[21:58:19] <jmkasunich> click settings in the menu bar
[21:58:21] <jmkasunich> then fonts
[21:58:30] <alex_joni> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?ESTOPStuff
[21:58:37] <alex_joni> that's easier
[21:58:40] <rayh> thanks
[21:59:06] <alex_joni> now.. if you look at that picture..
[21:59:14] <alex_joni> we need to turn on (C)
[21:59:22] <alex_joni> for that to work we need A, B and D
[21:59:34] <alex_joni> D only momentarely, after that C will sustain itself
[21:59:35] <rayh> k
[21:59:39] <alex_joni> ok so far?
[21:59:45] <rayh> so I can't do that from the control panel
[21:59:52] <rayh> I must do it from cl
[22:00:04] <alex_joni> control panel is connected to cl
[22:00:05] <rayh> make a button, make a relay
[22:00:23] <alex_joni> those connections can be done in CL or in real hardware
[22:00:26] <alex_joni> either way..
[22:00:29] <rayh> Let me put it this way, I can't restart from a gui>
[22:00:34] <alex_joni> yes you can
[22:00:41] <alex_joni> but the GUI needs to drive D
[22:00:46] <jmkasunich> that's exactly what we're talking about
[22:01:01] <jmkasunich> a bit out of iocontrol, that can be used to drive D
[22:01:03] <alex_joni> you don't need to worry how it will do it..
[22:01:14] <SWPadnos> hold on - ray - are you saying that you can't, or that you don't want to be able to?
[22:01:15] <rayh> And what will my display show when A, B, and D are closed.
[22:01:26] <rayh> can't
[22:01:26] <alex_joni> ESTOP_RESET
[22:01:52] <SWPadnos> bu tyou want to be able to , assuming that all external contacts are in a "non-estop" state
[22:01:55] <rayh> And that is exactly what I do not want it to say, cause I'm in estop.
[22:02:00] <rayh> out there in the world.
[22:02:04] <alex_joni> but you pushed D !!!!!!!!!!!
[22:02:06] <jmkasunich> when A and B are closed, and D has (momentarily) closed, and C has latched in, your display will say that EMC is ready to run (I believe that is ESTOP RESET on Tkemc, something else on mini)
[22:02:13] <rayh> I dnd't push d
[22:02:23] <alex_joni> <rayh> And what will my display show when A, B, and D are closed.
[22:02:31] <jmkasunich> if B is close, then you are NOT in estop out in the world
[22:02:48] <rayh> I've not pulled in the C relay
[22:02:57] <jmkasunich> yes you did
[22:02:59] <alex_joni> hang on ray..
[22:03:10] <alex_joni> A closed means USER does NOT want stop
[22:03:21] <alex_joni> B closed means external does NOT want stop
[22:03:25] <jmkasunich> +---| A |----| B |--+--| C |---+----(C)----+
[22:03:25] <jmkasunich> | | | |
[22:03:25] <jmkasunich> | +--| D |---+ |
[22:03:30] <jmkasunich> oops, sorry
[22:03:47] <SWPadnos> reload the wiki page :)
[22:03:54] <alex_joni> C closed means everything ok, emc goes to ESTOP_RESET
[22:03:56] <jmkasunich> D closed (momentary) means USER does want OUT of ESTOP
[22:03:58] <rayh> but until I press it D holds that relay open
[22:04:19] <alex_joni> ok.. let's start with a non-functional machine
[22:04:23] <alex_joni> machine is stoped
[22:04:33] <alex_joni> A is open, B is open (external estop), C is open
[22:04:34] <jmkasunich> A open, B open, D open, C off
[22:04:52] <rayh> sorry guys It's just that I struggled with this for much to long at Mazak
[22:04:57] <rayh> and several days here.
[22:05:03] <alex_joni> first you will want to F1, A goes on, D goes on, nothing happens because B is off
[22:05:19] <jmkasunich> rayh: first thing - we are not in ANY way describing what exists right nwo
[22:05:20] <jmkasunich> now
[22:05:20] <rayh> Wait why would B be open.
[22:05:26] <alex_joni> the user will have to resolve external ESTOP conditions..
[22:05:32] <alex_joni> * alex_joni assumed so...
[22:05:35] <alex_joni> next case:
[22:05:37] <jmkasunich> we already know that what exists now has problems, forget it, forget the struggles
[22:05:46] <jmkasunich> we are talking about what we intend to implement
[22:05:46] <alex_joni> A open, B=closed, C=open, D=open
[22:05:51] <rayh> If the machine was shut down normally, there would be no external estop condition.
[22:05:58] <alex_joni> B=closed means no external estop
[22:06:01] <jmkasunich> right
[22:06:17] <rayh> Um I'd do the the other way round.
[22:06:23] <rayh> but okay.
[22:06:27] <jmkasunich> why?
[22:06:28] <alex_joni> now.. user presses F1-> A=closed, B=closed, D=closed -> C=closed
[22:06:34] <alex_joni> machine goes to ESTOP_RESET
[22:06:48] <rayh> nah
[22:06:48] <jmkasunich> D immediately opens back up
[22:06:54] <jmkasunich> why not
[22:06:58] <alex_joni> it stays that way till either A goes off or B goes off..
[22:07:23] <rayh> and the display does not change to follow the state of the external relay?
[22:07:39] <jmkasunich> it does change - the display is driven by the external realy
[22:07:51] <rayh> and what does it say now?
[22:07:59] <rayh> Hi Pete
[22:08:07] <petev> hi ray
[22:08:11] <alex_joni> A=closed, B=close, C=closed -> ESTOP_RESET
[22:08:13] <jmkasunich> it says "ESTOP RESET" or whatever the fuck it says when emc is ready for F2
[22:08:25] <alex_joni> jmkasunich: easy now.. :P
[22:08:41] <rayh> so there would be no difference in the display between A,B,D closed
[22:08:51] <jmkasunich> more precisely, C= closed = ESTOP_RESET, we don't care about A or B
[22:08:53] <rayh> and A,B,C,D closed
[22:09:06] <alex_joni> rayh: no, but D is only for a period.. so shouldn't matter
[22:09:13] <jmkasunich> assuming the ladder is as shown, A,B,D closed, C closes 1 ms later
[22:09:41] <rayh> I didn't see any timer that would do that?
[22:09:49] <jmkasunich> the ladder runs every 1mS
[22:10:04] <rayh> So we have hardcoded in a estop reset
[22:10:06] <rayh> again
[22:10:14] <jmkasunich> "hardcoded
[22:10:16] <jmkasunich> "?
[22:10:21] <jmkasunich> this is in CL
[22:10:44] <alex_joni> on a simple system without external estop, you only loopback C to A
[22:10:48] <rayh> Words fail at this project
[22:10:52] <jmkasunich> they sure do
[22:11:00] <alex_joni> on a system with external ESTOP you need some logic
[22:11:13] <jmkasunich> damn, ray, this is incredibly simple
[22:11:14] <alex_joni> either in CL (like jmkasunich did) or in external hardware (relays)
[22:11:26] <rayh> I was imagining a pin out of iocontrol that was high when emc's state was reset
[22:11:38] <rayh> and was low when emc's state was estopped
[22:11:51] <jmkasunich> you are assuming a pin that is driven by emc's state
[22:11:58] <rayh> Yes
[22:12:02] <jmkasunich> we are assuming emc's state is driven by a pin
[22:12:19] <jmkasunich> you sound like you want to do the latching inside emc
[22:12:21] <rayh> Well that would be there also
[22:12:30] <jmkasunich> we want to latch in CL (or a real relay)
[22:12:37] <SWPadnos> it's both - you're talking about an ESTOP-RESET command, and that cna go on an output from IOcontrol
[22:12:53] <SWPadnos> "emc-ready"
[22:12:54] <alex_joni> we're wasting too much time on this..
[22:13:05] <rayh> just put a pin in iocontrol that says "estopped" to emc when
[22:13:06] <jmkasunich> only a command though - it has absolutely no effect on state until it goes thru the ladder and comes back as C
[22:13:10] <alex_joni> * alex_joni goes back to coding...
[22:13:14] <SWPadnos> exactly
[22:13:27] <SWPadnos> iocontrol (/emc) is controlled by estop-in
[22:13:38] <rayh> okay I'll test what you do. Trust me guys we have made progress.
[22:13:46] <SWPadnos> it signals that it has no problems (is not estopped) on emc-ready (or whatver)
[22:13:52] <jmkasunich> the "estopped" input pin was never an issue IMO
[22:14:04] <jmkasunich> nor was the enable-out (our A)
[22:14:06] <SWPadnos> no - it's the status that's the problem
[22:14:07] <jmkasunich> the issue is D
[22:14:11] <alex_joni> ok.. lets drop that
[22:14:22] <jmkasunich> not yet ;-)
[22:14:25] <alex_joni> maybe we jumped over that too quickly
[22:14:32] <alex_joni> because it seemed clear to us
[22:14:32] <jmkasunich> I still think we should have another NML message
[22:14:42] <alex_joni> jmkasunich: there is a EMC_RESET message
[22:14:50] <alex_joni> well status.. :/
[22:14:53] <jmkasunich> is that a request, or a status
[22:15:06] <jmkasunich> naming sucks
[22:15:12] <SWPadnos> only two requests - ESTOP on and ESTOP off
[22:15:19] <jmkasunich> we should have a third
[22:16:37] <jmkasunich> the way I see it (and ray groked this when we were at roland's place)
[22:16:45] <SWPadnos> that's where the status pin comes in handy - it may just be (1) from way back, but it's a (1) that coimes back up to the GUI
[22:16:57] <jmkasunich> the GUI has a maintained contact button that is just like any other estop button
[22:17:16] <jmkasunich> I see the ESTOP_ON and ESTOP_OFF messages as telling the system the state of the GUI button
[22:17:54] <Jymmm> jmkasunich that doens't seem right for some reason.
[22:18:13] <jmkasunich> its not, those are badly named too
[22:18:14] <SWPadnos> all this depends on whether emc needs to have its own internal "latching relay"
[22:18:34] <jmkasunich> "emc" as in the GUI, or the iocontrol, or task, etc, should not have latching
[22:18:41] <SWPadnos> which would then require the "momentary start" that an ESTOP_RESET command would give
[22:18:54] <jmkasunich> because they're useless anyway for anything that needs speed or reliability
[22:19:21] <SWPadnos> no - think of emc as another motor contactor with a NO aux contact
[22:19:35] <SWPadnos> or as a plain contactor without the latching stuff
[22:19:59] <SWPadnos> if it's a plain contactor, then the estop input is the only thing that determines whether emc can run or not
[22:20:03] <jmkasunich> I want to use CL or a real relay for that, not some user space code that runs 10 times/sec
[22:20:25] <SWPadnos> OK - that's not important right now
[22:20:32] <jmkasunich> I think that is much of the confusion
[22:20:41] <SWPadnos> probably true
[22:20:50] <jmkasunich> ray thinks of emc's internal state as the master, but I think of the external relay as the master
[22:21:05] <SWPadnos> that could be it
[22:21:29] <SWPadnos> he was also looking at it from a user indicator point of view
[22:21:34] <Jymmm> jmkasunich (goes back to what I said about TDC you think?)
[22:21:39] <petev> guys I know I missed most of this
[22:21:46] <jmkasunich> lucky
[22:21:57] <petev> but isn't it simple to just think of emc as another contact in the estop chain?
[22:22:05] <SWPadnos> yes - very simple
[22:22:08] <petev> the status back to emc is the status of the estop chain
[22:22:15] <jmkasunich> but that is only part of it
[22:22:17] <petev> whether all hw or part sw in cl
[22:22:25] <SWPadnos> it depends on what you're calling "emc"
[22:22:42] <SWPadnos> which parts does emc include: HAL, ladder, iocontrol, task, GUI
[22:23:01] <petev> no, i would consider the estop contact the gui
[22:23:01] <jmkasunich> depends on who is talking, and about what
[22:23:01] <Jymmm> SWPadnos (Enhanced MASTER controller)
[22:23:08] <jmkasunich> BTW, you forgot CL
[22:23:13] <petev> as when the user presses the soft estop button/cmd
[22:23:38] <Jymmm> * Jymmm likes that term.... Soft stop.
[22:23:41] <alex_joni> petev: exactly what were saying
[22:24:10] <SWPadnos> I think ray had a problem with "reset"
[22:24:11] <jmkasunich> IMO, the entire mess is a result of trying to stuff too much stuff into one screen widget
[22:24:29] <jmkasunich> there should be one widget that is an estop button
[22:24:33] <jmkasunich> one that is an estop reset
[22:24:36] <SWPadnos> if you look at emc stop as a maintained contact, then the button doesn't change state when the machine goes into (e)stop
[22:24:38] <jmkasunich> and one that tells you the state
[22:24:45] <Jymmm> jmkasunich agreed
[22:24:59] <SWPadnos> agreed, but that doesn't change the underlying problem
[22:25:02] <Jymmm> jmkasunich (not that anyone gives a rat ass what I think =)
[22:25:19] <jmkasunich> once I catch a rat, I'll give you his ass
[22:25:21] <SWPadnos> the question is, what has to be done, and how is it done, to get the machine out of estop
[22:25:35] <Jymmm> jmkasunich: Um... thanks?!
[22:25:56] <jmkasunich> SWP: it does change the underlying problem in a way
[22:26:26] <SWPadnos> if the GUI button is a maintained contact in an estop chain, then the machine by default comes back on as soon as someone pulls out the red mushroom switch
[22:26:35] <jmkasunich> if we design logic that works properly with independent widgets, then we can let the GUI designer squish things into fewer any way he wants
[22:26:52] <SWPadnos> absoutely - that's why I say it's unimportant what the GUI looks like ;)
[22:27:00] <jmkasunich> the problem is that some of the logic is currently based on the single widget model, and that screws you when you want to do it any other way
[22:27:20] <Jymmm> SWPadnos: I *THINK* Ray want digital control of reset. Meaning even if ext estop is hit(mushroombutton), that he can hit something on the GUI and bring everything up and ready to go.
[22:27:41] <jmkasunich> Jymm, no he does NOT
[22:27:41] <alex_joni> no he's not
[22:27:44] <SWPadnos> no - I guarantee that's not what he wants
[22:27:50] <jmkasunich> he was adamantly arguing against that
[22:27:58] <Jymmm> Oh, ok.
[22:28:10] <SWPadnos> he wants the opposite - to make damned sure that the machine doesn't turn on as soon as you pull out that mushroom switch
[22:28:17] <alex_joni> what he doesn't want is removing an external ESTOP, and emc automatically switching from ESTOP to ESTOP_RESET
[22:28:25] <alex_joni> which is what is happening at the moment
[22:28:35] <Jymmm> that makes sense.
[22:28:38] <jmkasunich> only because he doesn't have the right CL rungfs
[22:29:04] <jmkasunich> IOW, he as integrator designed it to do exactly what it is doing, and he as integrator is capable of fixing it
[22:29:24] <Jymmm> heh
[22:29:26] <jmkasunich> I could write CL that would work as he wants right now, no iocontrol changes needed
[22:29:50] <jmkasunich> * jmkasunich is getting grouchy
[22:29:54] <Imperator_> every CNC controller i Know doesn't go out of estop if you pull the external estop button. You have to reset estop at the gui. And then you can go to auto mode again and start the program again !!!!
[22:29:58] <SWPadnos> heh - no shit, sherlock :)
[22:30:05] <SWPadnos> (jmk=sherlock)
[22:30:42] <alex_joni> Imperator_: that's what we are planing
[22:30:42] <Jymmm> Anyone hear about Kurt Bush?
[22:30:44] <jmkasunich> gets back to widgets again
[22:30:48] <alex_joni> some talking.. some actually doing.
[22:31:15] <Jymmm> jmkasunich your into nascar arent you?
[22:31:21] <alex_joni> jmkasunich: a warning in stepgen.c
[22:31:25] <jmkasunich> no
[22:31:28] <alex_joni> "cfg" not used..
[22:31:34] <Imperator_> I don't have wired a external estop to emc so im surprised that it does it not that way
[22:31:38] <jmkasunich> that's yabo
[22:31:51] <alex_joni> I know..
[22:31:56] <jmkasunich> he took out my original cfg="somestring" and replaced it with a array
[22:32:10] <jmkasunich> I'm not sure the array is portable to older kernels
[22:32:15] <alex_joni> I know.. I fixed the .hal's if you remember :)
[22:32:25] <jmkasunich> if it is, his way might be better
[22:32:31] <alex_joni> yup.. agreed
[22:32:44] <jmkasunich> but the docs need to be fixed
[22:32:46] <Imperator_> exevy chian Lathe has a swich which turns the machine off when you pull the wire out of the wall, so that it doesn't start automaticaly again
[22:32:57] <Imperator_> every china ....
[22:33:26] <alex_joni> ok.. back to serious stuff
[22:33:43] <alex_joni> is it gonna be "enable-out" and "enable-in" or "emc-enable-out" ?
[22:33:54] <jmkasunich> enable-out, enable-in
[22:33:56] <alex_joni> * alex_joni is about to change all .hal's ..
[22:34:02] <alex_joni> don't want to do it twice
[22:34:10] <jmkasunich> or maybe gui-enable-out, master-enable-in
[22:34:17] <Jymmm> alex_joni: RegEx is your friend.
[22:36:02] <jmkasunich> "gui-enable-out", "master-enable-in" ??
[22:36:20] <alex_joni> emc-enable-in
[22:36:46] <SWPadnos> emc - it's not a master, because it doesn't control external hardware
[22:36:52] <jmkasunich> true
[22:37:07] <Jymmm> engaged/disengaged
[22:37:08] <jmkasunich> in the HAL file, I'd call the "C" signal "master-enable"
[22:37:18] <jmkasunich> then send it to external HW and to emc-enable-in
[22:37:22] <alex_joni> jmkasunich: will you do the HAL files?
[22:37:24] <alex_joni> ;;)
[22:37:28] <jmkasunich> ok
[22:37:35] <jmkasunich> you do iocontrol, I'll do the hal
[22:37:42] <alex_joni> so : emc-enable-in and ....
[22:37:45] <jmkasunich> (and cl)
[22:38:03] <jmkasunich> gui-enable-out
[22:38:04] <alex_joni> any issue with breaking HEAD for a few hours?
[22:38:15] <jmkasunich> what kind of breakage?
[22:38:15] <alex_joni> then we might start working in parallel
[22:38:18] <SWPadnos> shall I cobble up something for attribute matching in halcmd?
[22:38:26] <SWPadnos> (as long as we're talking about breaking things)
[22:38:29] <jmkasunich> the filtering stuff?
[22:38:30] <jmkasunich> sure
[22:38:32] <SWPadnos> yep
[22:38:35] <SWPadnos> ok
[22:38:54] <jmkasunich> head will be broken between when you commit the new iocontrol and I commit the matching hal files
[22:38:55] <alex_joni> SWPadnos: only if you're sure that you'll have it working in a few hours
[22:39:09] <alex_joni> jmkasunich: whichever comes first
[22:39:11] <jmkasunich> well he doesn't have to commit until it works
[22:39:15] <SWPadnos> I'll not commit until it is at least equivalent to what already exists
[22:39:16] <alex_joni> but I also changed emc.cc && emc.hh
[22:39:26] <jmkasunich> adding a new NML?
[22:39:31] <alex_joni> also need to change emcsh & the guis
[22:39:34] <alex_joni> jmkasunich: yes
[22:39:44] <alex_joni> shall do this proper
[22:39:52] <jmkasunich> wow - so you've been doing while we've been yacking
[22:39:53] <alex_joni> also task gets busted up ;)
[22:39:57] <alex_joni> a bit..
[22:40:05] <alex_joni> so .. may I break HEAD? :P
[22:40:07] <jmkasunich> one problem
[22:40:19] <alex_joni> shoot
[22:40:25] <jmkasunich> I will only be up until about 11pm tonight, because i have to catch a plane tomorrow early
[22:40:33] <jmkasunich> and I will be away until Thurs
[22:40:37] <alex_joni> that's how many hours?
[22:40:41] <alex_joni> from now..
[22:40:42] <SWPadnos> roughly 100
[22:40:54] <jmkasunich> so anything broken that I can't fix by tonight stays broke
[22:41:02] <jmkasunich> about 5 hours
[22:41:05] <jmkasunich> and I have to eat
[22:41:07] <alex_joni> 5 should be enough..
[22:41:12] <alex_joni> I don't plan more than 3-4
[22:41:19] <alex_joni> [00:02] <alex_joni> I don't plan more than 3-4
[22:41:25] <alex_joni> make a branch?
[22:41:26] <SWPadnos> heh
[22:41:35] <jmkasunich> what a pain
[22:41:43] <jmkasunich> (branches that is)
[22:41:52] <SWPadnos> throw it into lerman-interp - shifts the blame as well :)
[22:42:16] <alex_joni> heck.. let's just start
[22:42:30] <alex_joni> and fix it .. I'll be able to work tomorrow too on this..
[22:42:33] <alex_joni> so no worries
[22:42:36] <jmkasunich> ok
[22:44:03] <alex_joni> to summarize: gui-enable-out, emc-enable-in and enable-reset?
[22:44:40] <jmkasunich> how about "request-enable" for the reset one?
[22:44:47] <alex_joni> ok..
[22:45:49] <Jymmm> Forget EMC for a moment... On machinery when hit hit the big red button to stop everything, then pull it out. Does every startup where it was before it was pushed?
[22:45:56] <petev> should it be gui-enable-request ?
[22:46:13] <jmkasunich> petev: perhaps
[22:46:22] <alex_joni> gui-request-enable
[22:46:24] <alex_joni> ?
[22:46:32] <SWPadnos> how about user- instead of gui-
[22:46:42] <jmkasunich> read my mind
[22:46:42] <SWPadnos> since it could be from e.g. a panel
[22:46:44] <alex_joni> stop changing the names..
[22:46:46] <jmkasunich> (and typed faster)
[22:46:51] <SWPadnos> keep using regexp :)
[22:46:53] <alex_joni> I renamed them 3 times already
[22:47:05] <jmkasunich> leave the names for last ;-)
[22:47:22] <alex_joni> well.. want to finish with iocontrol.cc then move on
[22:47:37] <alex_joni> so .. user-request-enable ?
[22:47:46] <jmkasunich> just put in "pin-formerly-known-as-A" and "pin-formerly-known-as-D"
[22:47:49] <SWPadnos> Jymmm, no - the machine should do nothing until you tell it it's OK. removing the emergency stop condition shouldn't be sufficient
[22:48:03] <petev> what is the convention, heirarchical naming or english language style?
[22:48:22] <jmkasunich> but once you do reset it, it should pick up where it left off, I think. was that the question?
[22:48:36] <jmkasunich> petev: you think we have a convention?
[22:48:50] <petev> probably should for consistency
[22:48:52] <SWPadnos> user-stop-request, user-enable-request, emc-enable-status
[22:49:10] <jmkasunich> stop_request has the wrong polarity,
[22:49:17] <jmkasunich> implies TRUE to stop
[22:49:25] <jmkasunich> user-enable-out
[22:49:40] <SWPadnos> no - two different things, I think
[22:49:43] <alex_joni> ok.. I changed them
[22:49:49] <SWPadnos> wait - how about ...
[22:49:51] <alex_joni> if you don't like them .. change them again
[22:49:59] <alex_joni> user-enable-out
[22:50:09] <jmkasunich> alex: stop that - all joking aside, we need good names
[22:50:28] <alex_joni> user-request-enable
[22:50:34] <alex_joni> and emc-enable-in
[22:50:42] <jmkasunich> user-enable-out = means user is willing to let the machine come out of estop
[22:50:48] <alex_joni> yes
[22:50:56] <jmkasunich> emc-enable-in says it is out of estop
[22:51:01] <alex_joni> yes
[22:51:42] <alex_joni> and user-request-enable = user requests machine to be enabled (turn on (C))
[22:51:44] <jmkasunich> user-enable-request or user-request-enable means the user wants to come out of estop (which is distinct from simply being willing for it to come out)
[22:51:54] <jmkasunich> yeah
[22:52:07] <jmkasunich> now let me throw something else out (while we're changin stuff)
[22:52:10] <alex_joni> ok.. so these will stick for now
[22:52:11] <jmkasunich> what about machine on?
[22:52:32] <alex_joni> that's in emc only for now.. and the amp enable in motion
[22:52:37] <alex_joni> might want to change that too
[22:52:41] <jmkasunich> currently there are no hooks to HAL for that
[22:52:45] <jmkasunich> there should be
[22:52:48] <Jymmm> could "machine on" also double as "reset enable"
[22:52:50] <Jymmm> ?
[22:53:00] <jmkasunich> for instance, machine on only when hydraulic pressure is ok
[22:53:30] <jmkasunich> something like "user-on-enable", "emc-machine-on", and "user-request-on"
[22:53:35] <Jymmm> jmkasunich sound like "machine ready" more than machine on
[22:53:48] <jmkasunich> machine-ready = out-of-estop
[22:53:48] <petev> what exactly is machine on supposed to be in the eyes of the emc creators, does it mean motion control is enabled?
[22:53:54] <Jymmm> assuming pump has to build up pressure
[22:53:56] <jmkasunich> machine-on = servos enabled
[22:54:06] <jmkasunich> petev: yes
[22:54:23] <alex_joni> brakes are off, motors are on
[22:54:33] <jmkasunich> the names I find most clear for the actual states are: estopped, ready, running
[22:54:58] <petev> in the current emc, the motion loop is only closed in running
[22:55:04] <jmkasunich> right
[22:55:05] <petev> I find that a pain
[22:55:12] <jmkasunich> why?
[22:55:29] <petev> it implies that the servos should be powered off in all other states
[22:55:34] <petev> rather than just disabled
[22:55:47] <petev> that means encoders don't work, etc
[22:55:49] <jmkasunich> no, powered off is estopped, ready means ready to go
[22:56:13] <jmkasunich> you can switch from ready to running to ready again without loosing position or anything
[22:56:21] <petev> so in ready, servos are on, but somehow disabled?
[22:56:32] <jmkasunich> servos are powered, but disabled
[22:56:40] <petev> ok
[22:56:52] <jmkasunich> DACs are outputting zero, PIDs are disabled, integrators held, etc
[22:57:05] <jmkasunich> actually integrators are reset
[22:57:10] <alex_joni> brakes might be on
[22:57:14] <jmkasunich> right
[22:57:20] <alex_joni> depending on the integrator really
[22:57:25] <petev> ok, so then you really need servo drives that pay attention to the amp enables for it to work
[22:57:37] <jmkasunich> kinda
[22:57:54] <jmkasunich> amps without enables will still do nothing when the DACs are zeroed
[22:58:03] <petev> not really
[22:58:12] <jmkasunich> ready is not intended to be a safe state for sticking your hands into the workspace
[22:58:13] <petev> theres is always offset and they will drift
[22:58:30] <jmkasunich> true
[22:58:38] <SWPadnos> then there's manual operation, using EMC as a DRO
[22:58:54] <petev> so if ready is not the safe state, do you have to estop?
[22:59:07] <jmkasunich> all this is up to the integrator
[22:59:11] <petev> that would mean loosing position
[22:59:28] <CIA-5> 03alex_joni * 10emc2/src/emc/nml_intf/ (emc.cc emc.hh): added EMC_AUX_ESTOP_RESET message. this message should be used by the GUI's to reset any ESTOP/ENABLE latch there is, be it in CL or in external HARDWARE
[22:59:40] <jmkasunich> on the mazak for example, encoder power is independent of servo amp power, so we can estop and retain position info
[23:00:16] <jmkasunich> if you have amps that power the encoders only when the amps are powered, and also begin running as soon as they are powered, then you are kinda screwed
[23:00:16] <petev> ok, but most smaller commercial drives have the encoder power integrated
[23:00:27] <jmkasunich> do they have enable inputs?
[23:00:32] <petev> most do
[23:00:41] <petev> but the cheap hobby stuff doesn't
[23:00:43] <jmkasunich> ok, so you can be powered but not enabled in ready
[23:01:04] <jmkasunich> question - why are the encoders connected to the amps at all anyway>
[23:01:06] <jmkasunich> ?
[23:01:20] <petev> most use encoder tracks for commutation
[23:01:26] <alex_joni> yeah..
[23:01:26] <Jymmm> estop,on,ready, running
[23:01:38] <petev> they output the encoder signal (possibly scaled) for use by controller
[23:01:40] <alex_joni> estop,ready, on, running
[23:01:45] <jmkasunich> you are talking about brushless DC aka AC servos?
[23:01:56] <jmkasunich> on and running are the same thing
[23:02:08] <jmkasunich> if not, explain the difference
[23:02:15] <jmkasunich> this gets to the runlevels thing
[23:02:18] <Jymmm> estop = obvious
[23:02:19] <petev> yes
[23:02:22] <jmkasunich> more than we want to tackle now
[23:02:34] <Jymmm> on = safe to put paws in and has DRO capabilities
[23:03:22] <Jymmm> ready = not safe for paws, but spin and movement capable (jog,etc)
[23:03:41] <Jymmm> running, obvious
[23:03:48] <jmkasunich> not so obvious
[23:04:02] <jmkasunich> running = running g-code, aka EMC's AUTO mode?
[23:04:12] <Jymmm> running == spinng and in motion.
[23:04:14] <jmkasunich> because sounds like your ON = EMC's MANUAL mode
[23:04:25] <Jymmm> jmkasunich correct
[23:04:50] <jmkasunich> for EMC, MANUAL, MDI, and AUTO are all "ON"
[23:05:34] <Jymmm> oh you want them seperate, ok.
[23:06:22] <Jymmm> I was tthinking on as also a test mode, calibration, etc.
[23:06:33] <petev> jymmm are you talking about a manual mode where you could use cranks?
[23:07:29] <Jymmm> petev: by ON and READY, yeah. Just something where it's safe for paws, but you don't lose postion.
[23:08:10] <Jymmm> petev: but jmkasunich explained that's in auto/manual/mdi
[23:08:32] <jmkasunich> no - auto/manual/mdi all have servos active
[23:08:39] <jmkasunich> in manual, you can jog, home, etc
[23:08:40] <petev> yeah, but you can't use cranks with servos on in the machine on state
[23:08:47] <jmkasunich> in mdi, you can execute single lines of g-code
[23:08:48] <petev> yes
[23:08:49] <SWPadnos> don't lose position meaning that the emcoders are on, or that the motors are maintaining position?
[23:08:52] <jmkasunich> in auto, you execute a program
[23:09:13] <jmkasunich> but you cannot crank, and it isn't really "paw safe"
[23:09:23] <SWPadnos> emcoders - is that us? :)
[23:09:25] <petev> meaning encoders are on and drives are not applying power to motors
[23:09:41] <jmkasunich> that is machine dependent
[23:10:00] <jmkasunich> on the mazak, encoders on, drives not powered = estopped
[23:10:08] <jmkasunich> encoders on, drives powered but not enabled = ready
[23:10:09] <Jymmm> sorry guys, didn't mean to start up something here.
[23:10:21] <jmkasunich> encoders on, drives powered and running, PID loops active = running
[23:10:47] <jmkasunich> if we implemented something like runlevels you could do what you are talking about
[23:10:55] <petev> ok, I think the best is to just have the flexibility to enable each block when appropriate
[23:10:58] <jmkasunich> but the impact is too widespread to tackle in the short term
[23:11:00] <Imperator_> that brings me to another problem. If the machine has a housing. When you open it, then the machine has to go into a save state (amps of breaks on) but i think it has not to go to estop. And if you want to find your zero point you need also jogging with open doors
[23:11:06] <petev> I think most of the enables are already there
[23:12:12] <alex_joni> jmkasunich: commit now the changes to iocontrol
[23:12:20] <alex_joni> jmkasunich: commiting now the changes to iocontrol
[23:12:25] <alex_joni> can you read the intro if it's ok?
[23:12:34] <jmkasunich> sure
[23:13:35] <SWPadnos> here's a snippet of an email I sent to the gecko list some time ago - relevant to the stop / state questions:
[23:13:41] <CIA-5> 03alex_joni * 10emc2/src/emc/iotask/ioControl.cc: changed the HAL pins regarding ESTOP/ENABLE, a detailed description at the beginning of the file
[23:13:42] <SWPadnos> It seems to me that there are at least four types of stop condition:
[23:13:44] <SWPadnos> 1) User Pause: The operator wants to pause a program, and will probably
[23:13:46] <SWPadnos> continue later (maybe a tool change or single stepping)
[23:13:48] <SWPadnos> 2) Limit: One or more axes has hit a limit switch
[23:13:49] <SWPadnos> 3) Fault: Some problem has occurred in the system
[23:13:51] <SWPadnos> 4) E-Stop: Somebody might get hurt - the machine HAS to stop all motion
[23:13:52] <SWPadnos> as quickly as possible.
[23:13:54] <SWPadnos> (I guess there'd be a '0' in that list as well - programmed stop, like
[23:13:55] <SWPadnos> prompt for tool change or end of program)
[23:13:57] <SWPadnos> There are then (at least) two issues to deal with for each stop
[23:13:58] <SWPadnos> situation: how are the motors stopped, and does the controller maintain
[23:14:00] <SWPadnos> (or keep track of) machine position? You can stop by slowing the motors
[23:14:01] <SWPadnos> to 0 speed, along the programmed contour (essentially doing a F0
[23:14:03] <SWPadnos> override), by decelerating all motors at the max rate simultaneously, by
[23:14:04] <SWPadnos> applying a braking resistor and power supply related techniques, or by
[23:14:06] <SWPadnos> applying a physical brake.
[23:14:07] <SWPadnos> You just have to decide how you want to deal with each level of stop
[23:14:09] <SWPadnos> condition. You can choose to make 2, 3, and 4 all act the same - limit
[23:14:10] <SWPadnos> = fault = estop = stop immediately, don't care about keeping track of
[23:14:12] <SWPadnos> position. Or, decide that you only want to lose position (if possible)
[23:14:14] <SWPadnos> in a true E-Stop situation, so that faults are recoverable. Any E-Stop
[23:14:15] <SWPadnos> should not depend on software (including firmware) - it should be a
[23:14:17] <SWPadnos> physical switch or set of switches that causes the machine to stop as
[23:14:19] <SWPadnos> fast as possible.
[23:15:02] <SWPadnos> this was in relation to some early discussions about estop and the G200x
[23:15:15] <CIA-5> 03alex_joni * 10emc2/configs/core_sim.hal: changed to work with the new enable/estop pins from iocontrol
[23:15:19] <jmkasunich> guys - look at this and tell me (or edit the wiki) what you think
[23:16:18] <jmkasunich> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl/emcinfo.pl?RunLevels
[23:17:12] <alex_joni> seen it already .. not sure :/
[23:17:20] <alex_joni> I mean.. I agree it's nice..
[23:17:28] <jmkasunich> it relates more to what Jymm has been talking about
[23:17:49] <jmkasunich> but it is also a more general approach to the estop mess
[23:18:19] <SWPadnos> yes, though making all the level transitions configurable isn't trivial
[23:18:35] <SWPadnos> also, for different machine types, there might be a different number of levels
[23:20:30] <Jymmm> What about 0-256, in 8 increments. That should give intergrators room to play.
[23:20:35] <alex_joni> jmkasunich: the EMC_RESET is a bitch
[23:21:01] <alex_joni> right now GUI talks only STATE to task
[23:21:04] <SWPadnos> wouldn't that be equivalent to 0-7? (other than the specifics of outputting state bits)
[23:21:10] <alex_joni> and task sends the NML messages to iocontrol
[23:21:30] <jmkasunich> GUI sends the state it wants?
[23:21:32] <Jymmm> SWPadnos: Sorta, but lets say an intergrator doesn't want a level 2, but not quite a level three.
[23:21:34] <alex_joni> yes
[23:22:05] <jmkasunich> well that's fscked
[23:22:06] <alex_joni> maybe sends the state it wants is not appropiate.. sets the state it wants
[23:22:32] <jmkasunich> * jmkasunich just can't deal with this anymore
[23:22:40] <jmkasunich> I want a fscking clean sheet of paper
[23:22:50] <SWPadnos> look at the handshaking to get from state to state
[23:22:51] <alex_joni> heh
[23:22:57] <SWPadnos> indeed
[23:23:27] <Imperator_> if someone doesen't want a state he sets the conditions for that state to true, then emc swiches imidiatly to the next state
[23:23:37] <Jymmm> SWPadnos: Like estop, you dont' want to remove power from the electric brakes (at least not immediately).
[23:24:03] <alex_joni> Jymmm: I usually have brakes that turn on when power is removed..
[23:24:21] <alex_joni> so estop cuts all power.. mechanically ;)
[23:24:28] <SWPadnos> sure, but I'm just thinging of what happens to eget from state to state, not what the machine does for any of those transitions (that's"machine logic")
[23:24:33] <Imperator_> Jymmm: the the PLC (CL) makes the delay that you want
[23:24:35] <Jymmm> alex_joni: I was talking with someone couple weeks ago that have brakes that engage with power.
[23:24:48] <SWPadnos> so, there's a request from somewhere to go up one state
[23:24:49] <Jymmm> (electric brakes)
[23:24:49] <alex_joni> bleah.. those are not safe
[23:25:02] <Jymmm> alex_joni no, but they do exists.
[23:25:18] <SWPadnos> they're good for slowing a spindle, for example
[23:25:19] <alex_joni> you're under the machine.. power goes down, and the machine lands on you.. no thank you
[23:25:34] <jmkasunich> we digress
[23:25:35] <SWPadnos> but not for preventing operators from getting crushed
[23:25:39] <petev> jmk:what type of mechanism did you envision for implementing the run levels?
[23:25:57] <petev> seems like CL would be tedious at best
[23:26:00] <jmkasunich> unknown, perhaps a HAL module (it would need to be in realtime IMO)
[23:26:08] <petev> agreed
[23:26:26] <SWPadnos> this could possibly be done with a "lookup table" module
[23:26:36] <SWPadnos> ie, it has some number of outputs, and an index input
[23:26:40] <petev> I suppose simple bit masks could be used on I/O for level changes
[23:26:51] <petev> but not very nice from the integrator standpoint
[23:27:11] <jmkasunich> it would want to have one output bit for each state
[23:27:14] <SWPadnos> given some input (runlevel), the corresponding outputs are set (enables for motion, power, brakes, estop, spindle, etc. etc.)
[23:27:23] <petev> SWP, that wastes a lot of rt mem
[23:27:48] <jmkasunich> oops: it would want to have one output bit for each runlevel
[23:27:55] <SWPadnos> not a lot - it's essentially a group of bits that can be OR'ed or piped into ladder
[23:28:02] <jmkasunich> the output bit for the active level, and all levels below, would be on
[23:28:09] <petev> ok, if you just want to map run level to enables
[23:28:14] <jmkasunich> so you can turn things on at any level
[23:28:18] <SWPadnos> no - one output bit for each subsystem controlled by runlevel
[23:28:27] <Imperator_> jmkasunich: and at least one input that has to be true to swich to the next higher runlevel
[23:28:31] <jmkasunich> CL can do that
[23:28:33] <petev> but if you want to check conditions for run levels, that would take a lot of mem
[23:28:50] <Imperator_> and if that pin goes low it has to jump one level back
[23:28:51] <SWPadnos> yes, but that has to be done "externally" to be configurable
[23:28:52] <jmkasunich> one input for each level, permits moving up to that level
[23:29:11] <jmkasunich> the actual runlevel module would have one output and one input per level
[23:29:17] <Jymmm> ok. Unplugged frm the wall (OFF), level 0. Making a mess all over the place producing swarf, Level 255. I'll let you folks fill in the blanks =)
[23:29:27] <jmkasunich> no numbers
[23:29:38] <jmkasunich> the total number of levels would be set by the integrator
[23:29:49] <jmkasunich> and they would have names (also set by the integrator)
[23:29:58] <jmkasunich> a sherline might only have 2
[23:30:15] <jmkasunich> a big machine might have 5, or even 10 (unlikely)
[23:30:25] <SWPadnos> I don't think you can have a single component manage runlevels for any arbitrary machine
[23:30:32] <jmkasunich> why not?
[23:30:38] <petev> jmk: so you're saying all logic done in CL, then routed to run level controller?
[23:30:43] <jmkasunich> yes
[23:31:08] <petev> so inputs to run level controller are the ok to go to each level?
[23:31:13] <jmkasunich> if three things have to be true to move to level X, then you check them in a CL rung and route to runlevel.level.X.enable
[23:31:18] <petev> outputs are the current level?
[23:31:22] <jmkasunich> yea
[23:31:36] <SWPadnos> ok - so your module is just a set of <n> groups of (at_state-x, state-x-OK, Go-to-state-X+1, etc)
[23:31:41] <petev> ok, what is request to change leve? I think another input is neede for that
[23:32:06] <jmkasunich> one possibility is just to have the module go to the highest enabled level
[23:32:18] <SWPadnos> no automatic level changes
[23:32:19] <petev> ok, I can see that
[23:32:27] <SWPadnos> not upward, anyway
[23:32:39] <petev> not really automatic, some input condition allowed it
[23:32:50] <jmkasunich> to bring it down from level 10 to level 3, you disable level 4
[23:32:57] <petev> could be a request pin in the logic
[23:33:12] <Jymmm> jmkasunich that makes sense.
[23:33:25] <SWPadnos> how about having a maxlevel HAL_BYTE input instead? :)
[23:33:31] <Imperator_> so if we do it in CL then we don't have to do so much at emc !! We only have to add a condition to some parts of emc that enables that part. For example one for Auto mode, one for Jog, ... that are not so much
[23:33:35] <jmkasunich> but that means that all the enables/disables need to be maintained
[23:34:02] <alex_joni> jmkasunich: CL coils
[23:34:18] <jmkasunich> we probably want a momentary condition to be able to push us down a level (or more) and not go back up until user asks
[23:34:26] <Jymmm> jmkasunich logical AND's
[23:34:45] <jmkasunich> actualy, the entire runlevel concept can be done in CL
[23:34:49] <SWPadnos> no - I don't think we want a motorcycle shifter here, at least, not only that
[23:35:57] <petev> I think the key is that there probably has to be another interface to the HAL component other than pins
[23:36:04] <jmkasunich> each level can be a single rung/coil
[23:36:11] <petev> is it time to figure out a NML connector?
[23:36:26] <petev> either to CL or in general?
[23:36:29] <jmkasunich> the problem is that NML and realtime are mutually incompatible
[23:36:42] <jmkasunich> iocontrol is already an NML/HAL interface
[23:36:56] <petev> yes, but it is pretty hard coded
[23:37:11] <SWPadnos> hold on - we're trying to figure out how to selectively enable/disable pieces of emc here, and to move between these enable/disable states, right?
[23:37:13] <petev> what about an nml connector that allows you to flip internal CL bits/words
[23:37:33] <Imperator_> SWPadnos: exactly
[23:37:37] <jmkasunich> not just pieces of emc, also pieces of external hardware
[23:37:39] <petev> ok, just jumping ahead to how the GUI would effect this
[23:37:51] <SWPadnos> sure - pieces of the machine, including emc internals
[23:37:51] <jmkasunich> hyduralic pump on in state X,
[23:38:16] <SWPadnos> VFD disabled in state Y, etc
[23:38:20] <jmkasunich> right
[23:38:40] <jmkasunich> and externals would also affect the transitions
[23:38:41] <SWPadnos> ok - this is what my array output component dows for you
[23:38:50] <SWPadnos> note that it could also be done in ladder
[23:38:56] <jmkasunich> can't transition to Z unless VFD is reporting ready to run
[23:39:22] <SWPadnos> that's machine logic, and should therefore be either in ladder or HAL blocks/other components
[23:39:30] <jmkasunich> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl/emcinfo.pl?RunLevels
[23:39:32] <Jymmm> Why cant the run level simply be linear?
[23:39:33] <jmkasunich> dammit
[23:39:44] <jmkasunich> 17:56:05] <jmkasunich> actualy, the entire runlevel concept can be done in CL
[23:40:03] <SWPadnos> yes - I agree
[23:40:12] <petev> jmk:agreed, but a bit tedious, at least without readable names
[23:40:20] <SWPadnos> it's just a question of whether another component might make it more straightforward
[23:40:25] <jmkasunich> right
[23:40:37] <petev> so maybe we need readable names in CL and a CL to NML connector?
[23:40:46] <Jymmm> jmkasunich any reason you saud earlier "no numbers" ?
[23:40:54] <SWPadnos> so - the decision of whether or not it's allowed to change levels is a separate question from what to do in a particular level
[23:40:57] <alex_joni> damn.. CL is hard to work with
[23:41:00] <alex_joni> jmkasunich: help :P
[23:41:03] <jmkasunich> numbers don't convey much information
[23:41:18] <jmkasunich> alex: what's up?
[23:41:23] <SWPadnos> and they would differ significantly from machine to machine
[23:41:28] <Jymmm> jmkasunich couldn't the number just be assigned labels (like symlinks)?
[23:41:32] <alex_joni> jmkasunich: can you add the rung we discussed to step_cl ?
[23:41:38] <jmkasunich> ok
[23:41:53] <jmkasunich> I've never tried step_cl yet, time to do that
[23:42:18] <SWPadnos> how does one fire up the CL editor under emc, anyway?
[23:42:33] <jmkasunich> Jymmm: flipping the question back at you: why numbers instead of names?
[23:42:37] <petev> you put the RT part in a HAL config
[23:42:49] <jmkasunich> and invoke the user part from the command line
[23:42:51] <petev> then lauch the user part (GUI) from a shell or whatever
[23:42:53] <SWPadnos> ok - then bin/classicladder will work
[23:43:04] <alex_joni> petev:you can put the UI in the HAL file aswell
[23:43:04] <petev> yes
[23:43:12] <jmkasunich> you probably want to exit the user part before you shut down the RT part
[23:43:16] <alex_joni> easier for the user..
[23:43:31] <alex_joni> jmkasunich: added classicladder to the KILL_TASK list in emc.run
[23:43:32] <jmkasunich> the average machine user doesn't want the ladder GUI on screen
[23:43:37] <alex_joni> so it is going down nicely..
[23:43:44] <Jymmm> jmkasunich: I only say numbers as then the intergrator can have as many or as little levels as they want as.
[23:43:51] <alex_joni> we'll remove it lateron..
[23:43:55] <petev> aj: yes, for loading without GUI, but probably not wanted with GUI
[23:43:55] <jmkasunich> oh, that's right - I remember seeing that commit
[23:44:44] <jmkasunich> Jymmm: names work that way to
[23:45:12] <jmkasunich> there probably would be numbers behind the names anyway
[23:45:28] <jmkasunich> if only to specify the order
[23:46:08] <jmkasunich> alex: back to the ESTOP_RESET problem
[23:46:12] <Jymmm> jmkasunich: True, or even the dot name space convention. Machine.user.gui.estop.status.reuest etc
[23:46:22] <Jymmm> request
[23:46:23] <jmkasunich> it sounds like the trouble is not in the GUI->TASK NML interface
[23:46:28] <SWPadnos> runlevel 3 on a sherline is probably "full auto", whereas on a Bridgeport (or Mazak), it may be "encoders on, motors off, not able to execute gcode"
[23:46:38] <jmkasunich> we have NML msgs for task->io for ON, OFF, RESET
[23:46:41] <alex_joni> task->iocontrol ?
[23:46:44] <jmkasunich> but the GUI messages are different
[23:46:49] <alex_joni> yes
[23:46:51] <SWPadnos> something "full auto" would be the highest on either
[23:46:58] <alex_joni> GUI-> task is setting states
[23:47:09] <alex_joni> task->iocontrol is NML messages
[23:47:52] <jmkasunich> dinner time... I'll think on this
[23:48:41] <alex_joni> can I have the rung first?
[23:48:48] <alex_joni> please.. to have something to work on
[23:50:50] <jmkasunich> I'm sorry, wife is calling, and I've never even run CL on this box
[23:51:00] <jmkasunich> * jmkasunich is very frustrated
[23:51:00] <alex_joni> ok...
[23:51:04] <alex_joni> n/m
[23:51:10] <alex_joni> I'll try to see what I can do ;)
[23:51:54] <SWPadnos> hmmm - when I run bin/classicladder, I get this:
[23:52:09] <SWPadnos> INIT SOCKET!!!
[23:52:11] <SWPadnos> Server socket init ok (modbus - port 9502)!
[23:52:13] <SWPadnos> SOCKET WAITING...
[23:52:25] <SWPadnos> and I can't use the GUI
[23:52:30] <jmkasunich> huh
[23:52:42] <SWPadnos> this is after loading the RT portion with the same line as in the mazak hal file
[23:52:43] <jmkasunich> it always says that socket stuff
[23:52:44] <alex_joni> did you start the RT part?
[23:52:48] <SWPadnos> this is after loading the RT portion with the same line as in the mazak hal file
[23:52:56] <petev> the user part has a modbus server embedded in it
[23:53:12] <SWPadnos> none of the GUI buttons do anything though
[23:53:14] <alex_joni> SWPadnos: try the step_cl stuff
[23:53:22] <alex_joni> so it starts?
[23:53:33] <SWPadnos> hold on a sec
[23:53:35] <alex_joni> you have Add/Insert, foo..
[23:53:40] <alex_joni> not sure how you use it though :D
[23:53:55] <jmkasunich> wtf? "Can't find variable SHMEM_KEY in section [EMCMOT] of file configs/step_cl.ini."
[23:54:02] <SWPadnos> yes, halcmd show comp lists classicladder_rt
[23:54:05] <jmkasunich> shouldn't need that variable
[23:54:20] <alex_joni> jmkasunich: run with -d
[23:55:06] <petev> aj: the CL gui is not the most intuitive
[23:55:14] <jmkasunich> strange: scripts/emc.run (no ini file) works OK, scripts/emc.run configs/emc.ini doesn;t
[23:55:23] <SWPadnos> :) I had noticed that a while ago
[23:55:23] <petev> it shows what it calls a rung as a grid
[23:55:24] <alex_joni> yeah..
[23:55:31] <petev> actually more like a group of rungs
[23:55:35] <jmkasunich> always fscking something - I gotta eat, deal with it later
[23:55:37] <alex_joni> sudo scripts/emc.run step_cl.ini
[23:55:47] <SWPadnos> enjoy your dinner
[23:55:49] <alex_joni> not configs/step_cl.ini
[23:56:32] <petev> the edit windo lets you insert(before current), add(after current) or edit(current) rung
[23:56:40] <petev> I never used the sections
[23:56:59] <petev> they are for different laguages (other than ladder), etc.
[23:57:11] <petev> there is a sequential language built in too
[23:57:18] <SWPadnos> hmmm - it looks like the problem is that you can't resize the section display
[23:57:36] <petev> don't need to see that one anyhow
[23:57:42] <petev> one section is all you will need
[23:57:55] <SWPadnos> as soon as you resize that, all controls stop working, and none of the windows redraw
[23:58:10] <SWPadnos> I haven't tried the section manager yet
[23:58:19] <petev> hmm, that seems odd
[23:58:52] <SWPadnos> it may be my setup - I'm running remote X