#emc | Logs for 2006-08-21

Back
[00:01:18] <A-L-P-H-A> what are those nuts called, that are part nut, part washer... looks like _| |_ where the gap is threaded on the inside. Sometimes they have teeth to bite into wood.
[00:01:29] <jmkasunich> tee-nuts
[00:01:50] <A-L-P-H-A> thought so... wasn't sure if they were called something else, officially
[00:02:10] <cradek> hi guys
[00:02:37] <cradek> jmkasunich: back home yet?
[00:02:41] <jmkasunich> yeah
[00:02:46] <cradek> good
[00:03:17] <cradek> I finally got new glasses - everything is sharp but I'm in a fun-house
[00:03:27] <jmkasunich> bifocals?
[00:03:37] <cradek> not yet
[00:03:37] <A-L-P-H-A> jmkasunich, thanks.
[00:03:43] <cradek> pop-bottles
[00:03:53] <A-L-P-H-A> cradek? how old are you?
[00:03:53] <jmkasunich> heh
[00:04:06] <cradek> 3x and holding haha
[00:04:10] <A-L-P-H-A> cradek = bubbles! [maybe it's a Canadian reference]
[00:04:25] <cradek> actually I'm only 32 or 33
[00:04:40] <A-L-P-H-A> oh, so you're 5-6years older than me.
[00:04:45] <cradek> feel 40, act 17
[00:05:33] <cradek> what is bubbles! ?
[00:06:12] <A-L-P-H-A> bubbles is a character on a popular show on "Showcase". Showcase is this edgy channel.
[00:06:33] <A-L-P-H-A> bubbles is this dopey character with huge thick glasses...
[00:06:38] <cradek> ah
[00:06:54] <A-L-P-H-A> he's the most sane one of the trio of misfits that live in a trailor park.
[00:07:13] <cradek> here, people who are my advanced age and remember when pop came in glass bottles call them pop-bottle glasses (named after the bottom of the bottle which was thick glass)
[00:07:17] <A-L-P-H-A> it's actually a really funny show, if you just allow zero brain function.
[00:07:31] <cradek> I can sure do that sometimes.
[00:07:50] <cradek> sometimes I like Southpark, but I don't have TV service so don't see them very often
[00:08:33] <A-L-P-H-A> cradek... www.mininova.org www.eztvefnet.org www.demonoid.com www.piratebay.org
[00:08:42] <A-L-P-H-A> you can find them there.
[00:08:46] <A-L-P-H-A> or at your local video store.
[00:09:19] <cradek> thanks but I stay away from "borrowing" shows/movies online
[00:09:29] <cradek> true about the video store
[00:09:43] <A-L-P-H-A> are you affraid of the big bad R*AA
[00:10:04] <cradek> their crap isn't worth any risk whatsoever
[00:10:29] <cradek> so anyway
[00:10:30] <A-L-P-H-A> lucky I live in a FREE country.
[00:10:30] <A-L-P-H-A> :)
[00:10:49] <A-L-P-H-A> Did you vote Republican? :)
[00:10:58] <cradek> you must be joking
[00:11:05] <A-L-P-H-A> I was... hence the :)
[00:11:25] <cradek> my dad and I make a point of cancelling each other's votes every time
[00:11:29] <cradek> it's a tradition I guess
[00:11:36] <jmkasunich> what does voting republican have to do with music piracy?
[00:12:05] <cradek> voting republican is often voting (a little more) for corporate interests
[00:12:09] <A-L-P-H-A> jmkasunich, the republicans are the major endorsers(sp) of DRM and such crap.
[00:12:25] <jmkasunich> corporations are the major endorsers of DRM and such crap
[00:12:25] <cradek> of course it's bad with both parties, but not equally bad.
[00:12:26] <A-L-P-H-A> "hands in my pocket" commercial comes to mind.
[00:12:46] <A-L-P-H-A> jmkasunich, yes... but they get their puppets to move it in the senate and congress.
[00:12:53] <A-L-P-H-A> cradek, yup.
[00:13:08] <A-L-P-H-A> if/when the democrats get back into power... they'll be just as bad. :)
[00:13:17] <jmkasunich> exactly
[00:13:19] <A-L-P-H-A> ahhhhhhhhhhh. love the status quoe, or move. :)
[00:13:28] <cradek> call me a bad geek but DRM is a small problem compared to other things.
[00:13:47] <A-L-P-H-A> cradek, just send soldiers at it... that'll make it better.
[00:13:48] <cradek> there's more important reasons to vote anti-republican.
[00:13:55] <cradek> but this is a bit off topic...
[00:14:02] <jmkasunich> the republicans (the religious right) want to stick their noses in bedrooms
[00:14:22] <jmkasunich> the dems want to take my pistols
[00:14:29] <cradek> jmkasunich: don't forget the science classroom
[00:14:31] <A-L-P-H-A> I'm all for civil unions... I'm all for gay marriages... but you can't make a church allow it.
[00:14:45] <A-L-P-H-A> ooooooooooh hahaha...
[00:15:01] <A-L-P-H-A> what states where thouse that most teach "intelligent wishful thinking design"?
[00:15:15] <cradek> so anyway I'm trying to fix this bug in threading
[00:15:17] <jmkasunich> fskced up ones
[00:15:29] <A-L-P-H-A> hehe... I love it.
[00:15:32] <cradek> does anyone want to talk about that?
[00:15:40] <jmkasunich> lol
[00:15:41] <jmkasunich> ok
[00:15:51] <cradek> whew
[00:15:52] <A-L-P-H-A> some girl in my senior year in hs, got excused from class because of the topic of evolution was being taught.
[00:16:09] <cradek> LALALALA I can't hear you I can't hear you I can't hear you
[00:16:29] <A-L-P-H-A> * A-L-P-H-A lures cradek out of his happy place with a cookie.
[00:16:38] <cradek> haha
[00:17:42] <jmkasunich> what kind of cookie
[00:18:05] <A-L-P-H-A> I personaly like white macedamian nut ones.
[00:18:23] <A-L-P-H-A> but chocolate chocolate chip works too.
[00:18:27] <cradek> ginger with frosting
[00:18:34] <A-L-P-H-A> you just want to eat a man!
[00:18:36] <A-L-P-H-A> sicko.
[00:18:46] <cradek> ?
[00:18:49] <jmkasunich> if its choc. choc. chip, I'm gonna steal it and let cradek go back to his happy place
[00:18:51] <A-L-P-H-A> ginger bread man.
[00:18:57] <cradek> oh
[00:19:06] <jmkasunich> gingersnap cookies, not gingerbread men
[00:19:11] <A-L-P-H-A> cradek, what has happened to your lateral thinking skills?
[00:19:23] <jmkasunich> the cookie distracted him
[00:19:27] <A-L-P-H-A> heh
[00:19:35] <cradek> WHERE'S MY COOKIE
[00:19:45] <jmkasunich> I took it
[00:19:49] <cradek> crap
[00:20:07] <A-L-P-H-A> no, I don't think you want a crap cookie.
[00:20:09] <jmkasunich> got some of that if you really want it
[00:20:23] <A-L-P-H-A> how about a cow pie instead?
[00:20:23] <jmkasunich> back corner of the yard where the dog goes
[00:20:50] <A-L-P-H-A> gonna buy some tee-nuts to hold down the seat cushions.
[00:21:12] <jmkasunich> what seats?
[00:21:36] <A-L-P-H-A> 8 dinning room chairs.
[00:21:50] <A-L-P-H-A> they're being re-upholstered. (sp)
[00:22:24] <jmkasunich> so... threading?
[00:22:29] <cradek> yeah threading
[00:22:43] <cradek> if you do a G33 with F0 it never starts moving
[00:22:48] <A-L-P-H-A> oh... they're old woodscrews. so changing them over to machine screws... so we can tighten them down nice.
[00:22:58] <cradek> although I can't see where F0 should matter
[00:22:59] <jmkasunich> well, with F0, what do you expect it to do?
[00:23:08] <cradek> G33 ignores the feed
[00:23:13] <jmkasunich> if you do G1 with F0 it never moves either
[00:23:34] <cradek> well G33 should
[00:23:36] <A-L-P-H-A> write a condition to change for F0 then.
[00:23:43] <jmkasunich> I thought with G33, F was the feed per rev?
[00:23:50] <cradek> no it's K
[00:23:58] <jmkasunich> ok... why?
[00:24:07] <cradek> why what?
[00:24:21] <jmkasunich> why use K for a number that is basically feed per rev?
[00:25:03] <cradek> it would mess up F modality before and after the synced move
[00:25:18] <cradek> g1x1
[00:25:21] <cradek> g33x0k.1
[00:25:27] <cradek> g1x1
[00:25:31] <cradek> errrr
[00:25:35] <cradek> put F20 on the first g1
[00:25:48] <cradek> g1x1f20 / g33x0k.1 / g1x1
[00:25:53] <jmkasunich> IOW, you want them to be able to leave the non-sync feedrate in "F" and not change it with G33 and change it back later
[00:26:06] <cradek> I guess
[00:26:14] <cradek> I argue with myself over this one
[00:26:29] <cradek> but having a g1 feed rate of .05 is never what you want
[00:26:59] <jmkasunich> I guess it depends on how you look at it
[00:27:29] <cradek> I don't think this matters - it could be any letter afaic
[00:27:35] <jmkasunich> if there is one "feedrate" that needs to be set appropriately for the code you are executing, you set F at the start of the G33 section, and set it again after the end
[00:27:54] <cradek> F has some drawbacks but is nice because it's a "feed"
[00:28:04] <jmkasunich> if you think of it as two independent "feeds", and use one or the other based on the g-code, then K makes sense to set the "other" one
[00:28:25] <jmkasunich> K during G33 is a feed too
[00:28:29] <cradek> in g76 I used P for "pitch"
[00:28:52] <cradek> * cradek juggles arbitrary letters
[00:29:05] <cradek> maybe G33 should use P too
[00:29:08] <jmkasunich> feels like 1980 BASIC doesn't it
[00:29:20] <cradek> yeah this language is silly
[00:29:35] <cradek> I'm back to not caring what letter it is
[00:29:42] <jmkasunich> the letter is irrelevant - the decision is whether to think in terms of a single feedrate that you change, or two that you switch between
[00:29:45] <cradek> I think at least some other controllers use G33/K
[00:29:57] <cradek> well the feed modes are totally different
[00:30:01] <jmkasunich> how will constant fed per rev specify feeds?
[00:30:08] <jmkasunich> s/fed/feed/
[00:30:13] <cradek> g9x fx iirc
[00:30:24] <jmkasunich> where x is feed per rev?
[00:30:28] <cradek> you switch F "modes" with g9x
[00:30:43] <cradek> look at the wiki to be sure, I haven't read it for a while
[00:30:50] <cradek> AdvancedLatheFeatures iirc
[00:30:57] <jmkasunich> thats OK, I'll take your word for it
[00:31:05] <jmkasunich> my point is that we're inconsistent
[00:31:20] <jmkasunich> constant feed/rev uses F, but threading feed/rev uses K
[00:31:41] <jmkasunich> maybe thats because everybody expects us to be inconsistent, I dunno
[00:31:48] <cradek> I'm not sure if there is feed/rev, or if it's constant surface feed
[00:31:54] <cradek> maybe both
[00:31:59] <jmkasunich> CSS and feed/rev are independent
[00:32:03] <jmkasunich> but often used together
[00:32:11] <jmkasunich> CSS makes no sense without feed/rev
[00:32:16] <jmkasunich> but feed/rev doesn't need CSS
[00:32:22] <cradek> * cradek shivers
[00:32:29] <jmkasunich> why?
[00:32:51] <cradek> oh I just know that nobody else will tackle those and they look hard to get right.
[00:32:53] <jmkasunich> CSS adjusts spindle speed as a function of cutting radius, and doesn't give a flying hoot about feed
[00:33:08] <cradek> ok right
[00:33:22] <jmkasunich> feed/rev means that as css (or anything else) changes the speed, the tool will continue to take the same thickness chip
[00:33:26] <cradek> so that's in sf/m or somesuch
[00:33:30] <jmkasunich> completely independent
[00:33:36] <cradek> but you can have any feed at some fixed sf/m
[00:33:38] <cradek> I got it
[00:34:11] <jmkasunich> no more shivers? ;-)
[00:34:32] <cradek> not until I read the spec that talks about how all the gcodes interact to do this
[00:34:53] <jmkasunich> yeah, there are always complications
[00:34:59] <jmkasunich> but anyway, CSS is irrelevant
[00:35:00] <jmkasunich> I
[00:35:10] <jmkasunich> I'm not convinced that feed/rev is tho
[00:35:21] <cradek> now can I whine about how I can't use the debugger to find this bug?
[00:35:25] <jmkasunich> what is G33 except a special case of feed/rev?
[00:35:42] <jmkasunich> sure, you can whine
[00:35:48] <cradek> it is a special case.
[00:35:58] <cradek> wah, I can't use the debugger to find this bug
[00:36:08] <jmkasunich> I still think debuggers are of limited usefullness with RT code
[00:36:20] <jmkasunich> (counterwhine)
[00:36:26] <cradek> wah, I can't run this code in sim mode without realtime
[00:36:28] <jmkasunich> ok, thats out of the way
[00:36:45] <jmkasunich> what exactly is it doing wrong? F0 stops it?
[00:37:01] <cradek> I think it's waiting for the spindle index, but it waits forever
[00:37:04] <jmkasunich> F0.001 is OK, and gives the same result as F100?
[00:39:07] <SWPadnos> we need a non-blocking error FIFO for the RT code ;)
[00:40:11] <cradek> ohhhhhh
[00:40:30] <cradek> maybe it's a problem with threading in MDI mode
[00:41:40] <cradek> Aug 20 19:42:47 buster kernel: [855229.117186] Default Trap Handler: vector 14: Suspend RT task ede6b800
[00:41:43] <cradek> ouch
[00:41:52] <cradek> dammit
[00:42:02] <jmkasunich> kernel space segfault?
[00:42:16] <cradek> looks like
[00:42:35] <jmkasunich> how did you make it do that?
[00:42:50] <cradek> s400m3
[00:42:50] <cradek> g0x0z0
[00:42:50] <cradek> g33z-.5k.1
[00:42:50] <cradek> m2
[00:43:37] <jmkasunich> in a program, or MDI?
[00:43:54] <cradek> in a program
[00:44:04] <cradek> something's really wrong now
[00:44:35] <cradek> taking out my print_msg - that's the only thing I added
[00:45:14] <jmkasunich> how long was the message? did you attempt to print a float?
[00:45:22] <cradek> that wasn't the problem
[00:45:39] <cradek> huh I wonder how this can be so broken
[00:45:50] <jmkasunich> its doing it with stock code?
[00:45:56] <cradek> yes
[00:45:58] <SWPadnos> this may seem like a silly idea, but have you restarted? something in kernel space may have been borked
[00:46:17] <cradek> I'm trying threading.ngc now which has worked a thousand times
[00:46:42] <jmkasunich> is this a stock config? I'll try to duplicate
[00:46:56] <SWPadnos> (of course, trying a different RIP version would be quicker)
[00:47:06] <cradek> threading.ngc works fine
[00:48:05] <cradek> bonk! my short program bombs every time
[00:48:30] <SWPadnos> try putting a non-synchronized move between the G33 and the M2
[00:48:49] <cradek> just did, that doesn't seem to help
[00:48:55] <SWPadnos> bummer
[00:49:21] <jmkasunich> put pauses between each line (that will at least confirm the line where the error is happening) (or can you already be sure)
[00:49:40] <cradek> pretty sure it bombs when the g33 starts
[00:50:00] <jmkasunich> what config are you using?
[00:50:04] <cradek> max
[00:50:10] <cradek> it has the simulated encoder
[00:50:14] <cradek> it has the simulated spindle encoder
[00:52:10] <cradek> aha
[00:52:20] <cradek> putting two unsynced moves after the g33 fixes it
[00:52:35] <cradek> I bet this is jepler's new acute stuff
[00:52:42] <jmkasunich> but it needs 2?
[00:52:46] <cradek> seems to
[00:53:09] <SWPadnos> blending?
[00:53:17] <jmkasunich> you are using the stock max config? when I try I get linear move 3 out of range
[00:53:21] <SWPadnos> or a lookahead kind of thing?
[00:53:27] <jmkasunich> bet I need to home first
[00:53:44] <cradek> stock max config
[00:54:02] <cradek> move Z up an inch or two and press End Return to offset
[00:55:28] <jmkasunich> it seems to hang on the g33 line
[00:55:40] <jmkasunich> no trap message in /var/log/messages tho
[00:56:48] <cradek> ok that's the first problem
[00:56:53] <cradek> not sure if the two problems are the same
[00:56:59] <cradek> second one is the crash
[00:57:19] <cradek> your program is s400m3 / g0x0z0 / g33z-.5k.1 / m2 ?
[00:57:36] <jmkasunich> yes
[00:57:44] <cradek> that definitely crashes on me
[00:57:48] <cradek> let me see if I'm updated
[00:58:24] <cradek> yes I am
[00:58:39] <cradek> our machines are totally different
[00:58:50] <jmkasunich> when I run it, the highlight makes it down to the g33 line, then freezes
[00:58:57] <jmkasunich> I can estop the machine
[00:59:03] <cradek> ok
[00:59:06] <jmkasunich> the file menu is grayed except for quit
[00:59:23] <jmkasunich> only after I go back into run does the file menu recover and it acts "normal"
[00:59:37] <jmkasunich> no output to dmesg (var/log/messages) at all
[00:59:52] <cradek> if you watch emctop you'll see that the id for that command stays active until you estop
[01:02:26] <jmkasunich> interesting - it issues linear move (the G0), set_spindlesync (start of G33), linear move (G33 move) and set_spindlesync again
[01:02:45] <cradek> yes the second spindlesync is to "unsync"
[01:02:55] <jmkasunich> that implies that it finished the move
[01:03:18] <cradek> no it just means it's queued up, right?
[01:03:28] <jmkasunich> duh, all these "issued" commands are just in a bugger
[01:03:34] <jmkasunich> biffer
[01:03:36] <jmkasunich> buffer
[01:03:44] <cradek> booger
[01:03:51] <jmkasunich> bugger it (as Paul would say)
[01:04:36] <cradek> it never finishes the linear move, watch emctop
[01:04:58] <cradek> but still ... my crash
[01:05:18] <jmkasunich> it never even starts the linear move
[01:05:20] <cradek> I guess I'll put in some cursed prints
[01:05:36] <cradek> it doesn't start moving, but I bet the motion is active
[01:05:53] <jmkasunich> at 1000 print per second, make 'em small (or smart)(
[01:06:11] <cradek> arg.
[01:07:41] <cradek> so there's no way to figure out where it crashes? how do you deal with this stuff?
[01:08:09] <jmkasunich> inspection, smart prints, dumb luck
[01:08:39] <jmkasunich> there is some "smart print" code in there already, just a sec
[01:08:44] <cradek> there's kernel-mode gdb but the patches apparently interfere with rtai
[01:09:03] <cradek> if we had non-rtai but still kernel sim, maybe we could use that
[01:09:11] <cradek> it would still suck, but maybe less
[01:09:33] <jmkasunich> see "check_stuff()" in control.c
[01:09:47] <jmkasunich> enable it (ifdef)
[01:10:03] <jmkasunich> and change the variable it looks at as desired
[01:10:36] <jmkasunich> it tests the var for changes at a lot of places in the main control loop, and prints where it changes
[01:11:14] <cradek> I bet the bug is in tp.c
[01:11:36] <jmkasunich> it seems like it starts the second move
[01:11:42] <jmkasunich> I scoped motion.in-pos
[01:11:55] <jmkasunich> it goes low (for the G0), then high (when done), then low again
[01:12:11] <cradek> wish you had the crash too
[01:12:52] <jmkasunich> mixed feelings about that ;-/
[01:12:54] <cradek> it does crash with execId=3 (the g33 move)
[01:14:42] <SWPadnos> might this apply? https://mail.comedi.org/pipermail/comedi/2003-January/004006.html
[01:14:56] <SWPadnos> (not quit esure what you were doing when the problem showed up)
[01:16:02] <jmkasunich> SWPadnos: I don't think we call udelay anywhere
[01:16:23] <SWPadnos> that's just one example - it's any Linux-context-sensitive thing you might do
[01:17:02] <jmkasunich> to my knowledge, none of the emc RT code calls linux (of course, I could be completely wrong about that, its not like I audited it)
[01:17:12] <SWPadnos> hmmm - this message implies that you can use kgdb with RTAI, but you have to use a serial debugging host
[01:17:17] <SWPadnos> https://mail.rtai.org/pipermail/rtai/2003-January/002034.html
[01:17:40] <SWPadnos> right - the gettimeofday thing was removed because it took up too much of the day's time :)
[01:18:21] <cradek> yes I think you always use two machiens for kgdb
[01:18:49] <jmkasunich> I can't use the procedure in that message - I don't drink coffee
[01:18:59] <SWPadnos> the previous paragraph implied that someone had a self-hosted version, but it was questionable (and unlocatable)
[01:19:07] <cradek> jmkasunich: I can do that step
[01:19:19] <SWPadnos> yeah - we can definitely fill in that gap for you
[01:19:31] <cradek> RT_SET_RTAI_TRAP_HANDLER(your_trap_handler) in your init_module().
[01:19:41] <cradek> can this help? we can get eip that way
[01:19:57] <jmkasunich> no clue
[01:20:18] <jmkasunich> one reason for RTAPI is so that I and other developers can remain blissfully clueless about RTAI itseof
[01:20:21] <cradek> chris@buster:~$ grep tpRunCycle /proc/kallsyms
[01:20:21] <cradek> f0d3bde0 t tpRunCycle [motmod]
[01:20:31] <cradek> oooooooh
[01:20:37] <jmkasunich> what a surprize
[01:21:06] <cradek> that would be so much better than nothing
[01:21:08] <SWPadnos> hmmm - at least the default trap handler shuts down the offending task, and doesn't freezethe machine ...
[01:21:14] <cradek> yeah no kidding
[01:21:29] <jmkasunich> oh, thats not the failure location, just noting that you have a bit of a symbol table to work with
[01:21:39] <cradek> right
[01:21:47] <cradek> if we had eip we could see which function is bad
[01:21:54] <cradek> we can get eip with RT_SET_BLAHBLAH
[01:22:07] <cradek> but I don't know how to do the suspend in order to not crash
[01:22:11] <jmkasunich> assuming we can figure out how to write a trap handler
[01:22:27] <jmkasunich> can we just nab the EIP and then chain to the default handler and let it do the messy stuff?
[01:22:35] <cradek> it says how to get eip, but not how to suspend
[01:22:36] <SWPadnos> if you get the address of the default handler, you can just poke the address somewhere, and then call the default
[01:22:38] <SWPadnos> right
[01:22:56] <cradek> maybe there's RT_GET_BLAHBLAH
[01:23:12] <jmkasunich> what about:
[01:23:12] <SWPadnos> what's the return from the SET_BLAHBLAH function?
[01:23:20] <jmkasunich> 1. Define DEBUG_TRAP at the top of arch/i386/rtai.c, recompile and
[01:23:20] <jmkasunich> reload it along with your application. You'll see the faulting EIP in
[01:23:20] <jmkasunich> a console message. You'll have to chase the culprit in assembly mode
[01:23:20] <jmkasunich> (*).
[01:23:49] <jmkasunich> that was option 1, option 2 is the RT_SET_blah thingy
[01:23:57] <cradek> that would be great for the future
[01:24:17] <jmkasunich> the recompile in question is basically a kernel build?
[01:24:27] <cradek> yes
[01:24:29] <jmkasunich> or just the rtai module?
[01:24:37] <cradek> kernel
[01:24:55] <jmkasunich> ok, option 2 it is
[01:25:21] <cradek> I don't even see that file in my kernel
[01:25:38] <cradek> or in the rtai source
[01:26:00] <cradek> hmm
[01:27:56] <cradek> I thinkit does return the old handler
[01:28:46] <SWPadnos> yep - it does
[01:28:53] <SWPadnos> RT_TRAP_HANDLER rt_set_rtai_trap_handler(RT_TRAP_HANDLER handler)
[01:29:16] <SWPadnos> https://mail.rtai.org/pipermail/rtai/2002-November/001648.html
[01:30:00] <SWPadnos> I like the last sentence:
[01:30:14] <SWPadnos> "Whatever your choice you can catch everything and manage it the way you want, but you must be in full knowledge of what you'll do from that very moment onward."
[01:30:25] <jmkasunich> yeah
[01:30:30] <cradek> heh
[01:30:33] <jmkasunich> to be honest, I think that way lies madness
[01:30:46] <jmkasunich> smart prints my man, smart prints
[01:30:49] <cradek> adding a print and then calling the old handler doesn't seem mad to me.
[01:30:59] <cradek> this is called axe-sharpening
[01:31:03] <SWPadnos> it is a task-specific handler though
[01:31:04] <jmkasunich> calling it might not be right
[01:31:23] <jmkasunich> does it return? or do a "end of interrupt" lkind of thing?
[01:31:28] <SWPadnos> so you won't necessarily screw up all of RTAI
[01:31:36] <jmkasunich> your stack frame is gonna be there if you call it
[01:31:50] <SWPadnos> durn good question
[01:33:27] <jmkasunich> how about this: "emcmot_hal_data->debug_float_0 = 1.0;"
[01:33:44] <jmkasunich> scatter those around, with differnt values for 1.0
[01:33:56] <jmkasunich> then scope it, and see what value you have when it freezes
[01:34:00] <SWPadnos> well, if 1.0 changes value, that could be a clue ;)
[01:34:03] <cradek> halscope immediately crashes
[01:34:25] <jmkasunich> as soon as you start it up?
[01:34:52] <jmkasunich> thats a clue itself - maybe hal shared memory is buggered?
[01:34:53] <cradek> when I get the crash halscope freaks out (pops up its "pick a thread" window)
[01:35:09] <jmkasunich> oh, because you are sampling in the thread that is suspended
[01:35:12] <cradek> no it's always done that when something crashes
[01:35:12] <jmkasunich> thats not a freakout
[01:35:23] <cradek> ok
[01:35:37] <jmkasunich> it has a sort of watchdog - if the sampling code isn't running it assumes you haven't assigned it to a thread
[01:35:43] <jmkasunich> halcmd stop would have the same effect
[01:35:53] <jmkasunich> try sampling in the base thread instead of the servo thread
[01:35:57] <jmkasunich> I bet that one keeps running
[01:37:37] <jmkasunich> note that if you are changing the debug value in many places in the code, you won't see all the changes
[01:38:00] <cradek> wonder if I'll see the last one
[01:38:01] <jmkasunich> because halscope only samples once in a while, probably never during execution of the servo thread
[01:38:14] <jmkasunich> you will always see the value that it freezes at
[01:39:02] <jmkasunich> the code is doing sleep sleep sample sleep sleep run-servo-thread 1.0 2.0 3.0 4.0 sleep sleep sample sleep
[01:39:14] <SWPadnos> the default trap handler returns 0
[01:39:19] <jmkasunich> so you won't see the 1,2,3,4, but if it freezes at 3, you'll see that
[01:39:33] <SWPadnos> or sometimes 1, but it's a static int function
[01:39:48] <SWPadnos> line 2201 in this file: http://cvs.gna.org/cvsweb/magma/base/sched/sched.c?rev=1.111;cvsroot=rtai
[01:40:48] <jmkasunich> looks like the suspend is just "rt_task_suspend()"
[01:41:57] <jmkasunich> you can call rtapi_task_pause(rtapi_task_self)) to avoid trying to figure out the rtai task id
[01:42:23] <jmkasunich> except, calling it from a trap handler might not work
[01:42:33] <jmkasunich> rtapi_task_self that is
[01:43:24] <SWPadnos> they determine rt_task in a simple way that should be usable by a custom handler
[01:43:53] <jmkasunich> rtapi_task_pause has the rt_task in an array, all you need is the rtapi task ID
[01:44:03] <jmkasunich> which just might be the same as the hal thread ID
[01:44:07] <jmkasunich> lemme check
[01:44:14] <SWPadnos> 2205: rt_task = rt_smp_current[smp_processor_id()];
[01:44:28] <SWPadnos> 2211: rt_task_suspend(rt_task);
[01:44:50] <jmkasunich> assuming rt_smp_current and all the rest is in scope for your handler code
[01:44:56] <jmkasunich> dunno what .h file that stuff is in
[01:45:12] <jmkasunich> rtapi hides that
[01:45:14] <SWPadnos> oops - don't call that function - it's the one that calls the custom trap handler
[01:45:52] <jmkasunich> cradek has gotten very quiet
[01:45:59] <jmkasunich> hopefully that means he's making progress
[01:46:05] <SWPadnos> he's probably thinking or something
[01:46:21] <jtr> logger_aj: bookmark
[01:46:21] <jtr> See http://81.196.65.201/irc/irc.freenode.net:6667/emc/2006-08-21#T01-46-21
[01:46:27] <SWPadnos> I suppose I should change the sheets, and figure out why my wife's computer isn't working
[01:46:31] <SWPadnos> (not related)
[01:46:39] <jmkasunich> I have holes to bore
[01:46:49] <jmkasunich> boring, in more than one sense of the word, but needs to get done
[01:46:50] <SWPadnos> bor-ing!
[01:46:59] <cradek> I'm about to try the scope trick
[01:48:18] <jmkasunich> * jmkasunich waits eagerly
[01:48:23] <jmkasunich> (anything to avoid boring)
[01:49:46] <cradek> there's a reason they call it boring
[01:50:00] <cradek> halscope does keep running in the base thread
[01:50:12] <jmkasunich> yay
[01:52:02] <cradek> something about the scheme doesn't work, I always get 1.0
[01:52:27] <jmkasunich> I assume you have different values in differnet places?
[01:52:33] <cradek> oh duh
[01:52:34] <cradek> jas
[01:52:42] <jmkasunich> ;-)
[01:54:07] <cradek> oooo
[01:54:30] <cradek> did anyone figure out what vector 14 is?
[01:55:41] <cradek> think I found it
[01:56:20] <cradek> whee
[01:57:11] <jmkasunich> what did you find?
[01:57:26] <cradek> a programming 101 error
[01:57:35] <jmkasunich> oops
[01:57:52] <jmkasunich> how did you find it?
[01:58:02] <cradek> with your scheme
[01:58:19] <jmkasunich> 50 minutes ago:
[01:58:22] <jmkasunich> cradek so there's no way to figure out where it crashes? how do you deal with this stuff?
[01:58:22] <jmkasunich> jmkasunich inspection, smart prints, dumb luck
[01:58:32] <cradek> :-P
[01:58:56] <jmkasunich> granted, with a debugger it might have been 5 minutes ago
[01:59:31] <cradek> it would have immediately shown the line of code causing the crash...
[02:00:22] <jmkasunich> and inspection would have found the error?
[02:00:36] <cradek> eventually I suppose
[02:00:43] <cradek> I was definitely looking for this kind of thing
[02:01:17] <jmkasunich> I mean inspection of the line the debugger pointed to
[02:01:32] <cradek> oh yeah in a second
[02:01:40] <CIA-10> 03cradek 07HEAD * 10emc2/src/emc/kinematics/tp.c: fix crash when the synced move was the last (or only) move
[02:01:57] <jmkasunich> ultimately its always inspection, the debugger (or the smart prints) only narrow down the area to be inspected
[02:02:13] <cradek> yep
[02:02:42] <cradek> ok that's definitely a nice trick to remember
[02:04:33] <cradek> and remember you can't let your guard down for a second when programming with those pointers to structures that may be null
[02:05:22] <jmkasunich> more like "when programming with pointers"
[02:06:02] <cradek> wonder if this fixes the mdi issue too
[02:06:55] <cradek> nope
[02:07:04] <cradek> err not mdi, F 0
[02:07:44] <cradek> ah heck
[02:07:46] <cradek> it's not F0
[02:08:04] <cradek> it's worse
[02:08:27] <cradek> I bet there's more than one cycle between sync / move messages
[02:08:32] <cradek> so it gets "sync"
[02:08:36] <cradek> then the queue empties
[02:08:40] <cradek> so it turns off sync
[02:08:54] <cradek> then it gets "move" which, being not synced, goes at vel 0
[02:09:19] <jmkasunich> why does it turn off sync when the queue empties
[02:09:27] <jmkasunich> shouldn't it get a message to turn it off?
[02:09:33] <cradek> well it resets everything
[02:09:37] <cradek> not if you abort
[02:09:37] <jmkasunich> oh
[02:09:47] <cradek> yep that's it
[02:10:02] <cradek> if I MDI the g33 during a move that's still going, it all works
[02:10:15] <jmkasunich> question:
[02:10:30] <jmkasunich> _why_ do these things happen when the queue empties
[02:10:40] <jmkasunich> if abort should do them, then code abort to explicitly do them
[02:10:45] <jmkasunich> likewise with other conditions
[02:11:06] <jmkasunich> instead of having "queue empty" have all sorts of side effects
[02:12:29] <cradek> I guess abort does turn it off at the right time too
[02:12:37] <cradek> let me just try taking that out of the queue-empty code
[02:13:28] <cradek> that didn't fix it - maybe I don't understand the problem
[02:15:16] <cradek> flail flail
[02:15:19] <jmkasunich> heh
[02:15:33] <jmkasunich> I'm not much help - I'm multiplexing now
[02:15:55] <jmkasunich> 3" at 0.002 per rev and 120 RPM means time to type
[02:16:40] <CIA-10> 03cradek 07HEAD * 10emc2/src/emc/kinematics/tp.c: fix g33 in mdi mode
[02:17:01] <jmkasunich> ! flail
[02:17:08] <jmkasunich> what did you find?
[02:17:10] <cradek> let's just say I'm glad people are testing this
[02:17:19] <cradek> just what I thought it was
[02:17:28] <jmkasunich> queue empty?
[02:17:40] <cradek> yeah I think it emptied between sync and move
[02:19:39] <jmkasunich> crap
[02:19:50] <jmkasunich> I just realized I removed the part from the faceplate too soon
[02:19:58] <cradek> oh no
[02:20:06] <jmkasunich> I was supposed to bore full depth 0.630, then part depth 0.812
[02:20:19] <jmkasunich> I bored the .630, then moved on to the second part (its boring now)
[02:21:07] <jmkasunich> not fatal, that part needs to have more boring done from the other side anyway, and I can do the 0.812 bore then
[02:21:26] <cradek> good
[02:21:39] <jmkasunich> its just that the 0.812 bore has a tighter concentricity requirement than the rest, so I'll have to be more carefull than I was planning when I remount it
[02:21:40] <cradek> it sucks when removing a part from the machine ruins it, but sometimes it does
[02:22:45] <cradek> I have trouble patiently mounting stuff, I always want to get on to the cutting part
[02:24:03] <jmkasunich> same here, so I try to design stuff for minimal chuckings and all precision cuts done in the same chucking
[02:24:23] <cradek> that's definitely good practice anyway
[02:24:43] <jmkasunich> well, 0.630 is done on the 2nd part, time for the 0.812
[02:25:17] <jmkasunich> .812 is a bearing seat, no time to be fscking up
[02:26:14] <jmkasunich> y'know... it might make sense to do the .812 later on both parts
[02:26:31] <jmkasunich> I'll have a lot less rotating mass, and I'll be able to bore all the way thru
[02:27:32] <cradek> http://www.historictimekeepers.com/Staffsteps.htm
[02:27:55] <cradek> this is a classic problem of remounting in watchmaking
[02:28:11] <cradek> this guy turns (the .15mm diameters) between centers to work around it
[02:30:05] <cradek> he says it "takes a little practice"
[02:31:25] <jmkasunich> his fingers are damn close to the spinning lathe dog
[02:31:58] <cradek> no matter, the staff would just break if it hit him
[02:32:26] <cradek> I'm surprised he's not using a safety drive
[02:32:37] <cradek> (it slips to provide limited torque)
[02:32:47] <cradek> so if you dig in, the rotation stops, maybe saving the part
[02:33:41] <cradek> I've broken many more staffs than I've made succesfully
[02:34:49] <cradek> hmm, if I can't see the bottom of the screen is it time to clean the desk?
[02:34:59] <jmkasunich> yeah
[02:35:05] <jmkasunich> unless the obstacle is a cat
[02:35:10] <jmkasunich> which used to happen to me a lot
[02:35:17] <cradek> not this time
[02:36:15] <jmkasunich> man, that guy is nutz
[02:36:23] <jmkasunich> did you see the detent widget?
[02:36:34] <cradek> I've seen them
[02:36:44] <cradek> a bit thin, right?
[02:36:52] <jmkasunich> yeah, a bit
[02:37:06] <jmkasunich> .03 mm
[02:37:11] <jmkasunich> whats that in inches
[02:37:21] <jmkasunich> 1.2 thou?
[02:37:26] <cradek> 1.1
[02:37:32] <jmkasunich> nitpicker
[02:37:38] <jmkasunich> f-ing thin any way
[02:37:47] <cradek> I think .02mm is more standard, this must be for a big watch
[02:38:18] <jmkasunich> marine chronometer
[02:38:38] <cradek> yeah a pocket chronometer will be smaller (lighter balance)
[02:41:07] <cradek> .02mm = .0007 in
[02:41:27] <jmkasunich> heh, he gets $850 for those detents
[02:41:47] <cradek> good for him for keeping his prices up
[02:43:01] <cradek> and that reminds me to be careful with my pocket chronometer... I'm not up to making that part.
[02:47:05] <cradek> nice web page, no flashy stuff, just information
[02:47:11] <jmkasunich> yeah
[02:47:16] <jmkasunich> I'm still reading it
[02:47:30] <jmkasunich> the diamond wheels he sells are interesting, maybe handy to have around
[02:50:01] <cradek> if you have a 5mm collet (the largest on a watchmaker's lathe)
[02:50:28] <jmkasunich> I don't have metric
[02:50:40] <jmkasunich> but could make a custom sleeve or something
[02:55:17] <jmkasunich> well that was a pleasant digression
[02:55:20] <jmkasunich> back to boring boring
[02:55:34] <cradek> thanks for helping me fix those bugs
[02:55:38] <cradek> I'm probably off to bed soon
[02:55:49] <jmkasunich> you're welcome (such little help that it was)
[02:56:02] <jmkasunich> actually bed sounds like a good plan
[02:56:35] <jmkasunich> I'll set up the 4-jaw and do the rest tomorrow
[02:56:37] <jmkasunich> goodnight
[02:56:48] <cradek> night
[06:31:55] <robin_sz> bookmark?
[06:32:11] <robin_sz> logger_aj, bookmark?
[06:32:11] <robin_sz> See http://81.196.65.201/irc/irc.freenode.net:6667/emc/2006-08-21#T06-32-11
[06:36:38] <robin_sz> sigh ... sodding sourceforge .. how come the wiki crashes more than it runs?
[07:06:07] <alex_joni> robin_sz: overloaded server
[07:06:14] <alex_joni> can't spawn the perl script
[07:47:37] <NickServ> This nickname is owned by someone else
[07:47:37] <NickServ> If this is your nickname, type /msg NickServ IDENTIFY <password>
[08:01:24] <Jymmm> hi jepler
[08:39:28] <Lerneaen_Hydra> 'lo there
[08:39:31] <Lerneaen_Hydra> anyone here?
[08:39:54] <Lerneaen_Hydra> logger_aj: bookmark
[08:39:54] <Lerneaen_Hydra> See http://81.196.65.201/irc/irc.freenode.net:6667/emc/2006-08-21#T08-39-54
[09:18:22] <alex_joni> Lerneaen_Hydra: not me
[09:18:30] <Lerneaen_Hydra> oh noes
[09:20:15] <Lerneaen_Hydra> I noticed that K is always needed after a G33, is that the way it should be?
[09:20:24] <Lerneaen_Hydra> say doing G33 z-5 k1
[09:20:36] <Lerneaen_Hydra> z-7
[09:20:54] <Lerneaen_Hydra> will cause an error because K is "missing"
[09:21:06] <Lerneaen_Hydra> even though EMC knows that the next move is a G33 move
[09:24:04] <harty> Lerneaen_Hydra: it does need the k the k is move per rev for the selected axis
[09:24:40] <Lerneaen_Hydra> yes, I was thinking that if it is not specified then it continues with the previous value
[09:24:49] <Lerneaen_Hydra> as it does with most other parameters
[09:27:02] <harty> got your lathe threading ?
[09:27:22] <Lerneaen_Hydra> yep
[09:27:26] <Lerneaen_Hydra> works really nicely
[09:27:30] <harty> sweet
[09:27:42] <Lerneaen_Hydra> I'm making the CAM post ouput correct code now
[09:28:19] <harty> cool you going to post it on the wiki
[09:28:23] <Lerneaen_Hydra> the one thing that seems to be troublesome is getting the K value to be total feed/rev and not only feed(X)
[09:28:32] <Lerneaen_Hydra> Yeah I think so
[09:28:52] <Lerneaen_Hydra> and I can't get math to work nicely in the post
[09:29:20] <Lerneaen_Hydra> what I want to do is something like sqrt(xmove^2+zmove^2)*pitch=user_var1
[09:29:25] <Lerneaen_Hydra> but I can't get that working
[09:29:34] <Lerneaen_Hydra> I guess I'll have to play with it a bit
[09:29:46] <harty> i got a mastercam post sort of working but im not sure how i did it
[09:29:57] <harty> and the traeding code was already in there
[09:30:04] <harty> threading
[09:30:07] <Lerneaen_Hydra> oh, I see
[09:30:09] <Lerneaen_Hydra> lathe?
[09:30:13] <harty> yep
[09:30:15] <Lerneaen_Hydra> nice
[09:32:22] <harty> i think you can use g33 with 2 axis at the same time eg g33 z-1 x.2 k.05 for tapered threads which could be cool
[09:39:23] <Lerneaen_Hydra> yeah that works
[09:39:35] <Lerneaen_Hydra> you can do soft thread lead outs too
[10:14:39] <alex_joni> there is also a canned cycle for threading
[10:19:16] <alex_joni> G76 mumble
[10:41:59] <Lerneaen_Hydra> I don't really need that though, with CAM and all ;)
[10:42:26] <Lerneaen_Hydra> I just use gcode as a slightly-higher-level-than-binary format ATM
[10:42:52] <Lerneaen_Hydra> never even look at it, if I want to change something then I do it in the cam app, and regen the code
[10:42:55] <Lerneaen_Hydra> bbl
[11:35:37] <cradek> Lerneaen_Hydra: I fixed a couple problems with g33 last night (including the MDI problem) - you should update
[12:40:54] <alex_joni> morning chris
[12:57:07] <alex_joni> * alex_joni shakes his head: http://sourceforge.net/docs/A04
[13:40:18] <Lerneaen_Hydra> hi cradek
[13:40:25] <Lerneaen_Hydra> oh, ok. I'll do that today then
[13:40:35] <Lerneaen_Hydra> ciabot doesn't have a log does it?
[13:41:47] <cradek> there's some stuff at cia.navi.cx
[13:45:32] <Lerneaen_Hydra> oh that g33 only crash seems nasty
[13:46:01] <Lerneaen_Hydra> do you know of anyone else that runs with g33?
[13:47:07] <Lerneaen_Hydra> oh, how do I go from emc+axis head to emc with embedded axis?
[13:47:33] <Lerneaen_Hydra> remove everything from the emc2/ folder and redownload?
[13:50:19] <SWPadnos> a new checkout would work ;)
[13:51:33] <Lerneaen_Hydra> SWPadnos: so I just delete the run-in-place folder and redownload + compile?
[13:52:04] <SWPadnos> sure, or you can specify a different directory to download to:
[13:52:22] <alex_joni> Lerneaen_Hydra: a fresh checkout is the easiest
[13:52:45] <alex_joni> but you can remove the old AXIS, then "cd emc2/ ; rm -r share lib/python"
[13:52:50] <alex_joni> then checkout "cvs up -dP"
[13:52:52] <SWPadnos> cvs -d:ext:anon@cvs.linuxcnc.org:/cvs/emc co -d new_dir_name emc2
[13:52:58] <alex_joni> or that
[13:53:01] <alex_joni> * alex_joni heads home
[13:53:03] <alex_joni> later
[13:53:09] <SWPadnos> (substituting the correct form for anything I screwed up :) )
[13:53:32] <Lerneaen_Hydra> It's not like I need to save the old install or anything
[13:53:42] <Lerneaen_Hydra> later alex
[13:53:45] <SWPadnos> if you've changed any configs, you may want to save them
[13:53:49] <SWPadnos> see you Alex
[13:53:57] <Lerneaen_Hydra> oh, those I have somewhere entirely else
[13:54:19] <SWPadnos> well, if you're sure yhere's nothing you need, then deleting is a fine alternative
[13:54:24] <Lerneaen_Hydra> after compile I don't touch anything in the emc2/ directories
[13:54:42] <SWPadnos> but the configs are also in the RIP tree, aren't they
[13:54:55] <Lerneaen_Hydra> RIP?
[13:55:02] <SWPadnos> Run-In-Place
[13:55:08] <Lerneaen_Hydra> the the default ones yes
[13:55:12] <Lerneaen_Hydra> but not mine
[13:55:36] <Lerneaen_Hydra> I launch emc with a launcher that uses the command line option with emc
[13:56:03] <SWPadnos> ah. and you probably haven't changed anything behind the scenes, like the NML files
[13:56:08] <Lerneaen_Hydra> nope
[13:56:42] <Lerneaen_Hydra> oh, if I delete everything except the CVS folder then a cvs -dP should suffice, right?
[13:56:57] <SWPadnos> anyway - the only difference between a checkout and a checkout that puts the files in a different directory is the "-d somedirname" after the co command (and before the names of the modules to check out)
[13:57:11] <Lerneaen_Hydra> ohok
[18:39:19] <robin_sz> meep?
[18:39:58] <Lerneaen_Hydra> meep
[18:40:06] <Lerneaen_Hydra> hah, nice timing
[18:40:17] <Lerneaen_Hydra> I just come back after being away for quite some time
[19:00:16] <robin_sz> and .. like a bad penny ... I turn up
[19:27:09] <A-L-P-H-A> this is just cool. http://www.amateurillustrator.com/galleries/displayimage.php?pid=192&fullsize=1
[19:30:13] <CIA-10> 03alex_joni 07HEAD * 10emc2/docs/src/Master_Integrator.lyx: some more sections..
[19:36:09] <alex_joni> night all
[20:06:39] <Lerneaen_Hydra> night alex
[20:11:19] <davidf> hi
[20:14:31] <davidf> anybody home?
[20:16:15] <Lerneaen_Hydra> for a little whi
[20:16:17] <Lerneaen_Hydra> le
[20:16:40] <davidf> hi Lerneaen_Hydra
[20:17:16] <davidf> Hey what gives? I just checked the transcript file. Last one in the list.
[20:17:43] <Lerneaen_Hydra> huh?
[20:17:47] <davidf> Shows my input but starts from last night with nothing in between.
[20:18:22] <davidf> http://81.196.65.201/irc/irc.freenode.net:6667/emc/2006-08-21.txt
[20:19:33] <davidf> Shows this current input time as 20:11
[20:19:40] <davidf> That right?
[20:20:12] <davidf> what time is it for the server time approx?
[20:21:12] <davidf> Late where most of you guys are I guess.
[20:21:37] <SWPadnos> IRC times should be local time
[20:21:48] <cradek> times in that log are UTC
[20:21:49] <davidf> Hi SWPadnos
[20:21:52] <SWPadnos> hi
[20:21:58] <SWPadnos> oh - that one ;)
[20:22:04] <SWPadnos> (maybe I should have more coffee)
[20:22:11] <davidf> hmm?
[20:22:24] <davidf> Oh. Not updated huh?
[20:22:40] <SWPadnos> those logs are real-time
[20:27:13] <davidf> cradek, Q re axis if you have a sec...
[20:27:58] <davidf> Anytime I get a following error I have to exit emc and restart. Is that normal or is there something I'm missing?
[20:29:30] <Lerneaen_Hydra> cradek: g33 seems to work nicely :)
[20:29:38] <Lerneaen_Hydra> I got a new checkout today
[20:46:10] <cradek> davidf: why are you getting following errors?
[20:46:14] <cradek> Lerneaen_Hydra: yay
[20:47:31] <davidf> I don't know, but it happens sometimes when I turn up the speed too high.
[20:48:05] <SWPadnos> steppers or servos?
[20:48:13] <davidf> I di figure out part of my problem with thge drives though.
[20:48:16] <davidf> Steppers
[20:48:48] <SWPadnos> are you sure that the BASE_PERIOD is sufficient to run at MAX_VEL (assuming you're using software step generation)?
[20:49:09] <davidf> My Parker drives have to be cycled of/on after making any changes to the dip switches for microsteps, etc.
[20:49:22] <davidf> No I'm not.
[20:49:38] <SWPadnos> heh - that's the first place to look.
[20:49:48] <davidf> ok.
[20:50:12] <SWPadnos> the second (and just about tied for first) is the STEPGEN_MAXVEL ad STEPGEN_MAX_ACCEL (or similar) settings
[20:50:26] <davidf> But I was wondering if the behavior of axis having to shut down after a following error was normal.
[20:50:42] <SWPadnos> I don't think so
[20:50:48] <SWPadnos> in fact, I nkow it's not normal
[20:50:51] <SWPadnos> know, even
[20:51:06] <davidf> Right. I have those set to Max_vel * 3^.5 etc.
[20:51:18] <davidf> hmm..
[20:51:23] <Lerneaen_Hydra> 'night
[20:51:27] <SWPadnos> see you LH
[20:51:36] <Lerneaen_Hydra> bye
[20:51:38] <SWPadnos> why sqrt(3)?
[20:51:51] <davidf> After athat error, I just get the error box over and over after I try to reset the stop button.
[20:52:22] <SWPadnos> that would be in the TRAJ section, but it's the per-axis maxvel/maxaccel and stepgen versions (fro that axis) that matter
[20:52:25] <davidf> Well I saw cradek (I think) post that as the optimum value.
[20:52:44] <davidf> yes...
[20:53:20] <SWPadnos> it's optimal for [TRAJ]MAXACCEL (and MAXVEL), because it allows full speed from all axes, which results in a higher vector velocity than any individual axis
[20:53:30] <SWPadnos> limit
[20:54:55] <davidf> hmm.. I think I see.
[20:56:12] <davidf> so like if you go 1 in/sec on X and 1 in/sec on Y cordinated, then you can go 2^.5 on the combined move, & take that to 3 dimensions...
[20:56:34] <SWPadnos> right
[20:56:42] <davidf> & get sqrt(3)
[20:56:45] <davidf> OK.
[20:56:59] <SWPadnos> the TP will still limit the move if any axis can't go fast enough to do it
[20:57:24] <davidf> But when you're talking one axis that is just not an issue for that particular axis. I get it now.
[20:57:36] <SWPadnos> so you have two problems - you get following errors, and for some reason the errors aren't cleared correctly, so you can't restart after one occurs
[20:57:54] <davidf> uh huh.
[20:58:03] <SWPadnos> right - the velocity will be the lower of TRAJ max, AXIS_n max, or F
[20:58:05] <cradek> a following error turns machine off, you can turn it back on with F2
[20:58:24] <davidf> ah... Thanks!
[20:59:00] <cradek> but you should never ever get them unless you have a misconfiguration, so let's concentrate on that
[20:59:08] <davidf> But should clicking the e stop & the other red one do it also?
[20:59:31] <cradek> which gui is this?
[20:59:37] <davidf> Axis
[20:59:42] <cradek> 'machine on' is the second icon from the left
[20:59:46] <cradek> when you get a FE it will pop out
[20:59:48] <davidf> ok...
[20:59:49] <cradek> you can push it back in
[21:00:04] <davidf> When I do, I still get the FE
[21:00:10] <cradek> you get another one?
[21:00:15] <davidf> yes.
[21:00:24] <cradek> which version of emc is this? (help/about)
[21:00:37] <davidf> Just keeps saying that the second I click it.
[21:00:53] <cradek> after a few times it'll stop, but this is a bug
[21:01:01] <cradek> a bug we fixed, I thought
[21:01:09] <cradek> a bug jmk fixed, I thought
[21:01:34] <SWPadnos> ok - I think we're thinking of the same problem, which was fixed months ago (if not a year)
[21:01:58] <cradek> it was actually pretty recent I think, since fest
[21:02:04] <cradek> it was fixed for servos long ago
[21:02:17] <davidf> axis v 1.4a0 / emc v 2.2.0.3
[21:02:35] <SWPadnos> ok - I was thinkong of the one where he current position was always being updated when in error (or when stopped), or something along those lines
[21:02:35] <cradek> ok I bet that fix didn't make it into the release branch
[21:02:46] <SWPadnos> 2.2.0.3?
[21:02:57] <cradek> yes that works, I use it all the time (machine off, then turn the servos by hand to jog a little)
[21:02:59] <SWPadnos> emc2, 2.0.3
[21:03:10] <davidf> sorry - emc2 v 2.0.3
[21:03:19] <davidf> yes.
[21:03:24] <SWPadnos> ok ;) I thought I was *waaaay* behind the times
[21:03:35] <davidf> well...
[21:03:49] <cradek> let me see if I can find that fix and put it in 2.0.4, swp, can you help davidf find the cause of the FEs themselves meanwhile?
[21:03:56] <SWPadnos> sure
[21:04:10] <davidf> Hey thanks.
[21:04:22] <SWPadnos> davidf, can you post your ini file to pastebin?
[21:04:59] <davidf> But the FE's only happen when I have set a way high vel or acc, not really a prob that's omni-present.
[21:05:09] <SWPadnos> or just tell me the BASE_PERIOD, and the MAXVEL and INPUT_SCALE for each axis
[21:05:46] <SWPadnos> well - you can configure it so that it'll just not move as fast as you ask, instead of giving an error
[21:06:13] <davidf> OK. Really, I'd appreciate it if you could help me to understand the principle behind the BASE_PERIOD, etc. myself so I don't have to keep asking for help.
[21:06:19] <SWPadnos> sure
[21:06:42] <SWPadnos> why don't you post the numbers for AXIS_0, and I'll go through the calcs for that
[21:06:45] <davidf> Thanks.
[21:07:01] <SWPadnos> you can do AXIS_1-n ;)
[21:07:25] <davidf> Hang on, let me give you some background as to what I'm doing right now. & What probs I'm having.
[21:07:34] <SWPadnos> ok
[21:08:05] <davidf> I have these real nice Parker Zeta4 drives.
[21:08:18] <davidf> They can UStep from 200 to 50K.
[21:08:30] <robin_sz> ahh. yes. I remember.
[21:08:44] <davidf> I get much quieter moves with UStep of course.
[21:09:02] <robin_sz> part of the problem is that emc doesnt really work well with ustepped drives
[21:09:15] <davidf> Also I have two types of motors on two different machines.
[21:09:15] <robin_sz> well, it does, but only at low motor speeds.
[21:09:27] <davidf> ok.
[21:09:43] <robin_sz> sorry,. keep going ...
[21:09:50] <robin_sz> I was premature
[21:10:00] <cradek> I think that's not a fair statement. software step generation can't go as fast as hardware step generation, that's all. You have to understand the limitations to use it.
[21:10:11] <davidf> But I did find your sug. (rbin_sz) helpful. 2000 steps is much better than 400.
[21:10:23] <cradek> there are some great solutions for emc with hardware step generation, but it costs more.
[21:10:25] <SWPadnos> is that
[21:10:32] <SWPadnos> is that "steps per rev"?
[21:10:36] <robin_sz> yes ... but dotn try and use the full performance of the motors
[21:10:38] <davidf> yes.
[21:10:57] <SWPadnos> ok. and what's the drive ratio (ie, what is the final INPUT_SCALE)
[21:11:26] <davidf> several different ones
[21:11:31] <davidf> dep on the axis.
[21:11:39] <SWPadnos> what's the worst case?
[21:11:40] <davidf> But the one I'm working on now,
[21:11:54] <davidf> (The only problematic one,
[21:11:55] <SWPadnos> worst = highest steps/unit
[21:12:22] <davidf> Is a 118 oz in motor turning the lathe (3 inch chuck)
[21:12:34] <robin_sz> cradek, modern motors need to spin at quite some speed to reach their corner frequency. operating them in a mdoe when they never get there is a bad thing. practically, that meeans that for most modern motors, with 10:1 ustepping emc needs to be able to do 20khz or the whole thing is a bad compromise
[21:13:09] <robin_sz> hardware step generation is the real answer ...
[21:13:10] <davidf> I can do 25K.
[21:13:11] <cradek> robin_sz: you didn't read what I wrote. You can use emc just fine with high step rates but you probably need hardware step generation.
[21:13:21] <SWPadnos> emc can do 60 KHz, depending on the hardware
[21:13:42] <SWPadnos> Alex has has a 6 uS BASE_PERIOD on an athlon 1800 (I think)
[21:13:47] <SWPadnos> has had ...
[21:13:48] <cradek> robin_sz: to say emc can't run microstepped drives well is an incorrect statement.
[21:14:01] <davidf> My box is 733 MHz
[21:14:23] <davidf> On one axis I have input_scale at 8000 & that's no prob.
[21:14:25] <SWPadnos> in any case - I take it your BASE_PERIOD is 20 uS
[21:14:35] <cradek> saying software step generation and high microstep values don't mix well is certainly correct
[21:14:51] <SWPadnos> unless you don't need high speed ;)
[21:14:56] <cradek> right
[21:15:04] <davidf> Let me post the file. This one is one I've been changeing so some things might be off.
[21:15:09] <SWPadnos> ok
[21:15:36] <cradek> btw the "fix" for recovery after stepper FE is in 2.0.3. It must not work.
[21:15:46] <davidf> ok...
[21:16:00] <davidf> Probly I broke it. =)
[21:16:05] <SWPadnos> given 25kPPS max, and 8000 steps/inch (?), you have a maxvel of 3.125 units/sec on that axis
[21:16:08] <cradek> heh I don't think so...
[21:16:15] <robin_sz> ok, if that makes yo happier "software step generation and high microstep values don't mix well" ..
[21:16:18] <robin_sz> better?
[21:16:32] <SWPadnos> yes, if you add "for medium to high speed applications" ;)
[21:16:46] <cradek> it's not about me being happy, it's about telling davidf incorrect things when he wants to understand the limitations he's dealing with
[21:16:54] <davidf> :)
[21:17:04] <SWPadnos> you can be happy though - it's OK
[21:17:04] <robin_sz> regardless of the speed of travel you should always gear to get your motors to at least their corner freq on G0 moves
[21:17:12] <davidf> I'm confused enough already.
[21:17:18] <robin_sz> otherwise, its called "bad design"
[21:17:25] <SWPadnos> only if efficiency and power are important in your application
[21:17:53] <robin_sz> getting the best possible performance out of my hardware is alwways important to me
[21:18:20] <davidf> This one is just turning a mini lathe chuck. Very little torque required. Just positioning it.
[21:18:38] <SWPadnos> davidf, the calculations are simple:
[21:18:42] <davidf> Anyway, hold on I'l get that up.
[21:18:53] <davidf> ok...
[21:18:54] <SWPadnos> you can generate at most one step every two BASE_PERIODs
[21:19:16] <SWPadnos> it may be less than that if you have hold time or step width higher than 1
[21:19:38] <SWPadnos> so max_PPS = 1/ (2 * BASE_PERIOD)
[21:19:45] <SWPadnos> you said 25k, so we'll use that
[21:20:10] <SWPadnos> any axis can move at most INPUT_SCALE / max_PPS units per second
[21:20:19] <davidf> OK it's there.
[21:20:35] <davidf> Let me see what I've missed...
[21:20:36] <SWPadnos> for the 8k axis, that's 25k / 8k = 3.125 units per second
[21:21:10] <SWPadnos> if an axis is configured for 500k steps/unit, then 25k / 500k = 1/20 unit per second, or 3 units/minute max feed
[21:22:44] <davidf> SWPadnos, that file as posted looks really messy. No Carriage returns.
[21:22:53] <SWPadnos> where is it?
[21:23:03] <davidf> pasebin
[21:23:09] <SWPadnos> .com or .ca?
[21:23:10] <davidf> name davidf
[21:23:15] <davidf> .com
[21:23:47] <SWPadnos> err -I see no "recent" list
[21:23:54] <cradek> same here
[21:23:55] <SWPadnos> can you paste in a URL?
[21:24:29] <SWPadnos> you can also use INI File highlighting, which should be cool
[21:25:37] <davidf> actually, me niether.
[21:25:51] <cradek> try pastebin.ca? it always seems to work
[21:26:27] <davidf> I pasted it and clicked send. Then I was sent to a PHP page. So that's what I saw. But it says something about not locked error.
[21:27:55] <SWPadnos> there's a message on pastebin.com about a problem a few weeks ago - maybe there are others that haven't been fixed
[21:28:37] <davidf> OK I tried again, But I dont see anything.
[21:28:48] <SWPadnos> use http://pastebin.ca/
[21:28:59] <davidf> ok...
[21:29:10] <SWPadnos> (no INI hilighting though :( )
[21:30:32] <davidf> http://pastebin.ca/143093
[21:30:37] <davidf> There.
[21:30:50] <davidf> gotta go tinkle.
[21:31:07] <SWPadnos> err - ok
[21:31:30] <SWPadnos> the base period is 50 uS, so the max step rate is 10K per second
[21:32:16] <SWPadnos> that gives a max of 1.2 IPS for the first two axes (at 8K INPUT_SCALE)
[21:32:44] <SWPadnos> and a max of ~30 IPM on AXIS_2, with the 19200 INPUT_SCALE
[21:33:46] <davidf> er.. Im back. Sorry.
[21:34:24] <SWPadnos> no problem
[21:34:25] <davidf> Boy. Let me take a sec to catch up to you.
[21:34:29] <SWPadnos> no problem
[21:34:31] <SWPadnos> :)
[21:35:26] <davidf> OK. Back at the beginning, 2 steps/base_per.
[21:35:39] <SWPadnos> one to set the output high, one to set the output low
[21:35:40] <davidf> Then something about pulse width > 1?
[21:35:48] <davidf> pls elaborate.
[21:36:08] <SWPadnos> yep, you can have the step pulse last more than one BASE_PERIOD, but this should be unnecessary in most cases
[21:36:27] <davidf> oh ok.
[21:36:55] <davidf> My waveform seems to be 1 ms wide step pule. TYhat about right>
[21:37:00] <davidf> ?
[21:37:05] <SWPadnos> nope
[21:37:14] <SWPadnos> it should be 0.05 ms
[21:37:26] <davidf> OK LET ME LOOK...
[21:37:30] <SWPadnos> unless it's inverted, and you're sending out 1000 pulses per second ;)
[21:37:37] <davidf> sory for the caps.
[21:37:48] <SWPadnos> (you could be looking at the space between pulses)
[21:37:57] <davidf> no, the step.
[21:38:14] <SWPadnos> how are youlooking at it?
[21:38:14] <davidf> but I probably had the scope off cal.
[21:38:22] <SWPadnos> with a physical oscilloscope?
[21:38:27] <davidf> yes.
[21:38:30] <SWPadnos> ok
[21:40:27] <davidf> yes. 0.1 ms.
[21:40:40] <SWPadnos> pulse width, or period?
[21:40:49] <davidf> PW
[21:41:05] <SWPadnos> hmm - the step time may be set to 2
[21:41:30] <SWPadnos> it should be one BASE_PERIOD high, then a bunch low, then the next step
[21:41:37] <davidf> My scope is a piece of crap. Dinosaur.
[21:41:55] <SWPadnos> it's likely to be good enough for a 2:1 measurement error ;)
[21:42:05] <davidf> So I don't trust the time base.
[21:42:07] <robin_sz> theres always halscope ;)
[21:42:18] <davidf> yes
[21:42:32] <SWPadnos> not ideal for sampling in the BASE_THREAD though :)
[21:42:41] <robin_sz> ahh, true enough
[21:42:43] <SWPadnos> (nor for checking its own timing ;) )
[21:43:09] <robin_sz> I recommend something I call "a cheap pair of headphones" ;)
[21:43:20] <davidf> Problem is on the scope, seeing the whole period with enough width on the Pulse at low speed.
[21:43:33] <SWPadnos> easy to tell frequency, not so easy to check pulse width that way
[21:43:45] <davidf> yeah.
[21:44:07] <robin_sz> but still a useful tool, ears are very good at spotting glitches and roughness in a pulse train
[21:44:12] <davidf> Anyway, that's probably not the problem, right?
[21:44:35] <robin_sz> checking the pulse width is important
[21:44:44] <davidf> Screaming motors work too.
[21:44:49] <robin_sz> it will show what the base thread si running at
[21:44:53] <SWPadnos> what is the output of halcmd show param stepgen.0.
[21:45:03] <davidf> hang on...
[21:45:55] <davidf> Parameters:
[21:45:55] <davidf> Owner Type Dir Value Name
[21:45:55] <davidf> 04 u8 -W 1 (01) stepgen.0.dirhold
[21:45:55] <davidf> 04 u8 -W 1 (01) stepgen.0.dirsetup
[21:45:55] <davidf> 04 float R- 0.00000e+00 stepgen.0.frequency
[21:45:55] <davidf> 04 float -W 7.08000e+00 stepgen.0.maxaccel
[21:45:59] <davidf> 04 float -W 1.22000e+00 stepgen.0.maxvel
[21:46:01] <davidf> 04 float -W 8.00000e+03 stepgen.0.position-scale
[21:46:03] <davidf> 04 s32 R- 0 stepgen.0.rawcounts
[21:46:05] <davidf> 04 u8 -W 1 (01) stepgen.0.steplen
[21:46:07] <davidf> 04 u8 -W 1 (01) stepgen.0.stepspace
[21:46:36] <SWPadnos> hmmm - it looks to me like each step should be one period up, one period down
[21:46:42] <SWPadnos> (steplen and stepspace)
[21:47:15] <SWPadnos> well, more periods down, to get the correct frequency
[21:47:18] <davidf> like a square wave?
[21:47:33] <SWPadnos> only at max frequency
[21:47:44] <SWPadnos> it would be lots of blips at lower rates
[21:47:52] <davidf> I'm seeing real long down, short up, long down...
[21:48:00] <SWPadnos> that's right
[21:48:04] <davidf> At fairly low speed though.
[21:48:17] <SWPadnos> so, I'm assuming it's axis 2 (Z) that gives you errors most of the time
[21:48:42] <davidf> I'm working on axis A.
[21:48:52] <davidf> Thats the problematic one.
[21:48:57] <SWPadnos> oh, ok
[21:49:05] <davidf> mostly a setup issue, I think.
[21:49:11] <davidf> in the ini.
[21:49:16] <davidf> vel, acc, etc.
[21:49:18] <SWPadnos> it's 3200 steps per full revolution
[21:49:23] <SWPadnos> ?
[21:49:52] <davidf> wait... that is axis x I checked just now right?
[21:50:04] <SWPadnos> I have no idea
[21:50:10] <SWPadnos> yes - the halcmd was for axis 0
[21:50:22] <davidf> stepgen.0 is axis 0 right?
[21:50:30] <davidf> ok.
[21:50:39] <SWPadnos> you can do this: halcmd show param stepgen | grep steplen
[21:50:46] <SWPadnos> that'll give you all four
[21:50:54] <davidf> This should be axis(3) 0=x,1=y,2=z,3=A
[21:51:00] <SWPadnos> yep
[21:51:02] <davidf> hang on...
[21:51:38] <SWPadnos> you have sTEPGEN_MAXVEL set lower than MAX_VELOCITY - that's a no-no
[21:51:39] <davidf> Parameters:
[21:51:39] <davidf> Owner Type Dir Value Name
[21:51:39] <davidf> 04 u8 -W 1 (01) stepgen.3.dirhold
[21:51:39] <davidf> 04 u8 -W 1 (01) stepgen.3.dirsetup
[21:51:39] <davidf> 04 float R- 0.00000e+00 stepgen.3.frequency
[21:51:40] <davidf> 04 float -W 6.24000e+01 stepgen.3.maxaccel
[21:51:42] <davidf> 04 float -W 6.24000e+01 stepgen.3.maxvel
[21:51:46] <davidf> 04 float -W 8.88889e+00 stepgen.3.position-scale
[21:51:48] <davidf> 04 s32 R- 9712 stepgen.3.rawcounts
[21:51:50] <davidf> 04 u8 -W 1 (01) stepgen.3.steplen
[21:51:52] <davidf> 04 u8 -W 1 (01) stepgen.3.stepspace
[21:52:56] <SWPadnos> that tells the step generator that it can't go faster than X, but the TP may ask for more than that,
[21:53:36] <SWPadnos> when the step generator tells the TP how far it's gone, it's not far enough, since it can't keep up with the request
[21:54:25] <davidf> hence FE's?
[21:54:30] <SWPadnos> yep
[21:54:37] <davidf> ah...
[21:54:53] <SWPadnos> incidentally, you can test this with the motors off - it's strictly a software configuration thing
[21:55:06] <davidf> ok...
[21:55:27] <SWPadnos> it's when you're trying to find the actual limit of the motor that you need to turn things on and measure actual vs. expected travel
[21:55:51] <davidf> k
[21:56:13] <SWPadnos> gotta run for a bit. good luck with it
[21:57:28] <davidf> how's this?
[21:57:33] <davidf> #+ Fourth axis
[21:57:33] <davidf> [AXIS_3]
[21:57:33] <davidf> TYPE = ANGULAR
[21:57:33] <davidf> UNITS = 1.0
[21:57:33] <davidf> HOME = 0.0
[21:57:33] <davidf> MAX_VELOCITY = 360.0
[21:57:35] <davidf> MAX_ACCELERATION = 36.0
[21:57:37] <davidf> STEPGEN_MAXVEL = 624
[21:57:39] <davidf> STEPGEN_MAXACCEL = 62.4
[21:57:51] <davidf> ok...
[21:57:57] <davidf> thanks a lot.
[22:00:18] <SWPadnos> sure
[22:00:20] <danex> hello all
[22:00:27] <SWPadnos> now I'm really gone :)
[22:01:02] <davidf> hi
[22:07:42] <danex> cradek, good news with the brake outputs I was working on
[22:10:00] <danex> I have a working set now
[22:18:56] <robin_sz> thats one bit of the config I find weird ... perhaps it would be better to just set accels in one place, say the stepgens, and these are the physical limits of ther machine ,.. the tp then interrogates the stepgens and lits itself based on what they have said they can do
[22:43:54] <davidf> robin_sz, I kind of agree with that.
[22:44:36] <davidf> I'm making progress. Have to go now though. Thanks for the help. & Thanks cradek..
[22:44:51] <davidf> bye
[22:50:15] <jmkasunich> robin_sz: the reason we don't do that is that not everybody uses steppers
[22:50:39] <jmkasunich> if you have steppers, its reasonable for the TP to ask them the limit, and then set its own limit based on that
[22:50:52] <jmkasunich> but if you have servos, there's nobody to ask
[22:54:13] <SWPadnos> yeah, in the case of servos, the "servo_maxaccel" is set by the driver current limit trimpot ;)
[22:55:21] <SWPadnos> though in both cases, a TP "safety margin" may be applicable
[22:55:48] <SWPadnos> still set by the user, and deafult to something small, like 1% or 0
[22:56:17] <jmkasunich> one of these days we need to examine all the common configs, and unify them, then come up with a "fill in the form" way to adapt them to a specific user's needs
[22:56:38] <jmkasunich> the more complex configs will still require the integrator to actually know stuff
[22:56:43] <SWPadnos> yep
[22:57:12] <SWPadnos> I was thinking that a halcmd "set this if the item exists" option would be good
[22:57:27] <jmkasunich> eww
[22:57:32] <SWPadnos> like setp stepgen.0.maxaccel +[AXIS_0]STEPGEN_MAXACCEL
[22:58:13] <SWPadnos> makes common configs easier
[22:58:41] <jmkasunich> I guess its a matter of perspective. IMO, if the hal file has [AXIS_0]STEPGEN_MAXACCEL in it, then the matching ini file damn well better have that variable, if not its an error
[22:58:49] <jmkasunich> the ini and the hal should be matched
[22:59:13] <SWPadnos> sure
[22:59:39] <jmkasunich> seems like the "set if it exists" option is only for cases where they might not match
[22:59:47] <SWPadnos> I just look it as the corrolary to the ability to have extra stuff in the INI that isn't used
[22:59:48] <jmkasunich> unless I'm misunderstanding you
[23:00:06] <jmkasunich> you can always have extra stuff in the ini that isn't used
[23:00:13] <SWPadnos> it's not an error if there are settings that are unused, and that could also be construed as a mismatch or mistake
[23:00:15] <jmkasunich> as far as HAL is concerned, 95% of the ini is unised
[23:00:18] <SWPadnos> rigth
[23:00:20] <SWPadnos> right
[23:00:31] <SWPadnos> so they're not perfectly matched
[23:00:38] <SWPadnos> but it's only one way right now
[23:00:57] <SWPadnos> note that I'm not suggesting that halcmd silently ignore all instances where a setting isn't found
[23:01:23] <jmkasunich> you're suggesting that the .hal writer can permit that when it seems appropriate
[23:01:24] <SWPadnos> only that some option (on a per-line basis) allow the creator of the file t ospecify that it's not an error if that line fails
[23:01:30] <SWPadnos> yep
[23:03:24] <jmkasunich> thats more general than the original statement I think
[23:03:54] <jmkasunich> the original would be a setp [inivar] that is ignored if [inivar] doesn't exist
[23:04:00] <SWPadnos> it may be - I'm still only thinking of ini (or externally set) parameters though
[23:04:04] <SWPadnos> or shell var
[23:04:07] <SWPadnos> but yes
[23:04:18] <jmkasunich> but the idea of certain lines failing without a fatal error would also allow
[23:04:19] <SWPadnos> a loadrt obviously should load, damnit
[23:04:32] <jmkasunich> linksp sig pin where either pin or sig doesn't exist to fail silently
[23:04:41] <jmkasunich> which sometimes might be what you want
[23:04:51] <SWPadnos> that may be useful as well, though not in the scope of what I was originally thinking
[23:04:55] <jmkasunich> especially if people start ganging together bunches of little hal files
[23:05:12] <SWPadnos> hmmm - you know, adding a + or - to the start of a line may be a good generalization
[23:05:17] <jmkasunich> "if this sig exists, hook to it, otherwise never mind"
[23:05:27] <SWPadnos> + means "never ignore an error on this line", even if -k is specified
[23:05:39] <SWPadnos> - means "never stop for an error on this line"
[23:05:50] <SWPadnos> again regardless of -k
[23:05:56] <jmkasunich> hmm
[23:06:47] <jmkasunich> my leanings toward construction of hal files have been going away from the "lots of little files" approach
[23:06:54] <jmkasunich> toward a single file customized to the machine
[23:07:30] <jmkasunich> all the loads, then the addfs, then the newsigs and links,e tc
[23:07:43] <SWPadnos> internally, it's "all one file", so if there aren't commands that let you source other files, for example, then the splitting into multiple files isn't as useful as it could be
[23:07:44] <jmkasunich> one halfile, one inifile, done
[23:07:47] <SWPadnos> yep
[23:08:06] <jmkasunich> the ini allows you to source multiple files
[23:08:31] <jmkasunich> that means only one level of nesting, rather than the arbitrary that you can get with a proper include directive, but...
[23:08:38] <SWPadnos> I was thinking of a script or something that would load all HAL files referenced in the ini, and basically reorder them so that things won't fail due to e.g. setting a parameter before the module is loaded
[23:09:01] <SWPadnos> there's a known order to certain things:
[23:09:05] <SWPadnos> 1) load RT modules
[23:09:12] <SWPadnos> 2) create signals
[23:09:45] <SWPadnos> 3) (gets a little fuzzy) link some signals to pins
[23:10:04] <SWPadnos> only some, since some connections will be to userspace components that haven't been loaded yet
[23:10:25] <jmkasunich> unless you use loadusr to load the userspace components
[23:10:27] <SWPadnos> 4) load userspace components (not done before some links since it helps to have e.g. stop input wired before TP is run)
[23:11:10] <jmkasunich> nothing RT runs until you do halcmd start
[23:11:14] <SWPadnos> I was actually considering a higher level - having the runscript do this for all hal and other programs
[23:11:17] <SWPadnos> true
[23:11:57] <jmkasunich> I wonder if the user space hal API should have a "sleep till started" call
[23:12:01] <SWPadnos> so the order is then start realtime, load RT components, load user components (which the GUI may be one of, BTW), connect things
[23:12:09] <SWPadnos> hmmm - maybe
[23:12:25] <jmkasunich> or maybe "check if started", so you can decide what to do instead of sleeping
[23:12:55] <SWPadnos> damn - I had thought of more stuff, but I can't remember right now :(
[23:12:58] <jmkasunich> so you build your entire control, then you start the whole thing at "once"
[23:13:02] <SWPadnos> yep
[23:13:14] <SWPadnos> and in the correct order, regardless of what file the commands are in
[23:13:19] <jmkasunich> you mean the numbered list? don't forget creating threads and adding functions to them
[23:13:32] <jmkasunich> I balk a little at re-ordering
[23:13:36] <SWPadnos> the idea was to flatten out the multiple HAL files before actually running any commands
[23:14:11] <jmkasunich> I've been known to embedd show commands into a hal file to debug
[23:14:12] <SWPadnos> the order would be the same, just that you split things into multiple groups, and run the groups in the correct order
[23:14:26] <SWPadnos> so the loadrt group is always first
[23:14:43] <SWPadnos> and the addf group may always be last
[23:14:52] <SWPadnos> but the commands in each group would be in order
[23:15:04] <jmkasunich> and what group is show in?
[23:15:10] <SWPadnos> damfine ;)
[23:15:13] <SWPadnos> damfino
[23:15:14] <SWPadnos> there
[23:15:42] <jmkasunich> what is the benefit from flattening things?
[23:16:04] <SWPadnos> you can't screw things up by putting a signal connection in the wrong file, for example
[23:16:06] <jmkasunich> in theory it lets you put a "subsystem" in one .hal file, load, addf, newsig, link
[23:16:52] <jmkasunich> but in practice, if you need anything from blocks, you're gonna have problems
[23:17:03] <jmkasunich> also if your subsystem needs to add one more stepgen, for example
[23:17:07] <SWPadnos> yeah - aggregating things like that would be an added benefit
[23:17:21] <SWPadnos> but harder to implement
[23:17:25] <jmkasunich> added benefit? you mean fscking nightmare
[23:17:28] <SWPadnos> heh
[23:17:37] <jmkasunich> (to implement, to debug, etc)
[23:17:57] <SWPadnos> no - the benefit is that you put "loadrt blocks blah blah" in a separate mofule
[23:17:58] <jmkasunich> my answer to things in the wrong file is to merge all the files (for real)
[23:18:22] <SWPadnos> I agree
[23:18:31] <jmkasunich> I guess it depends on how you view the hal language
[23:18:51] <jmkasunich> if you see it as a decription of the state of the system, then re-ordering makes perfect sense
[23:19:02] <jmkasunich> if you see it as a procedural language, then reordering is evil
[23:19:16] <SWPadnos> I see it as a way to get some final system state
[23:19:20] <SWPadnos> not as a programming language
[23:19:46] <jmkasunich> if you use it manually, it for darn sure is a procedural language
[23:19:56] <jmkasunich> I routinely do a load of setp's to tune
[23:20:01] <SWPadnos> well you can't set up a macro and call it
[23:20:19] <jmkasunich> I never said it was a sophisticated language
[23:20:32] <SWPadnos> I wouldn't have halcmd reorder things - that would be a higher level program that then feeds everything to halcmd in one go
[23:21:09] <SWPadnos> it is sophisticated - it has tab completion ;)
[23:21:48] <jmkasunich> hmm, I just thought of a way to implement what you are talking about that isn't too complex to do (forget the loadrt blocks issue)
[23:21:55] <jmkasunich> think multipass assembler
[23:22:07] <jmkasunich> first pass thru all files, echo only the load commands
[23:22:10] <SWPadnos> yep -that was exactly what I had thought of
[23:22:14] <jmkasunich> next pass, the newsigs, etc
[23:22:39] <SWPadnos> except that I was thinking of creating a command list in memory, and having multiple lists
[23:23:01] <SWPadnos> then the list gets output (only one pass through each file then)
[23:23:01] <jmkasunich> more complex to code I think
[23:23:07] <SWPadnos> I don't think so
[23:23:17] <jmkasunich> it would be faster, but is that really an issue?
[23:23:31] <SWPadnos> if string matches "foo", add line to foo_list
[23:23:41] <jmkasunich> still have list management
[23:23:45] <SWPadnos> if string matched "bar", add line to "barlist
[23:23:55] <SWPadnos> true, but that's easy in tcl, for example
[23:24:13] <jmkasunich> I suppose
[23:24:18] <SWPadnos> either way, it's the same algorithm, I'm just printing to a temp buffer, then outputting multiple buffers
[23:24:19] <jmkasunich> need to keep other data though
[23:24:33] <SWPadnos> not for halcmd - comments are ignored
[23:24:36] <jmkasunich> if a line does fail, you need to tell the user the original file and line number
[23:24:39] <SWPadnos> true
[23:24:51] <SWPadnos> oh, that data :)
[23:25:46] <jmkasunich> there are other errors that flattening won't help
[23:25:59] <jmkasunich> connecting a write pin to a signal that already has a writer
[23:26:13] <SWPadnos> sure - that's a definite error in integrator logic
[23:27:07] <jmkasunich> so is trying to link to a signal you haven't defined yet ;-)
[23:27:16] <SWPadnos> heh
[23:27:23] <jmkasunich> you are describing a way to allow the writer to get away with certain errors
[23:27:40] <jmkasunich> I'm less generous
[23:27:40] <SWPadnos> I think it's bad practice to force the integrator to insure that their HAL lines are in a particular order in the INI file
[23:27:44] <SWPadnos> heh
[23:28:09] <jmkasunich> I (in hindsight) think its a bad idea to have multiple HAL lines in an ini file ;-)
[23:28:41] <SWPadnos> heh
[23:28:54] <SWPadnos> well, if there's only one HAL file, then that wouldn't be an issue, would it?
[23:28:58] <SWPadnos> :)
[23:29:02] <jmkasunich> as soon as you start splitting the hal stuff up, you're gonna have as many ways of splitting it as you have integrators
[23:29:48] <SWPadnos> yep
[23:30:05] <SWPadnos> I had just thought of an interesting possibility for the "multiple blocks" problem
[23:30:12] <jmkasunich> one guy is gonna split it motion vs io, another will split it by what it controls (maybe even each axis), another will split it by loads and sigs and etc
[23:30:13] <SWPadnos> but I think it may be more trouble than it's worth
[23:30:18] <SWPadnos> yep
[23:30:45] <jmkasunich> imo, that way lies madness for the average user
[23:30:54] <jmkasunich> experienced integrators can do whatever they want
[23:31:03] <SWPadnos> what do we care for average users? ;)
[23:31:05] <jmkasunich> but I think the samples should be changed to single hal files
[23:31:11] <SWPadnos> we want above verage users!
[23:31:16] <SWPadnos> above average, even!
[23:31:22] <cradek> darn, that rules me out
[23:31:34] <jmkasunich> we tend to wind up handholding the average (and below average) ones
[23:31:44] <SWPadnos> hmm, maybe we can have an exemption for above average developers?
[23:31:47] <jmkasunich> I don't want them any confuseder than they have to be
[23:32:12] <cradek> we handhold people who don't read the docs, I'm not sure they're all below average
[23:32:32] <cradek> to me, that's sometimes frustrating
[23:32:32] <jmkasunich> below average in understanding HAL, how's that?
[23:32:41] <cradek> ok.
[23:32:59] <cradek> hi btw
[23:33:22] <jmkasunich> one of paul's somewhat legitimate criticisms of HAL is that it can be very complex for a newbie trying to do something simple
[23:33:41] <cradek> matt timmermans said that too
[23:33:44] <jmkasunich> the tradeoff is that experts can do things Paul's never even thought of in his wildest dreams
[23:33:46] <jmkasunich> yep
[23:33:58] <cradek> I think that's combatted somewhat by having good sample configs
[23:34:06] <cradek> (I'm not sure we have succeeded at that 100%)
[23:34:11] <jmkasunich> keyword _good_ samples
[23:34:17] <cradek> right
[23:34:38] <SWPadnos> one way to make it less user-hostile is to allow people to "override" defaults, but without having to edit a 1000-line file
[23:34:44] <jmkasunich> I think the multiple hal file samples were a mistake (even tho I started it with the standard pinout / xylotex pinout stuff)
[23:35:07] <cradek> is anything keeping you from fixing it?
[23:35:20] <jmkasunich> a parport stepper hal file could (not, not back then) get the parport pin numbers from the ini (I think)
[23:35:44] <jmkasunich> can you do "linksp Xstep parport.0.pin-[AXIS_0]STEP_PIN-out" ?
[23:35:49] <cradek> (not being a smartass, I'm serious)
[23:36:00] <cradek> I think so
[23:36:03] <jmkasunich> cradek: lack of time and energy mostly
[23:36:10] <cradek> ok, no technical problem
[23:36:17] <cradek> just wondered
[23:36:31] <jmkasunich> I'm not sure how the code would know where the "PIN" stops and the "-out" starts
[23:36:46] <cradek> I'm not either without looking
[23:36:53] <jmkasunich> SWPadnos: did you make it understand parens for that issue?
[23:36:56] <cradek> let me see if I can find it
[23:38:41] <jmkasunich> not gonna worry about it now - if it doesn't work, it can be fixed
[23:39:36] <jmkasunich> the other reason that changing it is non-trivial is inertia, don't want to break a bunch of user's configs
[23:39:42] <jmkasunich> but thats not always a good reason
[23:39:59] <cradek> you won't break any custom configs by changing the samples
[23:40:11] <cradek> I think
[23:40:21] <SWPadnos> parens are in there
[23:40:33] <jmkasunich> not directly (assuming the users copied it to his own directory before editing)
[23:40:41] <SWPadnos> and I think curly braces for shell vars
[23:41:00] <jmkasunich> I thought it was $ for shell vars
[23:41:12] <jmkasunich> with () in both cases as an option when needed for clarity
[23:41:18] <cradek> so we really could have pretty much everything in the ini for basic configs
[23:41:29] <jmkasunich> yeah, I think so
[23:42:06] <jmkasunich> still need differnet .hal for XYZ vs XYZA
[23:42:18] <cradek> why not put in all six?
[23:42:55] <jmkasunich> you want to be running six stepgens even when you don't need them? that will burden the CPU and lower the max step rate for folks with slower hardware
[23:43:08] <cradek> ok
[23:43:22] <jmkasunich> hmm, if and fi for hal ;-)
[23:43:36] <SWPadnos> is make_pulses a single function for all configured channels?
[23:43:38] <jmkasunich> that way lies madness too
[23:43:40] <jmkasunich> yes
[23:43:43] <SWPadnos> ok
[23:43:56] <jmkasunich> that may also not be the smartest way to do it
[23:44:28] <jmkasunich> cuts down on the number of addf commands, at the expense of some flexibility
[23:44:28] <SWPadnos> There are two formats for environment variables:
[23:44:30] <SWPadnos> $envvar
[23:44:31] <SWPadnos> $(envvar)
[23:44:33] <SWPadnos> Similar for ini vars:
[23:44:35] <SWPadnos> [section]variable
[23:44:37] <SWPadnos> [section](variable)
[23:44:38] <SWPadnos> now we know :)
[23:44:52] <jmkasunich> are you reading that from code, or docs?
[23:45:03] <SWPadnos> the commit message
[23:45:32] <jmkasunich> hmm, should probably be added to the man page
[23:45:48] <SWPadnos> oh - I thought I had (but I probably didn't)
[23:46:33] <jmkasunich> the man page (at least for 2.0.3) doesn't mention that
[23:46:36] <SWPadnos> the real answer to your question: The parenthesized versions allow variables to not be separated by whitespace: if FOO = "baz", then $(FOO).bar will be expanded to "baz.bar"
[23:46:58] <jmkasunich> in fact it doesn't mention substitution at all (nor tab completion) and it doesn't even include the -i option that you use to pass the ini file name
[23:47:11] <jmkasunich> right
[23:47:25] <jmkasunich> so that allows parport pins to be specified in the ini
[23:47:29] <SWPadnos> yep
[23:47:48] <SWPadnos> there's a place where you really want the optional skipping
[23:48:00] <cradek> if we had loops in halfiles we could make the right number of stepgens
[23:48:17] <jmkasunich> linksp foo parport.[AXIS_0](PORT).pin-[AXIS_0](STEP_PIN)-out
[23:48:18] <SWPadnos> loops + the ability to instantiate comonents at some time other than load time
[23:48:23] <SWPadnos> components
[23:48:50] <jmkasunich> the instantiation problem is the biggie
[23:48:54] <SWPadnos> that assumes that it'll be a parallel port though
[23:49:10] <jmkasunich> we're talking about simple configs
[23:49:13] <SWPadnos> on a mesa card, it's blahblah.dout-(PIN)
[23:49:21] <jmkasunich> steppers with parport is a simple config
[23:49:24] <SWPadnos> sure
[23:49:39] <jmkasunich> if you are doing software generated steps with a mesa, you need slapped
[23:49:50] <SWPadnos> they don't have a stepgen config yet
[23:49:51] <jmkasunich> (or you're doing one such axis for some special reason)
[23:49:56] <SWPadnos> only PWM
[23:50:00] <jmkasunich> oh
[23:50:17] <jmkasunich> well still, if you pay $200 and then use software steps, you should have gotten jon's board
[23:50:21] <SWPadnos> Pete W is working on it though (and I think I have some files that almost work)
[23:50:24] <SWPadnos> probably
[23:50:39] <SWPadnos> unless you need 8 axes of encoder input
[23:50:43] <SWPadnos> plus secondaries
[23:50:50] <jmkasunich> anyway, stepgen + mesa is _not_ the paul/matt simple user case we're talking about
[23:50:53] <SWPadnos> oops - that includes secondaries, I think
[23:50:57] <SWPadnos> sure
[23:51:10] <cradek> I think we already have a config for the simple case.
[23:51:21] <cradek> the problem comes when someone wants to add a home switch.
[23:51:25] <jmkasunich> right
[23:51:31] <cradek> "problem"
[23:51:36] <cradek> (I'm not sure it is one)
[23:51:40] <SWPadnos> and that's where the "continue after fail" option is useful
[23:51:51] <jmkasunich> it is when we have to walk them thru it step by step
[23:52:00] <cradek> well we should put the commented-out home switch lines in the sample config and call it good.
[23:52:11] <jmkasunich> whether that is a lack of docs, or users that don't read the docs, or...
[23:52:12] <cradek> it's not hard to understand how to change -pin-11 to -pin-13
[23:52:12] <SWPadnos> youthe sample config does linksp axos.0.home [AXIS_0]HOME_PIN (or whatever)
[23:52:36] <cradek> it is hard how to make a new signal and hook it all up to the right stuff
[23:52:37] <SWPadnos> but if HOME_PIN doesn't exist, it's not an error
[23:53:20] <cradek> SWPadnos: I think that'll all be wrong if you want to use the same pin for several axes, or both limits, etc
[23:53:41] <jmkasunich> yeah, if you are ganging inputs you have to think at least a little bit
[23:53:43] <cradek> too many different cases.
[23:53:48] <SWPadnos> true
[23:54:06] <SWPadnos> I don't think you can use a single switch for home on multiple axes
[23:54:12] <cradek> I'm back to thinking some better commented-out stuff in the samples
[23:54:15] <SWPadnos> not without moving it between axes
[23:54:21] <jmkasunich> yeah you can, IF you follow a couple rules
[23:54:24] <cradek> sure you can
[23:54:33] <SWPadnos> ok, multiple switches, one input pin (duh)
[23:54:36] <jmkasunich> home != home_offset (so you get off the switch after homing)
[23:54:39] <cradek> right
[23:54:43] <jmkasunich> and don't try to home two at once
[23:54:57] <Jymmm> Howdy Folks!
[23:55:07] <SWPadnos> hi
[23:55:08] <cradek> and it's best to have them way at one extreme
[23:55:10] <jmkasunich> everybody hide!
[23:55:19] <SWPadnos> switch to tach 2
[23:55:25] <Jymmm> * Jymmm hides (and wonders why)
[23:56:09] <SWPadnos> TAC 2, I guess that would be
[23:56:11] <jmkasunich> I'm liking cradek's idea of better comments
[23:56:15] <Jymmm> Well, after 16 years we've being kicked out!
[23:56:22] <jmkasunich> commented code I mean
[23:56:22] <SWPadnos> heh -document, and let people hang themselves :)
[23:56:39] <Jymmm> s/we've'/we're/
[23:56:52] <jmkasunich> speaking of comments - sample hal files should include "section numbers" or something
[23:56:54] <SWPadnos> they probably got tired of all the noise and sawdust ;)
[23:57:10] <jmkasunich> so when you're talking somebody thru editing it, you can point them at the right part
[23:57:27] <Jymmm> SWPadnos: No, the owner died in February, and the children can't deal with it
[23:57:33] <jmkasunich> line numbers don't survive much editing and some folks use editors that don't show the lines
[23:57:51] <jmkasunich> Jymmm: that sucks
[23:57:54] <jmkasunich> how soon?
[23:57:57] <SWPadnos> line numbers are pretty useless for anything other than compiler errors
[23:58:35] <cradek> if the comments are decent and the examples clear, you have to point them at the right file, not line
[23:59:15] <Jymmm> We'll they are givign bullshit, they asked US to give them notice. But Earl was a smart/honest man. He told us they he put in his will that none of his managers are to be let go or have their rent increased. So, they are giving us some time. But we think it's because of that clause in his will.
[23:59:25] <jmkasunich> btw, I think I like your idea of "linksp Xstep [AXIS_0]STEP_PIN" better than "linksp Xstep parport.0.pin-{AXIS_0](STEP_PIN)-out"
[23:59:55] <jmkasunich> cradek: sometimes they've already picked the file, edited it a bit, and are now asking for more help