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