Back
[00:24:55] <Jymmm> signs
[03:38:45] <dmwaters> {global notice} Hi all! one of our sponsors is doing some router maintenence, this is scheduled maintenence. In the process, I'm going to upgrade one of the main rotation servers. this won't effect anyone, since the server has already dropped it's users. Thank you for your patience, and thank you for using freenode!
[04:40:02] <LawrenceG> where did everyone go?
[04:40:49] <fenn> you mean the netsplit? or the fact that nobody has said anything for 8 hours?
[04:41:49] <fenn> * fenn is trying to design a PIC-based brushed servo controller
[04:41:51] <LawrenceG> hi fenn.... it has been quiet.... the number of usersdropped to 12 for while... lowest Ive seen it
[04:42:17] <fenn> that's a netsplit.. not all the users are logged into the same irc server
[04:42:23] <LawrenceG> how big a motor? volts/amps
[04:42:37] <fenn> 100W servo, says 12 or 24V
[04:43:05] <fenn> I'm reading up on how to use an H bridge
[04:43:26] <LawrenceG> I did one that did step/dir input...
[04:43:40] <fenn> bleh
[04:43:47] <fenn> i'm sick of thinking about step rates
[04:44:28] <fenn> want to get some practice with this EPP stuff
[04:48:20] <LawrenceG> much better approach I think... real servos are much easier on the rt part of emc
[05:04:28] <fenn> i think people are scared of programming microcontrollers, and that's why they haven't been used very much in any hobby motor controllers
[05:05:08] <fenn> i've been looking at some app notes and the code is really easy (it's in C though dunno if that will work with a pic)
[05:06:16] <fenn> is 72-100 bytes of ram enough to run a small C program?
[06:24:24] <CIA-6> 03paul_c * 10emc2-auto/wiki/ (63 files in 34 dirs): "Auto update wiki from a cron job. Fri Nov 4 05:30:01 GMT 2005 "
[07:33:34] <alpha> fenn, no.
[07:33:38] <alpha> wait.
[07:33:45] <alpha> hmm... depend on how simple.
[07:34:02] <alpha> fenn, ifyou did it with asm. YUP!
[07:37:49] <Jacky^afk> Jacky^afk is now known as Jacky^
[07:38:07] <Jacky^> morning
[07:38:22] <Jacky^> fenn: did you seen this:
http://www.jrkerr.com/icproducts.html
[07:38:44] <Jacky^> its a simply way to get servo up and running ..
[07:39:01] <Jacky^> i consider it time ago ..
[07:39:44] <Jacky^> but at the end, assuming ic,h bdrige, ect .. isnt cheaper at all
[07:39:52] <Jacky^> i bought geckos
[07:39:56] <Jacky^> :/
[07:41:37] <Jacky^> not sure, maybe the website have the source code too
[07:41:51] <Jacky^> for the PIC18F2331
[13:36:01] <alex_joni> hello crowd
[13:36:10] <ValarQ> hello mr Joni
[13:36:18] <alex_joni> what's up?
[13:36:23] <alex_joni> got acustomed to CVS on SF?
[13:36:26] <ValarQ> rewriting some crap
[13:36:44] <alex_joni> ok.. you should subscribe to the emc-commit list
[13:36:56] <ValarQ> nah, i don't think i'll ever feel comfortable with cvs again :(
[13:38:56] <ValarQ> ok, soon on the commit list...
[13:39:46] <alex_joni> why not? (confortable with cvs)
[13:40:20] <ValarQ> alex_joni: i tried to add the halgui directory for example
[13:40:54] <ValarQ> and it needs to contact the server right away for that
[13:41:29] <ValarQ> in svn and darcs you can stack changes and create patches easier
[13:41:59] <ValarQ> not that cvs doesn't work, but i prefer svn
[13:47:42] <ValarQ> the vcs isn't a big problem thought, the gui interface is
[13:48:38] <ValarQ> i don't know how i should represent components
[13:49:56] <ValarQ> the way i do it now is the easiest, showing entire components as blocks with all the pins
[13:50:54] <ValarQ> but the most logical way might be to break them apart, siggen.0 siggen.1 etc..
[13:59:02] <alex_joni> hrmm... I see what you mean
[13:59:10] <alex_joni> but HAL isn't ready for that
[13:59:21] <alex_joni> not all drivers do it how they should
[13:59:23] <alex_joni> I mean it
[13:59:37] <alex_joni> it's not a standard naming scheme.. unfortunatealy
[13:59:46] <alex_joni> damn... can't type at all today
[13:59:52] <ValarQ> :)
[14:00:12] <ValarQ> i might get your point anyway
[14:00:28] <alex_joni> I certainly hope so
[14:00:36] <alex_joni> and my back is killing me
[14:00:47] <ValarQ> that bad?
[14:00:51] <alex_joni> I think I twisted a muscle this morning, lifted something
[14:00:57] <alex_joni> and it cracked :)
[14:01:02] <ValarQ> ow
[14:01:15] <alex_joni> yup.. not very nice
[14:02:22] <ValarQ> another problem of mine is how to place the logical cables between pins and signals
[14:02:37] <alex_joni> direct wires for now
[14:02:50] <alex_joni> even if it'll look like shit
[14:02:53] <alex_joni> we'll work on that
[14:02:55] <ValarQ> it will
[14:03:06] <alex_joni> yeah.. I can imagine
[14:03:21] <ValarQ> the problem is that i have to rewrite much of the canvas code
[14:03:23] <alex_joni> algorithms for autorouting aren't very simple
[14:03:32] <ValarQ> nope
[14:03:35] <alex_joni> here's a thought..
[14:03:46] <ValarQ> i might choose gtk2hs instead of pygtk ;)
[14:03:49] <alex_joni> what if on the pins there is a signal name?
[14:04:03] <alex_joni> and when you hover the mouse it draws the line to where it is connected?
[14:04:13] <ValarQ> you mean that you can connect pins to signals in a specific dialog?
[14:04:18] <alex_joni> nah..
[14:04:36] <alex_joni> I mean that on schem. editors, you can have connections without wires
[14:04:44] <alex_joni> you place a label, or what it's called
[14:04:45] <ValarQ> well, even if i didn't get your point this is a great idea :)
[14:04:58] <alex_joni> on both pins, so it knows they are connected
[14:05:03] <ValarQ> it will hide all those unused pins as well
[14:05:08] <alex_joni> in our case the HAL signal name
[14:05:28] <alex_joni> and if you move the mouse over it, it should draw the line directly to where the other pin is
[14:05:36] <alex_joni> so that you quickly see where that goes to
[14:05:49] <alex_joni> but when you don't need it, it is hidden so the display isn't cluttered
[14:05:54] <alex_joni> maybe now you got me...
[14:06:17] <alex_joni> hello rayh
[14:06:28] <rayh> hi alex
[14:06:33] <rayh> brb phone
[14:06:50] <alex_joni> ok.. going home soon, gotta lie down (having a small back problem)
[14:07:02] <ValarQ> ok :/
[14:07:14] <ValarQ> i hope it gets better
[14:07:15] <rayh> You have a small back?
[14:07:26] <alex_joni> no.. a big back :D
[14:07:32] <alex_joni> a fscked big back
[14:08:49] <rayh> I know a bit about pack pain after my surgery
[14:09:10] <alex_joni> not nice
[14:09:20] <alex_joni> ValarQ: did you understand what I mean?
[14:09:47] <ValarQ> alex_joni: not all of it
[14:10:06] <alex_joni> will you be around in a few hours?
[14:10:11] <ValarQ> maybe
[14:10:18] <alex_joni> ok.. then we'll continue this then
[14:10:20] <alex_joni> gotta run now
[14:10:22] <alex_joni> later
[14:10:27] <rayh> see you
[14:10:29] <ValarQ> see you
[14:12:29] <alex_joni> yeah.. bye
[14:33:05] <lerman> Quoting fenn:
[14:33:06] <lerman> fenni think people are scared of programming microcontrollers, and that's why they haven't been used very much in any hobby motor controllers
[14:33:08] <lerman> fenni've been looking at some app notes and the code is really easy (it's in C though dunno if that will work with a pic)
[14:33:10] <lerman> fennis 72-100 bytes of ram enough to run a small C program?
[14:33:12] <lerman> I've been programming atmega (8, 16, ...) processors for the last year or so. Free development tools based on gcc are available, and easy to use. Also, the attiny13 can be programmed in C. The atmega8 is only a few dollars.
[14:34:37] <cradek> I have done moderately complex programs in C on the atmel at90s2313 which has 128 bytes of RAM
[14:35:33] <cradek> it is easy to run out of program space (of which there is 2k) when doing something complex, but the 16k and 32k atmegas are not that expensive.
[14:41:07] <jepler> don't expect to use malloc() much. Even the larger atmegas only have 2k or 4k of memory.
[14:41:34] <lerman> Yup. And they just work. On an 8 bit machine, doing 16 bit arithmetic by hand is a pain, but in C, the compiler just takes care of it for you.
[14:43:07] <lerman> For realtime work, malloc/free is a disaster waiting to happen. If you can't statically allocate memory, there is a potential for those hard to find bugs.
[15:56:56] <alex_joni> evening
[15:59:13] <cradek> hello
[16:00:13] <alex_joni> hey chris
[16:00:45] <cradek> I had jury duty monday through thursday this week and did not keep up with the mailing lists
[16:00:57] <cradek> there is sure a lot of talk
[16:01:09] <alex_joni> yes there is...
[16:01:15] <alex_joni> but lots of bullocks too :)
[16:01:24] <alex_joni> if you excuse me for calling it that
[16:01:26] <cradek> maybe so.
[16:01:31] <cradek> excused!
[16:01:41] <alex_joni> not really.. one's bullocks is other's interest
[16:01:54] <cradek> something like that I guess
[16:50:12] <rayh> Hi alex.
[16:50:22] <rayh> You able to rest your back?
[16:52:27] <alex_joni> finally yes
[16:52:33] <alex_joni> just finished eating
[16:53:12] <rayh> I think that I've figured out what I don't like about estop.
[16:53:18] <rayh> There are two of them.
[16:53:28] <rayh> estop in emc
[16:53:36] <rayh> and aux estop.
[16:53:39] <alex_joni> yes
[16:54:49] <rayh> If emc is in estop and we use your loopback.
[16:54:53] <rayh> all is good.
[17:01:35] <rayh> for the gui.
[17:01:35] <rayh> The aux-estop
[17:01:35] <rayh> toggles between estop and estop reset.
[17:01:35] <rayh> so they work the same but do not communicate between them.
[17:01:35] <alex_joni> I'm not sure I'm following
[17:01:35] <alex_joni> we have EMC estop
[17:01:35] <alex_joni> lets focus on that for now
[17:01:35] <rayh> k
[17:01:35] <alex_joni> F1 should toggle between ESTOP and ESTOP_RESET
[17:01:35] <alex_joni> ESTOP_RESET means ESTOP condition is cleared
[17:01:35] <rayh> Right. That is what it does now.
[17:01:35] <alex_joni> and that's about it.. nothing else to it
[17:01:35] <alex_joni> F2 switches the machine on
[17:01:35] <alex_joni> or off
[17:01:35] <rayh> Um. Okay.
[17:01:35] <alex_joni> if you push an F1 at any time, it should go into ESTOP
[17:01:35] <alex_joni> likewise if we have an external estop
[17:01:36] <rayh> ah yes it should. but it doesn't
[17:01:36] <alex_joni> F1 doesn't get you into estop?
[17:01:36] <alex_joni> if you remove my loopback?
[17:01:36] <rayh> Well it depends upon the state of aux-estop
[17:01:36] <alex_joni> it shouldn't
[17:01:36] <alex_joni> if you push ESTOP, then it should ESTOP
[17:01:36] <rayh> with the loopback, which is just about what is done with it in minimillio
[17:01:36] <rayh> then it works.
[17:01:36] <alex_joni> ok, so loopback works
[17:01:36] <alex_joni> no loopback it doesn't.. right?
[17:01:36] <rayh> and on top of that it will work with aux-estop IF we use a maintained button
[17:01:36] <alex_joni> not an maintained button
[17:01:36] <alex_joni> not neccessarely
[17:01:36] <alex_joni> that's why there is another HAL module
[17:01:36] <alex_joni> to do the maintained stuff
[17:01:36] <rayh> Yes and there should NOT be that module
[17:01:38] <rayh> No need.
[17:01:40] <alex_joni> why not?
[17:01:52] <rayh> If the aux estop also set emc-estop
[17:01:53] <alex_joni> the advantage of that module is that it's realtime
[17:02:00] <rayh> No matter.
[17:02:07] <alex_joni> hrmmm
[17:02:11] <rayh> cl is real time
[17:02:17] <alex_joni> aux estop as it is does set emc-estop
[17:02:25] <alex_joni> but it needs to have the loopback
[17:02:32] <alex_joni> on simple systems it's in HAL
[17:02:46] <alex_joni> on more complex systems (like the Mazak) it is done externally
[17:02:47] <rayh> Ah but as soon as you release the aux estop it drops emc-estop off as well.
[17:03:09] <alex_joni> not if you use the HAL-estop module
[17:03:11] <rayh> so that if you do not have a maintained contact, you do not get estop from the gui.
[17:03:34] <alex_joni> ok.. so that hal-estop module can be migrated into the iocontrol logic
[17:03:37] <alex_joni> no problem there
[17:03:42] <rayh> What I'm pointing at is that the module adds logic to overcome logic that is hard coded.
[17:04:44] <rayh> If aux-estop on simply set emc-estop to 1
[17:04:55] <alex_joni> but if I do that, then the hardcoded logic would be in iocontrol
[17:04:59] <rayh> and removing aux estop did not return emc estop to 2
[17:05:00] <alex_joni> it does that
[17:05:11] <alex_joni> to 2?
[17:05:20] <rayh> then we would not have any need for the hal-estop-logic module
[17:05:34] <rayh> state 1 is emc-estop on
[17:05:44] <rayh> state 2 is emc-estop-reset
[17:06:03] <rayh> state 4 is emc-estop-reset and machine on
[17:06:46] <rayh> It is all the same state variable, I think.
[17:07:06] <alex_joni> yes, but it doesn't get changed in iocontrol
[17:07:13] <alex_joni> it gets changed in task :(
[17:07:24] <alex_joni> it's the task_state variable (the one you refer to)
[17:07:28] <rayh> No, yes in that order.
[17:07:52] <rayh> I looked at the task code last night but could not find where
[17:08:02] <alex_joni> let me find it
[17:08:17] <rayh> aux-estop off meant that a estop-reset message was sent.
[17:08:46] <rayh> If we kill that one call. We will have produced a controllable system.
[17:09:09] <alex_joni> static int determineState()
[17:09:09] <alex_joni> {
[17:09:09] <alex_joni> if (emcStatus->io.aux.estop) {
[17:09:09] <alex_joni> return EMC_TASK_STATE_ESTOP;
[17:09:09] <alex_joni> }
[17:09:10] <alex_joni> if (!emcStatus->motion.traj.enabled) {
[17:09:12] <alex_joni> return EMC_TASK_STATE_ESTOP_RESET;
[17:09:14] <alex_joni> }
[17:09:16] <alex_joni> return EMC_TASK_STATE_ON;
[17:09:18] <alex_joni> }
[17:09:46] <alex_joni> that's in emctask.cc
[17:10:13] <alex_joni> let me run some tests..I'll keep you posted on what I see..
[17:12:35] <rayh> Okay. I can test it here.
[17:13:35] <alex_joni> btw, figured out that 2.6.12.6 problem?
[17:14:19] <rayh> Really?
[17:14:58] <alex_joni> no, I'm asking you...
[17:15:28] <rayh> No. I abandoned emc on this box and am running it on another.
[17:15:56] <rayh> Thought when I get a chance, I'll back out to the kernel, modules, and emc from the 30 disk
[17:16:00] <alex_joni> ok, started standard emc.run, and ESTOP seems to be working as promised
[17:16:45] <alex_joni> looking at the HAL part now
[17:18:04] <alex_joni> if I remove the loopback I see:
[17:18:21] <alex_joni> pushing F1 brings the machine into ESTOP_RESET
[17:18:49] <alex_joni> no matter how many times it gets pushed
[17:18:56] <alex_joni> F2 can switch the machine on
[17:19:55] <alex_joni> estop_out gets set properly
[17:20:03] <alex_joni> but doesn't get reset..
[17:20:08] <alex_joni> I see a problem with the logic there
[17:20:21] <alex_joni> emc estop should be = OR (estop_in, estop_out)
[17:20:29] <alex_joni> estop_out = emc estop
[17:20:38] <alex_joni> agreed?
[17:20:50] <rayh> Yep.
[17:23:05] <alex_joni> hmmm.. guess what?
[17:23:34] <alex_joni> that was the way I did it originally, but seems JMK changed it
[17:23:39] <alex_joni> http://cvs.sourceforge.net/viewcvs.py/emc/emc2/src/emc/iotask/ioControl.cc?r1=1.16&r2=1.17
[17:25:22] <alex_joni> jepler: around?
[17:25:28] <alex_joni> cradek: or you chris...?
[17:29:02] <gurrag> Anyone had problems with power down with the BDI?
[17:30:38] <alex_joni> gurrag: what problems?
[17:32:15] <gurrag> When I do halt the pc terminates everything ok, but never power off the computer, it sais "power down" but nothing really happens.
[17:32:17] <jepler> alex_joni: yeah, but unfortunately I'm doing my job right now...
[17:32:45] <alex_joni> no problem, only wanted to mention that that aux.estopIn was removed by JMK lately
[17:32:56] <alex_joni> that's why the AXIS compile was erroring
[17:33:09] <jepler> I removed estopIn in CVS
[17:33:10] <alex_joni> gurrag: to power down a computer completely you need APM or ACPI
[17:33:15] <alex_joni> jepler: cool
[17:33:28] <alex_joni> gurrag: both are missing from the BDI kernel
[17:33:53] <jepler> alex_joni: we didn't actually use estopIn
[17:34:03] <alex_joni> jepler: I know...
[17:34:14] <jepler> only problem is if you try to use a SIMPLEINSTALL (don't rebuild emcmodule and others) after this change, your axis will be mysteriously busted
[17:34:15] <gurrag> alex_joni: That means I have to recompile the Kernel if I want it.
[17:34:33] <alex_joni> gurrag: yes, if you can't push the button manually, please recompile the kernel
[17:34:42] <alex_joni> but don't be upset if it won't work
[17:34:50] <alex_joni> it's removed from the kernel for a reason
[17:34:56] <jepler> they're not merely missing -- APM and ACPI are deliberately disabled, because often they can cause realtime deadlines to be missed.
[17:35:03] <alex_joni> ACPI, APM and a RT kernel don't mix up nicely
[17:35:27] <gurrag> Thanks for letting me know
[17:37:27] <rayh> I see that the puppy version does shut down the pc power.
[17:38:11] <Jymmm> anyone knows what causes a bit to scream like a banchie?
[17:38:38] <Jymmm> crappy quality bit?
[17:39:17] <rayh> what are you drilling?
[17:39:51] <Jymmm> 1/4" downcut 2 flute into mdf - stepover being .24"
[17:40:11] <Jymmm> 18K rpm, 75IPM
[17:40:40] <Jymmm> This is a Freud bit, my CMT was never this loud even at 100IPM
[17:43:45] <Jymmm> Just wanted to know IF it could be the (freud) bit
[17:45:26] <fenn> jymmm is it the same length? it could be a resonance thing
[17:45:55] <Jymmm> fenn: Ya, same length. Exact same spec, just different brands.
[17:46:49] <Jymmm> would a dull bit have these characteristics?
[17:46:50] <alex_joni> rayh: seems JMK changed the whole thing a bit (ESTOP logic)
[17:47:10] <alex_joni> we should discuss this with him (maybe drop him an email)...
[17:47:40] <Jymmm> Speaking of email... anyone seen Mr Paul?
[17:48:31] <alex_joni> Jymmm: not really, want somthg particular from him?
[17:49:07] <Jymmm> alex_joni: Just to give him a hard time
[17:50:17] <alex_joni> ok then
[17:52:43] <rayh> were all of jmk's changes to iocontrol.cc?
[17:53:25] <alex_joni> emc.cc, emc.hh, emctaskmain, iocontrol, emcsh.cc, iosh.cc
[17:57:23] <alex_joni> basicly he removed aux.estop_in
[18:01:39] <rayh> okay. I'll write a note to him.
[18:02:54] <alex_joni> I'll keep looking at this
[18:09:37] <rayh> k I'll send a copy of my note to you as well.
[18:10:20] <alex_joni> thx
[18:25:55] <rayh> On the way.
[18:31:51] <alex_joni> rayh: did you read the comment at the beginning of iocontrol.cc ?
[18:32:00] <alex_joni> the one regarding ESTOP ?
[18:33:18] <alex_joni> seems it's working now exactly how it's put there...
[18:45:57] <rayh> No it doesn't cause opening the external switch resets the emc
[18:46:01] <rayh> It should NOT.
[18:46:29] <rayh> we should have to close the iocontrol-estop-reset pin
[18:46:42] <rayh> before it changes to estop off.
[18:46:59] <alex_joni> estop_reset isn't usually used
[18:47:04] <alex_joni> so that doesn't matter
[18:47:21] <alex_joni> estop_reset is used together with the HAL estop buffering module
[18:47:25] <alex_joni> to reset that one
[18:50:34] <alex_joni> When it goes FALSE, EMC will go into the
[18:50:34] <alex_joni> * ESTOP_RESET state (also known as READY).
[18:50:41] <alex_joni> speaking about estop_in
[18:52:44] <rayh> I'm thinking of the estop-reset that is visible to the gui -- with the exception of axis
[18:53:23] <rayh> For now lets call the estop status #1 estopped
[18:53:29] <rayh> #2 ready
[18:53:35] <rayh> #4 running.
[18:53:51] <alex_joni> ok
[18:54:01] <alex_joni> now read the message at iocontrol.cc again
[18:54:09] <rayh> What happens right now is that when the external restop pin is false
[18:54:18] <alex_joni> emc is in #2
[18:54:20] <rayh> it moves the system to ready.
[18:54:27] <rayh> No matter what you do with the gui
[18:54:33] <alex_joni> and that's exactly what JMK has written there...
[18:54:48] <rayh> Then we just have to change that behavior.
[18:54:53] <alex_joni> * The first is estop-in. It is an input from the HAL, when TRUE,
[18:54:53] <alex_joni> * EMC will go into the STOPPED state (regardless of the state of
[18:54:53] <alex_joni> * the other two pins). When it goes FALSE, EMC will go into the
[18:54:53] <alex_joni> * ESTOP_RESET state (also known as READY).
[18:54:59] <gurrag> Anyone have a clue about segmentation fault , line 616 in generic.run?
[18:55:04] <alex_joni> well.. he might have had a reason for doing that
[18:55:09] <alex_joni> gurrag: that's new..
[18:55:16] <alex_joni> did you modify anything?
[18:55:51] <gurrag> alex_joni: Nada, running puppy BDI 4.30
[18:56:00] <rayh> the estop-reset pin is what should move it from stopped to reset.
[18:56:10] <alex_joni> what GUI do you have configured? (line 616 sounds like running the Display)
[18:56:15] <alex_joni> puppy BDI 4.30 ???????
[18:56:21] <alex_joni> that's a first
[18:56:28] <alex_joni> it's either puppy or BDI
[18:56:56] <alex_joni> how much did you download?
[18:57:02] <gurrag> alex_joni: I got it several times
[18:57:03] <alex_joni> a full CD or about 30 MB?
[18:57:22] <gurrag> The full cd
[18:57:34] <alex_joni> ok, then it's a BDI 4.30
[18:57:37] <alex_joni> no puppy involved
[18:57:57] <alex_joni> how did you run generic.run?
[18:58:12] <alex_joni> I mean.. where did you start it from?
[18:59:26] <gurrag> like /usr/local/emc/generic.run -ini mill_inch_freq.ini
[18:59:39] <gurrag> from my home catalog
[19:00:11] <gurrag> actually /usr/local/emc/generic.run -ini mill_mm_freq.ini
[19:00:26] <alex_joni> does it make a difference?
[19:00:32] <alex_joni> same error on both?
[19:00:39] <gurrag> I dont think so
[19:00:55] <gurrag> I run from a prompt
[19:01:08] <alex_joni> did you try the icons on the desktop?
[19:01:10] <alex_joni> do those work?
[19:02:08] <gurrag> Sometime it craches when starting with those but I can never se what problem caused the crash
[19:02:17] <alex_joni> rayh: the more I think about this, the more I start to agree with JMK
[19:02:29] <alex_joni> does it run sometimes?
[19:02:34] <alex_joni> or does it always crash?
[19:02:54] <gurrag> Shure... much better than the earlier BDI:s
[19:03:27] <gurrag> It craches ones a day.... Some days not
[19:04:03] <alex_joni> strange
[19:04:41] <gurrag> Some crashes are harder, like putting down X, but I think that is more RT related than EMC related
[19:05:16] <alex_joni> hmm.. I never experienced such problems
[19:05:26] <gurrag> I have a AMD XP processor, could that be involved?
[19:05:40] <alex_joni> not that I would know
[19:06:14] <gurrag> Have to eat... cu
[19:06:19] <alex_joni> ok
[19:08:12] <rayh> Why do you prefer his way. It locks out the gui from doing anything with estop unless the external pin is pulled.
[19:08:37] <alex_joni> yes, and the external pin should always get pulled
[19:09:04] <alex_joni> you need to see it like this...
[19:09:13] <alex_joni> EMC has 2 states
[19:09:23] <alex_joni> either ESTOPED or not (ESTOP_RESET)
[19:09:49] <alex_joni> so if you drive an ESTOP from the GUI (by pushing F1), that should reach the machine
[19:09:51] <alex_joni> and loopback
[19:10:18] <alex_joni> if you have an external ESTOP, EMC will go into ESTOP
[19:10:34] <rayh> Yes and the two states should NOT be connected to the same pin
[19:10:36] <alex_joni> but if the external ESTOP has been resolved (by some user intervention, maybe air pressure was low, or whatever)
[19:10:42] <alex_joni> EMC won't change the display
[19:10:46] <alex_joni> and that is BAD
[19:10:53] <rayh> an estop signal from anywhere should set an estopped state
[19:11:10] <alex_joni> rayh: yes, and it will
[19:11:15] <alex_joni> but it is the integrators job to assure that
[19:11:30] <rayh> No because emc does NOT have control of estop then only the external pin does
[19:11:50] <alex_joni> how do you mean that?
[19:11:58] <alex_joni> "emc does NOT have control of estop" ?
[19:12:45] <anonimasu> hi
[19:12:53] <alex_joni> hello anders
[19:13:18] <rayh> We've got three states. stopped, ready, running.
[19:13:34] <anonimasu> can you get me a phone number?
[19:13:52] <alex_joni> rayh: yes, go on
[19:14:37] <rayh> The pin in iocontrol that you named out. is supposed to show the internal state of estop
[19:14:45] <alex_joni> no
[19:14:48] <rayh> as either stopped or ready
[19:15:04] <rayh> It does not do that.
[19:15:06] <alex_joni> the pin in iocontrol that is named estop_out is supposed to go out of the machine controller
[19:15:22] <alex_joni> and drive an relay in the estop chain
[19:15:42] <rayh> when the external stop pin sets a stopped condition that pins state does not change.
[19:16:37] <rayh> As soon as I get my network up here, days, perhaps, I'll put together a page on the wiki that shows exactly what happens.
[19:16:48] <rayh> Not what we might believe should happen.
[19:17:25] <rayh> the external pin switches the entire system between stopped and ready
[19:17:33] <alex_joni> I know what happens.. but I think you're talking about a different thing
[19:17:34] <rayh> without regard to what is happening in the emc.
[19:18:14] <alex_joni> lets use some consistent naming when describing this
[19:18:15] <alex_joni> ok?
[19:18:39] <alex_joni> if we talk about hal pins, we'll use the hal pin names.. ok?
[19:18:58] <alex_joni> for example: estop_out is actually iocontrol.0.estop_out
[19:19:01] <rayh> okay.
[19:19:15] <rayh> my typing is not that fast.
[19:19:24] <rayh> but ok we will do that
[19:19:46] <rayh> I'll get to the other box where emc is running but I cannot pass stuff back.
[19:19:49] <alex_joni> ok.. now let me point out a scenario first
[19:20:07] <alex_joni> hang on.. let's discuss this a bit more, before testing
[19:20:09] <alex_joni> ok?
[19:20:46] <alex_joni> let's assume for a while that we don't want to touch EMC's internal ESTOP stuff
[19:21:08] <alex_joni> we are machining happilly, and suddenly the whole machine estops
[19:21:51] <alex_joni> seems there is an airpressure-sensor that's linked in the estop chain, and this sensor estop'ed the whole machine
[19:23:41] <rayh> iocontrol.0.estop_in is connected to I0 in CL.
[19:23:56] <alex_joni> forget that for a while..
[19:23:58] <rayh> That is an input signal to cl.
[19:24:00] <alex_joni> read what I was writing
[19:24:10] <alex_joni> rayh: in that case it's wrong
[19:24:15] <rayh> I can't because that is the way that I can see the problem.
[19:24:33] <alex_joni> try to bear with me for a while
[19:24:39] <rayh> k
[19:24:39] <alex_joni> you'll get a different perspective
[19:24:52] <alex_joni> ok.. so I was saying: an external ESTOP has occured
[19:25:01] <alex_joni> tkemc now reads ESTOP
[19:25:16] <alex_joni> so the user goes and fixes the cause (in my scenario airpressure)
[19:25:37] <alex_joni> now he comes back to the PC, and tkemc reads ESTOP_RESET (without him needing to touch anything)
[19:26:11] <alex_joni> agreed with this?
[19:27:01] <rayh> No because the tkemc screen can not change the state of estop
[19:27:17] <alex_joni> forget tkemc, it might be any gui
[19:27:19] <rayh> With the external done.
[19:27:35] <alex_joni> what I was actually asking.. should EMC reset to ESTOP_RESET on its own?
[19:27:46] <alex_joni> by noticing the change in the external ESTOP?
[19:27:47] <rayh> no it should not.
[19:27:50] <alex_joni> why not?
[19:28:05] <rayh> let's say that the problem was a faulty motor overtemp switch
[19:28:06] <alex_joni> how would the user know that he took care of the external ESTOP?
[19:28:11] <alex_joni> yes
[19:28:24] <rayh> I get out there with my arms wrapped around all kinds of belts and things,
[19:28:32] <rayh> I don't want that motor restarting.
[19:28:43] <alex_joni> well motors don't start unless MACHINE_ON
[19:28:48] <rayh> I want to have to go back to the front control and push stuff by hand./
[19:28:49] <alex_joni> on ESTOP_RESET nothing happens
[19:28:54] <rayh> Oh yea they do.
[19:28:57] <alex_joni> yes, you get to push F2
[19:29:00] <alex_joni> what does?
[19:29:00] <rayh> hydraulic
[19:29:24] <rayh> an whole bunch of stuff who's sensors are in the estop chain.
[19:29:32] <rayh> afte ready
[19:29:43] <rayh> after ready and before machine on or run
[19:30:07] <alex_joni> hmm.. was this the case on the mazak?
[19:31:07] <rayh> That is what I was working toward when I left.
[19:31:38] <rayh> That is the reason why the current system puts to much hard coded logic into the estop system.
[19:32:04] <alex_joni> I see it like this: ESTOP is a crucial security issue
[19:32:19] <alex_joni> and it shouldn't have all sorts of wacky devices connected to it
[19:32:35] <alex_joni> like hydraulics & such
[19:32:50] <alex_joni> I might be biased by the robots I work with
[19:32:58] <alex_joni> but on those there are 2 systems
[19:33:04] <alex_joni> ESTOP, and POWER_ON
[19:33:18] <alex_joni> similar to EMC's MACHINE_ON
[19:33:40] <alex_joni> but all is done in 24V signals, no high logic in it
[19:34:00] <rayh> I don't have a problem with the differences between US and EU estop standards.
[19:34:22] <alex_joni> nah.. not that's the issue here now
[19:34:38] <rayh> What I have issue with is stop turning to ready when a single pin is changed.
[19:34:44] <alex_joni> but what I'm trying to say.. ESTOP only is a condition
[19:34:53] <alex_joni> no actions are done because of it
[19:34:59] <alex_joni> (like enabling hydraulics)
[19:35:16] <rayh> I want estop to be estop whenever either the gui or an external pin does it.
[19:35:34] <alex_joni> yes, but ESTOP_RESET is still machine_off
[19:35:39] <alex_joni> that's where we don't agree
[19:35:53] <rayh> I don't care about machine on or off.
[19:35:57] <alex_joni> ESTOP_RESET is the state where ESTOP was there, but was reset
[19:35:59] <alex_joni> nothing more
[19:36:03] <rayh> I want to press a pin and get estop.
[19:36:06] <alex_joni> no further actions have happened
[19:36:15] <rayh> I want to have to press another pin to get ready
[19:36:53] <alex_joni> what's a pin?
[19:37:22] <rayh> iocontrol.0.emc-estop-in
[19:37:35] <alex_joni> how do you press that? *grin
[19:38:01] <rayh> I connect it to cl and toggle the bit with cl's gui
[19:38:24] <alex_joni> ahh.. so you're playing temperature sensor
[19:38:27] <rayh> I connect it to cl to another hal pin on a parport
[19:38:55] <rayh> I'm allowing any integrator to play any game they fscking well please to play.
[19:39:12] <alex_joni> I agree on that
[19:39:34] <alex_joni> but I don't agree on allowing any integrator to connect some hazardous actions to ESTOP_RESET
[19:40:14] <rayh> i believe i said any way the integrator pleases
[19:40:21] <alex_joni> still not safe
[19:40:29] <rayh> It is not our place to decide what is safe or not.
[19:40:34] <alex_joni> I know the integrator might do it.. but on his own risk
[19:40:53] <rayh> cause if we try we will just get folk to find ways round what we think of as safe.
[19:41:35] <rayh> The less hard coded logic we have the more likely the user is to make a straight-forward comprehensible design.
[19:41:51] <alex_joni> yes, but not necessarely sound or safe
[19:42:01] <rayh> And what could be more straight forward than
[19:42:01] <etla> but the interface to the upper level needs to be uniform
[19:42:13] <rayh> press an estop and you always get an estop
[19:42:26] <rayh> press a reset and you always get a ready
[19:42:45] <rayh> as long as the internal state of the emc permits
[19:43:08] <rayh> and press a machine on and you get a machine on again with the emc permit disclaimer.
[19:43:35] <rayh> As it is now without HAL or CL. press an estop and you get it.
[19:43:53] <rayh> press a emc-off or ready and you get it.
[19:44:11] <rayh> press a machine on, and if ready you get on.
[19:44:16] <alex_joni> yes, I agree
[19:44:36] <alex_joni> but... maybe I'm not beeing fully clear here..
[19:44:44] <alex_joni> the main issue is:
[19:44:46] <rayh> with hal and cl, press an external estop and you get estop, as long as the button is maintained.
[19:45:06] <rayh> release that external pin and you get ready./
[19:45:21] <alex_joni> when an external-estop has been cleared, should it go to estop_reset on it's own (JMK) or not (RayH)
[19:45:25] <rayh> that should not happen until the external program presses a reset
[19:45:47] <rayh> at least we are seeing the issue.
[19:46:18] <rayh> Now jmk gets around that by writing a hal module that allows him to do what I want to do with the original three pins.
[19:46:22] <rayh> out of iocontrol
[19:46:44] <rayh> occams razor favors me.
[19:47:00] <rayh> cause I don't need a hal module interposed.
[19:47:48] <alex_joni> I think we should talk this over with jmk when he's around
[19:49:47] <rayh> Right.
[19:50:10] <rayh> Darn I wish this were simpler.
[19:50:16] <alex_joni> heh.. nothing is
[19:50:32] <alex_joni> if it were simpler we weren't required to do the job
[19:50:40] <alex_joni> right?
[19:50:58] <alex_joni> someone else could do it, if it were simpler :D
[19:51:05] <rayh> Would I have to revert all of the changes jmk made in order to test a system like I want?
[19:51:24] <alex_joni> you could checkout an older version
[19:51:32] <alex_joni> but toolchanging might be missing
[19:51:42] <alex_joni> as I added that after the estop changes jmk did
[19:52:15] <rayh> Okay. Ray skulks off to do something else.
[19:52:32] <alex_joni> there is a magic incantation to cvs to checkout a version from x days ago
[19:53:13] <rayh> I know that but then we miss all the cl and iocontrol.cc stuff.
[19:53:42] <rayh> and if we then try to add them to the older we are again in trouble.\
[19:54:08] <dmess> question... has emc or emc2 been sucsessful in controling a stewart platform?? ie hexa pod configuration machine
[19:54:19] <alex_joni> dmess: yes
[19:54:29] <alex_joni> emc1, but no reason for emc2 not to
[19:54:32] <rayh> Years ago. Lot's of different models.
[19:54:36] <alex_joni> I have been running a tripod on emc2
[19:54:49] <fenn> i thought hexapod kins were not in emc2
[19:54:51] <dmess> how accurate...??? big?? and fast???
[19:55:41] <alex_joni> very
[19:55:55] <rayh> Gotta reboot.
[19:56:01] <dmess> could we design a hexapod style cmm using emc1 or 2
[19:56:13] <fenn> yes
[19:56:20] <alex_joni> emc2 I would suggest
[19:56:26] <gurrag> Anyone know a way of setting up logging so I can read back in wich row the interpreter where of the g-code when EMC crached?
[19:56:46] <fenn> alex_joni: how much time would it take to port the genhexkins to emc2?
[19:56:53] <dmess> our parts are VERY peculiat to how they are measured
[19:56:54] <fenn> * fenn is guessing it would be easy, but not sure
[19:56:54] <alex_joni> fenn: depends for who?
[19:57:03] <fenn> * fenn is slow
[19:57:15] <cradek> gurrag: if you use AXIS it will tell you which program line triggers the error
[19:57:16] <alex_joni> * alex_joni would probably need a bit for testing and such
[19:57:23] <fenn> and i dont have anything to test it on either
[19:57:30] <fenn> not yet
[19:57:30] <alex_joni> cradek: he really means crashes... not stops
[19:57:36] <cradek> ah
[19:57:40] <alex_joni> fenn: I reckon about a half an hour
[19:57:43] <cradek> run sim in gdb then
[19:58:54] <fenn> dmess: it will be $$$ simply because hexapods are "weird" and you will have to pay more to get people to design it
[19:59:24] <fenn> the awful truth.
[19:59:49] <fenn> of course, if you are making it yourself, it will be much easier to make than a standard orthogonal machine
[19:59:58] <dmess> we design and build landing gear systems... they can handle the numbers
[20:00:47] <fenn> well, a landing gear isn't exactly a high precision device like a cmm
[20:01:05] <dmess> but they want them to be..
[20:02:47] <dmess> .002 true posn from 2 skewed planes to 2 bores 36" down the part ofset by x,y....
[20:03:20] <fenn> should be easy
[20:04:18] <dmess> GOOOD LUCK was my advise to the cmm programmer... we'll NEVER pass a part thru there but they will ALWAYS work
[20:04:41] <fenn> i dont think emc supports capacative probes
[20:04:46] <fenn> so it will be slow
[20:05:10] <dmess> infa red renishaw
[20:05:28] <fenn> definitely doesn't support those :P
[20:05:33] <dmess> have a skip type signal??
[20:05:42] <fenn> what's a skip type signal?
[20:06:09] <dmess> stop probe trigered.. capture x,y,z
[20:06:18] <fenn> yeah that's how emc's probing works
[20:07:36] <dmess> so you load an i/r probe in the spindle... set up the reciever to triger the STOP and capture routine... and it supports it
[20:08:14] <fenn> i thought an ir probe worked by measuring the distance to the part surface
[20:08:37] <fenn> you're spending a lot of money and not using the device right
[20:09:07] <fenn> * fenn is blowing smoke
[20:09:15] <dmess> not this tpe of probing... this is ir reciever.. from a touch trigger probe
[20:10:32] <fenn> like an optical switch instead of a mechanical switch?
[20:10:33] <dmess> im quite sure Marposs have them too
[20:11:24] <dmess> no mechanical inside the head.. but no wires to transmit the stop... its ir
[20:11:53] <dmess> ??
[20:12:05] <fenn> "no wires to transmit the stop" like a tv remote? :)
[20:12:20] <fenn> you got a link to the product webpage?
[20:12:59] <dmess> tool and probe has battery and transmitter...reciver ... is on inpuy abcd
[20:13:25] <dmess> no i have workin macros..
[20:13:55] <dmess> and have installed quite a few
[20:14:11] <Jymmm> dmess: Well, lets see one =)
[20:14:26] <Jymmm> talk is cheap =)
[20:14:55] <fenn> that's kinda silly if you have a dedicated cmm
[20:15:07] <fenn> i can understand for doing probing in a milling machine
[20:15:07] <dmess> fanuc or toshiba tosnuc 888???
[20:15:10] <Jymmm> put your mouth where your Wireless IR Probe is =)
[20:15:36] <Jymmm> * Jymmm can't use light... too much dust.
[20:15:47] <Jymmm> s/light/optical/
[20:16:29] <dmess> ppl on the gorou have seen them ...
[20:16:35] <dmess> group
[20:16:54] <Jymmm> dmess: but we haven't. you got a link?
[20:17:13] <alex_joni> Jymmm: people worth seeing it have already
[20:17:15] <alex_joni> :))
[20:21:27] <fenn> * fenn wonders when valarq is going to commit his crap
[20:25:54] <etla> what has valarq been working on ?
[20:26:06] <fenn> a program to show hal connections as a schematic
[20:26:21] <etla> cool
[20:26:30] <etla> like realtime LabView
[20:26:46] <etla> make it a GUI for doing the connections also
[20:26:52] <fenn> http://arda.no-ip.org/crapahalic.png
[20:28:45] <etla> anyone working on HALification of the motion controller / traj planner ?
[20:28:59] <fenn> i think that's your job :)
[20:29:04] <alex_joni> etla: this has been covered so many times
[20:29:21] <alex_joni> and I really am tired explaining that it's not a good thing
[20:29:59] <Jacky^> uhm..
[20:30:01] <fenn> i think that comes about because HAL is the only part of emc that people can understand
[20:30:07] <Jacky^> evening :)
[20:30:15] <etla> fenn: right
[20:30:41] <Jacky^> alex_joni: not good for someone, but possible ?
[20:30:53] <alex_joni> it's not feasible/workable
[20:31:02] <alex_joni> not what HAL was/is intended for
[20:32:00] <fenn> that's why i was pushing to make emc more modular a couple months ago
[20:32:10] <fenn> so that you could see what's going on inside of it
[20:32:16] <alex_joni> fenn: didn't see anything in that direction?
[20:32:31] <fenn> well, herding cats
[20:32:42] <fenn> far be it from me to actually DO anything :)
[20:32:57] <alex_joni> ohh silly me for actually assuming that
[20:33:27] <fenn> * fenn is looking at crapplication sources
[20:33:37] <alex_joni> so that should actually read: that's why i was thinking of pushing to make emc more modular a couple months ago
[20:33:44] <etla> it's hard to know where to start if you'd like to do something...
[20:34:06] <fenn> alex_joni: i wrote a couple messages to the devel list
[20:34:07] <alex_joni> etla: start by understanding the code
[20:34:16] <cradek> I could never get any of the crap applications to run, because of dependencies on gtk stuff newer than mine
[20:34:25] <etla> but noone understands the trajectory planner
[20:34:40] <fenn> i think that it should get tossed since nobody understands it
[20:34:41] <alex_joni> etla: no-one bothered
[20:34:50] <alex_joni> fenn: ditto
[20:35:19] <fenn> etla: talk to les to get an idea of what it ought to do, then write a new one
[20:35:22] <cradek> I agree, if someone writes something that works better first
[20:35:47] <jepler> many people have tried to understand it
[20:35:52] <alex_joni> well.. I was very enthusiastic about developers a while ago
[20:35:53] <jepler> most or all have given up
[20:35:59] <etla> do we at least have the in and outputs clear ?
[20:36:07] <jepler> (trapezoidal planner)
[20:36:08] <alex_joni> etla: yes
[20:36:11] <cradek> etla: yeah, that API is pretty clear
[20:36:26] <alex_joni> and we have covered that already, but seems your memory is sluggish
[20:36:44] <alex_joni> or maybe mine?
[20:36:50] <Jacky^> wine ?
[20:36:52] <Jacky^> :P
[20:36:53] <etla> yes. some kind of shared memory buffer with canon commands ?
[20:37:04] <etla> and the output would be a position command every servo cycle ?
[20:37:08] <alex_joni> yes
[20:37:14] <alex_joni> kinda...
[20:37:53] <etla> if I do the math, will someone be able to do the code ? :)
[20:38:00] <fenn> etla: no :P
[20:38:03] <alex_joni> depends on how you do it
[20:38:35] <etla> suggest a good way !
[20:40:12] <fenn> * fenn blows some more smoke
[20:40:26] <fenn> i think it needs more layers of abstraction
[20:40:38] <etla> what kind ?
[20:41:22] <fenn> separation of the interface into an object
[20:41:36] <fenn> like, right now all the messages just go right into the trajectory planner
[20:41:46] <fenn> it's not encapsulated
[20:41:57] <icee> i'm planning on looking at the trajectory planner some.
[20:42:22] <cradek> it has to handle feed override, stop, pause, resume, step, etc
[20:42:28] <cradek> this adds a lot of complexity
[20:43:23] <etla> throw in rigid tapping / threads on a lathe while were at it !
[20:44:30] <icee> etla: did you see my schematic, btw?
[20:44:41] <etla> icee: no not yet
[20:45:00] <icee> http://lyle.org/~mlyle/servoctrl.pdf i believe
[20:45:14] <fenn> forget what i just said about messages going into the tp.. i was thinking of someting else
[20:45:46] <icee> i'll be doing real component selection and entry of the amplifier today
[20:46:47] <etla> icee: ok, and the pins on the dsPIC are enough ?
[20:47:15] <icee> uh, yah
[20:47:26] <alex_joni_> alex_joni_ is now known as alex_joni
[20:47:32] <icee> i even have two open pins
[20:48:10] <icee> as it stands it looks like i'm perimeter-area limited so I have no way to get the additional signals out
[20:48:33] <fenn> etla: i would like to see a "realtime" planner to handle feed override and probing and such, and also a path pre-processor that handles all the grunt work in userspace before the program is even run
[20:49:01] <fenn> that way you can be assured that you dont have to make any hard calculations in realtime
[20:49:11] <fenn> (unless the user forces you to)
[20:49:18] <icee> the calculations involved aren't exactly that hard imo
[20:49:25] <Jymmm> or the force is with you
[20:49:38] <icee> fitting rational b-splines to commands and coming up with a jerk-limited trajectory doesn't take that many cycles
[20:50:12] <etla> fenn: but the the path pre-processor would have to export some kind of (new?) intermediate format...
[20:50:27] <fenn> just a list of canonical commands
[20:50:50] <etla> but not the same "canonicals" as in g-code ?
[20:51:07] <fenn> uh.. canonicals like from canterp.c
[20:51:48] <fenn> hmm no that's not right
[20:51:59] <fenn> just position/time commands
[20:52:16] <fenn> it all gets boiled down to linear and circular moves at the end
[20:53:11] <etla> if it's possible to do it in realtime then I think it would be 'cleaner' to not have a separate pre-processor
[20:54:21] <alex_joni> etla, fenn, icee: that's the way it is now
[20:54:34] <alex_joni> but it's nice to see that you guys come up with the same conclusions
[20:54:58] <fenn> yeehaw
[20:55:08] <fenn> maybe it just needs documentation
[20:55:25] <etla> no. G64 is really not that good as it is now.
[20:59:03] <icee> a_j: how hard would it be to change the following error stuff? e.g. have different tolerances for 'falling behind' vs. lateral errors on the path
[21:04:30] <alex_joni> icee: depends on what you understand under hard
[21:04:39] <alex_joni> you'll probably need a few months to understand the code
[21:04:49] <alex_joni> till you get to a level where you could change it
[21:05:23] <etla> why would 'falling behind' errors be any better than other following errors, in principle ?
[21:05:49] <alex_joni> because some apps are critical on speed, not on position
[21:06:32] <etla> so were back to the shortcomings of the traj planner are we :)
[21:06:46] <alex_joni> not really..
[21:07:08] <etla> design smooth paths and a good traj planner will create smooth motion
[21:07:19] <icee> a_j: yah.. and for each app you could set each tolerance differently
[21:07:40] <fenn> etla: lots of CAM programs out there put out "smooth" paths made up of 1000's of little lines
[21:07:51] <icee> falling behind doesn't matter on some machines.
[21:07:58] <fenn> les was having problems because the realtime planner couldn't handle all the little lines
[21:08:12] <etla> fenn: yes, and a lookahead planner should cope with that
[21:09:51] <fenn> icee: there's lots of nurbs packages in C++ but none (?) in C, and all the realtime code has to be C
[21:10:23] <icee> fenn: evaluating a simple set of rational b-splines is not hard
[21:10:32] <icee> fenn: and mapping primitives to them isn't
[21:10:47] <fenn> ok
[21:10:48] <jepler> not GPL compatible, but here is C code for NURBS that I found with a quick google search:
http://www.nar-associates.com/nurbs/c_code.html
[21:10:48] <icee> and even mapping trapezoidal trajectories to them isn't ridiculously difficult
[21:10:51] <jepler> there have got to be others
[21:11:08] <icee> but jerk limiting starts to get hard.
[21:11:13] <alex_joni> jepler: don't spoil them the fun of doing it on their owns
[21:11:24] <fenn> why's jerk limiting harder?
[21:11:28] <jepler> jerk limiting is always a problem in open source projects.
[21:11:45] <alex_joni> ROFLMAO
[21:12:12] <etla> nurbs and splines etc is still just geometry. I think you need to include dynamics
[21:12:35] <alex_joni> etla: don't forget you're having 6 axes
[21:12:36] <alex_joni> not 3
[21:12:44] <icee> dynamics is hard ;)
[21:13:04] <etla> a_j: yeah, I'm thinking a first version will only work with trivkins
[21:13:06] <icee> really, the goal should be to come up with a clean code base with simple geometry
[21:13:08] <etla> take it or leave it :)
[21:13:15] <icee> and then if you want to throw in elements of dynamics, etc, it isn't impossible
[21:13:45] <alex_joni> well.. then it won't be any better than the current one.. right?
[21:13:56] <fenn> by dynamics you mean feed override and probing?
[21:14:20] <icee> f: no, dynamics of the machine itself
[21:14:26] <etla> fenn: by dynamics I mean jerk limited or double-jerk (smile)
[21:14:41] <icee> oh, ok.
[21:14:48] <icee> Yah, I'm probably wiling to take on jerk or double-jerk
[21:14:59] <icee> more complicated ways of describing machine dynamics scare me some
[21:15:03] <alex_joni> there is a big difference between path planning (static path)
[21:15:14] <alex_joni> and motion planning, take care of accells and such
[21:15:20] <alex_joni> the first one is trivial
[21:15:26] <fenn> yes you have to include a nurbs curve of velocity too
[21:15:27] <alex_joni> I'd say a day or so of conding
[21:15:39] <fenn> it's a parametric equation
[21:16:50] <fenn> time, not velocity
[21:17:10] <fenn> makes more sense if you think about velocity for some reason
[21:18:44] <fenn> why do we need feed_override anyway?
[21:19:37] <fenn> blegh nevermind i know why
[21:20:24] <etla> it would get really hard with something else than trivkins
[21:20:44] <fenn> what does kinematics have to do with it?
[21:20:49] <etla> one set of vel,accel,jerk limits for axes, and another set for joints. and no simple eq. between them...
[21:21:21] <alex_joni> you don't need 2
[21:21:24] <jepler> is it important to limit accel, jerk for axes if you limit it for joints?
[21:21:35] <alex_joni> you only need one for axes
[21:21:43] <alex_joni> then run the inverse kins
[21:22:07] <etla> a_j: but max vel for an axis might result in more than max vel for a joint ?
[21:22:24] <fenn> you need to make sure that the axes limits don't exceed joint limits, but you only have to calculate that once
[21:22:40] <etla> once per servo cycle ?
[21:23:02] <fenn> well, it depends how much performance you expect...
[21:23:03] <jepler> (I should butt out, because I don't understand the kinds of non-trivial systems you might work with)
[21:23:24] <fenn> see if you are operating a robot in its "sweet spot" you can turn up the axes limits
[21:23:30] <etla> we just talk about them, I bet no-one has a hexapod at home
[21:24:02] <Jymmm> * Jymmm has three quadpods sitting right here...
[21:24:26] <fenn> but to simplify the code you can just consider the extreme limits of motion and apply those limits for all cases
[21:25:10] <fenn> i mean pretend that you have a long-arm lever even when you are working with a short lever
[21:25:22] <fenn> am i making sense?
[21:25:44] <etla> yes, choose the worst case from within the work envelope
[21:25:49] <fenn> exactly
[21:26:13] <etla> well, I'd be happy (for a while atleast) with only trivkins
[21:26:20] <alex_joni> etla: there is no max_vel for an axis
[21:26:34] <alex_joni> that's joint actually (what you have in the ini)
[21:26:41] <alex_joni> even if the name is borked...
[21:26:51] <alex_joni> but guess you knew that..
[21:26:54] <fenn> * fenn wants to fix all the names so this isn't so damn confusing
[21:27:33] <etla> ok... but feedrates are specified and calculated in cartesian coords
[21:28:13] <jepler> and need to be respected, because they might be based on the capability of the cutter
[21:28:37] <etla> was there some consensus on how rotational axes should be treated ?
[21:28:55] <jepler> consensus? doubtful.
[21:28:57] <alex_joni> yes, they should spin
[21:29:03] <alex_joni> as in rotate
[21:29:15] <jepler> for anything I've done, I have either XYZ moves or A moves, and never mix them
[21:29:16] <etla> but the farther out you're on a carusel the more fun it is !
[21:29:36] <fenn> i would like to specify it in degrees/sec and let the operator figure it out
[21:30:17] <jepler> yes, we should use the new code Ḟ to specify the angular feed rate
[21:30:31] <jepler> only it would have to be in picoradians per fortnight or something
[21:30:52] <fenn> what's wrong with degrees/sec
[21:31:11] <fenn> or rpm whatever you want
[21:31:16] <etla> if you want SI it's radians/sec
[21:31:45] <fenn> ok so we are agreed at least that it should NOT be specified as units length/sec?
[21:31:51] <jepler> well it'd have to be "per minute" to match what F- does now
[21:32:20] <etla> or, a machine specific kinematics function should do the calc ?
[21:32:30] <jepler> G1 X0 X10 A[360 * 10 * 20] F???
[21:32:49] <fenn> etla you are confusing axes and joints
[21:33:04] <etla> probably
[21:33:10] <fenn> a puma doesn't have and rotary axes, it uses rotary joints
[21:33:11] <jepler> I want to cut a 20 threads-per-inch thread on my 10 inch rod. If I know how many inches of material per minute my cutter can cut, what do I specify for F?
[21:33:19] <fenn> s/and/any
[21:33:34] <alex_joni> fenn: how many axes does a puma have?
[21:33:45] <fenn> alex_joni: none
[21:34:04] <alex_joni> hrmpf... that's .. not true
[21:34:12] <fenn> i dont care if they call it a "5 axis robot" or whatever
[21:34:16] <Jymmm> jepler was that a retirical question?
[21:34:21] <Jymmm> retorical
[21:34:28] <fenn> you should be asking "how many degrees of freedom does a puma have"
[21:34:48] <jepler> Jymmm: I'm not interested in the numeric answer, if that's what you mean
[21:35:09] <alex_joni> fenn: a PUMA works in XYZ (3 axes) and ABC (3 rotary axes)
[21:35:19] <fenn> jepler: that is why i hate g-code
[21:35:23] <jepler> Jymmm: I mean, in a broad sense, when I have things like rotational axes, how do I make sure I don't break my tool off because I was cutting too much material too fast
[21:35:28] <alex_joni> but usually you call those joints
[21:35:29] <Jymmm> jepler: Well, no. But knowing the max speed alone of somethig isn't always the best/common practice either.
[21:35:30] <alex_joni> darn
[21:35:32] <alex_joni> DOF's
[21:35:34] <jepler> since after all F- is the only tool you have to do to specify feed rate
[21:35:35] <alex_joni> * alex_joni is tired
[21:35:54] <jepler> "only tool" meaning "only way to express it in g-code"
[21:36:03] <Jymmm> jepler what if your rod is RC60 as example.
[21:36:19] <fenn> alex_joni: the human body works in 6 axes, but has like 200 DOF's
[21:36:39] <alex_joni> I don't think so
[21:36:43] <alex_joni> you can move 2 hands
[21:36:50] <alex_joni> each in it's own 6 axes
[21:36:52] <jepler> Jymmm: I'm afraid I don't know what RC60 is
[21:37:11] <Jymmm> jepler: RC60 is a hardness rating
[21:37:15] <Jymmm> Rockwell 60
[21:37:26] <Jymmm> jepler RC60 == a BITCH to machine.
[21:37:37] <Jymmm> can be done, but needs TLC
[21:37:58] <jepler> OK, sure, I can machine butter faster than a piece of wood faster than a piece of AL faster than RC60, given the same tool and spindle
[21:38:31] <jepler> assume I have that figured out and I know an appropriate F-number if it's an XY problem
[21:39:01] <Jymmm> jepler: Right, so unless you're going to include the moleculer denistitys of various materials (in the MAchinery Handvbook), knowing MAx speed isn'tt the best thing.
[21:39:38] <Jymmm> (less all the typos =)
[21:39:56] <jepler> for an XA movement I need to know how emc is going to treat the f-number so I can still cut at an appropriate speed for my tool and my material
[21:40:21] <Jymmm> Now, if you want to know how fast you can turn a corner of X radius, Les knows all that stuff.
[21:40:41] <etla> if something goes wrong you can take to the F-word
[21:40:52] <Jymmm> lol
[21:41:00] <fenn> jepler you need some sort of kinematics so you know how the rotational joint (spindle) is related to the linear joint (x slide)
[21:41:08] <fenn> you cant just use trivial kinematics
[21:41:49] <Jymmm> jepler: Les explained it to me once in simplistic terms. You might want to give him a chat sometime.
[21:42:01] <fenn> les is good at explaining things
[21:42:19] <Jymmm> it's all physics
[21:42:35] <Jymmm> 30,000 feet and climbing
[21:42:51] <etla> maybe it's not a good idea to try to control lathes and mills with the exact same software ?
[21:43:25] <fenn> the reason mills are simpler to understand is that they are all the same
[21:43:26] <Jymmm> etla they're all the same, just turned sideways =)
[21:44:51] <fenn> damn thoughts bleeding over into other people's heads
[21:45:36] <fenn> hobby-level mills always use trivial kinematics
[21:45:51] <fenn> high-end mills do not, but nobody here has one of those, so we tend not to worry about it
[21:46:16] <fenn> now, low-end lathes do not use trivial kinematics, so you are forced to think about it
[21:47:05] <fenn> (by high end mill i mean like a 5 axis mill or one with redundant CNC controlled axes)
[21:47:17] <gurrag> alex_joni: Now I transfered the prompt output at the crash. I have the output of the two latest crashes
[21:47:25] <fenn> er, s/axes/joints :P
[21:47:29] <alex_joni> send them in a private message
[21:48:09] <fenn> for instance a bridgeport needs non-trivial kinematics to know that the knee and the quill are parallel
[21:48:40] <etla> fenn: a while ago you told me not to confuse axes and joints
[21:48:58] <etla> and now you're talking about kinematics for solving the angular feed stuff??
[21:49:02] <fenn> yeah i am trying not to confuse them myself
[21:49:42] <fenn> etla: how do you know what the diameter of the workpiece is, given X and A
[21:50:30] <fenn> erf.. X is always parllel to A
[21:50:38] <etla> well you don't, but you know the tangential velocity of the tool
[21:50:51] <etla> (in a reference frame where the workpiece is standing still)
[21:51:06] <fenn> i mean the diameter of the thing that is spinning
[21:51:13] <fenn> in a mill, you just tell it
[21:51:25] <fenn> in a lathe, it is changing so the computer has to figure it out
[21:51:48] <etla> well you know the exact radius at which your tool is right ?
[21:52:10] <fenn> you have to tell it something about how the lathe is constructed in order to know that
[21:52:16] <fenn> that's why i brought up kinematics
[21:52:34] <etla> mee too, and you said don't confuse axes with joints :)
[21:53:26] <etla> anyway, I'm not going to need to program lathes anytime soon
[21:53:43] <etla> and I guess the answer is to use a smart CAM package to gen the G-code
[21:54:34] <fenn> etla: i guess i am just overzealous in my crusade to keep joints and axes separate concepts
[21:55:55] <fenn> i've never used a cam package, but i assume they require some kinematics input
[21:56:09] <etla> not for trivkins
[21:56:16] <etla> I have not tried lathe mode
[21:56:29] <etla> i've tried mastercam and surfcam
[21:56:51] <fenn> well, trivkins is an implicit statement
[21:57:12] <fenn> "you didn't say anthing about kinematics so i'm using trivkins"
[21:57:20] <etla> yes
[21:57:38] <fenn> i wish cam were built into the cnc control more than the cad package
[21:57:47] <etla> 4th and 5th axes would be nice, but building them rigid enough DIY is kind of hard
[21:58:16] <fenn> you seen rainnea's 5 axis router?
[21:58:21] <etla> no
[21:59:17] <fenn> he seems to have removed the page
[21:59:30] <etla> google cache ??
[21:59:35] <fenn> http://www.rainnea.com/cnc.htm
[21:59:43] <fenn> it's just not linked from the front page i guess
[22:00:49] <fenn> the rotary axes look rigid enough, i dunno about the frame though
[22:01:10] <Jymmm> fenn: Just look at the work he produces with it
[22:01:57] <fenn> yeah wtf
[22:02:07] <fenn> you dont need a 5 axis mill to make bas-relief carvings
[22:04:25] <fenn> i dont see what you're talking about
[22:04:41] <alex_joni> mucus
[22:04:43] <Jymmm> fenn look inside your mind!
[22:04:57] <alex_joni> * alex_joni goes to bed
[22:04:58] <alex_joni> night all
[22:05:02] <Jymmm> nite
[22:05:35] <fenn> my head is no longer full of mucus.. i bought this ionic air purifier and it's great!
[22:06:45] <fenn> aside from his wooden box it's all engravings
[22:07:50] <fenn> the software he made is pretty cool
[22:08:01] <fenn> cnc toolkit
[22:11:12] <fenn> still, this modern "celtic" stuff pales in comparison to the real thing:
http://www2.hawaii.edu/~kjolly/151/images/kells2.jpg
[22:19:52] <K`zan> weird. EMC is not pulling the Y or Z clock low enough, but it is doing fine with the X, WTF?!?!?
[22:20:17] <Jymmm> voltage?
[22:20:49] <Jymmm> voltage wise you mean?
[22:25:21] <fenn> is it a laptop?
[22:25:49] <K`zan> No, old desktop (Thunderbird 1100)
[22:25:54] <Jymmm> is it a Coleco?
[22:26:15] <K`zan> Mayhe the 4K7 pullups are too aggressive, maybe swap in a 10K and see what happens.
[22:26:53] <fenn> are you looking at it on a scope or a meter?
[22:27:00] <fenn> (it might be pulsing>)
[22:31:13] <K`zan> Yep, looking at it on a scope, seems to get pulled down to about 2.5V...
[22:31:53] <K`zan> Only pulsing when commanded...
[22:33:23] <K`zan> Perplexing is that X is working...
[22:35:08] <K`zan> lemme see what happens when I connect the Y output to X.
[22:36:58] <K`zan> Gets more interesting...
[22:37:17] <K`zan> Y works on X driver but MUCH more slowly than X to X.
[22:37:35] <K`zan> Is it too early for a drink? Nah, after noon someplace ;-).
[22:40:11] <fenn> if drinking helps you figure out electronics problems, by all means..
[22:42:18] <fenn> why do they use mosfets to deal with the motor back-emf instead of diodes?
[22:42:43] <fenn> maybe i should just keep reading..
[22:43:24] <K`zan> NEI
[22:43:43] <K`zan> I'm outta ideas, break time.
[22:44:14] <K`zan> Heh, synergy-cad wants to upgrade every time I run apt-get upgrade, quick those folks :).
[23:02:16] <fenn> gah. this is like the third time i've read about motor control circuits and had no idea what happened in the end
[23:05:52] <Jacky^> -.-
[23:05:54] <Jymmm> K`zan: just remove it from the apt sources file
[23:06:07] <Jacky^> night
[23:06:13] <Jymmm> NITE Jacky^
[23:06:16] <Jacky^> Jacky^ is now known as Jacky^afk
[23:54:10] <lerman> Regarding plain kernel preemption, Con offered the following summary, "with these workloads, on this hardware, running these real time simulations there is not a convincing argument for CONFIG-PREEMPT. Note that running interbench with the non-real time benchmarks also does not show a convincing reason for preempt." Conversely, the PREEMPT_RT test revealed a noticeable change, about which...
[23:54:11] <lerman> Has anyone (else) seen this?
http://kerneltrap.org/node/5466 --
[23:54:13] <lerman> Con Kolivas [interview] used the latest version of Interbench, his interactivity benchmarking tool [story], to compare latencies between the plain 2.6.12 kernel, the 2.6.12 kernel with kernel preemption enabled, the plan 2.6.10 kernel, and the 2.6.10 kernel with the PREEMPT_RT realtime preemption option enabled.
[23:54:15] <lerman> ...Con concluded, "interestingly the average latencies are slightly higher (in the miniscule <2us range), but the maximum latencies are excellently bound to 25us."
[23:54:16] <lerman> Follow the link for details.
[23:54:18] <lerman> The reason I find this interesting is that it might lead to off the shelf linux with hard realtime priority support. I really don't know anything about when this will be widespread and whether the benchmark numbers reflect application process context switch times. I suspect, though, that it could obsolete the requirement for a special Kernel to run EMC (or EMC2).
[23:54:22] <lerman> Does anyone out there have more info?
[23:55:12] <icee> you need a better level of assurance than benchmarking IMO
[23:55:34] <icee> and 25 microseconds isn't that great
[23:55:44] <a-l-p-h-a> no it's not at all. it's really slow
[23:55:46] <a-l-p-h-a> gah.
[23:56:07] <a-l-p-h-a> I have the same issue. which is why I'm contemplating getting the g101 or g102.
[23:57:04] <icee> rtai/adeos is a joke though
[23:58:48] <lerman> It's probably fast enough for non step based systems. The idea of using a general purpose computer to output a step at a time through a parallel port to drive a counter up or down to control PWM doesn't make sense to me.
[23:59:19] <lerman> icee: I don't know much about that. Why do you say that it is a joke?
[23:59:54] <icee> lerman: performance isn't great, and all your code needs to run in kernel space
