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