don't everyone talk at once now, i can hardly hear myself type
* Jymmm drops a pin and shatters fenn's eardrums
im in uk
go see what paul is up to, eh?
* alex_joni yawns
gprs is neat
I figured out what was going on with my cl in the sample stuff.
of course you did .)
The estop pin into the emc that is exposed by iocontrol
the pin... was inversed? or what was the problem?
I'm seeing some EMC logic connected to that state variable
there is some logic involved
It does set an emc state right?
depends on who you refer to :)
lets back it up, and start with a clean sheet
ok.. we have 4 task states
ESTOP_ON, ESTOP_RESET, ON and OFF
ON is machine On, off likewise
ESTOP_ON means there is an ESTOP condition, and the task is halted
These are accessed with F2?
ESTOP_RESET means ESTOP condition is gone, and machine could get switched on
those are set by changin the status variable, and by sending some NML messages
if you care for specifics, I can look it up, but I don't think it's important how it's done..
so.. that's what EMC knows
now for the big picture...
there is EMC ESTOP, and external ESTOP (like on the mazak)
* rayh likes big pictures
external ESTOP should get connected serially with the EMC estop
so if either breaks the whole machine stops. agreed?
ok.. so EMC should know if the external ESTOP has happened, and likewise the other way around
therefor iocontrol (who does the NML-HAL interface for this) exports 2 pins, estopIn and estopOut
estopIn figures if there is an external ESTOP condition going on, and if that's true EMC will also ESTOP
and estopOut is the current ESTOP condition of EMC, used to drive a relay or something like that
this was what I have done initially.. jmk modified this slightly...
there is an aditional estop_reset pin
When was that done.
the idea was this: if en external ESTOP happened, EMC needs to stay in ESTOP, till the user does something
the external ESTOP might have been a short signal, and it might have reset on it's own..
but it wouldn't be nice to have the machine working on itself
so the external estopIn is run through an HAL module which does some kind of latching
so if an short external ESTOP occurs, the HAL estop module will keep it forever
actually till the user tries to reset it
(by pushing F1)
okay. so the two pins that I have access to from iocontrol,
estopIn and estopOut
on a simple machine with no ESTOP logic, those need to be looped back
These are what I was working with last night.
I saw your loopback
I removed that, and that's when things began to go downhill.
if estopIn is always low (true for a signal that noone writes to), it might work always..
need to look at that
What I found is that estopin must be enabled in order for emc to go into estop at all.
What I wound up with was your loopback implemented in cl
I need to look at that in more detail.. but I agree it's fishy if it works like you described :)
Now the emc would work fine. f1 toggles estop, f2 toggles machine on.
I put a second contact on parport pin 10
rayh: cl == common lisp ?
does the toolchanging stuff work as promised?
ValarQ: CL= classicladder
almost got scared there :)
i should caps that.
cl is ok too
ValarQ: didn't see your commit yet
it is crude.
alex_joni: nope, i am what you call lazy
I know :P
alex_joni: i am working on getting a public darcs or svn repo to work
ValarQ: why not CVS on SF?
alex_joni: because i like darcs better
hrmmm.. I guess I don't know who'll touch that then...
alex_joni: maybe i migrate to sf later...
damnable kde. It won't see my keyboard now on the emc setup.
ValarQ: I see..
why not from the beginning?
alex_joni: good question
alex_joni: maybe sf.net is simplest
it is.. do you have an account on sf?
and it'll be in place with the rest of the emc2 code
alex_joni thats not what ray said =)
Jymmm: no, I said that
* rayh said he is starting to dislike kde more each day.
ValarQ: got an account on SF? registered as a developer?
rayh: "Please use it in a sentance" =)
alex_joni: no, i am no emc developer
tell me your username, I'll add you
should i commit to a directory in the emc2 tree?
Um I get a pile of error messages when I try to startup emc2 here this morning.
It is today's sf checkout.
Only difference from yesterday's is that I installed the latest kernel and emc from Paul.
insmod: error inserting '/lib/modules/220.127.116.11-magma/rtai/rtai_hal.ko': -1 Invalid module format
hrmmm... did you reconfigure?
you need to
also you need to get the new kernel-headers
check the wiki page
you need to redo all steps with the new deb-names
Okay. Got em and will work through the wiki page. Thanks.
No new names, just the extension number is changed.
I guess that must be a new name.
alex_joni: did you add me?
hang on.. doing it now
no hurry :)
think it should work now
but sourceforge isn't responding anymore from here :(
Daniel Nilsson valarq Developer valarq at users.sourceforge.net Private
Well I'm getting invalid module format with emc as well.
But I downloaded the latest and greatest.
I guess this box is borked.
rayh: it's not borked, you need to recompile all modules
using the new kernel sources and headers
and then it'll work
but if you have modules compiled for a different kernel those obviously won't work
Jymmm: are you there?
alex_joni: No, please leave a message at the __________________ .
alex_joni: Thanks for the info.
to keep troubles away, I suggest removing the old packages
It is unfortunate that there isn't an easy way to get the source for emc and the modules
./configure might get confused
how do you mean that?
There have been several releases of emc-bdi since the last tag in sf.
let me look and see what the last tag is. brb
bdi-4.27 is the last tag I see.
The last compile on your site is just a couple days old.
on my site?
I guess that I assumed that when a new EMC was out there that a corrresponding modules package would be there as well if required.
well they are..
and they should get installed automatically
but I thought you're having problems with emc2 not emc1-bdi
sarge updates extras
Ah neither will work now.
well.. I have an rsync set up, not sure what's on the repository
but emc-modules should be there
But the one that is there will not run with the patched kernel that is there.
that's odd, and shouldn't happen
let me look
I'll just try to step back a ways with my install here.
At any rate, I got kdm working agin on the other box so can test the cl stuff.
try removing all emc, and modules you have
and install only the latest
[19:06:17] <alex_joni> http://solaris.cs.utt.ro/emc/debian/pool/extras/e/emc/emc_1.0-35_i386.deb
[19:06:27] <alex_joni> http://solaris.cs.utt.ro/emc/debian/pool/extras/e/emc/emc-modules-18.104.22.168-magma_+bdi.102_i386.deb
[19:07:09] <alex_joni> http://solaris.cs.utt.ro/emc/debian/pool/extras/k/kernel-2.6.12-magma/kernel-image-22.214.171.124-magma_bdi.102_i386.deb
I got all this yesterday afternoon.
DON'T INSTALL kernel-126.96.36.199-fusion
It looks like the kernel was compiled with 3.3xx but the modules with 2.95
Right didn't do that.
did the magma
ok.. then it's ok
but it's strange if it's like you say..
I am running 2.6.12-magma too
Na. It may well be me.
but installed it a while ago
about 1 month or so
I was running magma before
but the newest was a new bdi-103 or so.
I see it now
188.8.131.52 - strange
what does your kernel report? 184.108.40.206 ?
or simply 2.6.12-magma?
oh what it is is 102 for the latest magma
Okay. All of it's gone. will try a reinstall.
crap 6+ hours of download again.
not worth it right now. Will come back to this later.
Thanks for trying.
Wow! I sure do like HAL and CL. This stuff is awesome.
Hey thanks for all your work.
Question. Where does the spindle brake get turned on when spindle is not?
task I think
let me look
it's a NML message that sets it
it's not the gui
Ah. So that is where we need to rip out the machine logic like this.
Certainly. I remember now.
Stuff like this needs to be passed down to HAL without logic applied.
or the logic needs to be applied in task in such a way that we can disable it when we run HAL and CL.
hmm.. that sounds..strange
to say the least
but I agree that spindle-brake after spindle-off is not a good idea
It does sound like we are ripping the guts out of task and assigning them to CL.
hrmmm... at least for IO that's not such a bad thing
because it gives you flexibility
as long as it's machine specific stuff...
I think task should stay functional
even without HAL
or with limited HAL
hmm im in edinburgh now...
* rayh is back
I agree, in fact I'd like to see task expanded but not with machine specific junk.
It does nothing when manual mode is active.
It should always be central to what is happening in emc.
I think slowly we need to shift machining specific things somewhere else
so in manual mode the gui cals mot directly ?
and leave the code for general purpose machines
Right absolutely. Give that man another bubbly.
I think that it might work to read in those extra machine tasks from some sort of canon extension file.
But they should not be inlined as they are now.
As is, I've got to set the brake on and off time in the ini file.
that is machine specific.
we just ignore it if the machine does mot have a brake.
I'd a whole lot rather see the brake NML go away completely.
If you've got a spindle brake and you want to time it on and off,
CL is the place to do it.
Now you might want to leave a brake NML so that you can release the brake
and examine tools and such.
but the logic of operating it, when and how much should be reserved for a single location.
That location might be cl or it might be a text script.
It might be user space or it might be rt.
If we build a scripting language interpreter for emc machine logic.
It would have to be an executable module that exports hal pins like iocontrol.
The difference is that the logic would be above the shmem while cl's is below.
yes, and not neccessarely realtime
like iocontrol does
The realtime needs are limited.
I'd like to see the homing pins and index pulses made in hal
along with hard limits.
well they are
but the logic for them resides either in hal or in motmod or someplace other than where the rest of the machine logic is.
It's like "machine logic" is scattered all over the code.
Even some of the stuff the interpreter does can be considered machine logic.
I'm going to go hack at emctask.cc for a bit and see if I can change the way we see
spindle brake and estop in iocontrol.cc
indeed it is, that's what I'm afraid of
that it's so scattered around the code that we can't rip it out
wot. afraid of rayh hacking at these files.
nah.. I encourage that :D
i think that having a scripting lang for mch logic is a nice idea
just don't commit those hacks right.
Would it be possible to set variables in the interpreter while it is running, from a scripter?
hrmm.. what scripter
* fenn whispers "python!"
that is vaporware.
An example of what I'd like to do is pull the list of things that abort does and estop does.
out and assign variables to them in the interpreter code.
now at runtime, the scripter adds those variables in.
That way if one integrator wants abort to reset the interp to g54, they can put that in there.
As you can tell, I see what emc does with things like abort, reset, estop
as being machine logic.
g92 at reset was the biggie last year.
My idea is to take all of these out and wherever they occur, we create a set of variables.
* fenn thinks rayh doesn't know what he's getting into
I jsut don't know if it is going to be easy to pass values to them while the system is running or when it starts up.
* rayh knows that fenn is right.
could you define what you mean by "machine logic"?
In tickle, it's easy to pass variables into a script at startup.
the command is source <filename>
not that easy inside the interp
and you can reset those anytime during a run by sourcing again.
you need wrapping functions (like emcsh.cc)
er you name it.
Machine logic is the stuff that will vary from one type of machine to another.
from one integrator to another.
from milling to threading to plasma cutting to laser cutting to welding to .. you name it
space ship flying?
When NIST wrote emc, their goal was to make one Kerney & Trekker machine run.
yeah.. that too
They were not faced with the task of lots of installs.
All of the time that FredP spent in MattS's garage was to make the K&T code fit a bpt.
btw, a bpt that we still suffer with.
Motion modules still have residual machine specific stuff.
Task is burdened with it.
Hell all of the goofy things that are done in a Servo-
so, for example, you think a minimill shouldn't have any more runlevels than on and off?
are left over from FredP while he was at Matt's.
That would be the Sherline Dream.
and we need to make a simple upgrade path from that to as large and complex a machine
Jymmm is now known as Jymm
as we can imagine on PC running.
would the integrator be able to create any number of runlevels for his device?
Jymm is now known as Jymmm
one (1) pc running
I'd like to see that.
that's largely a matter of documentation and UI
Yes. If we can get a scripting system going.
I'd like to see us try to extract the logics around say abort for example.
put them all in a configuration file.
i ran across this last night: www.yaml.org - it's something to think about at least
and be able to select the subset and make it run just like the interpreter does now.
what i like is the close correlation between data structures and the actual config file, without sacrificing readability
ok - what does abort do when it aborts?
about a dozen actions iirc
and that's mostly NML messages right?
also state changes
It creates canonicals
why does it do that?
point me in the direction of the abort code, please :)
so task can handle them if it need to.
grep -r -e "abort" *
and now I'm lost cause the whole source got broken apart.
when HAL is now becoming quite logical and easy to understand it seems that all the rest needs an overhaul :)
fenn: check /msg, I sent you some snips
I see 19 files with abort in em.
well.. task takes care of the most
and also sends emcMotionAbort()
that "resume at aborted line" feature sure would be nice
We implement "resume at aborted line" in the tickle front ends by
saving last line and then issuing restart with that line number.
Another example of machine logic being scattered all over the code.
that's weird how emcTaskAbort() doesn't actually do anything in task, only the nml message does
i mean shouldn't emcTaskAbort issue EMC_TASK_ABORT_TYPE
emcTaskAbort() is called when EMC_TASK_ABORT is received
right, what i meant was that all the code is in EMC_TASK_ABORT
EMC_TASK_ABORT is sent by the GUI
still don't understand what you mean?
so if you call emcTaskAbort() it doesn't clear out the commands and stuff
with tickle it is sent by emcsh.
and we use the simpler emc_abort
right, that one sends EMC_TASK_ABORT
wich is a NML_message of the EMC_TASK_ABORT_TYPE type
once that is received (inside task), emcTaskAbort() is issued
Yep. XXX -> YYY -> ZZZ ->and on we go.
emcTaskAbort() then sends emcMotionAbort(), and emcIoAbort() - by sending EMC_IO_ABORT
i guess it just seems weird to me that stuff happens when you are parsing a message, and nothing happens in the function that the message is supposed to call
well that function actually sends the abort furtheron
In several places, the function calls several other functions.
Is that another example of hard coded logic?
/*! \todo FIXME-- duplicate code for abort, - does that mean "add in the code that is called for EMC_TASK_ABORT"?
that means the code exists several time
and it's duplicated
// reset the estop
A machine builder does not have control of when lube comes on or off.
I'd a whole lot rather emcLubeOff() under the control of the integrator.
Many machines even have a lube pressure switch.
and it resets a counter so that if lube pressure goes low for longer than xxxminutes
a warning comes up.
Easy to do in CL if we have access to lube state.
* fenn sighs
No question but that this is a big thing?
now do you understand why i got all pissy about NML a while ago?
fenn: not NML is the problem here
it's all just thrown in there, and there's no organization to it
can't even understand what's going on if you don't already know the code by heart
and I think that there isn't one that does that
not even the ones who wrote it :)
If we start a change like this, and can get effort from most of the developers
by assigning them each a part.
ok so where do we start? :P
It will be broke for quite a while.
I'd say we start by specifying what kind of control over it we want.
and devise a system that can do that.
* alex_joni fully agrees
proove the system on just one part or bit
yet .. I am somehow reluctant
to think that it will succeed
because of the lack of manpower
I can't understand why.<g>
sure you can't
i hope it will get easer as it goes along if we can de-spaghettify it a little
We had some of this discussion around kconfig.
well, first you have to understand how kconfig works
but imo that was more aimed at make time rather than run time.
ot: is there a "shell" for sending arbitrary NML messages?
for testing and such
like echo "FOO_NML_TYPE" > emcsh
fenn: start emcsh
and issue emcsh commands
emcsh and iosh both handle bits of it.
with some overlap.
but I don't remember being able to just type in a NML message, send it and watch what happens.
That would be a fascinating tool.
no, but emcsh commands I think are no problem
and most of those are 1:1 to NML messages
emc_lube (none) | on | off
Gotta fix a machine. Back later. Thanks for the interesting discussion.
I'll put up a wiki page with what I've found about estop and cl.
So you can see my confusion.
emcsh keeps complaining about emc.nml... cms_cfg.cc 624: cms_config: can't open 'emc.nml'. Error = 2 -- No such file or directory
you need to run it within a certain dir
try from emc2/
it works if i ln -s configs/emc.nml emc.nml
well, i guess it works.. there's a blank window and the prompt changes
I hope emc is running, while you do this
it should error if not
ok it does something yay!
see the beauty of NML?
not really :P
you simply connect software together
just like HAL
the concept of NML is fine, it's the implementation that sucks
only the data sent is borked
% emc_lube on
kill the shell and start again, emc_lube
oh it might have something to do with pressing the up arrow
you can start more than one shell
do i have to be root to run emcsh?
ok it was the arrow that did it
so btw people
this is very early, but:
[21:53:28] <icee> http://lyle.org/~mlyle/servoctrl.pdf
A preliminary schematic for my servo controller
hm, the page order is nonideal.. basically, there's design reuse in here (4 sets of the per-axis stuff)
alex_joni: cheering for icee
fenn: thankyou :)
icee: looks nice
alex: cool, thank you. I still have a lot of component selection and BOM annotation and things to do
But I may enter the amplifier before i get to that
SP720 is a chip socket?
SP720 is a transient voltage suppression part (SCRs to ground and VCC)
it provides protection against ESD (weak protection because I don't have series resistors)
* alex_joni goes to bed
i read that DT2_design document and feel like i have some idea what's going on now
* fenn goes back to poking around nml
er, my bad
icee: got any suggestions for chips to talk EPP for controlling 6 brushed servos?
i need something that will read encoder inputs or at least step/dir
from the encoders that is
seems like a dspic would be overkill
i like the 1 chip 1 motor scheme
fenn: well, there's no reason you couldn't use our board with slightly different software
or there's the smaller dspic
but i don't need 3 pwm's or gobs of processing power
nah.. but there's not much else with quadrature decoding
you could do a CPLD, but it'd be more trouble and probably more expensive than using a dspic
(and you can homebrew quadrature encoding with an interrupt or two, but.. it doesn't work well)
would it be easy to implement i/o through the unused chip pins?
I've done a little bit of that
i still have a few left over
right now i'm connnector-limited
are there any reliable ttl limit switch devices?
ray always harps about how industrial stuff uses 24V
but what about optical switches and such
should be just as reliable as the encoders
i'm just thinking about the huge rack of opto-22's on the mazak and how much it would cost
you can use optoisolators to take the 24V to ttl
or just use the closure on the fault bus tht i have there for limit switching
but then EMC just sees "fault" and goes into estop
when it should see "limit"
you can't turn the motors in estop to move them off the limit
i never really understood how you get the machine off of the limit switch
fenn: Step 1: Grab wire cutters. Step 2:
i guess you could just crank the leadscrew by hand
but there is probably a better way
I'd suspect that if the left limit switch |<-------- is hit, then you can only travel to the right.
hopefully that's how it works (but i dont have any limits so i dunno)
interesting --> http://en.wikipedia.org/wiki/Polyurethane
rayh is now known as rayh-away
Jacky^ is now known as Jacky^afk
* Jymmm is now known as Jymmm
10,000 F in under 30 seconds! http://www.monolithic.com/foam/fire_hazard/index.html
well, that makes sense
what are you making with urethane foam?