Back
[04:58:12] <ChanServ> [#emc] "This is the #emc channel - talk related to the Enhanced Machine Controller and general machining. Website:
http://www.linuxcnc.org/, wiki at
http://wiki.linuxcnc.org/"
[04:58:34] <maddash> logger_emc: slept late?
[04:58:34] <maddash> I'm logging. Sorry, searching removed.
[04:58:56] <SWPadnos> thanks for noticing. good night
[05:00:37] <jtr_> Thanks much. I was looking on DH one time, saw that cron jobs need the full path. wonder if that's whey they don't restart.
[05:00:49] <jtr_> -e
[05:01:17] <jtr_> good night.
[05:30:23] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[05:30:48] <eric_u> SWPadnos, any power supply recs?
[06:02:41] <K`zan_CNC> Anyone here using mach3? I am playing with it for the wizards and I think I have my Y axis backwards...
[06:03:24] <eric_u> and?
[06:03:39] <K`zan_CNC> Standing in front of the machine x zero (home?) should be to the left, y zero should be at the front or back of the table?
[06:04:24] <K`zan_CNC> front == closest to me.
[06:04:44] <eric_u> sorry, I forget
[06:04:53] <K`zan_CNC> I have never been sure I have this set up right and when I ran the text wizard it came out mirrored.
[06:05:31] <K`zan_CNC> Much easier to purchase one all put together but this is more fun...
[06:05:56] <eric_u> doesn't it have a pic in the manual?
[06:06:30] <K`zan_CNC> I've seen both and y zero toward the back makes more sense to me (head out of the way for setup and all that).
[06:07:18] <K`zan_CNC> But with this text thing being mirrored, Perhaps it is standard to put it to the front.
[06:07:30] <K`zan_CNC> I can redo it and see what happens I guess.
[06:07:46] <K`zan_CNC> I am assuming that home and zero are the same, but I am not sure about that either.
[06:08:47] <K`zan_CNC> The more I learn the less I know :).
[06:09:21] <eric_u> I don't do enough machining to remember
[06:09:46] <eric_u> so being dyslexic, I get things backwards a lot
[06:12:27] <K`zan_CNC> :-) understand that :-/.
[06:15:23] <eric_u> y zero is w/ table all the way back
[06:15:36] <eric_u> x zero is with table all the way right
[06:15:40] <eric_u> or is it a gantry?
[06:15:57] <K`zan_CNC> pipedream - fixed head (z)
[06:16:19] <K`zan_CNC> It appears that I have it arse backwards...
[06:16:20] <eric_u> how does it cut anything :)
[06:16:41] <eric_u> so it is like a mill
[06:16:50] <K`zan_CNC> For what little I have done it does OK, but that is incredibly trivial,
[06:17:04] <eric_u> I was just kidding, you said fixed head
[06:17:07] <K`zan_CNC> true up table (pocket, essentially) and engrave my call sign.
[06:17:25] <K`zan_CNC> Yes, like a mill, sorta kinda somewhat :).
[06:17:57] <eric_u> turns out it's not a right handed system
[06:18:05] <eric_u> which is somewhat freakish
[06:20:07] <K`zan_CNC> I suspect it is the way I set it up. Just because it makes sense to me has nothing to do with reality :-/.
[06:20:09] <K`zan_CNC> I got pix someplace, lemme find them...
[06:24:41] <K`zan_CNC> http://wrlabs.shacknet.nu/~vw/MyMachineShop/PipeDreamMill/PDM-V2/
[06:24:55] <K`zan_CNC> Some changes since then, but you'll get the idea.
[06:25:33] <eric_u> you need to upgrade to drawer slides :)
[06:26:11] <eric_u> how do the slides work?
[06:26:21] <K`zan_CNC> Plan on dropping this or giving it to my roomie and CNCing the HF Micro Mill once the last few coins to do so stack up.
[06:26:28] <K`zan_CNC> BUt for now it is educational...
[06:27:04] <K`zan_CNC> channel sliding against another (inverted) channel with a bearing pressing it together.
[06:27:09] <eric_u> nothing wrong with that
[06:27:29] <eric_u> ok, I saw the bearing on the vert axis, but not the others
[06:27:41] <K`zan_CNC> Might be OK for engraving or PCB milling.
[06:28:12] <K`zan_CNC> Same things on the x and y but only one each - look almost exactly the same as the Z ones.
[06:28:15] <eric_u> have you tried it?
[06:28:38] <K`zan_CNC> Yes, took me a while to get it leveled out but now it seems to work OK.
[06:28:55] <eric_u> there is nothing like seeing things move
[06:29:12] <K`zan_CNC> True, most encouraging :).
[06:29:34] <K`zan_CNC> More pix of the adventure up one level:
http://wrlabs.shacknet.nu/~vw/MyMachineShop/PipeDreamMill/
[06:29:56] <K`zan_CNC> Learning a lot as I go with this.
[06:30:28] <K`zan_CNC> Fun if sometimes FRUSTRATING :-).
[06:30:44] <eric_u> so you got emc to work, but not mach
[06:31:34] <K`zan_CNC> http://wrlabs.shacknet.nu/~vw/MyMachineShop/PipeDreamMill/PDM-Xaxis1/
[06:31:42] <K`zan_CNC> img_0011.jpg shows it.
[06:32:07] <K`zan_CNC> Yes, EMC works fine but I have no toolchain other than writing gcode.
[06:32:28] <K`zan_CNC> That is why I am playing with the wizards in Mach3 at the moment.
[06:32:30] <eric_u> that's why computers are so cheap
[06:32:59] <eric_u> wizards are overrated
[06:33:25] <eric_u> plus, when hurco gets done with them ...
[06:33:50] <K`zan_CNC> At this point for me, no. Poor docs and a klunky UI but it is something other than just moving the axis around.
[06:33:59] <K`zan_CNC> hurco?
[06:34:15] <eric_u> they have a patent on programming at the machine
[06:34:37] <eric_u> "conversational programming"
[06:35:45] <K`zan_CNC> Err, newbie warning.... What Greek you speak? :)
[06:36:29] <K`zan_CNC> I think I might be wise to go ahead and just print out all 157 pages of the manual...
[06:36:30] <eric_u> it doesn't really matter
[06:36:43] <eric_u> cheaper to get a bigger screen
[06:37:03] <eric_u> in my copy, only chapter 6 is interesting
[06:37:51] <K`zan_CNC> Mach3 controls and running a part program?
[06:38:02] <eric_u> yeah
[06:39:03] <eric_u> generally, I don't print any more
[06:39:09] <eric_u> the laser printers stopped working
[06:39:11] <K`zan_CNC> Maybe chapter5
[06:39:29] <eric_u> could be, I closed it
[06:39:31] <K`zan_CNC> My old LJ6L is still chunking 10 years later on the same cart...
[06:39:58] <eric_u> actually, my wife bought a hp cart, and it smoked some motors I think
[06:40:02] <K`zan_CNC> Printed about half a case of paper on it over the years, just the 3 hole punch stuff :)
[06:40:13] <K`zan_CNC> Bummer...
[06:40:27] <eric_u> did it to two apple lj before I realized it
[06:40:42] <K`zan_CNC> Picked up a LJ4P at the thrft store for $15 and it works well too.
[06:40:53] <eric_u> nice
[06:41:02] <K`zan_CNC> They had a color laser up there (3300CN IIRC) and I passed that up, sigh...
[06:41:05] <eric_u> I don't feel like having one around any more
[06:41:20] <K`zan_CNC> $35 but I am saving pennies for mounts and steppers for the micro mill now.
[06:42:09] <K`zan_CNC> CNCFusion mounts and 425 in/zo steppers (derates to 305 in/oz with my unipolar drive).
[07:26:13] <fenn_> fenn_ is now known as fenn
[07:48:09] <tomp> argh! the wire labeled ZVAL on this encoder interface means Z Valid . argh for 2 more letters! Zval? what Z value??
[07:53:59] <tomp> this is better, the 'nonius' is the mpg/handwheel input!
[07:54:28] <eric_u> what kind of encoder?
[08:06:32] <K`zan> eric_u: Thanks for the input tonight, much appreciated!
[08:08:27] <eric_u> sure, good luck with the mill
[08:08:42] <eric_u> I need to put together a little system like the one you built
[08:09:12] <tomp> eric, its not the encoer its this breakout board thats got weird names
[08:09:20] <eric_u> I see
[08:09:46] <eric_u> what does z valid mean then?
[08:10:34] <tomp> that the Z phase of the ecoder should home the machine. in the one revolution where this is valid, thats where the real reference mark is
[08:10:53] <eric_u> ok
[08:11:12] <eric_u> you would need a home switch then?
[08:11:20] <tomp> yep
[08:12:02] <eric_u> which bob?
[08:12:14] <tomp> you get a z signal every rev of a rotary encoer, the switch tells you when your'e close to the one use for real 'home'
[08:12:36] <tomp> portugese bob ( i knew him well :)
[08:12:48] <eric_u> that's backwards from the way EMC looks at it, but it doesn't really matter
[12:31:27] <micges> when HOME_SEQUENCE was started from 1, c.home(-1) will result no motion. there is no warning about this
[12:32:43] <micges> I know there is info in manual but when accidentally change begin value from 0 to 1 it's waste of time to check what's wrong
[13:45:55] <jepler> there may be a traditional home switch, plus this "home valid" input (hostmot2 calls this "index mask") plus the index pulse itself.
[13:46:51] <jepler> "home valid" may be too narrow to reliably see at the speed you'd like to move to home, so you home to switch+index and rely on the quadrature counting hardware to only count the index where the mask is true and the rising edge of Z is seen
[14:08:30] <cradek> jepler: ?
[14:08:51] <cradek> oh
[14:40:14] <jepler> cradek: did I get it right?
[14:41:03] <cradek> yes I think so
[14:41:12] <cradek> it looked 'out of the blue' but then I looked back more
[14:41:18] <cradek> so forget I said anything
[14:55:44] <jmkasunich> I did the same thing
[14:55:56] <skunkworks> * skunkworks thinks he has come a long way with eagle..
http://www.electronicsam.com/images/KandT/eagle.JPG
[14:56:06] <jmkasunich> I thought it was a really weird reply to micges
[14:56:42] <skunkworks> * skunkworks still thinks it is weird seeing jmkasunich on in the day.
[14:56:49] <jmkasunich> before 10am even!
[14:56:52] <cradek> me too
[14:57:02] <jmkasunich> (this is the earliest I've been up since my vacation started
[14:57:11] <cradek> this weekend I was in the shop before noon one day - but I forget what I accomplished that day
[14:57:35] <archivist> welcome to the waking world
[14:57:39] <cradek> jmkasunich: doesn't count until you put on pants
[14:58:26] <jmkasunich> pants are on, breakfast is eaten, dog is fed
[14:58:27] <archivist> skunkworks, er why the diodes on top of the fets
[14:58:36] <cradek> wow, count me impressed
[14:58:41] <jmkasunich> ;-)
[14:58:47] <jmkasunich> impressed += 1
[14:59:04] <archivist> heh what did you miss doing
[15:00:55] <jepler> jmkasunich: I think what Eric may be saying when he talks about "stutter" is that the trajectory planner "exact stop"s at each place S-numbers are commanded, rather than blending.
[15:01:18] <jmkasunich> jepler: yeah, that seems reasonable
[15:01:39] <jmkasunich> personally I think there is nothing wrong with using Z to control the laser power
[15:02:10] <cradek> I agree
[15:02:15] <skunkworks> it solves the problem of when things happen.. (realtime)
[15:02:27] <jmkasunich> other ways could include basing it on speed (using ddt and hypot), with a M6x digital on-off, or just using an M6x analog output (which I'm not sure is implemented yet)
[15:02:36] <cradek> if he just sets the accel high, I think it'll work well
[15:02:59] <skunkworks> would the motion studder using M6x?
[15:03:11] <jmkasunich> shouldn't
[15:03:27] <cradek> yes it would
[15:03:30] <jmkasunich> oh
[15:03:33] <jmkasunich> poo
[15:03:44] <skunkworks> heh
[15:04:14] <cradek> actually I think using Z is about the only way to get what he wants
[15:04:14] <jmkasunich> an M6x causes exact stop mode?
[15:04:45] <cradek> jmkasunich: pretty sure those cause the motion queue to drain, leading to a stop.
[15:04:56] <jmkasunich> hmm
[15:05:00] <jmkasunich> that could be improved
[15:05:01] <cradek> the only other way would be to queue them up with motion and have the TP do the setting
[15:05:18] <jmkasunich> I kind of thought that is how they work now
[15:05:21] <cradek> it would have to set them 'somewhere' during the blend
[15:05:31] <skunkworks> I suppose - if it is supposed to do the m6x at the right time.. how would it know when thru the blend to do it.
[15:05:36] <cradek> nope
[15:05:44] <jmkasunich> but I may be confusing that with how the FO override g-codes work
[15:05:46] <cradek> skunkworks: 'near the middle'?
[15:06:06] <skunkworks> what if one axis has a lot lower accel then the other?
[15:06:13] <cradek> jmkasunich: the feed override override override stuff is queued up like you say
[15:06:23] <jmkasunich> I know that - I did it
[15:06:30] <jmkasunich> for some reason I thought M6x was too
[15:06:32] <cradek> skunkworks: it will do the right thing
[15:06:44] <skunkworks> whatever 'thing' is? ;)
[15:06:50] <cradek> thing = honor all accel constraints
[15:07:03] <cradek> ohh
[15:07:08] <cradek> I misunderstood what you were askin
[15:07:08] <jmkasunich> which isn't actually the right thing for the laser app
[15:07:09] <cradek> g
[15:07:12] <skunkworks> * skunkworks was wondering when it would do them m6x..
[15:07:23] <cradek> right, sorry
[15:07:36] <skunkworks> * skunkworks has already had 3 cups of coffee so far.
[15:07:37] <cradek> jmkasunich: what is the problem statement and the needed behavior?
[15:08:00] <jmkasunich> I believe he wants very rapid ramps to the desired power
[15:08:12] <cradek> is the Z thing insufficient for some reason? it seems fine to me
[15:08:17] <jmkasunich> if I understand the messages properly, the ramps should be close to steps
[15:09:05] <skunkworks> our laser (fanuc controller) has a separate board that bases the power on velocity. I would think he could do the same thing in hal.
[15:09:41] <cradek> hm, with the Z scheme I guess motion will stop (but not pause like for an S change)
[15:09:48] <jmkasunich> I think he should figure out his "mysterious stop" problem, THEN and only then start debating the best way to control the laser
[15:10:13] <jmkasunich> since our source of actual knowledge about his goal is the same as the source of all debugging into, I don't want to divert him
[15:10:32] <cradek> true.
[15:11:02] <jmkasunich> he could avoid the stop, if he programs the Z move to take place along with some XY movement
[15:11:06] <jmkasunich> a ramp instead of a step
[15:11:31] <cradek> also true
[15:11:59] <jmkasunich> of course that may give bad results - a gradually increasing depth of cut instead of a sharp start, or something
[15:12:07] <jmkasunich> we don't know enough about the application
[15:12:35] <cradek> we could change M6x to be realtime. it would only be a minor pain.
[15:12:41] <cradek> medium sized pain?
[15:13:22] <cradek> I don't see any drawback to it working that way - seems like it would be better.
[15:14:18] <jmkasunich> I don't see any user drawbacks
[15:14:31] <skunkworks> I still don't know how you would decide when it would be turned on. or am I making this too complicated.
[15:14:32] <jmkasunich> dunno how many outputs there are, queuing all that could get bulky
[15:14:51] <skunkworks> (thru a blended corner)
[15:14:58] <jmkasunich> skunkworks: right now, the TP reports "what line am I executing", and I believe it changes that number mid-blend
[15:15:03] <jmkasunich> I'd just use that info
[15:15:08] <cradek> skunkworks: turning it on anytime during the blend would be ok. near the middle would be better. a lot of stuff already ^^ yeah that
[15:15:19] <skunkworks> heh
[15:15:51] <cradek> jmkasunich: also, there are analogs and digitals
[15:15:57] <jmkasunich> I think there are 4 M6x analog outs, and some digitals
[15:16:08] <jmkasunich> 5 x 32 bits isn't too much to queue
[15:16:47] <skunkworks> probably not a problem... My only thought is 'mid blend' could be way to one end if one axis has a slow acc. (but probably not an issue most of the time)
[15:16:49] <SWPadnos> what if "what line I'm executing" were exported to HAL?
[15:17:23] <SWPadnos> wouldn't help with this, but could be used in general to synchronize things to motion
[15:17:25] <jmkasunich> oops, doubles - make that 4 * 64 + 32
[15:17:31] <cradek> skunkworks: I think you are right but I doubt it would matter too much
[15:17:38] <skunkworks> right
[15:17:45] <jmkasunich> SWPadnos: maybe, but as you say, not directly related
[15:17:49] <SWPadnos> jmkasunich, still under one cache line :)
[15:17:55] <cradek> skunkworks: if it needs to be at an exact point you could always use G61.
[15:17:57] <jmkasunich> would be handy for troubleshooting with halscope tho
[15:18:21] <jmkasunich> "trigger when running line 4013"
[15:18:43] <cradek> dudes, man motion
[15:18:48] <cradek> (motion.program-line)
[15:18:52] <SWPadnos> yay! :)
[15:19:00] <SWPadnos> that was easy
[15:19:07] <jmkasunich> best kind of feature
[15:19:13] <jmkasunich> back to synced outputs
[15:19:57] <jmkasunich> struct synced_outs { double analog[SOME_NUM]; u32 digital[SOME_OTHER_NUM_DIVIDED_BY_32] }
[15:20:06] <jmkasunich> embed one of those into the structs in the tp queue
[15:20:40] <cradek> it's interesting to think that between two moves, you can have many M6x commands
[15:20:50] <jmkasunich> all the M6x commands in command.c would just change the values of a local copy, motion commands would queue a copy of the local, and the tp would drive outputs with the values coming off the queue
[15:21:07] <cradek> I believe the old code (in emc1?) that did this assumed you could only change one thing
[15:21:26] <jmkasunich> they queued the command, as opposed to the states of the outputs?
[15:21:39] <cradek> yes I think so
[15:21:56] <cradek> 'at the end of this move set/clear outupt bit N' iirc
[15:22:00] <cradek> (it's been a while)
[15:22:10] <jmkasunich> my way uses more memory probably, but is more versatile
[15:22:14] <cradek> yes
[15:22:45] <cradek> perhaps 'is more versatile' = 'is not a broken implementation'
[15:22:51] <jmkasunich> there would be some special case code - when nothing is queued (no motion), then write directly from the local (command.c) struct to the outputs
[15:23:27] <SWPadnos> can you set multiple outputs on one line, or are they "modal"?
[15:24:02] <cradek> pretty sure it takes multiple lines
[15:24:17] <jmkasunich> I think the syntax is M6x <some-letter> channel-num <some-letter> value
[15:24:25] <jmkasunich> so only one channel/value pair per line
[15:24:31] <cradek> http://www.linuxcnc.org/docs/devel/html/gcode_main.html#sec:M62-to-M65:
[15:24:39] <SWPadnos> ok, then a single "do this at the end" is sufficient
[15:24:43] <cradek> no talk of analog outputs - but I thought we had them
[15:24:45] <jmkasunich> but you could put several lines between two G1s, and all would take effect at the blend point between those two moves
[15:24:46] <SWPadnos> since only one thing can change
[15:24:51] <cradek> SWPadnos: no
[15:24:52] <SWPadnos> that's true
[15:24:54] <cradek> g1x1
[15:24:57] <cradek> M6x P1
[15:24:58] <cradek> M6x P2
[15:24:59] <cradek> g1x2
[15:25:05] <SWPadnos> right
[15:25:59] <jmkasunich> cradek: I think the analog outputs either got dropped somewhere during the emc1->emc2 transition, or (more likely) were never implemented in emc1
[15:26:34] <jmkasunich> the words for M66 are a bit unclear
[15:26:50] <jmkasunich> "To control a digital input bit, program M66"
[15:26:58] <jmkasunich> # The P-word specifies the digital input number.
[15:26:58] <jmkasunich> # The E-word specifies the analog input number.
[15:27:29] <jmkasunich> the first line should read "To read an analog or digital input, program M66"
[15:27:49] <cradek> yep
[15:28:08] <jmkasunich> I wonder why wait mode 0 (no wait, just read) is only allowed for analog
[15:29:01] <jmkasunich> hmm, BigJohnT isn't here, and I don't seem to have lyx installed on this machine
[15:29:09] <jmkasunich> I guess I can fix the latter problem
[15:29:35] <archivist> is it expecting to address external hardware latches then "To control a digital input bit, program M66" makes a bit more sense
[15:29:57] <cradek> where do you see "wait mode 0 (no wait, just read) is only allowed for analog"
[15:30:19] <jmkasunich> http://www.linuxcnc.org/docs/devel/html/gcode_main.html#sec:M66
[15:30:30] <jmkasunich> last item in the bulletted list
[15:30:37] <cradek> you misread it
[15:30:43] <jmkasunich> oh, I did
[15:31:01] <cradek> I think this one is wrong: "It is an error to program a timeout value of 0 with any mode different than mode 0."
[15:31:19] <cradek> err, no
[15:31:23] <cradek> dangit
[15:31:44] <cradek> today reading unable to, me
[15:31:59] <jmkasunich> if it is any consolation, I find that hard to parse too
[15:32:22] <jmkasunich> a timeout has no meaning at all in mode 0
[15:32:52] <jmkasunich> and a timeout of zero doesn't make sense for the other modes (when you intend to wait for something)
[15:33:54] <cradek> although I was sure we have analog outputs, I don't see any sign of them in the source...
[15:33:56] <jmkasunich> it would probably be better to say "The timeout value is ignored in mode zero, which always reads the input immediately. In all other modes, the timeout value must be non-zero."
[15:34:13] <cradek> I agree your wording is much better
[15:34:23] <cradek> well, actually it's an error
[15:34:27] <jmkasunich> I told you - they were broken/missing in emc1, and never made the transition
[15:34:49] <cradek> garbage in should = error out, not garbage in = ignore it
[15:34:54] <jmkasunich> I read "must be" as "or else it is an error"
[15:34:57] <SWPadnos> is there any particular reason to have the input codes?
[15:35:11] <jmkasunich> SWPadnos: ?
[15:35:16] <jmkasunich> M66 you mean?
[15:35:18] <cradek> SWPadnos: some people mistakenly want to run tool changers (etc) that way
[15:35:23] <jmkasunich> or the wait type codes?
[15:35:26] <SWPadnos> ie, why can't the motion controller just put the values of the input HAL pins into some vars
[15:35:33] <SWPadnos> every line
[15:35:36] <jmkasunich> queueing
[15:35:37] <cradek> SWPadnos: readahead
[15:35:51] <cradek> brb
[15:35:58] <SWPadnos> if you want to "read" one at a particular time, you use #mine=#the_input
[15:36:00] <SWPadnos> hmm
[15:36:10] <jmkasunich> M66 is a queue flushing command, so that the interp can get the results
[15:36:20] <SWPadnos> oh, that darned interp
[15:36:49] <SWPadnos> g#in1 X#in2 Y#in3 wouldn't work so hot then :(
[15:37:06] <SWPadnos> I guess I should go pour some of that coffee now :)
[15:37:12] <jmkasunich> G1FslowXlong; M66; O if <something-that-m66-read> do <decision based on input at the start, not end, of the long slow move>
[15:37:33] <jmkasunich> (if implemented as you suggest)
[15:37:51] <jmkasunich> bah, I borked that up, since you wouldn't use M66
[15:38:21] <SWPadnos> well, the O line would come after the G1 line anyway, so there would be a "new" copy
[15:38:51] <jmkasunich> you'd have to sync every one of the input vars after every line of g-code
[15:38:55] <SWPadnos> but it's true that the interp wouldn't know what to do (O-wise) until the line had finished
[15:39:00] <SWPadnos> only the ones you want to use
[15:39:13] <jmkasunich> how does the interp know which ones those are?
[15:39:18] <SWPadnos> I don't know if it's legal to do multiple #x=#y on the same line
[15:39:55] <SWPadnos> if the digital inputs are always #6000-#6031, all I have to do to read one is #100=6001
[15:39:58] <SWPadnos> err
[15:40:05] <SWPadnos> #100=#6001
[15:40:08] <jmkasunich> the "write #my = #input" to tell the interp to sync is a very non-obvious requirement
[15:40:15] <SWPadnos> and the input can change all it wants
[15:40:31] <SWPadnos> yes, the sync thing is a problem
[15:40:37] <SWPadnos> I claim -ENOCAFFEINE
[15:41:08] <jmkasunich> M66 solves the issue, I think the only thing wrong with it is a line or two of docs that I'm about to fix
[15:41:32] <jmkasunich> we've digressed from the issue of analog outputs, and sync of all outputs
[15:51:18] <archivist> I can imagine a use of an analog read during engraving to sense material height
[15:51:52] <cradek> is it true that syncing digital outs with motion won't help Eric J and other laser folks, because they need analog outs?
[15:52:01] <cradek> or is it on/off that they need
[15:52:14] <SWPadnos> Eric wants analog
[15:52:36] <SWPadnos> I think he said he can set engraving depth with it (or something like that)
[15:52:50] <SWPadnos> also, it's used to compensate for speed, like the old Gerber photoplotters did
[15:54:18] <jmkasunich> cradek: if I were to sync any outs with motion, I'd sync all of them, analog and digital
[15:54:28] <cradek> I agree
[15:54:38] <SWPadnos> me too, fwiw :)
[15:55:47] <jmkasunich> it is interesting that the manual says (re M66 inputs): In EMC2 these inputs are not monitored in realtime and thus should not be used for timing-critical applications.
[15:56:21] <jmkasunich> oh, I'm confusing two things again
[15:56:24] <jmkasunich> sync vs. realtime
[15:57:13] <SWPadnos> EMC made no guarantee about I/O timing because the I/O could be (and sometimes was) at the end of an NML link, at the IO controller
[15:57:14] <jmkasunich> I think (and the manual should probably clearly state) that M66 causes interpretation to stop until all previous motions have been executed, then samples the input, and continues interpretation
[15:57:47] <jmkasunich> ^^^ is sync, realtime is something else entirely
[15:58:07] <SWPadnos> there could also be no guarantees about sync
[15:58:16] <cradek> lots of things cause that, and it's generally no concern to the user
[15:58:17] <SWPadnos> since the IO controller could have been at the end of a serial link
[15:58:42] <jmkasunich> SWPadnos: why are you talking about EMC1?
[15:58:57] <SWPadnos> the EMC2 manual is based on the EMC1 manual
[15:59:04] <jmkasunich> cradek: I beg to differ ;-)
[15:59:32] <SWPadnos> so some verbiage may be there based on the design decisions in EMC1, not necessarily based on some ideal idea for the language
[15:59:43] <jmkasunich> if the user doesn't understand that the interpreter sometimes (usually) reads ahead, he is gonna get very confused
[16:00:02] <cradek> can you give me a specific example? I don't think he needs to care.
[16:00:10] <jmkasunich> SWPadnos: the verbiage in there specifically says EMC2
[16:00:27] <SWPadnos> s/EMC/EMC2/g ...
[16:00:47] <cradek> the things that readahead would screw up (digital inputs, spindle speed changes, tool change) cause readahead to stop at the right point
[16:00:56] <jmkasunich> I think he should know that programming a M66 in the middle of a stream of G1 moves is gonna stop blending at that point, for instance
[16:01:18] <cradek> but that has nothing to do with the interpreter reading ahead.
[16:01:20] <SWPadnos> and cause unexpected "stuttering" in some applications, apparently :)
[16:01:29] <cradek> the user will see motion pause. that's the thing you document.
[16:01:31] <jmkasunich> and Eric's "The motion stutters when I use S to control the laser" is also a result of that
[16:01:57] <cradek> yes spindle speed change causes motion to pause, document that, not the implementation
[16:02:12] <jmkasunich> ok, I see your point
[16:02:14] <SWPadnos> does it need to?
[16:02:18] <jmkasunich> I only partially agree with it
[16:04:14] <jmkasunich> if the main reason for a behavior is because of an implementation constraint, not because it is something that an "ideal implementation" would do, then both the behavior and the cause should be documented (maybe not in the same place)
[16:04:47] <SWPadnos> manual and wish-list :)
[16:05:11] <skunkworks> other than it looks like it was stung by a bee..
http://imagebin.ca/img/2MB7X6.png
[16:05:24] <jmkasunich> something as fundemantal (and not likely to go away) as interpreter read-ahead should be acknowledged, IMO
[16:05:27] <jepler> skunkworks: er what?
[16:05:48] <jmkasunich> fundamental duh
[16:06:13] <skunkworks> * skunkworks had to make the pads bigger.
[16:06:38] <jmkasunich> pad-flood clearance doesn't look very big
[16:06:39] <cradek> jmkasunich: I think we disagree about user docs vs. design docs. You think the user should be more intimate with the design than I do.
[16:06:52] <jmkasunich> yeah
[16:06:56] <jmkasunich> and you are probably right
[16:06:59] <cradek> I think users don't understand or care about designs, docs should be about behavior
[16:07:16] <jmkasunich> the user I know the most about is me
[16:07:20] <jmkasunich> I'm not a typical user
[16:07:28] <SWPadnos> I'd say you're an atypical user
[16:07:32] <cradek> 'you will get an error if you...' 'it will do [x] when you ...'
[16:07:47] <eric_u> lots of users are interested in the programming
[16:07:53] <archivist> if user knows why he can react
[16:08:00] <cradek> not '[design] does not allow [x] so it is an error'
[16:08:34] <jmkasunich> yeah, yeah
[16:08:42] <archivist> if user knows its design he can add feature requests
[16:08:49] <cradek> * cradek puts away the soapbox
[16:08:56] <jmkasunich> the problem is that listing behaviors requires that we list ALL of the behaviors
[16:09:03] <eric_u> if user wants feature, user asks for feature
[16:09:17] <jmkasunich> yeah, I think design and feature requests are not related
[16:09:26] <cradek> archivist: but the user should ask for the behavior he wants. if he thinks he can suggest a new design, he is usually just wrong, and we can't even tell what he really wants.
[16:09:30] <jmkasunich> if he asks for a feature that the design makes impossible, we say so
[16:09:54] <skunkworks> jmkasunich: not happy with it.. It would take a lot of changes to fix. (I am down to .030 osolation atm). The plan is to test and see what happens.
[16:10:03] <archivist> fix design :)
[16:10:14] <jmkasunich> archivist: you volunteering?
[16:10:29] <archivist> hoo meee
[16:10:30] <eric_u> I know a feature request when I see one
[16:10:46] <jepler> I'd like to request a feature: that the design be made such that all future feature requests are easy to implement.
[16:10:54] <jepler> I think that'll require a modified design, though;...
[16:11:16] <jmkasunich> we digress again - I think my thing with "the docs should describe some design stuff" is that a (smart) user who knows about readahead can figure out some things, like "ah-ha, that is why motion stutters when I change spindle-speed between two G1 moves"
[16:11:19] <eric_u> could you list all future feature requests first?
[16:12:05] <jmkasunich> if we can document every little stutter and other seemingly strange behavior, then sure, we don't need to explain the design issues that cause them
[16:12:21] <eric_u> it stutters because the interpreter read ahead can't go past the speed change?
[16:12:37] <archivist> yes
[16:12:38] <jmkasunich> I'm not entirely sure of that myself
[16:12:38] <SWPadnos> blending doesn't, not read-ahead
[16:12:55] <SWPadnos> I'm not sure why S would cause that, it doesn't seem that it should be necessary
[16:13:09] <jmkasunich> * jmkasunich head spins
[16:13:11] <SWPadnos> (except that in EMC1 the spindle controller was also NML-connected)
[16:13:18] <eric_u> have to think about that
[16:13:19] <jmkasunich> stop talking about EMC1
[16:13:26] <jmkasunich> it adds nothing to the discussion
[16:13:30] <SWPadnos> it wasn't just hal_data->spindle-speed = newspeed
[16:13:41] <SWPadnos> it provides background for the current implementation
[16:13:56] <SWPadnos> or the docs, as the case may be
[16:13:57] <jmkasunich> I think that cradek recently added a feature (maybe optional) that stops motion until spinde at-speed
[16:14:10] <cradek> yes
[16:14:17] <eric_u> not a horrible idea
[16:14:20] <SWPadnos> right
[16:14:31] <cradek> you might even call it a good idea
[16:14:40] <jmkasunich> yes
[16:14:44] <stustev1> yes
[16:14:46] <SWPadnos> I certainly do
[16:14:50] <cradek> or a kick-ass idea
[16:14:51] <jmkasunich> in the case it was designed for, certainly
[16:15:10] <jmkasunich> but when somebody decides to be clever and use spindle speed to control laser power on the fly, guess what?
[16:15:22] <jmkasunich> they are confused by the stopping during "speed change"
[16:15:39] <eric_u> how do you know that the spindle is at speed for a normal machine?
[16:15:48] <jmkasunich> some of this is inevitable - EMC is complex
[16:16:01] <SWPadnos> the default behavior is (should be) the same as before the feature was added
[16:16:03] <cradek> eric_u: there is an input to motion, so the integrator can detect it any way he wants
[16:16:26] <jmkasunich> including setting it "always at-speed"
[16:16:38] <cradek> eric_u: reading the spindle encoder and a vfd 'at speed' output would be the most common ways I think
[16:16:47] <SWPadnos> if that input is unconnected, the spindle would never be at speed, and you'd have an indefinite pause at every S word
[16:17:02] <cradek> SWPadnos: (it doesn't pause at the S word)
[16:17:05] <SWPadnos> (if it didn't default to the old behavior)
[16:17:08] <SWPadnos> right
[16:17:13] <eric_u> when I said normal, i meant open loop
[16:17:13] <cradek> it does default to the old behavior
[16:17:19] <SWPadnos> I think I'm pointing out that the new feature shouldn't be the problem
[16:17:37] <SWPadnos> for Eric anyway
[16:17:39] <cradek> eric_u: you could even use something like a time delay (oneshot component maybe?)
[16:17:50] <cradek> eric_u: but still, the answer is 'however you want'
[16:18:06] <jmkasunich> cradek: it doesn't pause at S changes? (even if you have the at-speed input connected to something)
[16:18:13] <cradek> no
[16:18:17] <jmkasunich> why not?
[16:18:29] <SWPadnos> huh - use a limit3, if you know the accel parameters ofthe motors, that should give a pretty good approximation
[16:18:48] <SWPadnos> because the pin is set to true by default (it's a bit input, isn't it?)
[16:18:49] <cradek> jmkasunich: because I don't think a pause is wanted there
[16:19:01] <jmkasunich> so it only reacts to speed changes due to CSS?
[16:19:20] <jmkasunich> what about M5 -> M3 transition?
[16:22:49] <cradek> after any spindle speed/direction change OR always if in css mode, it pauses and waits for atspeed before the beginning of a set of one or more feed moves
[16:23:25] <jmkasunich> where is this documented? (I'm looking at man motion and don't see an at-speed input pin)
[16:23:35] <cradek> so spindle change - rapid - rapid - feed, it will allow the rapids while the spindle is changing speed.
[16:23:51] <cradek> I was looking for that too, so I could smugly point you at the documentation
[16:24:02] <jmkasunich> so it DOES pause at S changes!!!
[16:24:10] <cradek> NO
[16:24:25] <cradek> it pauses before the feed following an S change
[16:24:29] <jmkasunich> where pause is defined as "if you do G1, Ssomething, G1", it stops between the G1s
[16:24:58] <cradek> "stops" = waits for spindle atspeed?
[16:25:03] <jmkasunich> yes
[16:26:03] <cradek> well heck, now I'm not sure how it handles that
[16:26:05] <SWPadnos> if you are doing feed moves, then Ssomething, then more feed moves, there is no pause unless you're in CSS mode
[16:26:07] <cradek> I don't think it waits in that case
[16:26:31] <SWPadnos> if you do traverse moves, then Ssomething, then feed moves, it should pause until at-speed is true before doing the feed moves
[16:26:32] <cradek> dangit, already I don't remember how it works
[16:26:35] <SWPadnos> heh
[16:26:48] <cradek> someone should test and then document it, haha
[16:26:58] <jmkasunich> I think there are two sets of "things" here, and the behavior is the intersection of the two
[16:27:03] <SWPadnos> where's BigJohnT when you need him? :)
[16:27:06] <jmkasunich> I was asking about one set, cradek was answering the other
[16:27:22] <jmkasunich> set 1: things that cause a spindle speed change that _might_ make motion pause
[16:27:35] <jmkasunich> M5->M3 (or M4) transition
[16:27:57] <jmkasunich> M3 -> M4 transition (maybe? except rigid tap)
[16:28:05] <jmkasunich> CSS diameter change
[16:28:08] <jmkasunich> S word change
[16:28:25] <jmkasunich> set 2: conditions in which a change from set 1 will cause a pause
[16:28:34] <jmkasunich> 1) rapid -> change -> feed
[16:28:42] <jmkasunich> 2) feed -> change -> feed ?
[16:30:02] <jmkasunich> I was astonished because I thought cradek was telling me that S word changes aren't in set 1
[16:30:59] <cradek> also the other axis in our grid of topics is "motion will briefly stop" vs "motion will wait for the spindle at speed signal to be true"
[16:31:26] <jmkasunich> right - it won't stop if at-speed is already true
[16:31:29] <SWPadnos> "As discussed on emc-developers: wait for the spindle to be "at speed" (as shown by a hal input to motion) in these cases: before the first feed move after each spindle start or speed change; before the start of every chain of spindle-synchronized moves; and if in CSS mode, at every rapid->feed transition. This checkin also fixes a problem aborting while waiting for spindle index (or at-speed)."
[16:31:37] <SWPadnos> the commit message
[16:32:11] <cradek> well let's pretend that's the spec, and I implemented it right
[16:32:21] <cradek> ... brb
[16:32:23] <SWPadnos> welllll, it may still be ambiguous :)
[16:33:02] <SWPadnos> that first sentence could be read as "will pause the first feed move after every speed change"
[16:33:18] <jmkasunich> I don't read it that way
[16:33:34] <SWPadnos> me either, because I think I know what it's supposed to mean
[16:33:54] <jmkasunich> "wait for foo" doesn't mean "stop, then check foo", it means "check foo, then stop if not ready"
[16:34:28] <jmkasunich> "wait for green light at intersection"
[16:34:30] <SWPadnos> oops - replace "pause" with "pause until ready"
[16:34:32] <SWPadnos> sure
[16:34:45] <SWPadnos> G0 / Sxx / G1X1 / Syy / G1X2
[16:35:06] <SWPadnos> this should wait for at-speed before G1X1, but not for G1X2
[16:35:28] <jmkasunich> no, both
[16:35:30] <SWPadnos> and I don't know if (a) that's what it does or (b) the description describes that
[16:35:37] <jmkasunich> "before the first feed move after each spindle start or speed change"
[16:36:27] <SWPadnos> I guess you could use a mux and M6x to decide whether to use at-speed or not anyway
[16:36:32] <jmkasunich> I don't know what it does, but I believe the words clearly describe a wait at both G1s
[16:36:51] <SWPadnos> I think that's true, but I don't know that's what was intended
[16:37:00] <SWPadnos> I don't remember the conversation well enough to say
[16:37:22] <jmkasunich> "well let's pretend that's the spec, and I implemented it right"
[16:37:36] <jmkasunich> so, that is the spec, regardless of the now-forgotten conversation
[16:37:46] <SWPadnos> ok
[16:37:56] <eric_u> should be the message of the day on #emcdevel
[16:38:17] <SWPadnos> so if someone connects something to at-speed, they may see pauses around S words
[16:39:01] <anonimasu> dosent most machining centers already do this?(like wait for spindle to reach nominal speed before starting to cut)
[16:39:48] <SWPadnos> dunno
[16:39:58] <SWPadnos> EMC2 now allows you to do that if you like
[16:39:58] <eric_u> I think they have to
[16:40:16] <eric_u> otherwise starting up after a tool change would be a very iffy thing
[16:40:21] <anonimasu> yep
[16:40:24] <anonimasu> or any cutting action
[16:40:28] <anonimasu> I guess it's a sane spec..
[16:40:30] <eric_u> or you would have to program in a move
[16:40:51] <jmkasunich> cradek's implementation stems from watching a lathe rapid out to a large (slow) diameter on a CSS cut and start cutting before the spindle slowed down
[16:41:18] <eric_u> that sounds exciting
[16:41:32] <jmkasunich> a couple years ago, I put in something much cruder on the mazak, after watching the spindle start, a rapid to beginning of cut, and almost start a heavy cut while not up to speed
[16:41:59] <jmkasunich> in my case, I did it in HAL: feed hold connected to not-at-speed
[16:42:12] <anonimasu> I think you need to be able to have pre-positioning moves, like without considering the speed, having a rapid to start pos while the spindled is speeding up makes sense
[16:42:14] <jmkasunich> cradek's version is much better, and properly integrated into emc
[16:42:27] <eric_u> well, certainly you need it
[16:42:34] <eric_u> for a speedy machine
[16:42:39] <anonimasu> like pre-position, wait for go.. then start up
[16:43:04] <anonimasu> ofcourse they are all happening at roughtly the same time :p
[16:43:22] <jmkasunich> anyway, we have a spec of sorts, and an implementation
[16:43:42] <jmkasunich> we don't have docs, and we're not 110% sure the implementation matches the spec exactly
[16:44:13] <anonimasu> :S
[16:44:21] <jymm> hola
[16:44:43] <anonimasu> jmkasunich: we'll know after a few crases ;)
[16:45:35] <eric_u> creases?
[16:46:21] <jmkasunich> crashes
[16:46:22] <anonimasu> crashes...
[16:46:40] <alex_joni> still, it's not 100% related to the initial reported problem
[16:46:49] <jmkasunich> heh, not even 50% by now
[16:46:59] <alex_joni> hello, btw :)
[16:47:02] <jmkasunich> but the original problem is still waiting for info from the original poster
[16:47:10] <alex_joni> the stuttering is because blending is stopped
[16:47:37] <alex_joni> and the real answer for that is that eric? needs some motion synched DO's and AO's (that don't break blending)
[16:47:51] <eric_u> orly?
[16:47:57] <anonimasu> ^_^
[16:48:31] <eric_u> I wonder if I can convince that guy to change his name
[16:48:41] <jmkasunich> BUGS: This manual page is horribly incomplete.
[16:49:01] <jmkasunich> I guess that gets us off the hook for "motion.spindle-at-speed" not being in the manpage
[16:49:13] <eric_u> honest anyway
[16:49:40] <jmkasunich> I'm gonna fix that one small issue anyway
[16:49:49] <eric_u> yay
[16:50:09] <jmkasunich> motion.spindle-is-atspeed-in
[16:50:17] <jmkasunich> what a great name :-/
[16:50:27] <eric_u> that's the name of the man page?
[16:50:36] <alex_joni> is there a motion.spindle-is-atspeed-in-not ?
[16:50:37] <jmkasunich> no, the pin that I need to add to the manpage
[16:50:39] <seb_kuzminsky> you guys talking about Eric Johnson's stuttering problem?
[16:50:52] <jmkasunich> seb_kuzminsky: we started there, but have wandered quite a bit
[16:50:53] <seb_kuzminsky> or rather, the stuttering problem of his machine ;-)
[16:51:10] <eric_u> stuttering is such a tragedy, but it can be treated!
[16:51:17] <jmkasunich> really, that pin name is horrid, no wonder it isn't in the manpage
[16:51:40] <alex_joni> seb_kuzminsky: yeah, and seeing a SLT doesn't help
[16:51:52] <seb_kuzminsky> * seb_kuzminsky googles SLT
[16:52:03] <alex_joni> SPeech and Language Therapist
[16:52:08] <seb_kuzminsky> heh
[16:52:19] <seb_kuzminsky> jmk is slt for machines
[16:52:39] <jmkasunich> cradek: I wonder how many people (besides you) have connected things to that pin
[16:53:45] <alex_joni> I guess around 0.67 people
[16:54:30] <jmkasunich> given '-' between each word, there should be one between 'at' and 'speed'
[16:54:38] <eric_u> that other .33 person has got to be in pain
[16:54:51] <jmkasunich> and the 'is' seems a waste, given the presence of 'in'
[16:55:28] <alex_joni> well.. if it's TRUNK only, fix the manpage, then fix the motion pin to match the docs :D
[16:55:59] <jmkasunich> I'm checking the trunk only part, and asked cradek because I know the change will break his config
[16:56:25] <jmkasunich> yep, trunk only
[16:56:51] <jmkasunich> motion.spindle-at-speed-in
[16:57:09] <jmkasunich> even the -in seems unneeded to me...
[16:57:25] <jmkasunich> but I can live with it
[16:57:26] <cradek> the other stuff in motion has those in/out
[16:57:47] <jmkasunich> actually only two - spindle-speed-in and spindle-speed-out
[16:58:03] <cradek> oh
[16:58:24] <jmkasunich> well, the M6x analog and digital ins and outs, but those make sense
[16:58:33] <cradek> if you're going to rename it, make it whatever you think is the best name possible
[16:59:27] <jmkasunich> halcmd show and the manpage both show direction explicitly, so I don't think it needs to be in the name, unless there are two names that would be identical otherwise, like spindle-speed-in -out
[17:00:31] <cradek> I can sure understand that position
[17:03:45] <cradek> jmkasunich: are you working on synced digital outs?
[17:04:27] <jmkasunich> no
[17:04:30] <jmkasunich> at least not yet
[17:04:48] <jmkasunich> we kept digressing - atm I'm fixing the motion manpage and that signal name
[17:06:22] <jmkasunich> motion.spindle-at-speed IN bit
[17:06:22] <jmkasunich> Motion will pause until this pin is TRUE, under the following
[17:06:22] <jmkasunich> conditions: before the first feed move after each spindle start
[17:06:22] <jmkasunich> or speed change; before the start of every chain of spindle-syn‐
[17:06:22] <jmkasunich> chronized moves; and if in CSS mode, at every rapid->feed tran‐
[17:06:23] <jmkasunich> sition.
[17:06:32] <jmkasunich> ick, nasty paste
[17:06:37] <jmkasunich> but that is what I put in the manpage
[17:06:46] <alex_joni> I think synced digital outs aren't hard to do, just a bit tedious (need to put them on the TC queue, like the FO's)
[17:07:33] <cradek> jmkasunich: looks great
[17:07:57] <cradek> (the thing I wrote in the commit message is as likely to match the implementation as anything)
[17:09:02] <jmkasunich> and if not, it is a simple bug that needs fixing, not something to debate all day ;-)
[17:09:08] <cradek> haha
[17:09:08] <jmkasunich> manpage = spec
[17:10:17] <eric_u> I think it is a spirited agreement
[17:14:56] <anonimasu> hehe
[17:15:03] <anonimasu> the spec is right and the implemnetation is wrong..
[17:15:03] <anonimasu> :p
[17:15:07] <anonimasu> (classic solution)
[17:20:33] <toastatwork> total paintball bill so far: 1100
[17:20:37] <toastatwork> to go: 200
[18:29:11] <stustev1> I can understand the reason to calculate the inverse kinematics. It offsets the joint positions from the commanded positions. Why do we need to calculate the forward kins?
[18:34:02] <stustev1> because joint movement will need to be offset and fed back into EMC?
[18:34:43] <jmkasunich> one reason - if you jog a joint individually (say as part of setup), EMC needs to be able to convert that back to cartesean coords for the DRO, and to initialise itself when you go into auto or mdi mode
[18:35:25] <jmkasunich> there is actually some special case code for machines where you don't or can't have for forward kins
[18:35:55] <jmkasunich> it adds some new rules, like you can't go from manual to auto/mdi unless all joints are homed (and haven't been homed after moving)
[18:36:10] <jmkasunich> bah
[18:36:18] <jmkasunich> I mean "haven't been moved after homing"
[18:37:18] <stustev1> but won't the very same offset calculation give the proper adjustment?
[18:38:06] <jmkasunich> on a machine like a hexapod, if you move one leg only, it becomes very difficult to determine the XYZ locations - it's not just a simple offset
[18:38:58] <stustev1> the cinci is the same - I calculate a new offset for each rotary axis move
[18:39:22] <jmkasunich> I'm not sure I understand what you mean by "offset"
[18:39:28] <stustev1> on a hexapod it is physically impossible to move just one joint?
[18:39:44] <jmkasunich> no, you can move one joint
[18:40:08] <jmkasunich> it just results in a complex combined move of the tool - in general, all three linear and all three angular coords will change
[18:40:29] <stustev1> offset is the calculated adjustment between the joint and position command
[18:41:21] <stustev1> motion of one actuator on a hexapod will result in motion of every joint?
[18:41:42] <jmkasunich> the motion of one actuator = the motion of one joint
[18:42:07] <stustev1> the angle of every joint is thus changed
[18:42:09] <jmkasunich> and that will move the tool-carrying platform in space, changing its XYZ coordinates and its pitch/roll/yaw
[18:42:22] <jmkasunich> all 6 joints on a hexapod are lengths
[18:42:42] <jmkasunich> (I'm using joint in the technical EMC sense here - something that can be moved with a motor)
[18:43:05] <jmkasunich> if you mean joints as in the pivots at both ends of each link, then yes, they will all pivot too
[18:43:26] <stustev1> if you have a rigid platform with 6 joints connected is it not physically impossible to move one joint by itself?
[18:43:33] <jmkasunich> nope
[18:44:03] <jmkasunich> 6 joints, 6 degrees of freedom - as long as you aren't at a singularity, it can move
[18:44:41] <jmkasunich> the movement almost certainly won't be something that a human can predict
[18:45:33] <jmkasunich> "lemme see, if I lengthen this leg, the tool tip is gonna move thataway, and the platform is going to tip along a north-northwest axis, and rotate 12 degrees around the spindle centerline"
[18:45:59] <anonimasu> :)
[18:46:52] <stustev1> the hexapod has six legs - two each on three points?
[18:47:03] <jmkasunich> yes
[18:47:10] <stustev1> ok
[18:47:53] <stustev1> the position calculation (inv and for) need to result in exactly the same answer
[18:48:28] <stustev1> why cannot this answer be derived and then applied in opposite fashion to inv and for?
[18:50:22] <stustev1> this must be needed as the forward calculations are not called when joint motion is done and viceversa
[18:54:05] <alex_joni> stustev1: there are cases for a hexapod where certain movement can damage itself
[18:54:23] <alex_joni> if you have 5 fixed joints, and move the 6th chances are bad things happen
[18:54:31] <stustev1> hell - I've seen that on a 3 axis mill
[18:54:40] <alex_joni> (that is not true for a serial linked kin)
[18:55:07] <stustev1> I understand you meant the kins :)
[18:55:20] <alex_joni> yeah :)
[18:55:33] <alex_joni> also.. for hexapods there are more complex calculations involved
[18:56:00] <skunkworks> more then one solution
[18:56:03] <alex_joni> sometimes they can lead to more than one solution
[18:56:08] <skunkworks> heh
[18:56:20] <alex_joni> (was answering the phone in the mean time :D)
[18:56:22] <stustev1> yes - but the calculations need to result in the same answer for the inv and for kins
[18:56:35] <alex_joni> stustev1: pretty much
[18:56:46] <alex_joni> although the starting data is different for inv and forward
[18:56:54] <stustev1> I see two solutions when I am calculating my angle adjustment adn approach 90 degrees
[18:57:18] <stustev1> yes the starting data is different but it is the inverse of each other
[18:57:27] <alex_joni> right
[18:57:50] <alex_joni> usually it gets coded as the inverse function
[18:58:06] <stustev1> but why does it need to be?
[18:59:23] <stustev1> if the inverse answer is the 'inverse' of the forward answer then you should be able to calculate once and apply one as calculated and one as a negative of the calculated
[19:00:42] <jmkasunich> sorry, was on the phone
[19:00:47] <stustev1> when in auto/mdi does the forward kins get calculated and when in manual does the inverse kins get calculated
[19:00:50] <stustev1> :
[19:00:52] <stustev1> ?
[19:00:54] <stustev1> ugh
[19:01:19] <alex_joni> stustev1: there are a lot of mathematicl functions out there that don't have a clear inverse function
[19:01:46] <alex_joni> and I don't see how you can calculate the inverse automagically anyways
[19:01:54] <stustev1> by inverse I mean just to negate the magnitude
[19:02:10] <jmkasunich> stustev1: something like that - I always get the forward and inverse mixed
[19:02:11] <alex_joni> negate the magnitude?
[19:02:11] <jmkasunich> up
[19:02:28] <jmkasunich> definitely not that simple for a hexapod
[19:02:59] <jmkasunich> for a hexapod, if you know the platform and base positions in space, it isn't complicated to calculate the leg lengths
[19:03:04] <alex_joni> a simple invert might work for a linear function (or set of functions)
[19:03:24] <jmkasunich> but if you know the leg lengths and want the positions, that is much more complex - multple answers, etc
[19:03:46] <alex_joni> jmkasunich: I think you got that reversed
[19:03:48] <stustev1> yes - if my forward kins says to adjust the joint positions by x y z a b then -x -y -z -a -b should give me the inverse
[19:04:12] <alex_joni> stustev1: you mean dx, dy, dz, da, db, dc
[19:04:16] <stustev1> yes
[19:04:34] <alex_joni> I don't think that's correct
[19:04:40] <jmkasunich> alex_joni: I disagree - if I know the positions in space of the base and tool platform, I also know the positions in space of both ends of each leg
[19:04:52] <jmkasunich> hypot() tells me the length of the leg
[19:04:55] <jmkasunich> simple and closed form
[19:05:08] <alex_joni> you have a point ;)
[19:05:14] <alex_joni> * alex_joni keeps thinking serial link :D
[19:05:30] <alex_joni> on a puma it's way easier to go from joint to world than the other way around
[19:05:37] <jmkasunich> yeah
[19:06:21] <alex_joni> stustev1: I think what you are saying is that given an initial joint set (j10, j20, j30, j40, j50) and a next joint set (j11, j21, j31, j41, j51)
[19:06:38] <alex_joni> you can remember the change between j10 and j11, j20 and j21 , etc
[19:06:51] <alex_joni> then if that change caused some dx, dy, dz, da, db, dc
[19:07:22] <alex_joni> you can go from (j11, j21, j31, j41, j51) to (j10, j20, j30, j40, j50) by applying -dx, -dy, -dz, -da, -db
[19:07:47] <alex_joni> * alex_joni wonders if he made much sense
[19:07:50] <stustev1> not from a joint position to a joint position
[19:08:32] <alex_joni> (it should work the same way for X1,Y1,Z1,A1,B1 to X2,Y2,Z2,A2,B2 -> causing dj0, dj1, ..)
[19:08:54] <alex_joni> I mean, a change in the input causing a determined change of the output
[19:09:03] <stustev1> I am talking about the difference between an axis position and a joint position of a non trivial machine.
[19:09:15] <alex_joni> then if you have the reverse change in the input, you can probably apply the change of the output reversed
[19:09:41] <stustev1> wow :)
[19:10:02] <alex_joni> but I think that's unlikely to happen in practice, so you won't benefit from it
[19:11:21] <stustev1> on my cinci I calculate a joint position for an axis position to compensate for machine geometry inaccuracies
[19:11:32] <alex_joni> right
[19:11:40] <jmkasunich> hmm
[19:11:47] <alex_joni> err.. the other way around
[19:11:52] <jmkasunich> are we talking about general kins, or geometry correction?
[19:12:03] <jmkasunich> the latter problem is much simpler
[19:12:07] <stustev1> geometry correction
[19:12:16] <jmkasunich> I didn't realize that
[19:12:35] <jmkasunich> corrections are much simpler, because the deviations from ideal are small (we hope)
[19:12:47] <alex_joni> well the way this gets implemented in emc2 atm, is using kins.. so that might cause the miscommunication
[19:12:53] <jmkasunich> you don't have joints where there is a 30 degree difference between what you want and what you get
[19:12:59] <stustev1> smaller magnitude does not make simpler
[19:13:15] <jmkasunich> stustev1: actually, it can
[19:13:56] <jmkasunich> for example, for small angles, sin(theta) is approximately the same as theta (in radians)
[19:14:03] <stustev1> yes - as I approach 90 degrees with my rotary axes the calculation gets more problematic
[19:15:10] <jmkasunich> I was thinking of very small, like the angle between X and Y is 90.003 degrees instead of 90.000000 degrees
[19:15:24] <stustev1> that is exactly what I have
[19:15:26] <alex_joni> I think that's the easier stuff
[19:15:43] <alex_joni> the more problematic stuff is if rotating A causes XY to move by whatever
[19:16:06] <alex_joni> or C
[19:16:25] <stustev1> I have a small parallelism problem between the A and X axes - ditto B and Y
[19:16:49] <stustev1> I have orthogonal problems between X Y and Z
[19:17:02] <alex_joni> stustev1: that's why I love robots :D
[19:17:09] <alex_joni> they only care about repeatability
[19:17:15] <stustev1> I have the calculations done to do handle this
[19:17:17] <alex_joni> precision means squat :)
[19:17:47] <stustev1> I am trying to understand why I need to do inv and for calculations
[19:18:29] <jmkasunich> if the offsets are small, you probably can just subtract them for the inverse
[19:18:59] <stustev1> they will be each and all be small
[19:21:04] <stustev1> I can do a forward and inverse calculation - it is the same calculation until the very end - then I take the joint or axis position and finish the calculation
[19:21:12] <jmkasunich> let me try to put into words why you can reverse for small corrections, but not for general kins
[19:21:21] <stustev1> od
[19:21:23] <stustev1> ok
[19:21:31] <jmkasunich> let X, Y, Z, etc be cartesean coords
[19:21:36] <jmkasunich> x, y, z are joint coords
[19:21:55] <jmkasunich> forward takes XYZ, gives xyz
[19:22:02] <jmkasunich> inverse takes xyz, gives XYZ
[19:22:32] <jmkasunich> in general kins, xyz may be wildly different than XYZ (thats why we call them j0, j1, etc, so it isn;t confusing)
[19:22:57] <jmkasunich> if xys is wildly different than XYZ, then correction(xyz) is unlikely to be close to correction(XYZ)
[19:23:17] <jmkasunich> but if the difference between xyz and XYZ is _only_ a correction, it is small
[19:23:43] <jmkasunich> the correction also probably doesn't change radically over a small distance
[19:24:04] <jmkasunich> so xyz = XYZ + correction(XYZ)
[19:24:28] <jmkasunich> and XYZ = xyz - correction(XYZ), approximately
[19:24:39] <stustev1> why not exactly
[19:24:52] <jmkasunich> XYZ = xyz - correction(xyz) exactly
[19:25:16] <jmkasunich> duh, I screwed that up
[19:25:29] <jmkasunich> I'm a great explainer ain't I
[19:25:42] <jmkasunich> XYZ = xyz - correction(XYZ), exactly
[19:25:50] <stustev1> yes
[19:25:59] <jmkasunich> the problem is, you don't know XYZ in that case, so you can't calc correction
[19:26:24] <jmkasunich> XYZ = xyz - correction(xyz) approximately, and you can calculate that
[19:26:41] <alex_joni> hmm.. would xyz be closer than last_XYZ ?
[19:27:03] <alex_joni> (assuming one would remember the last values)
[19:27:04] <jmkasunich> depends on how fast you are moving, vs. how big the errors are
[19:27:18] <stustev1> it is not a matter of geometry - it is a matter of how and when it is calculated in the kins
[19:27:19] <alex_joni> hmm.. might be for angles
[19:27:35] <jmkasunich> if the difference between XYZ and xyz is only a few 0.001, but you are moving at 0.01 per servo period, then
[19:28:13] <alex_joni> gotcha
[19:33:40] <stustev1> thanks guys
[19:40:02] <toastatw1rk> toastatw1rk is now known as toastatwork
[19:49:48] <cradek> I agree with jmk - calculate the offset the same way. your forward and reverse won't QUITE match but it will be close enough.
[20:17:31] <stustev1> cradek: why would they not match? if they will not match I want to do them in a way that matches - bbiam
[20:23:02] <cradek> at position P you calculate the correction C(P) (call the result dP) and apply it to get P+dP. To go the other way, you only have P+dP so you can't calculate C(P) anymore to get (P+dP)-dP = P which would be ideal. But you can get C(P+dP) which will be extremely close to C(P). So when you go full circle you get P + C(P) - C(P+C(P)) which is not quite P but very close.
[20:26:54] <cradek> the assumption is that (1) the correction is small, so (2) pre-correction and post-correction positions are close. (3) correction for close positions are similar, so (4) the similar corrections will cancel each other pretty well
[20:32:52] <jepler> for instance, consider the 'correction' is for a screw that's 1% off its nominal TPI (just because it's a very simple function)
[20:32:55] <jepler> >>> def C(P): return .01*P
[20:33:02] <jepler> performing the correction:
[20:33:02] <jepler> >>> 2.0 + C(2.0)
[20:33:02] <jepler> 2.02
[20:33:12] <jepler> performing the "uncorrection":
[20:33:13] <jepler> >>> 2.02 - C(2.02)
[20:33:13] <jepler> 1.9998
[20:34:22] <cradek> thanks for reasurring me that I made some sense
[20:34:30] <cradek> reassuring?
[20:34:32] <cradek> reassurrinng
[20:34:55] <archivist> I hope your floats and maths are better than .0002
[20:35:28] <cradek> in your example, can you write un-C?
[20:36:02] <jepler> >>> def unC(P): return .01*P/1.01
[20:36:06] <jepler> >>> 2.02 - unC(2.02)
[20:36:06] <jepler> 2.0
[20:36:23] <cradek> aha
[20:36:52] <cradek> but for stuart, unC might be hard to write
[20:37:20] <jepler> archivist: surprisingly enough, all the results I got seem to be exactly what you'd get from infinite-precision arithmetic. It happens so seldom with computers...
[20:38:10] <stustev1> studying
[20:38:15] <archivist> Ive been well bitten by computer maths in the past as well
[20:38:19] <cradek> brb
[20:38:55] <archivist> pink noise filter calculations are fun
[20:43:14] <skunkworks> jepler:
http://www.cnczone.com/forums/showthread.php?t=69951
[20:43:40] <skunkworks> I know you said it may be possible but would require tweeking of the code..
[20:43:53] <cradek> yargh
[20:44:07] <cradek> someone other than me bought two of those!?
[20:44:07] <skunkworks> yargh? :)
[20:44:23] <skunkworks> oh - whatever - Yours is working great too. :)
[20:44:31] <skunkworks> yours is?
[20:44:44] <jepler> skunkworks: it's not supported.
[20:44:49] <skunkworks> that should be a yargh
[20:44:55] <skunkworks> Ok.
[20:45:40] <jepler> http://linuxcnc.org/docs/html/hal_drivers.html#r1_8_6
[20:45:49] <jepler> At present, only a single pluto_servo or pluto_step board is supported. At present there is no provision for multiple boards on one parallel port (because all boards reside at the same EPP address) but supporting one board per parallel port should be possible.
[20:45:53] <jepler> </docs>
[20:46:06] <jepler> however, I have no plans to work on supporting more than one parallel port for the pluto driver.
[20:46:26] <skunkworks> Thanks - that works
[20:49:00] <skunkworks> more than one 7I43 should be possible - right?
[20:49:19] <skunkworks> (on separate printer ports)
[20:49:29] <jepler> I'd ask seb_kuzminsky that
[20:49:59] <jepler> the other caveat is that the popular PCI parport chipset (netmos) is apparently broken in epp mode, and doesn't work with 7i43
[20:50:39] <cradek> I wonder if that's also why the pluto doesn't work on half the machines we try
[20:51:18] <skunkworks> seb_kuzminsky: can more than one 7I43 be run on a single computer?
[20:51:27] <skunkworks> jepler: I read that. Yeck.
[20:52:21] <archivist> * archivist rapidly checked his chip part numbers and have a slightly different number
[20:53:25] <jepler> a "better" method for reverse correction as long as you can afford to compute C(P) twice:
http://emergent.unpy.net/files/sandbox/corr.py
[20:54:54] <jepler> changes the relative error from .0001 to .000001
[20:54:57] <jepler> in the simple test case
[20:55:20] <cradek> now that's a pretty interesting idea.
[20:56:11] <jepler> I'm certain it's not original
[20:56:27] <jepler> I'm also certain I lack the skill to actually prove it's better under the assumptions you laid out about C(P)
[20:56:58] <cradek> my gut says it's better, but that's probably the best I can do
[20:57:53] <jmkasunich> the 1% error jepler used in his example is pretty severe, because it accumulates
[20:58:28] <jmkasunich> 1% is 1/8" per foot
[20:58:48] <jmkasunich> which is about 10 times worse than a crappy acme screw, and probably 50 times worse than a medium ballscrew
[20:58:54] <skunkworks> http://www.cnczone.com/forums/showthread.php?t=69951
[20:58:55] <cradek> stuart should be able to quantify the error and I bet he will find it's plenty small
[20:59:08] <seb_kuzminsky> skunkworks: up to 4 7i43's should be supported, though i haven't tested that
[20:59:26] <seb_kuzminsky> no netmos parport chips will work, so be careful buying your pci parport cards
[20:59:31] <jepler> jmkasunich: yes, I couldn't come up with an example that was simple, had a good motivation, and that I thought I could explicitly write the inverse function
[21:00:18] <skunkworks> http://www.cnczone.com/forums/showthread.php?p=539869#post539869
[21:02:20] <jepler> def C(P): return sin(.01*P)
[21:02:24] <jepler> Simple: 9.99731e-05
[21:02:25] <jepler> Better: 9.99531e-07
[21:02:32] <archivist> cards I bought have the moschip 9815
[21:02:46] <skunkworks> THey just don't work in EPP mode.
[21:03:07] <archivist> note the different part number
[21:03:08] <skunkworks> (needed for pluto and 7i43)
[21:03:09] <jepler> for a periodic error function that changes slowly, I get similar magnitude results
[21:03:22] <skunkworks> and jonE's stuff
[21:03:25] <archivist> not 9805
[21:03:37] <skunkworks> oh - didn't read that close.
[21:03:39] <skunkworks> :)
[21:03:40] <archivist> have 9815 been tested as well
[21:03:45] <cradek> jepler: those errors will change depending on P won't they?
[21:04:49] <jmkasunich> I think the error will be C(P) * dC(P/dP)
[21:04:55] <jepler> cradek: yes, the error isn't the same for all P
[21:05:06] <jmkasunich> pardon my notation
[21:05:26] <seb_kuzminsky> archivist, skunkworks: the 9815 hasnt been explicitly tested, but the NetMos/MosChip FAQ said their EPP bug affects all the 98XX chips
[21:05:28] <cradek> but 'better' is still always better
[21:05:39] <jepler> cradek: at each value I tested, yes
[21:06:01] <jmkasunich> if the example error is 10x bigger than the real error, the residual is likely to be 100x as big as real
[21:06:15] <jmkasunich> and the "need" for doing the more complex calc overstated by 100x
[21:06:48] <jepler> jmkasunich: yes
[21:07:44] <skunkworks> seb_kuzminsky: thanks
[21:08:42] <archivist> took me months to find any parport cards in the uk and thats what I have :(
[21:09:32] <cradek> if you don't need EPP, they're fine
[21:09:41] <cradek> lots of people are using them
[21:10:15] <archivist> was hoping to get mesa cards eventually
[21:10:19] <skunkworks> (like if you wanted to use the pluto, 7i47, or picosystems stuff.)
[21:11:01] <skunkworks> ah. what would be cheaper - finding a new printer port card or getting the mesa pci card?
[21:11:02] <cradek> I like my mesa card... it just works
[21:11:21] <anonimasu> haha :) good point cradek
[21:11:36] <cradek> and lots of thanks to seb for that too
[21:13:42] <skunkworks> here! here!
[21:13:54] <skunkworks> Hear! Hear!?
[21:56:57] <skunkworks> The only problem I see going from eagle on ubuntu to eagle on xp is it sets the units to mm every time. Even though in ubuntu it is set to IN.
[21:56:59] <skunkworks> wierd
