#emc-devel | Logs for 2007-03-10

[00:29:09] <jmkasunich> hi guys
[00:29:36] <SWPLinux> cradek: no problem - no offense taken
[00:29:38] <SWPLinux> hi jmkasunich
[00:30:01] <jmkasunich> disable feedhold disable.... has a nice ring to it ;-)
[00:30:02] <jmkasunich> not
[00:30:24] <SWPLinux> I prefer enable feedhold disable disabling
[00:30:34] <jmkasunich> how about motion.inhibit
[00:30:45] <SWPLinux> hey -that could work ;)
[00:31:14] <jmkasunich> ray gave me the idea with the inhibit ring
[00:32:15] <jmkasunich> it would default to false (not inhibited), so people who don't need it can ignore it
[00:32:24] <jmkasunich> it wouldn't interact with anything else
[00:32:30] <jmkasunich> it just makes things stop
[00:32:39] <SWPLinux> wouldn't that be !motion.enable?
[00:33:02] <jmkasunich> motion.enable is an output, used to turn on servo amps, PID loops, etc
[00:33:12] <jmkasunich> I believe it toggles with "machine on"
[00:33:27] <SWPLinux> hmmm - I must be confusing the meaning of HAL_IN
[00:33:38] <jmkasunich> and it would/should stay on during an inhibit - you want the amps and PID to remain active, you just don't wnat to move
[00:33:47] <SWPLinux> if ((retval = hal_pin_bit_newf(HAL_IN, &(emcmot_hal_data->enable), mot_comp_id, "motion.enable")) != HAL_SUCCESS) goto error;
[00:33:49] <jmkasunich> or I might be confused
[00:34:00] <SWPLinux> same as the feedhold poin
[00:34:04] <jmkasunich> looks like I'm confused
[00:34:05] <jmkasunich> sorry
[00:34:12] <jmkasunich> maybe I'm thinking of axis.enable as the output
[00:34:16] <SWPLinux> phew! ;)
[00:34:20] <SWPLinux> rigth
[00:34:20] <jmkasunich> damned if I know what motion-enable does
[00:34:22] <SWPLinux> right
[00:34:28] <jmkasunich> maybe it does what we want already?
[00:34:41] <SWPLinux> it has the right name. I'll check
[00:34:56] <jmkasunich> I worked on those hal manpages before the 2.1 release, but I didn't do one for motmod ;-(
[00:35:06] <jmkasunich> every pin should be documented
[00:35:13] <SWPLinux> yeah.
[00:35:43] <SWPLinux> actually, I found the old NIST site (still there, just _emc instead of emc in the name) - they had very good docs on all ini parameters and that kind of stuff
[00:36:09] <SWPLinux> I also found the NIST mail archive from around 1999 to 2003 (when it was shut down)
[00:36:31] <SWPLinux> hmmm - from the release of emc1.17 at least
[00:37:15] <SWPLinux> interesting - I did "halcmd setp motion.enable false" and got a dialog box from axis:
[00:37:25] <SWPLinux> "motion stopped by enable input"
[00:38:45] <SWPLinux> and now all the run-related buttons don't work
[00:39:04] <jmkasunich> well I wonder why thats there?
[00:39:16] <jmkasunich> unless it was supposed to be part of an estop chain
[00:39:21] <SWPLinux> even after reenabling motion, and reloading the file, and loading a different file
[00:39:26] <SWPLinux> dunno
[00:39:33] <SWPLinux> ah - duh
[00:39:38] <jmkasunich> what is the machine on and estop state?
[00:39:40] <SWPLinux> axis sets machine off (or motion does)
[00:39:51] <SWPLinux> right - it went to machine off
[00:40:00] <SWPLinux> it's a stop input, not a pause input
[00:40:06] <jmkasunich> so I was half right: enable was related to machine on/off ;-)
[00:40:14] <SWPLinux> heh
[00:41:10] <SWPLinux> yep - it's just a machine off input - you can't go to machine on when that input is false
[00:41:22] <SWPLinux> and it sets machine off
[00:42:21] <SWPLinux> ok - so what this tells me is that we need more of the functions provided by NML to be duplicated by HAL pins
[00:42:32] <SWPLinux> like pause, single step, etc.
[00:42:57] <SWPLinux> (actually, NML may be a red herring - I toned down my original thought but not enough to eliminate NML from what I wrote ;) )
[00:44:17] <jmkasunich> we need to think hard before we duplicate everything
[00:44:29] <jmkasunich> somehow that just doesn't seem right
[00:44:41] <SWPLinux> I agree
[00:45:37] <SWPLinux> it's certainly possible to have a HAL component that deals with some machine logic (like ladder or whatever), which talks to something like halui, which then sends NML messages to do things (though that's already duplication, since halui needs all those functions)
[00:45:49] <SWPLinux> in fact, it's already there, in halui
[00:45:58] <SWPLinux> just not RT
[00:46:57] <jmkasunich> this is getting hairy
[00:47:10] <SWPLinux> you could say that
[00:47:32] <jmkasunich> the other thought that flitted briefly across my mind was some sort of machine logic layer between NML and the motion controller
[00:47:41] <jmkasunich> so it can intercept commands, etc
[00:48:05] <SWPLinux> yeah. I'm not sure it makes sense to have the system stop when the motion controller gets stopped (paused)
[00:48:26] <SWPLinux> an external "system logic" component could decide when to pause motion
[00:48:45] <SWPLinux> right now "motmod" is the RT part of EMC though, right?
[00:49:11] <SWPLinux> (in other words, the stuff that makes all the HAL pieces and the UI and stuff into the unit known as EMC)
[01:11:28] <jmkasunich> motmod is a really big and complicated HAL component ;-)
[01:11:34] <jmkasunich> that just happens to listen to commands from task
[01:11:37] <SWPLinux> yeah
[01:11:57] <SWPLinux> motmod is doing double duty - it deals with task, and it does motion
[01:12:05] <SWPLinux> and some I/O
[01:12:08] <jmkasunich> it does motion as commanded by task
[01:12:10] <SWPLinux> right
[01:12:11] <jmkasunich> and some I/O ;-)
[01:12:15] <SWPLinux> heh
[01:12:40] <SWPLinux> but task has commands for non-motion things, like spindle and coolant
[01:12:47] <SWPLinux> (?)
[01:13:12] <jmkasunich> task doesn't have commands for anything
[01:13:15] <jmkasunich> task issues commands
[01:13:32] <jmkasunich> canon executes them (of course, canon is executing as part of the task process)
[01:13:40] <SWPLinux> ok - "task issues commands for things other than motion" ...
[01:13:48] <jmkasunich> oh, I dunno
[01:14:08] <SWPLinux> but they all get sent through the motion module, I think (anything that deals with RT/hardware anyway)
[01:14:17] <jmkasunich> its all a big mishmash, and then somehow emcmot_foo commands wind up i shared memory, and then I start to care
[01:14:21] <SWPLinux> heh
[01:14:33] <SWPLinux> step 2: then a miracle occurs ...
[01:15:32] <jmkasunich> nah, the miracle happens, the a command appears and motmod does some non-miracalous things with it
[01:16:02] <SWPLinux> right: step 1: a user command is input to task. step 2: miracle. step 3: HAL has work to do ;)
[01:16:25] <SWPLinux> stepn -INF through 0 are unimportant ;)
[01:17:44] <jmkasunich> wtf was matt thinking... posting a 5000x12000 pixel image
[01:17:47] <SWPLinux> damn. what was the name of that software I just installed
[01:17:49] <jmkasunich> firefox about had a stroke
[01:17:51] <SWPLinux> heh
[01:17:59] <SWPLinux> I got a big black box
[01:18:04] <SWPLinux> on MOzilla/Windows
[01:18:12] <SWPLinux> could you paste the URL here?
[01:18:43] <jmkasunich> http://www.mattshaver.com/diag/index-by-size.html
[01:18:45] <SWPLinux> I suspect ht'll pay when his bandwidth cap is reached ;)
[01:18:45] <jmkasunich> first one
[01:18:45] <SWPLinux> thanks
[01:19:14] <SWPLinux> oh - I couldn't even load that one - got an error. the second came up all black
[01:19:17] <SWPLinux> (on Win)
[01:19:29] <jmkasunich> I gotta try to see if I can figure out ed's stepgen issue
[01:19:43] <jmkasunich> he provides such nice bug reports, I really want to help him ;-)
[01:19:45] <SWPLinux> I noticed the xor2 component, just before I got his email ;)
[01:19:49] <SWPLinux> heh
[01:20:00] <SWPLinux> tha tis a large image
[01:21:36] <SWPLinux> some funny lines in emccanon.cc.egypt.png
[01:22:04] <SWPLinux> I think maybe he should have used that diagramming software I found before (and can't remember the name of_
[01:22:04] <SWPLinux> )
[01:22:40] <SWPLinux> graphviz
[01:34:07] <cradek> g'evening guys
[01:34:16] <SWPLinux> hiya
[01:34:26] <jmkasunich> hi
[01:34:31] <cradek> jepler convinced me ray is right about that exit move
[01:34:35] <cradek> well partly :-)
[01:34:46] <SWPLinux> you mean that it doesn't matter? :)
[01:34:47] <cradek> if you don't want to gouge the part, move away from it before you turn off comp
[01:34:49] <SWPLinux> heh
[01:35:01] <cradek> and I'd just like to say "duh" to that
[01:35:08] <cradek> (the arc is still broken though)
[01:37:05] <SWPLinux> there's got to be some way of using the existing arc comp functions to get the right exit arc
[01:37:13] <SWPLinux> I'm just not sure if it's more pain than it's worth
[01:37:35] <SWPLinux> (I meant the entry functions - you know, backwards)
[01:38:23] <cradek> well it's only about 5 lines of code - the exit would be the same
[01:38:48] <SWPLinux> right - just the decisions about addition and subtraction are for the most part opposite
[01:38:58] <cradek> also, you have to keep a little more state to realize this is the first move after turning off comp
[01:39:58] <cradek> comp-off would have to set that state, line and arc would clear it after any special handling
[01:41:22] <SWPLinux> how does comp-on determine that it's the entry move?
[01:41:38] <cradek> some state fiddling like that
[01:41:47] <SWPLinux> oh, so the same thing backeards then ;)
[01:41:51] <SWPLinux> backwards
[01:41:54] <cradek> clever
[01:42:14] <cradek> let me look at that
[01:42:36] <cradek> first = (settings->program_x == UNKNOWN);
[01:42:41] <cradek> * cradek winces
[01:42:59] <cradek> #define UNKNOWN 1e-20
[01:44:20] <SWPLinux> ?
[01:44:39] <cradek> one of the doubles serves as a boolean using a special number
[01:44:49] <SWPLinux> oh, great ;)
[01:44:52] <cradek> I'm going to change that first, it's terrible
[01:57:33] <cradek> hmm I borked it
[01:57:37] <cradek> (yay regression tests)
[02:14:12] <SWPadnos> I wonder if 1E-20 is an exact binary fraction
[02:16:01] <cradek> that seems unlikely since it's a power of 10?
[02:16:18] <SWPadnos> yes, it does seem unlikely
[02:21:16] <cradek> did you look at/follow the math (in that comment) for the entry arc fix?
[02:22:38] <cradek> I'd like it to be understandable - if it's not, I'll fix it
[02:23:00] <cradek> for instance someone should be able to build on that work to fix the exit arc
[02:24:17] <SWPadnos> I'll read it again and see if I frok it
[02:24:21] <SWPadnos> grok
[02:24:25] <cradek> thank you
[02:24:42] <cradek> my intent is that it would let you draw the same picture I drew
[02:24:50] <SWPadnos> sure. though my non-understanding shouldn't be taken as an indication that the comment (or the code) sucks ;)
[02:25:39] <cradek> well I doubt you were the slow one in grade school.
[02:25:59] <SWPLinux> hmmm. you had mentioned a time zone fix - I only see it on my edgy machine, not dapper
[02:26:03] <SWPLinux> heh - thanks :)
[02:26:23] <cradek> I got it the other day on dapper
[02:26:31] <SWPLinux> is it called tzdata?
[02:26:41] <cradek> no, locale-something I think
[02:26:43] <SWPLinux> ok
[02:28:37] <SWPLinux> ah - locales
[02:28:47] <cradek> $ zdump -v /etc/localtime|grep 2007
[02:28:47] <cradek> /etc/localtime Sun Mar 11 07:59:59 2007 UTC = Sun Mar 11 01:59:59 2007 CST isdst=0 gmtoff=-21600
[02:28:52] <cradek> /etc/localtime Sun Mar 11 08:00:00 2007 UTC = Sun Mar 11 03:00:00 2007 CDT isdst=1 gmtoff=-18000
[02:29:04] <cradek> ^^ to verify
[02:29:11] <SWPLinux> cool - thanks
[02:29:35] <SWPLinux> yeppers - that's the one
[02:31:33] <SWPLinux> so - are all the comments for the big functions in interp_arc.cc under scrutiny, or is it one or more of the callers in interp_convert?
[02:32:20] <cradek> mostly I was concerned about the one in convert_arc_comp1 (starting with "imagine a right triangle")
[02:32:37] <cradek> that explains the arc translation and should allow an interested person to fix the exit arc
[02:34:21] <SWPLinux> I don't have the word triangle in interp_convert.cc
[02:34:40] <cradek> you must not be updated
[02:34:51] <SWPLinux> I just did, about 3 minutes ago
[02:35:00] <SWPLinux> maybe I had editid that file - let me do it again
[02:35:05] <SWPLinux> edited
[02:35:07] <cradek> line 406
[02:35:20] <SWPLinux> nope
[02:35:29] <SWPLinux> what should the version be?
[02:35:33] <cradek> * $Revision: 1.65 $
[02:35:32] <cradek> * $Author: cradek $
[02:35:32] <cradek> * $Date: 2007/03/10 02:19:49 $
[02:35:36] <SWPLinux> argh
[02:36:13] <SWPLinux> P means protected, right? (in an update)
[02:36:19] <cradek> patched
[02:36:21] <SWPLinux> hmm
[02:36:57] <SWPLinux> ok - that is odd then. I just updated, interp_convert.cc is marked P, and I have version 1.58
[02:37:25] <jmkasunich> more odd: I just created a g-code file with about 80 reps of "G0 Z0.1 G0 Z0"
[02:37:37] <jmkasunich> when I opened it in axis, it said "no % at end"
[02:37:41] <jmkasunich> so I added one
[02:37:45] <cradek> SWPLinux: cvs stat interp_convert.cc
[02:37:46] <jmkasunich> now it says "bad character"
[02:37:55] <SWPLinux> use M2 :)
[02:38:11] <cradek> you have to have M2/M30 or matching % signs (start and end)
[02:38:17] <jmkasunich> ok
[02:38:22] <SWPLinux> the error is bogus then
[02:38:24] <cradek> it's a little mean of it to insult your character though
[02:38:32] <SWPLinux> heh
[02:38:34] <jmkasunich> pretty pathetic that I work on a CNC control and don't know basic g-code
[02:38:40] <cradek> just because you didn't memorize the whole ngc spec
[02:39:04] <cradek> jmkasunich: more humorous than pathetic, I think
[02:39:08] <jmkasunich> it actually said "bad character used" so I didn't take it personally
[02:39:13] <cradek> ah
[02:39:32] <SWPLinux> ok - I had a Kate error
[02:39:38] <SWPLinux> very odd
[02:42:15] <SWPLinux> it should have said "bad character used an extra % character"
[02:42:18] <SWPLinux> :)
[02:42:35] <jmkasunich> hmm
[02:42:57] <jmkasunich> I seem to recall somebody reporting a completely different error message (the realtime one) that was also truncated
[02:43:07] <jmkasunich> dunni if there is any connection
[02:43:27] <SWPLinux> I was joking about the character of the user ;)
[02:43:51] <jmkasunich> * jmkasunich ducks as joke hurtles overhead
[02:43:53] <SWPLinux> heh
[02:56:50] <SWPLinux> cradek: I don't think I understand the phrase "A_ang is the angle of the triangle itself"
[02:57:27] <SWPLinux> AB_ang is the angle from A to B with the center as the vertex (if I understand correctly)
[02:58:00] <cradek> A is the triangle's angle
[02:58:31] <cradek> AB is the direction of the AB vector in the world
[02:58:31] <SWPLinux> do you mean the angle of arc for the compensated move?
[02:59:03] <SWPLinux> ok - then maybe it's the phrase "AB_ang is the direction of A->B"
[02:59:22] <SWPLinux> that I don't get (or they're redundant comments or something)
[02:59:34] <cradek> ok (please fix!)
[02:59:53] <cradek> should probably have said 'the vector AB' since I can't put the arrow over it
[03:00:00] <SWPLinux> but I don;t understand ;)
[03:00:49] <SWPLinux> ah- duh - I just realized what I screwed up
[03:00:49] <cradek> ok, thanks for the sanity check
[03:00:57] <cradek> it really needs an image
[03:01:03] <SWPLinux> B is the *center* of the arc, not the midpoint of the arc
[03:01:16] <cradek> (I've been known to stick an image in the source directory for documentation)
[03:01:44] <SWPLinux> hmm. I was looking at it differently every time I looked at it, I think ;)
[03:02:01] <SWPLinux> A is the endpoint, offset however it needs to be for comp purposes
[03:02:21] <SWPLinux> B is the centerpoint, C is the midpoint of the chord across the compensated arc
[03:02:27] <SWPLinux> ?
[03:03:10] <SWPLinux> ok - you're doing exactly what we had in the diagram I made (and jmk improved)
[03:03:31] <cradek> ah!
[03:03:42] <cradek> i.e. keep looking until you find a right triangle in there somewhere?
[03:04:14] <SWPLinux> the right triangle falls out of it
[03:04:21] <cradek> fwiw I looked up the law of sines/cosines before I found the easy way
[03:04:25] <SWPLinux> heh
[03:04:41] <SWPLinux> actually, I'm not sure if your way or jmk's way is easier ;)
[03:05:07] <cradek> depends whether you think an equation 10 lines by 80 columns wide is easy
[03:05:14] <SWPLinux> heh
[03:05:26] <jmkasunich> what equation is that?
[03:05:41] <jmkasunich> my stuff had nice short expressions
[03:05:44] <cradek> in your email?
[03:05:52] <cradek> oh
[03:05:57] <SWPLinux> that was the derivation. the equations are only about 8 lines long, and not 80 columns
[03:06:04] <cradek> :-)
[03:06:05] <jmkasunich> the derivation is long, but the resulting formulas werent
[03:06:14] <SWPLinux> and it's all algebra, no trig
[03:06:26] <cradek> I only scanned it, regretting that we duplicated work, but continued because I was 90% done
[03:06:28] <jmkasunich> of course, I was using var names like xp3, and you probably have foo->barsgsdk->ssdbgkjl->x
[03:06:39] <SWPLinux> oh yeah - it would be 80 columns then ;)
[03:07:11] <SWPLinux> heh - reminds me of a funny story
[03:07:20] <jmkasunich> one sqrt, 6 divides (by three numbers), the rest is add/sub/mult
[03:07:43] <cradek> that's probably a better solution then
[03:07:58] <cradek> mine has a few hypots and atan2s
[03:08:09] <cradek> please feel free to rewrite it (as long as you do the exit case too!)
[03:08:18] <jmkasunich> thats ok
[03:08:30] <jmkasunich> doing the math is easy
[03:08:33] <jmkasunich> figuring out the code is not
[03:09:02] <SWPLinux> a college professor (calculus 2 or something not too advanced) was asked how many variables he had ever used in a real equation. We expected a number like 6 or 8, maybe 10. He said 63. (!) It would be even funnier if I could remember what in the real world had 63 independent variables.
[03:09:03] <jmkasunich> argh - I hate unreproducable bugs
[03:12:47] <cradek> Need to get 230MB of updates...
[03:13:23] <jmkasunich> fresh install from old CD
[03:13:31] <jmkasunich> or did they release a huge update
[03:13:54] <cradek> yeah, install that has been sitting around for a long time
[03:14:09] <cradek> the mill's on a "new" computer now
[03:15:41] <jmkasunich> * jmkasunich tries running tort.ngc
[03:16:36] <SWPLinux> elephant gun
[03:16:58] <jmkasunich> not holding out much hope
[03:17:20] <cradek> jmkasunich: not getting anything wrong?
[03:17:22] <jmkasunich> nope
[03:17:39] <cradek> he should run exactly the same test and see if he triggers it
[03:17:48] <SWPLinux> <stupid hat> you are using his config, right? </stupid hat>
[03:17:54] <jmkasunich> yes
[03:17:59] <jmkasunich> his hal file, his ini file
[03:18:06] <SWPLinux> this is the test he said triggers it
[03:18:28] <SWPLinux> do we know his computer specs?
[03:18:31] <jmkasunich> actually he didn't say it _does_ trigger it
[03:18:36] <jmkasunich> he said it might
[03:18:45] <jmkasunich> he didn't send me the g-code that triggered it
[03:18:58] <jmkasunich> and in any case, it happened after 20 minutes of g-code
[03:18:58] <SWPadnos> true
[03:19:05] <cradek> yuck
[03:19:16] <SWPLinux> for you, or for him?
[03:19:24] <SWPLinux> (20 minutes)
[03:19:26] <jmkasunich> for him
[03:19:31] <SWPLinux> ok -never for you
[03:19:37] <cradek> tort runs fairly long...
[03:19:50] <SWPLinux> so, do we know his computer specs?
[03:19:54] <jmkasunich> the symptom he's describing (dir pin change state while velocity is not near zero) has never happened for me
[03:19:58] <jmkasunich> no specs
[03:20:00] <SWPLinux> ok
[03:20:11] <jmkasunich> tort is maybe 1/2 done
[03:20:23] <jmkasunich> or less
[03:20:24] <cradek> there may be specs in the previous threads
[03:20:32] <SWPadnos> yep
[03:21:11] <SWPLinux> ok - BASE_PERIOD 20000 seems pretty wide open
[03:21:47] <SWPLinux> I was wondering what happens if the base thread functions are running, and there's another timer interrupt (if they happen to be a bit long one time)
[03:22:08] <jmkasunich> I could see a big latency hit making his motor lose sync
[03:22:23] <jmkasunich> but he's pretty confident that dir actually changed state
[03:22:26] <SWPLinux> does RTAI notice that they're still going and delay executing them again, or does the new interrupt cause a new execution, which then returns and allows the previous one to finish?
[03:23:05] <jmkasunich> I doesn't nest them
[03:23:10] <jmkasunich> its a thread, not an ISR
[03:23:13] <SWPLinux> sure
[03:23:30] <jmkasunich> it runs, then said "I'm going to sleep, wake me when its time to run again"
[03:23:34] <SWPLinux> though the RTAI scheduler should be parlty in the ISR
[03:23:38] <jmkasunich> can't get awakened till it sleeps
[03:23:47] <SWPLinux> ok
[03:24:22] <cradek> tell me if I'm crazy, but I thought when I cranked the base period too tight, I got missed periods (but that would certainly be detected now)
[03:24:28] <SWPLinux> so if the base thread is running when a new interrupt occurs, then that time tick gets lost, since the task is already awake?
[03:24:36] <jmkasunich> if an interrupt appears while its still running, RTAI probably says "I got a timer interrupt, but nobody is waiting on one, so forget it"
[03:24:44] <cradek> ok, yeah that
[03:24:58] <SWPLinux> I'm not sure it's detected/reported
[03:25:10] <jmkasunich> I doubt its detected
[03:25:11] <SWPLinux> the slow thread reports, but the fast ones don't
[03:25:15] <cradek> if nothing else, the check in motion would catch it
[03:25:15] <jmkasunich> right
[03:25:21] <cradek> oh! that's true
[03:25:27] <cradek> eek
[03:25:29] <SWPLinux> that's only for the servo (or traj) thread
[03:26:07] <jmkasunich> I think cradek just realized something about that realtime check
[03:26:24] <SWPLinux> ?
[03:26:29] <jmkasunich> it only catches bad stuff - a few 10s of uS here and there will be un-noticed
[03:26:42] <SWPLinux> and it only looks in the slowest thread
[03:26:47] <cradek> well it could miss dropped base periods.
[03:27:09] <cradek> is he near the limit of his step generation or could he increase the base period?
[03:27:43] <SWPLinux> sorry - gotta paste URLS for myself:
[03:27:51] <jmkasunich> scale 16000, maxvel 0.44 in/sec
[03:27:55] <SWPadnos> http://pastebin.ca/387751 http://pastebin.ca/387755
[03:28:03] <cradek> Fetched 280MB in 6m18s (740kB/s)
[03:28:07] <cradek> Fetched 280MB in 6m18s (740kB/s)
[03:28:12] <cradek> crap, sorry
[03:28:16] <jmkasunich> 7040 steps/sec
[03:28:25] <SWPLinux> that's fast
[03:28:33] <SWPLinux> (the download)
[03:28:33] <cradek> yeah but I didn't mean to paste it
[03:28:38] <SWPLinux> heh
[03:28:50] <cradek> yeah the updates are taking longer to install than to download
[03:29:10] <SWPLinux> funny -I hav ethe opposite problem ;)
[03:29:28] <cradek> you aren't using a PII then
[03:29:34] <jmkasunich> he has steplen = 3 and stepspace = 4
[03:29:35] <SWPLinux> hmmm - nope
[03:29:41] <jmkasunich> so his max rate is low
[03:29:53] <jmkasunich> 7142
[03:30:00] <SWPLinux> and dirsetup and dirhold of 20
[03:30:12] <cradek> those are in periods right?
[03:30:17] <SWPLinux> yes
[03:30:18] <jmkasunich> yep
[03:30:23] <cradek> he could run the thread at 1/4 the speed then?
[03:30:35] <jmkasunich> for 2.2 I want to change them to ns, but...
[03:30:40] <SWPLinux> 1/3 or so, yes
[03:30:42] <jmkasunich> this gives less step jitter
[03:31:03] <SWPLinux> yeah - same size pulse, better granularity
[03:31:24] <jmkasunich> c'mon ed, read your email.....
[03:31:28] <SWPLinux> but 400 uS seems like a lot of dirsetup/dirhold
[03:31:31] <jmkasunich> * jmkasunich paces impatiently
[03:31:44] <SWPLinux> you could read the comment on arc comp :)
[03:31:53] <jmkasunich> his driver is not teh shit ;-)
[03:32:04] <SWPLinux> heh
[03:32:17] <jmkasunich> no, I could not read the comment on arc comp
[03:32:22] <SWPLinux> ok then
[03:32:39] <jmkasunich> if I'm gonna do anything it will be either fpga stepgen, or a revision of the sw stepgen
[03:33:14] <jmkasunich> (the algorithm that peter wallace and I worked out for doing stepgen (dealing with steplen, space, dirsetup and hold, etc) is more elegant than what I have in sw
[03:33:35] <SWPLinux> a timer that triggers a state machine?
[03:33:38] <jmkasunich> and it gives much nicer feedback with sub-step resolution
[03:33:51] <jmkasunich> a dds
[03:33:56] <SWPLinux> s/timer/dds/ :)
[03:34:01] <jmkasunich> with the feedback taken from the accumulator
[03:34:10] <jmkasunich> the key is that the dds has a hold input that freezes it
[03:34:26] <SWPLinux> right, while the state machine (step generator) is running
[03:34:27] <jmkasunich> if there is a dir change, the dds gets frozen until setup and hold times have expired
[03:34:40] <SWPLinux> ok - I remember a bit of the discussion
[03:34:46] <jmkasunich> the old approach let the dds free-run and dropped illegal pulses
[03:34:48] <SWPLinux> (readback for me)
[03:35:01] <jmkasunich> that meant the accum could not be used for feedback, I had to count the output
[03:35:09] <jmkasunich> so I had one step resolution on the fb
[03:35:54] <SWPLinux> right. this has the disadvantage of possibly generating incorrect frequencies (correctable in the driver)
[03:36:07] <jmkasunich> what does?
[03:36:12] <jmkasunich> the new version?
[03:36:14] <SWPLinux> yes
[03:36:27] <jmkasunich> it only pauses the dds on a direction change
[03:36:30] <SWPLinux> ah
[03:36:39] <jmkasunich> the old one could discard pulses on a dir change
[03:36:42] <jmkasunich> no real diff there
[03:36:44] <SWPLinux> right
[03:37:01] <SWPLinux> ok - I was thinking that you pause the DDS during step generation as well
[03:37:13] <jmkasunich> nope
[03:37:27] <jmkasunich> ddr output pulse triggers a chain of three oneshots
[03:37:33] <SWPLinux> PeteW made the steps a fixed duty cycle so that wouldn't happen (essentially using DDS to generate edges, not steps)
[03:37:40] <jmkasunich> steplen, dirhold, dirsetup
[03:38:01] <jmkasunich> if a dir change is pending dds is held until all three time out
[03:38:13] <jmkasunich> dir is allowed to change when the 2nd times out
[03:38:25] <jmkasunich> step is set true when the first one starts, and false when it times out
[03:38:38] <SWPLinux> steplen should be delayed if dirsetup is still going
[03:39:23] <jmkasunich> it will be (the next pulse will be delayed - the current one is going in the current direction, so there is no problem
[03:40:09] <jmkasunich> the problem case was: request up step, 30nS later dir changes, 30nS later, request down step
[03:40:46] <jmkasunich> now, its request up step, timer chain starts, 30ns later (requested) dir changes, dds holds, long time later timers time out, dds resumes, 30nS later request down step
[03:41:39] <SWPLinux> maybe I meant dirhold. the steplen one-shot (and the step output) should only be started if the dirsetup (I think) one-shot is timed out
[03:42:02] <jmkasunich> the only way it can start is if the dds sends a request
[03:42:05] <SWPLinux> basically the dirsetup timer has an "inhibit step" output
[03:42:11] <jmkasunich> and the dds won't send a request if its being held
[03:42:36] <SWPLinux> ah - right. DDS is held if either dirsetup or dirhold are on - got it
[03:44:37] <SWPLinux> dirhold should be started at the end of the step pulse, I think
[03:44:55] <jmkasunich> darn - flowsnake would be a nice test program, except my test config is looking for errors on Z, not X or Y
[03:45:06] <jmkasunich> yeah, its a chain
[03:45:18] <SWPLinux> ah - chain of three oneshots ...
[03:45:24] <jmkasunich> steplen is started, when it ends dirhold starts, when it ends, dirsetup starts
[03:45:33] <SWPLinux> * SWPLinux really removes his stupid hat this time
[03:45:44] <jmkasunich> in fact, you just gave me an idea that might save gates
[03:45:50] <jmkasunich> instead of three timers, just have one
[03:45:57] <SWPLinux> and a mode
[03:46:07] <jmkasunich> it gets loaded with the sum of all three times and counts down
[03:46:19] <SWPLinux> turning it into a step generating state machine ;)
[03:46:28] <jmkasunich> when it hits dirhold+dirsetup, you know that steplen has passed, so you end the pulse
[03:46:40] <SWPLinux> I'd just reload it
[03:46:47] <jmkasunich> when it hits dirsetup, you know that hold time has passed, so you update the dir output
[03:46:52] <jmkasunich> when it hits zero, you unhold the dds
[03:47:37] <jmkasunich> one preload, down count, stop at zero and two equality detectors, is probably less gates than three counters
[03:47:58] <SWPLinux> plus an adder and an extra register
[03:48:04] <jmkasunich> what for?
[03:48:21] <SWPLinux> unless the adder output can be used directly in one of the comparators
[03:48:24] <jmkasunich> the driver will compute dirsetup+dirhold, and dirsetup+dirhold+steplen
[03:48:40] <jmkasunich> three registers, as now, but they will have the sums in them
[03:48:49] <jmkasunich> the big sum is used to load the counter
[03:49:03] <jmkasunich> the middle one and the dirsetup register are the comparator inputs
[03:49:13] <SWPLinux> ok - that can work as well, but it's less robust than an independent set of numbers
[03:49:12] <jmkasunich> in fact, the comparators can be merged
[03:49:44] <jmkasunich> two target values, a bit to select which one to compare, and the counter value = 4 inputs = one LUT per bit
[03:50:28] <jmkasunich> I'll have to try it both ways, see if there is a significant difference in gate count
[03:51:32] <SWPLinux> you also need the zero comparison, though that's only 1 LUT per 4 bits
[03:52:02] <jmkasunich> or less, if the counters underflow can be used
[03:52:16] <jmkasunich> if there were three counters, they'd all need zero detects anyway
[03:52:23] <SWPLinux> equality is a nasty one though - it's more prone to error than >= or <=
[03:52:27] <SWPLinux> tue
[03:52:28] <SWPLinux> true
[03:52:42] <SWPLinux> but fewer gates
[03:52:48] <jmkasunich> you mean if somebody changes the value in mid count?
[03:52:53] <SWPLinux> yep
[03:52:57] <SWPLinux> which is guaranteed
[03:53:08] <SWPLinux> to happen
[03:53:33] <jmkasunich> the result would be an extra long step pulse, or hold time, or setup time
[03:53:42] <jmkasunich> as the counter loops around
[03:53:55] <jmkasunich> but who changes their steplen while machining a part?
[03:54:01] <SWPLinux> with a 32-bit counter at 100 Mhz, that could be a very long time
[03:54:09] <SWPLinux> well, nobody I guess
[03:54:15] <jmkasunich> not 32 bits
[03:54:21] <jmkasunich> those timers are 12 bits right now
[03:54:30] <SWPLinux> I forogt that this is the timing contstraints we're talking about
[03:54:39] <SWPLinux> oh - what base freq?
[03:54:49] <SWPLinux> 50 MHz?
[03:55:10] <jmkasunich> 33MHz
[03:57:51] <jmkasunich> dammit, the black hole has claimed another victim
[03:58:10] <jmkasunich> I was fiddling with a large wood screw - a sample somebody gave me for a project
[03:58:18] <jmkasunich> I dropped it, and it disappeared
[03:58:34] <jmkasunich> it's 3-1/2" long with a 5/8" diameter head!
[03:59:53] <SWPadnos> don't roll around too much
[03:59:59] <SWPadnos> you're guaranteed to run over it
[04:00:21] <jmkasunich> if that meant I found it, fine
[04:01:37] <jmkasunich> how can something that big vanish, when dropped a couple of feet
[04:03:00] <SWPadnos> bouncy concrete?
[04:03:32] <SWPLinux> I'm always amazed at how far, and in what directions, things can go when dropped from chair height
[04:03:37] <jmkasunich> yeah
[04:03:40] <jmkasunich> I found it
[04:04:04] <jmkasunich> it bounced, then rolled - you know how things with skinny points and large heads roll
[04:04:12] <jmkasunich> it rolled around a corner and hid
[04:04:18] <SWPLinux> around and around
[04:04:21] <SWPLinux> heh
[04:11:11] <SWPLinux> I can't believe this - it looks like I need to unwrap a new IEC power cord
[04:11:22] <jmkasunich> you gotta be kidding
[04:11:31] <SWPLinux> I don't see any unused IEC ends in my office
[04:11:54] <jmkasunich> I have a whole box of them
[04:12:23] <SWPLinux> I do too, but I can't imagine what happened to all the ones that used to clutter up the desk (and the floor ...)
[04:13:00] <SWPLinux> I guess I do have 3 computers, 7 monitors, several peripherals, and several wall-warts plugged in
[04:13:17] <SWPLinux> aha! the soldering station isn't in use
[04:13:58] <jmkasunich> your monitor to computer ratio is backwards
[04:14:03] <SWPLinux> heh
[04:14:20] <SWPLinux> I guess one monitor isn't in use, so I could unplug it
[04:14:29] <jmkasunich> * jmkasunich wants a nice fast server that I will never sully with a gui
[04:14:35] <SWPLinux> heh
[04:15:13] <skunkworks> IEC?
[04:15:27] <SWPLinux> the standard 3-pin computer cord
[04:15:33] <SWPLinux> at the computer end
[04:16:44] <skunkworks> Ah
[04:16:52] <jmkasunich> steves_logging is being a wiseguy
[04:17:05] <SWPLinux> uh-oh
[04:17:34] <jtr> logger_emc can't decide whether to stay or go.
[04:17:44] <cradek> I went through all Ed's messages from December and he never mentions anything about the hardware
[04:19:09] <SWPadnos> jtr, I wonder if someone is fiddling with it - it doesn't look like it's netsplits
[04:19:24] <SWPadnos> but it could be the only client connected to calvino
[04:20:41] <SWPadnos> I was considering responding to steveS with something about how much of the image he can see at once, but I restrained myself :)
[04:21:00] <jmkasunich> cradek: jepler: I just started running flowsnake.ngc, and I got a popup: "AXIS error param 2:0.000000"
[04:22:04] <jmkasunich> oh, and more
[04:22:12] <jmkasunich> level: 5
[04:22:15] <cradek> jmkasunich: that seems like interp debug output - are there magic comments or something?
[04:22:21] <jmkasunich> and _foobar:729.000
[04:22:41] <jmkasunich> whats a magic comment?
[04:22:49] <jmkasunich> there are o words
[04:22:51] <cradek> (DEBUG, some crap here)
[04:22:55] <cradek> or somesuch
[04:23:03] <jmkasunich> yeah
[04:23:13] <cradek> ok, it's a feature then
[04:23:19] <SWPLinux> plus the ability to print variable values, not just strings
[04:23:21] <jmkasunich> if you say so ;-)
[04:23:49] <jmkasunich> the dialog title bar shouldn't say error then
[04:24:13] <cradek> I can't argue with that
[04:25:23] <jmkasunich> hmm, I got a couple reversals
[04:25:32] <jmkasunich> 3mS long, 2mS after the command reversed
[04:26:55] <SWPLinux> it's very hard to use a flexible keyboard on your lap
[04:27:29] <jmkasunich> one of those rubber ones?
[04:28:15] <SWPLinux> yep
[04:29:02] <SWPLinux> much better with a board between me and it
[04:31:20] <cradek> much better in the trash and replaced by a real keyboard?
[04:31:41] <jmkasunich> I almost ordered a buckling spring keyboard today
[04:31:46] <SWPLinux> not in this case - it's for the CNC and I expect to mount it behind a metal plate
[04:31:54] <cradek> jmkasunich: how many do you want?
[04:32:01] <jmkasunich> I have a rubber one too, with the same plans
[04:32:02] <SWPLinux> it'll be sealed if I do that
[04:32:10] <jmkasunich> cradek: one should last forever
[04:32:15] <SWPLinux> this one actually works, but not when it's flopping around
[04:32:31] <cradek> jmkasunich: remind me to bring one to fest for you
[04:32:44] <jmkasunich> thanks
[04:32:51] <SWPLinux> I can nearly touch-type on it almost as well as I nearly touch-type on a real keyboard
[04:32:54] <cradek> they are not rare, but they're also not everywhere you look
[04:33:24] <cradek> I have one on every machine I use - you'll be ruined as soon as you have one
[04:33:54] <cradek> this one is "new" - dated 91
[04:35:07] <SWPLinux> does anyone recall which BDI is based on kernel
[04:35:26] <cradek> I just updated emc 2.0.3 to 2.1.1 and it worked perfectly
[04:35:25] <SWPLinux> I think it's 4.30 or so
[04:35:35] <jmkasunich> cradek: you can get them new: http://www.pckeyboard.com/customizer.html
[04:36:25] <SWPLinux> $59 - not a bad price, actually
[04:36:39] <SWPLinux> they're available on eBay from time to time as well
[04:37:03] <jmkasunich> or NOS
[04:37:04] <jmkasunich> http://www.clickykeyboards.com/index.cfm/fa/categories.main/parentcat/9231
[04:37:38] <cradek> can you get them without the windows keys?
[04:37:48] <cradek> I still haven't learned to tolerate those
[04:38:23] <SWPLinux> they are
[04:38:27] <SWPLinux> 101 key, not 104
[04:38:39] <cradek> the photo shows windows keys
[04:38:39] <SWPLinux> http://us.st11.yimg.com/us.st.yimg.com/I/pckeyboards_1914_68416
[04:38:59] <cradek> ah perfect
[04:39:06] <cradek> they don't have the mutant enter key either
[04:41:24] <SWPLinux> cool: http://www.clickykeyboards.com/index.cfm/fa/items.main/parentcat/9231/subcatid/0/id/151997
[04:42:55] <cradek> I've always wanted one of those but I think they're extremely rare
[04:43:14] <SWPLinux> they seem to have them in stock at $70 each
[04:43:21] <cradek> oh, wow
[04:43:38] <SWPLinux> they have 5 in stock
[04:43:47] <cradek> 4
[04:43:55] <SWPLinux> I added 20 to my cart and thy limited it to 5
[04:44:03] <SWPLinux> heh
[04:44:19] <SWPLinux> hmmm - still says 5 for me
[04:46:10] <SWPLinux> bummer. I guess I need to update that BDI so I can compile EMC2 again
[04:46:11] <jmkasunich> did you just buy one?
[04:46:17] <cradek> yes
[04:46:22] <SWPLinux> heh
[04:46:25] <cradek> well, I'm trying
[04:46:31] <cradek> web commerce, you know
[04:46:36] <SWPLinux> I only added them to a cart, then emptied it
[04:46:44] <jmkasunich> how much are they? (not seeing the price)
[04:46:47] <SWPLinux> that does look like a good keyboard for a CNC though
[04:46:50] <SWPLinux> $70
[04:47:00] <jmkasunich> I saw a pic of that when I was surfing this afternoon, but it was from a collector, not for sale
[04:47:05] <jmkasunich> looked like a good idea
[04:47:18] <SWPLinux> http://www.clickykeyboards.com/index.cfm/fa/items.main/parentcat/11298/subcatid/0/id/146730
[04:47:30] <jmkasunich> but I'd want to retain a conventional mouse too, for cad and such
[04:48:09] <SWPLinux> sure. the nice thing about that keyboard is that the cord ends in separate connectors - you can always add another USB mouse (or touchscreen ...)
[04:48:20] <cradek> 4 remaining in stock.
[04:48:22] <jmkasunich> well, I use a kvm
[04:48:30] <SWPLinux> and it's not some proprietary driver to get both from one connection
[04:48:45] <cradek> no, it's back from when computer parts were good
[04:48:57] <SWPLinux> does anyone have any ideas for installing Ubuntu to a machne that is currently running something else (BDI)?
[04:49:08] <SWPLinux> the machine has no CD/DVD, and no USB
[04:49:11] <SWPLinux> and no floppy
[04:49:18] <cradek> uh
[04:49:26] <SWPLinux> it does have ethernet and a hard drive
[04:49:29] <cradek> the same way you installed BDI?
[04:49:46] <SWPLinux> by disassembling it and plugging a spare CD-ROM?
[04:49:52] <SWPLinux> (which I no longer have)
[04:50:10] <SWPLinux> maybe I do have it
[04:50:17] <cradek> I bet that would be simplest
[04:50:21] <SWPLinux> but it's still a royal PITA
[04:50:23] <cradek> in the long run
[04:50:23] <SWPLinux> hmm
[04:50:33] <SWPLinux> heh
[04:50:45] <SWPLinux> well, I can't install it, just connect it for the install, then remove it and close up the case
[04:50:52] <SWPLinux> there's no room for a CDROM
[04:51:03] <SWPLinux> it's the little kiosk touchscreen PC
[04:51:21] <petev> SWPadnos, what about a USB key boot?
[04:51:28] <cradek> that does sound like a pain
[04:51:30] <SWPLinux> hard with no USB
[04:51:35] <petev> oh
[04:51:39] <SWPLinux> heh :)
[04:51:57] <SWPLinux> it's ethernet or HD for me, and I don't think it can netboot
[04:52:20] <cradek> you could try dist-upgrade I guess
[04:52:34] <cradek> even if it works, it will take forever and a half
[04:52:47] <SWPLinux> and I'll be left with BDI 4.5x
[04:53:00] <cradek> bdibuntu
[04:53:10] <cradek> I mean point it at the ubuntu repos
[04:53:12] <jmkasunich> 3 remaining in stock
[04:53:19] <SWPLinux> I guess I probably should try installing XUbuntu and getting it configured
[04:53:26] <SWPLinux> hmm - that may work
[04:53:35] <SWPLinux> heh - selling fast
[04:53:36] <cradek> I wouldn't bet much on it
[04:53:55] <cradek> jmkasunich: I bet you won't see those for sale again except at collector prices
[04:53:58] <SWPLinux> on the ubuntu dist-upgrade? - me either
[04:54:23] <cradek> if you're not in a hurry, you could run it overnight for the heck of it
[04:54:25] <jmkasunich> I'll have to figure out how two get a regular mouse to co-exist with it
[04:54:25] <petev> u guys have seen the industrial KBs by intermec haven't you?
[04:54:43] <SWPLinux> intermec - meybe
[04:54:44] <cradek> jmkasunich: plug in a USB mouse, it will just work
[04:54:49] <petev> they are fully sealed and have a multi level backlight
[04:55:05] <cradek> backlight? what for?
[04:55:18] <cradek> I guess some laptops have keyboard lights too
[04:55:19] <SWPLinux> so you can see them in poor lighting conditions?
[04:56:07] <jmkasunich> cradek: have you ever actually used one of the M5-1 keyboards?
[04:56:20] <jmkasunich> I wonder how sensitive the trackball is?
[04:56:27] <cradek> no, but I think it's the normal IBM keyboard plus trackball
[04:56:38] <SWPLinux> petev: what kind of proces do they have on those KBs? the industrial ones I've seen are usually several $hundred+
[04:56:41] <cradek> probably it's relatively low resolution compared to modern
[04:57:13] <SWPLinux> you can prevent that trackball from sending core events to X, and use it as an auxiliary device
[04:57:20] <petev> I got some for pretty cheap on ebay
[04:57:21] <SWPLinux> it may have perfect resolution for jogging
[04:57:29] <petev> they seem to come up quite often
[04:57:36] <petev> I think I got 2 new for $100
[04:57:41] <SWPLinux> cool
[04:57:46] <jmkasunich> I'm not getting the kb for the machine, I'm getting it for my main keyboard
[04:57:58] <jmkasunich> the CNC will get a cheap rubber KB
[04:58:05] <petev> I tried those
[04:58:12] <petev> they seem to fail pretty easy
[04:58:16] <SWPLinux> I may have seen those - I remember several sealed (stainless) backlit keyboards with trackballs a year ago or so
[04:58:21] <jmkasunich> the rubber ones?
[04:58:23] <petev> had the virtually indestructable thing
[04:58:30] <petev> peice of $hit
[04:58:45] <petev> half the keys stopped working
[04:58:55] <SWPLinux> I tried several at Micro Center, and found only one model that more or less worked (so I bought one)
[05:04:31] <steves_logging> steves_logging is now known as steve_stallings
[05:06:03] <SWPadnos_> yay
[05:06:55] <SWPadnos_> could someone be so kind as to paste in the correct repositories for ubuntu/EMC ?
[05:07:03] <steve_stallings> .... just caught up reading back, joined for real, .... yes, wise guy comment about graph files, but why does a 800KB file give Foxfire a fit?
[05:07:16] <SWPLinux> it rescales it
[05:07:25] <SWPLinux> and the image is 12k+ x 5.5k+ pixels
[05:07:42] <jmkasunich> it was fine when viewed as a scrunched collection of scribbles
[05:07:50] <jmkasunich> click to enlarge to 100% and it gets nasty
[05:07:50] <steve_stallings> so does Internet Exploder and it does not have problems
[05:08:21] <SWPLinux> I had one problem with Mozilla on Windows, but none with FireFox
[05:08:28] <steve_stallings> .. so the expaned image chews up all available system memory?
[05:08:30] <jmkasunich> I didn't have crashing, just slow
[05:08:43] <jmkasunich> a crapload of my memory is tied up with VMs (the compile farm)
[05:08:54] <jmkasunich> so it started a swapfest
[05:08:59] <cradek> I think there's another task bug - my 'machine on' output stayed enabled when I exited emc
[05:09:24] <SWPLinux> tha could be an oops, for sure
[05:09:32] <cradek> I thought we fixed that once
[05:09:37] <SWPLinux> or the driver not running long enough to update the output
[05:09:51] <jmkasunich> hmm, might be a motmod bug, shouldn't motmod clear that pin before it gets rmmoded?
[05:10:03] <cradek> wow, the saved joint position is neat, I hadn't used that yet on my real machine
[05:10:15] <SWPLinux> when does the realtime stop happen?
[05:10:28] <jmkasunich> probalby before the rmmod...
[05:10:31] <jmkasunich> so forget what I said
[05:10:37] <SWPLinux> so setting a pin is useless :)
[05:10:38] <SWPLinux> ok
[05:10:54] <jmkasunich> gotta set/clear the pin, wait at least a few ms, then start shutting down
[05:12:06] <SWPLinux> so - any takers for pasting in the ubuntu/EMC2 sources.list ?
[05:12:11] <petev> guys, what is the appropriate routine to use for printing error messages from user space?
[05:12:16] <SWPLinux> (abbreviated)
[05:12:24] <petev> there is no consistency in the code that I see
[05:12:41] <SWPLinux> rcs_print for some parts, rtapi_print for others, I think
[05:12:52] <petev> why rtapi if it never runs RT?
[05:13:04] <jtr> SWPadnos_: deb http://www.linuxcnc.org/emc2/ dapper emc2.1
[05:13:04] <jmkasunich> deb-src http://www.linuxcnc.org/emc2/ dapper emc2.1
[05:13:14] <petev> I want to finish this INI stuff already
[05:13:23] <petev> it's been dragging way too long
[05:13:26] <SWPLinux> because the parts that talk to the RT system also use the RTAPI layer for other stuff?
[05:13:37] <jtr> SWPadnos_: deb-src http://www.linuxcnc.org/emc2/ dapper emc2.1
[05:13:51] <jmkasunich> there is probably not a good reason for stuff that will never use RT to make RTAPI calls
[05:13:54] <SWPLinux> thanks for that - I need all of the stock ones as well - I'm going to try the dist-upgrade from BDI 4.30-ish :)
[05:14:08] <jtr> oops - we had already hit both. sorry
[05:14:12] <petev> some of the code is just using fprintf
[05:14:14] <jmkasunich> ok, I'll /msg you
[05:14:21] <SWPLinux> go to swpadnos_
[05:14:27] <petev> so is the concensus that it should be rcs_...
[05:15:26] <SWPLinux> dunno - you could probably standardize on printf for the ini stuff - that should be usable without RCS or RTAPI
[05:15:41] <petev> to stderr?
[05:15:47] <SWPLinux> but I'm not sure how the messages are expected to be used there ...
[05:15:56] <jmkasunich> swPadnos: got it?
[05:16:31] <cradek> can't some of those messages make it into the emc gui?
[05:16:52] <petev> right now low level stuff is just printing
[05:16:57] <SWPLinux> yep. the other option is to return error messages and leave it to the caller to output them
[05:17:00] <petev> and all differently
[05:17:04] <petev> this is why I ask
[05:17:28] <petev> the caller always makes the decision based on the error return
[05:17:36] <petev> but I don't want to dup the print code
[05:17:46] <petev> so I want to stick something in the exception class
[05:18:20] <SWPLinux> did inifile print before?
[05:18:28] <petev> yes, fprintf()
[05:18:35] <SWPLinux> ok, then use fprintf for now
[05:18:38] <petev> and the callers printed too
[05:18:40] <SWPLinux> we can standardize later, I think
[05:18:45] <petev> with different routines
[05:18:52] <petev> the new code replaces both
[05:19:04] <petev> so I would like to get it right
[05:19:42] <SWPLinux> hmmm. the callers use rcs_print, fprintf, and rtapi_print_* - any others?
[05:19:53] <petev> that's mostly what I saw
[05:20:31] <SWPLinux> ok. rtapi_print is probably not needed because as you pointed out, no RT code directly uses ini files (at this point)
[05:20:47] <petev> right, and that's only usermotintf
[05:20:56] <petev> at least I didn't see it anywhere else
[05:21:08] <SWPLinux> rtapi_print is a simplification for code that may run in RT or userspace - it's defined differently in the two cases
[05:21:21] <petev> right
[05:21:21] <SWPLinux> do you recall where rcs_print is used?
[05:21:34] <petev> in many of the other ini modules
[05:21:40] <petev> and some of the ui interface stuff
[05:23:09] <SWPLinux> ok. and halcmd is the only other consumer of ini settings? (other than the GUIs, which don't use this library, do they?)
[05:23:24] <petev> its the only one using the C wrapper
[05:23:29] <SWPLinux> oh - you said ui interface stuff
[05:23:35] <SWPLinux> right
[05:23:37] <petev> the GUIs do use it
[05:26:51] <cradek> hey I found my rotary axis
[05:26:52] <petev> I'm thinking rcs_, it will only be in one spot so it will be easy to change, but I don't want to break anything
[05:27:02] <SWPLinux> I guess rcs_print should be the one
[05:27:08] <petev> agreed
[05:27:07] <SWPLinux> heh - beat me to it
[05:27:14] <jmkasunich> I don't think this is what Ed was describing, but its still annoying:
[05:27:15] <jmkasunich> http://jmkasunich.dyndns.org/pics/stepgen-dir-toggle-1.png
[05:28:25] <SWPLinux> what's the staircase trace?
[05:28:44] <jmkasunich> frequency - an internal param of stepgen, after scaling and accel limiting
[05:28:50] <SWPLinux> ah
[05:28:52] <jmkasunich> its in Hz
[05:35:00] <SWPLinux> heh - only 382M of upgrades :)
[05:35:37] <cradek> that's about 10 minutes to download, 4 hours to install
[05:36:14] <SWPLinux> no, 40 minutes to download, 10 hours to install (it's a celery 500/512M)
[05:37:29] <cradek> that's faster than my PII-400/256M then
[05:38:19] <SWPLinux> I hope so
[05:38:30] <cradek> this machine actually works pretty well
[05:38:38] <cradek> base period 50000 is plenty for my mill
[05:38:41] <SWPLinux> it seems very slow because of the terrible video controller, but I guess it has reasonable compute capacity
[05:39:00] <SWPLinux> this one can get to 20000, and I think I've had it at 16000
[05:39:21] <cradek> I might be able to do that, but it would make it (even) less responsive
[05:39:21] <SWPLinux> the max latency has never been over ~5000 or so
[05:39:24] <cradek> cool
[05:40:09] <SWPLinux> KDE and an onboard integrated video controller (buffer in the chip) - not the fastest combination
[05:40:31] <SWPLinux> I'd try a faster hard drive, but I don't know that the motherboard will support anything over 32G
[05:40:38] <cradek> not even one slot?
[05:40:46] <SWPLinux> (and I don't have any fast drives under that)
[05:40:50] <SWPLinux> 2 slots, PCI
[05:40:55] <SWPLinux> one shared ISA
[05:41:05] <cradek> oh, you can't add a video card, duh
[05:41:23] <SWPLinux> I can, but not with the internal monitor, of course
[05:41:37] <cradek> sure
[05:41:41] <SWPLinux> I could ad done actually, but it would need to have lvds output, which is very rare
[05:41:48] <SWPLinux> add one
[05:42:31] <SWPLinux> hmmm. I wonder how X deals with two touchscreens
[05:43:01] <SWPLinux> I'm not sure that the touchscreen driver had an offset value for the reported coordinates
[05:43:38] <petev> swpadnos, are you using the event driver for the touch?
[05:43:38] <steve_stallings> JMK - do you know what corresponds to/caused the reversal of direction in the HAL scope run that you captured
[05:43:55] <SWPLinux> nope - it's the elo driver
[05:44:06] <petev> what chip?
[05:44:08] <SWPLinux> the integrated touchscreen is serial - dunno if that works with evdev
[05:44:12] <petev> or is elo the chip?
[05:44:20] <SWPLinux> elo is the touch overlay manufacturer
[05:44:46] <SWPLinux> they have a Linux driver, and I think it may be included with later kernels
[05:44:55] <SWPLinux> (don't know that for sure)
[05:45:02] <petev> I use the evtouch driver for X
[05:45:15] <SWPLinux> USB or serial touchscreen?
[05:45:17] <petev> you attach it to an event driver
[05:45:30] <petev> I used a udev thing to make it the same every time
[05:45:36] <petev> yes, USB
[05:45:47] <SWPLinux> ok - I have a serial touchscreen
[05:45:52] <petev> and every fricking time you boot it's a different event driver number
[05:46:19] <SWPLinux> I know the hotplug is iffy with that (no plug events), I'm not sure the serial screen can be used with evdev (I'm betting not)
[05:46:27] <SWPLinux> heh
[05:46:43] <SWPLinux> like USB, which can reorder the devices at any plug/unplug event
[05:46:53] <petev> the evdev didn't work so hot and didn't have the long and 1.5 touch things
[05:47:09] <petev> but evtouch may work with serial too
[05:47:14] <petev> not sure
[05:47:30] <SWPLinux> I don't think I have anything other than tap, double-tap, drag, and tap-drag
[05:48:04] <SWPLinux> and dragging doesn't do anything but move the pointer - you need to tap-drag to act like a click/drag
[05:48:25] <petev> right
[05:51:33] <jmkasunich> steve_stallings: I'm writing an email to Ed and the list now with my interpretation of the picture
[05:57:40] <SWPLinux> jmkasunich: are you thinking of adding the fractional step value (DDS accumulator or something) to the position feedback?
[05:57:56] <jmkasunich> if anybody cares about the stepgen thing, the mail is on the list
[05:58:03] <SWPLinux> regardless of whether a step has been generated
[05:58:09] <SWPLinux> I was just reading it :)
[05:58:12] <jmkasunich> duh
[05:58:19] <jmkasunich> yeah
[05:58:36] <SWPadnos> I guess if I had read that far, I would have had my answer
[05:58:37] <jmkasunich> the feedback will actually be a long long, with 48.16 or something resolution
[05:58:54] <SWPadnos> and the DDS acc is the .16
[05:59:22] <jmkasunich> actually, the dds is 16.16, and the driver handles rollover and maintains the upper 32 bits
[05:59:29] <SWPadnos> ok
[05:59:41] <jmkasunich> or I might just make the accum 48.16 or so
[05:59:41] <SWPadnos> is that the way stepgen is now?
[06:00:09] <jmkasunich> today the accum is something like 1.31 or 0.32
[06:00:19] <jmkasunich> and steps are counted in another variable
[06:00:39] <jmkasunich> because sometimes the steplen/dirhold/etc logic drops a step due to timing variations
[06:00:58] <jmkasunich> with a hold on the dds, nothing ever gets dropped, so the accum _is_ the feedback
[06:01:15] <jmkasunich> now that I think about it, the accum will probably become 32.32
[06:01:34] <SWPadnos> ok - no biggie. just change the update_feedback routine to use the DDS count as a fraction - the feedback is a float anyway
[06:02:28] <jmkasunich> right, feedback position will be the 32.32 value converted to a double, and divided by both scale, and 2^32
[06:03:17] <jmkasunich> now i just have to code it... but I'll do that tomorrow - its 1am
[06:03:27] <jmkasunich> if I start now, I'll be up till 4 or later
[06:03:29] <SWPadnos> oh crap
[06:03:35] <cradek> goodnight everyone!
[06:03:47] <jmkasunich> goodnight
[06:04:16] <SWPadnos> I was thinking it could be as easy as adding or subtracting (depending on the sign of the adder) ddsvalue * scale / 2^31
[06:04:32] <SWPadnos> in the slow thread, of course
[06:05:00] <jmkasunich> all I have to do is take the accum and scale it
[06:05:41] <SWPadnos> right - the scale is scale (parameter) / MAXACC (2~31-1, I guess)
[06:05:46] <SWPadnos> 2^31, that was
[06:05:51] <jmkasunich> something like that
[06:06:07] <SWPadnos> anyway - good night
[06:06:08] <jmkasunich> I'm not sure if the existing accum is 1.31 or 0.32
[06:06:14] <jmkasunich> and the new one might not be 32.32 either
[06:06:24] <SWPadnos> no need to change the accum
[06:06:49] <jmkasunich> why not though?
[06:07:07] <jmkasunich> using a long long int for the accum should have minimal effect on the fast thread
[06:07:33] <jmkasunich> and saves me screwing around in the slow thread
[06:07:37] <SWPadnos> more changes that aren't necessary
[06:07:49] <SWPadnos> I bet if you had an extra 4 bits of resolution, it would fix the problem
[06:08:27] <jmkasunich> my mind is made up - the FPGA approach is simple and clean and IMO it is the way the software should work too
[06:09:03] <SWPadnos> oh, sure. for least impact you can just use the accum as it is. changing the accum is more invasive
[06:09:13] <SWPadnos> but also more correct in a sense
[06:10:04] <jmkasunich> less invasive and more testable than a lot of other changes that are being discussed and/or done right now ;-)
[06:10:05] <cradek> if there's a safer and less invasive stopgap for 2.1 and an entire better solution for 2.2, that would be fine
[06:10:26] <SWPadnos> heh
[06:10:40] <jmkasunich> wait until I have the new approach working, then we can debate what is appropriate for 2.1.2
[06:10:41] <cradek> jmkasunich: which branch are you thinking of targeting?
[06:10:47] <cradek> ok
[06:10:53] <cradek> fair enough
[06:11:01] <jmkasunich> I always do stuff in head, then I backport if its important enough
[06:11:25] <jmkasunich> and/or tested enough ;-)
[06:11:27] <cradek> that reminds me I think I forgot a backport
[06:11:28] <SWPadnos> heh
[06:11:34] <jmkasunich> goodnight all
[06:11:37] <cradek> goodnight
[06:11:45] <cradek> that's smart, I should go too
[06:11:52] <SWPadnos> yep, that makes three
[07:41:23] <steve_stallings> steve_stallings is now known as steves_logging
[07:50:16] <cradek> morning alex_joni
[07:51:46] <cradek> ... and goodnight
[08:14:03] <alex_joni> hi
[08:14:15] <alex_joni> darn.. missed you, but I got your email
[15:50:06] <jepler> 32326:binding file /home/jepler/emc2.head/rtlib/freqgen.so to /home/jepler/emc2.head/rtlib/stepgen.so: normal symbol `step_type'
[15:50:37] <alex_joni> that's trunk not head :P
[15:51:37] <jepler> whatever :-P
[15:51:46] <alex_joni> what's that 'binding file' ?
[15:51:59] <rayh> trunk reminds me of an elephant.
[15:52:18] <alex_joni> rayh: yeah, there is a resemblance :D
[15:52:25] <jepler> for some reason, when you load both freqgen and stepgen in the simulator, they get the same step_type array, so you may get wrong/undesired step generators created
[15:52:36] <jepler> I don't understand why, though
[15:55:38] <rayh> I like head ;)
[15:57:24] <SWPadnos> CVS repositories are like a hydra: many heads
[16:06:31] <rayh> I guess I'm supposed to understand that now. It is all so confusing though.
[16:06:44] <SWPadnos> heh
[16:07:09] <SWPadnos> think like a tree. TRUNK is main development, each leaf would be a HEAD of some other branch of development
[16:43:09] <rayh> I don't seem to be able to command a tool diameter comp with today's checkout.
[16:43:27] <rayh> probably just me...
[16:43:45] <cradek> rayh: what's happening?
[16:44:41] <alex_joni> morning chris
[16:44:45] <alex_joni> * alex_joni is hunting that bug
[16:45:27] <rayh> the same file I made the image from yesterday does not offset at all today.
[16:45:44] <rayh> runs the same path as tool 0
[16:47:14] <cradek> hmmm
[16:47:43] <cradek> was it line or arc entry? I don't remember the file
[16:47:51] <rayh> line
[16:48:39] <rayh> http://imagebin.org/7562
[16:51:10] <cradek> ok I'll punch that one in soon, I'm at the wrong computer now
[16:51:14] <cradek> what's tool 1 dia?
[16:51:42] <rayh> I think .5
[16:52:37] <rayh> must have been inch.
[16:59:03] <alex_joni> cradek: yay.. nailed that bug
[16:59:20] <cradek> alex_joni: the machine-on?
[16:59:45] <alex_joni> yeah
[16:59:49] <cradek> yay thank you!
[16:59:52] <alex_joni> you'll never guess where it was
[17:00:00] <alex_joni> but it would be nice if you try :P
[17:00:01] <cradek> task?
[17:00:03] <alex_joni> nope
[17:00:17] <cradek> ok, how about task?
[17:00:21] <alex_joni> nope
[17:00:25] <cradek> * cradek is running out of guesses
[17:00:32] <alex_joni> runscript :P
[17:00:40] <cradek> oh yuck
[17:00:46] <alex_joni> halcmd stop :P
[17:00:54] <alex_joni> motion controller doesn't execute any more
[17:01:41] <alex_joni> so even if task sends the machine off (DISABLE) command, it couldn't be executed
[17:01:48] <cradek> ok I see
[17:02:08] <cradek> * cradek waits for the patch email
[17:02:29] <alex_joni> it's 4 lines moved around
[17:02:41] <cradek> it's easy to miss this kind of thing - all my testing has been in sim
[17:03:13] <alex_joni> yeah, it happend (hard to catch) when the runscript was cleaned up a bit
[17:03:19] <alex_joni> the old way of shutting down HAL was tedious
[17:03:24] <alex_joni> lsmod & co
[17:03:36] <alex_joni> http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/emc2/scripts/emc.in.diff?r1=1.60;r2=1.61
[17:03:50] <alex_joni> I'll backport it to 2.1 now
[17:04:00] <cradek> thanks again!
[17:04:32] <alex_joni> it's good to be usefull from time to time ;)
[17:06:07] <cradek> well I knew you were the right person to ask about it
[17:10:08] <rayh> oh im getting really wierd results.
[17:11:04] <rayh> If I run a sim config from a couple days ago mini shows the file about the way I expect it to.
[17:11:10] <rayh> no comp but
[17:11:34] <rayh> If I run it with sim config from today the plot is way wrong
[17:13:50] <alex_joni> cradek: maybe you can test that fix on 'max' later?
[17:14:10] <alex_joni> it's hard for me to check actual parport pins while the modules/HAL are shutting down ;)
[17:17:54] <cradek> alex_joni: I certainly will
[17:18:09] <cradek> rayh: your file runs fine for me! are you sure you got a full update and compile?
[17:18:12] <alex_joni> ok, great
[17:18:27] <alex_joni> cradek: might be AXIS vs. mini ?
[17:18:50] <cradek> no, I actually ran it, not just preview
[17:20:22] <rayh> Let me make clean and try again.
[17:21:48] <cradek> mini also works right here
[17:22:47] <rayh> This will be a while.
[17:23:20] <cradek> http://timeguy.com/cradek-files/emc/raysemi-mini.png
[17:23:29] <cradek> pardon the bad picture - I don't know how to crop, so I resized the window
[17:23:54] <rayh> I use gimp but...
[17:23:59] <cradek> that's with D0 and D4, D4 is 0.9in
[17:24:22] <rayh> darn that looks just right.
[17:25:00] <cradek> I'm built for sim, not realtime, but that seems unlikely to change it
[17:29:03] <cradek> I'm cleaning mine too
[17:33:43] <cradek> rayh: looks right after a cvs update/clean/rebuild here
[17:34:05] <rayh> Not here.
[17:34:21] <cradek> ok maybe I broke something obscure, instead of outright like usual
[17:34:31] <rayh> Some goofy stuff.
[17:34:32] <alex_joni> haha
[17:34:41] <alex_joni> what need I do to test here?
[17:34:44] <cradek> can you post a screenpic
[17:34:51] <cradek> alex_joni: I'll pastebin the program
[17:34:55] <alex_joni> ok, coo
[17:35:32] <cradek> http://pastebin.ca/389329
[17:35:37] <rayh> Why would the selection of sim in rayh/configs/ be any different from emc2-head/configs/
[17:36:06] <cradek> you could diff them to find out what's different
[17:36:18] <rayh> and yet the plot is completely different between the two and no comp
[17:36:18] <cradek> diff -Ru rayh/configs/sim emc2-head/configs/sim
[17:36:32] <rayh> I must have gotten a borked download
[17:36:53] <rayh> the only diff is the location of the programs directory
[17:36:54] <cradek> is the time right on your computer?
[17:37:07] <rayh> 11:38
[17:37:08] <cradek> time and date
[17:37:14] <cradek> ok
[17:37:26] <cradek> (that can sometimes lead to bogus compiles)
[17:37:44] <rayh> Right.
[17:38:01] <rayh> btw what do we have to do to get the time change tomorrow?
[17:38:15] <cradek> just install the available ubuntu updates
[17:38:24] <cradek> they sent out a fix a few days ago
[17:38:35] <alex_joni> hmm.. it seems to go on the line without comp
[17:38:45] <alex_joni> * alex_joni updates again
[17:38:52] <cradek> alex_joni: do you have a tool #3?
[17:38:56] <alex_joni> #1
[17:38:59] <rayh> okay thanks
[17:39:13] <alex_joni> I did a M6T1 in MDI
[17:39:20] <rayh> I used d1 I think. If this is my file.
[17:39:20] <alex_joni> I see no M6 in that program
[17:39:32] <alex_joni> oh, D3
[17:39:49] <rayh> you really don't need to change to a tool to use it's diameter.
[17:40:12] <alex_joni> rayh: I have little clue about comp so far ;)
[17:40:37] <rayh> np
[17:41:02] <rayh> I'll try a new cvs up and make and see if it's the same still.
[17:41:20] <rayh> probably should do a complete checkout again.
[17:41:45] <rayh> CVS wouldn't know if a file got twisted up during download, would it.
[17:41:55] <cradek> I don't think so
[17:42:08] <jepler> ssh is supposed to ensure the integrity of the data it transfers
[17:42:10] <cradek> you could remove the files in src/emc/rs274ngc and do an up
[17:42:17] <cradek> well that's true
[17:42:24] <jepler> besides, what are the odds that a garbled file is valid "C" source code
[17:42:24] <jepler> ?
[17:42:31] <alex_joni> cradek: anything else to do, than simply run the program?
[17:42:53] <cradek> alex_joni: change it between D0 and D3 or whatever tool you want to use, and see if it offsets around the shape
[17:43:17] <alex_joni> it's D3 now, and it just walks the line (no offset from what I can tell)
[17:43:40] <cradek> what's the diameter of tool 3?
[17:43:54] <alex_joni> sim.tbl (0.25)
[17:43:58] <cradek> the lines will move - you have to run it twice to see the difference
[17:44:14] <cradek> the tool always follows the line
[17:44:18] <rayh> what is clarkexx
[17:44:43] <alex_joni> ok, it works now..
[17:44:53] <alex_joni> I changed the diam of the tool, and reloaded the tooltable
[17:45:18] <alex_joni> screenshot coming up
[17:45:20] <jepler> rayh: something to do with 3-phase motors, added recently by jmk
[17:45:27] <rayh> okay.
[17:45:27] <jepler> (recently meaning in the last month or two)
[17:45:49] <jepler> The Clarke transform can be used to translate a vector quantity from a
[17:45:53] <jepler> three phase system (three components 120 degrees apart) to a two phase
[17:45:57] <jepler> Cartesian system
[17:46:05] <rayh> oh okay. i get it.
[17:46:21] <rayh> what's the nsa_tap.o
[17:46:25] <rayh> ;)
[17:46:40] <alex_joni> that's where the NSA taps in
[17:46:48] <alex_joni> http://imagebin.org/7571
[17:46:56] <jepler> national servo academy torque adjustment procedure
[17:47:06] <rayh> Right. I wouldn't be surprised at all.
[17:47:32] <rayh> "we gonna torque on you a bit, boy."
[17:47:56] <cradek> alex_joni: that sure looks right
[17:48:18] <alex_joni> cradek: yep, thought so too
[17:48:39] <rayh> Then it's got to be my system.
[17:48:50] <rayh> glad to know that
[17:48:58] <cradek> rayh: say again please, what's the behavior you see?
[17:49:01] <alex_joni> rayh: is it really TRUNK you're checking out?
[17:49:07] <alex_joni> maybe you have a v2_1_branch checkout
[17:50:30] <rayh> I don't see any extra files in the cvs dir.
[17:51:18] <alex_joni> check emc2/CVS/Tag
[17:51:21] <alex_joni> if it's there..
[17:52:12] <cradek> cvs stat src/emc/rs274ngc/interp_convert.cc
[17:52:37] <rayh> no tag file.
[17:53:10] <rayh> still way wrong. I'll do a complete checkout.
[17:53:34] <SWPadnos> or up -dPAC (I think)
[17:53:44] <SWPadnos> or maybe only A or C
[17:54:54] <rayh> This is fascinating.
[17:55:11] <rayh> maybe I'll just move mini and up.
[17:55:31] <SWPadnos> petev was having some trouble compiling last night, which I couldn't reproduce
[17:56:20] <alex_joni> rayh: can you put a screenshot online?
[17:56:24] <alex_joni> * alex_joni wonders how it's wrong..
[17:56:26] <rayh> Wild stuff.
[17:57:09] <rayh> What i'm seeing on the display looks like it's rotated way off from where it should be and doesn't rotate to a "normal" view no matter what I do.
[18:00:54] <cradek> on my other machine, I get a strange default view in mini, and when I try to change it (I moved rot-x) I get "Error: domain error: argument not invalid range" popup
[18:01:13] <cradek> omain error: argument not in valid range
[18:01:14] <cradek> while executing
[18:01:15] <cradek> "expr "$A * $adir" / $scaler"
[18:01:51] <rayh> still strange.
[18:02:57] <cradek> so is the view wrong in mini, or is the radius comp wrong? I still don't understand what's going on
[18:03:14] <rayh> I've seen a strange error message twice this morning domain error: argument not in valid range.
[18:03:28] <rayh> seems to be coming from tcl.
[18:03:48] <cradek> yes probably a divide by zero in that expr I just pasted
[18:04:57] <rayh> * rayh needs a vacation.
[18:05:24] <cradek> I'm going to go vacation in a miniature waterfall for a while
[18:05:53] <alex_joni> * alex_joni can't rotate the backplot in mini to something usefull
[18:06:17] <alex_joni> this program has no Z movement.. right?
[18:06:48] <cradek> bbl
[18:07:04] <rayh> I can if I use an old configs/sim/mini.ini
[18:07:29] <SWPadnos> oh - ini changes have probably screwed up the tcl interface to ini files
[18:07:29] <rayh> but I can't if I use emc-head/config/sim/mini/ini
[18:07:48] <SWPadnos> wait - using the same mini program, or using a different mini?
[18:08:21] <rayh> using just a config in a different place.
[18:08:24] <SWPadnos> hmmm
[18:08:28] <alex_joni> ahhh.. bet I know what the problem is
[18:08:46] <SWPadnos> me too
[18:08:52] <SWPadnos> (I'd bet you know what the problem is :) )
[18:09:09] <rayh> * rayh looses all bets!
[18:09:18] <SWPadnos> then feel free to bet against me
[18:10:29] <SWPadnos> do you see any differences in the two configs? (with diff)
[18:11:19] <rayh> I just looked at the .ini files between the two. the location of the program directory changed.
[18:11:33] <alex_joni> hmm.. no
[18:11:34] <SWPadnos> any hal, tbl, or nml file changes?
[18:11:46] <alex_joni> SWPadnos: I saw a few changes lately
[18:11:54] <alex_joni> 0.039.. vs inch
[18:11:57] <SWPadnos> ok
[18:12:08] <alex_joni> INPUT_SCALE = 4000 vs INPUT_SCALE = 4000 0.0
[18:12:11] <SWPadnos> ray - how old is the "other" ini?
[18:12:15] <alex_joni> but neither was the problem
[18:12:21] <SWPadnos> ok - those are pretty old though - several weeks, right?
[18:12:27] <SWPadnos> at least
[18:13:45] <alex_joni> SWPadnos: way before 2.1.x
[18:13:56] <SWPadnos> ok - thought so
[18:13:58] <cradek> so you guys are thinking pete's changes last night broke tcl ini reading?
[18:14:10] <SWPadnos> it's possible, but I'm not sure
[18:14:12] <rayh> pastbin coming up.
[18:14:49] <alex_joni> I got the "domain error: argument not in valid range" out of the blue
[18:14:53] <alex_joni> while not touching the interface
[18:15:22] <rayh_> http://www.pastebin.ca/389353
[18:15:58] <rayh> You mean it might not be me?
[18:16:00] <SWPadnos> would you mind rerunning the diff with -u?
[18:16:49] <alex_joni> there is no real difference there
[18:17:19] <rayh_> k
[18:17:39] <rayh_> you still need the -u
[18:17:43] <alex_joni> I only see the max_joints I added there
[18:17:48] <SWPadnos> different tool diameters
[18:17:52] <alex_joni> rayh: that one is easier to read
[18:17:54] <SWPadnos> 1.5 vs. 0
[18:17:58] <alex_joni> SWPadnos: but even jogging is wrong
[18:17:59] <rayh_> k
[18:18:01] <SWPadnos> yes, -u would be nice
[18:18:15] <alex_joni> this is _not_ comp or tool related
[18:18:46] <SWPadnos> sure - the mini problem isn't, but the tool comp one may be ;)
[18:18:58] <alex_joni> tool comp works OK here
[18:18:59] <rayh_> http://www.pastebin.ca/389364
[18:19:08] <alex_joni> the display in mini is wrong..
[18:20:06] <rayh_> mini and tkemc tend to read directly from the ini file for a few variables.
[18:20:28] <rayh_> using some sort of thing in emcsh
[18:21:32] <SWPadnos> emcsh probably uses the nml/rs274 library, which has ini file stuff in it (I think)
[18:21:52] <alex_joni> tkemc works OK
[18:22:07] <SWPadnos> ok
[18:22:11] <jepler> now the inifile reading stuff is in its own shared library, libemcini.so
[18:22:14] <SWPadnos> that's a good thing
[18:22:22] <SWPadnos> ok, great
[18:22:30] <alex_joni> both the backplot & jogging and the comp stuff
[18:22:33] <SWPadnos> still used in emcsh though, right?
[18:22:52] <jepler> yes, libemcini.so is linked into emcsh
[18:23:24] <rayh_> One thing that turns out different between my two runs here is that I'm using rayh/emc2/nc-files/vartest.ngc for both
[18:24:08] <rayh_> so the part program is in different paths for each run as is the config.
[18:24:39] <alex_joni> rayh_: no, something is really broken
[18:24:42] <alex_joni> just start mini, and try to jog
[18:24:47] <alex_joni> and watch the backplot
[18:24:52] <alex_joni> (without loading any program)
[18:24:58] <rayh_> k
[18:25:46] <SWPadnos> OT: alex - can you fix the documentation page on linuxcnc.org - it says "the upcoming EMC version 2.1" ...
[18:25:46] <rayh_> works as promised with the old ini.
[18:26:08] <alex_joni> rayh_: really? wtf?
[18:27:08] <rayh_> with the new ini it is "strange days indeed, mamma!"
[18:27:43] <SWPadnos> most peculiar - whoa
[18:27:50] <rayh_> all the plotting is along a single line
[18:28:05] <alex_joni> rayh_: if you put it on 3D, then it'snot
[18:28:12] <alex_joni> but it's like space has folded
[18:28:26] <rayh_> and so has my head.
[18:28:34] <SWPadnos> what is traj[axes] in the inis?
[18:28:47] <jepler> is there an imagebin of this problem? I am running configs/sim/mini.ini against head and I don't see anything that looks wrong
[18:28:50] <rayh_> saw that error for a second and it died.
[18:28:54] <SWPadnos> change the loadrt line to 8 instead of traj[axes]
[18:29:49] <alex_joni> I think that's it SWPadnos
[18:30:06] <SWPadnos> hmmm - with -v, will the runscript display all hal commands (like that loadrt)?
[18:30:16] <jepler> SWPadnos: no, I don't think so
[18:30:19] <SWPadnos> I'd like to see that output
[18:30:28] <jepler> you'd have to pass an extra flag to halcmd to do that, not just to the runscript
[18:30:32] <jepler> good feature request though
[18:30:31] <SWPadnos> rigth
[18:30:34] <SWPadnos> right
[18:30:46] <SWPadnos> I don't know that halcmd has a -v option
[18:30:51] <SWPadnos> (or -v-like)
[18:31:12] <jepler> -v display results of each command
[18:31:23] <alex_joni> * alex_joni wonders what the connection between mini and motion controller is
[18:31:23] <SWPadnos> but it won't display the actual command
[18:31:27] <SWPadnos> emcsh
[18:31:29] <jepler> no, I don't think so
[18:31:30] <SWPadnos> ?
[18:31:48] <alex_joni> SWPadnos: think it barfs by not getting enough data?
[18:31:55] <alex_joni> or by looking at uninitialized stuff?
[18:31:57] <SWPadnos> ok, so to see what actually gets run, remove the loadrt line from the .hal file and stick it in the ini as a HALCMD= line
[18:32:03] <SWPadnos> alex_joni, I'm thinking something like that
[18:32:18] <alex_joni> SWPadnos: I fixed it by removing the max_joint=[TRAJ]AXES
[18:32:19] <SWPadnos> but I don't know - it's just a difference in the systems
[18:32:34] <alex_joni> or by changing [TRAJ]AXES to something else than 3
[18:33:03] <jepler> % emc_abs_cmd_pos 1
[18:33:03] <jepler> -0.9482
[18:33:03] <jepler> % emc_abs_cmd_pos 4
[18:33:03] <jepler> 2.12199579146e-314
[18:33:27] <alex_joni> ok, so it's not initialized
[18:33:32] <alex_joni> and mini barfs internally..
[18:33:35] <alex_joni> I'll fix it
[18:33:40] <jepler> all 3 of the unused axes have weird values on my system
[18:33:47] <jepler> maybe different ones than on yours
[18:33:56] <alex_joni> jepler: right.. guess they were assumed to be inited by motion
[18:34:00] <alex_joni> which doesn't anymore :)
[18:34:12] <SWPadnos> heh
[18:35:06] <alex_joni> oh darn, it's worse
[18:35:15] <SWPadnos> uh-oh
[18:35:31] <alex_joni> * alex_joni investigates
[18:35:44] <alex_joni> I think task reads data from uninitialized locations
[18:35:56] <SWPadnos> max_joints was added to unclutter the HAL listings, right?
[18:36:02] <alex_joni> right
[18:36:03] <SWPadnos> pin/param lists
[18:36:12] <alex_joni> and save some memory
[18:36:15] <SWPadnos> ok, so just leave everything alone except the export function
[18:36:27] <jepler> bzzt
[18:36:42] <alex_joni> well.. kinda, but the export function is the one that allocs the mem
[18:36:45] <SWPadnos> I wouldn't worry about the memory (unless that was the real reason for it ;) )
[18:36:52] <SWPadnos> oh, that is a problem ;)
[18:37:07] <alex_joni> but it shouldn't need to read axis 4 on systems with 3 axes
[18:37:13] <alex_joni> task does it right I think..
[18:37:22] <alex_joni> AXIS and tkemc too
[18:38:06] <rayh_> I'
[18:38:09] <SWPadnos> OT: I can't find the page that describes installation of emc2 on edgy - does anyone have a link?
[18:38:33] <rayh_> ve had mini sitting here a bit and I've got wild lines running all over the display.
[18:38:52] <jepler> SWPadnos: http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Installing_EMC2#Simulator_on_Ubuntu_6_10_Edgy_Eft
[18:38:57] <SWPadnos> ah - thanks
[18:39:11] <SWPadnos> hmmm. and the RTAISteps page may help if I want actual realtime
[18:39:18] <SWPadnos> (which I do)
[18:39:37] <rayh_> the position numbers don't change but the canvas gets really wierd lines.
[18:40:47] <alex_joni> rayh_: that's because A,B and C change
[18:40:55] <rayh_> when I shut down I saw a pile of these.
[18:41:06] <rayh_> program_units inch 0
[18:41:07] <rayh_> program_units inch 1
[18:44:58] <alex_joni> rayh_: that comes from mini.tcl
[18:44:58] <alex_joni> set units [emc_program_linear_units]
[18:44:59] <alex_joni> puts "program_units $units"
[18:44:59] <alex_joni> set jogType $jogIncrement
[18:45:24] <SWPadnos> hmmm. linuxcnc.org isn't very large font friendly
[18:45:27] <rayh_> But why is it changing.
[18:46:12] <rayh_> Is units changing when I switch active axis?
[18:46:20] <rayh_> I only have linear on the screen.
[18:46:32] <alex_joni> hmmm..
[18:47:08] <alex_joni> I get that when jogging
[18:47:25] <alex_joni> program_units inch 0 (for jogging on X)
[18:47:27] <alex_joni> program_units inch 1 (for jogging on Y)
[18:47:31] <alex_joni> program_units inch 2 (for jogging on Z)
[18:47:52] <jepler> oh -- "axis to jog"
[18:47:53] <jepler> puts "program_units $units $axisToJog"
[18:47:53] <jepler> puts "program_units $units $axisToJog"
[18:48:13] <alex_joni> confusing messages
[18:48:20] <rayh_> wow. tools and view tools is really going to confuse the crap out of newbee users.
[18:49:07] <alex_joni> what's tools & view tools ?
[18:49:18] <rayh_> tkemc does seem to work properly.
[18:49:38] <rayh_> Tools is a recent addition to tkemc.
[18:49:51] <rayh_> under there you find halscope and halshow.
[18:50:21] <rayh_> but I keep clicking that tools when I really want to change tool diameter.
[18:50:40] <cradek> rayh_: that's my fault - please rename as appropriate
[18:50:56] <rayh_> np.
[18:50:57] <cradek> I wanted not only AXIS users to be able to start the hal tools
[18:51:29] <rayh_> I like the ability.
[18:51:42] <alex_joni> maybe Utilities ?
[18:52:02] <rayh_> But what's going on with mini and why shouldn't we throw it out.
[18:52:30] <alex_joni> rayh_: I'm still investigating that
[18:52:31] <rayh_> I like utilities. that's good.
[18:52:48] <rayh_> thanks alex.
[19:12:22] <alex_joni> ok, I think I fixed it
[19:13:18] <jmkasunich> jepler: you around?
[19:13:41] <alex_joni> rayh: still around to test?
[19:13:54] <jmkasunich> problem with pluto_servo
[19:14:11] <jmkasunich> pluto_servo_rbf.h is generated at make time
[19:14:17] <jmkasunich> but it is also in CVS
[19:15:33] <jmkasunich> I think thats alright, IF everyone who changes the .rbf does a make before they commit, so both the .rbf and the .h file changes get committed
[19:18:41] <alex_joni> can someone else look if the mini backplot is ok now?
[19:20:10] <rayh> yep. i'm here.
[19:21:37] <rayh> i'll get it and test
[19:24:09] <alex_joni> * alex_joni reminds people he's not a tcl coder :/
[19:25:50] <jepler> jmkasunich: weird
[19:26:01] <jepler> it got removed in rev 1.6 but added on the branch in
[19:29:11] <rayh> alex_joni: Why has this just become an issue?
[19:29:41] <rayh> and why would an older config run it properly but the current not?
[19:31:16] <SWPadnos> hi Matt
[19:31:39] <alex_joni> rayh: the current config only sets up as many axes as are defined in the ini
[19:32:03] <alex_joni> an older config sets up 8 joints in the motion controller
[19:32:23] <alex_joni> the problem was with mini that queried the position for 6 axes, even if only 3 existed
[19:32:36] <rayh> I see.
[19:32:55] <rayh> But how did the older config set up 8
[19:33:03] <SWPadnos> motmod has 8 by default
[19:33:29] <SWPadnos> I'm not sure how the extra 2 map, but the first 6 are the same as XYZABC
[19:33:34] <rayh> oh the issue was in hal not in the ini file.
[19:34:05] <SWPadnos> sort of. motion wasn't updating any unused axes (when asked for only 3), but mini was still reading the data
[19:34:24] <jmkasunich> emcmot (the original motion module) had 8 axes - don't ask me why
[19:34:39] <SWPadnos> parallel axes?
[19:34:40] <alex_joni> technicly those are joints
[19:34:41] <jmkasunich> when it got ported over to emc2 we kept that "feature"
[19:34:45] <SWPadnos> alex_joni, right ;)
[19:34:53] <jmkasunich> right, but it didn't make the distinction
[19:35:14] <SWPadnos> at least, not everywhere
[19:35:15] <jmkasunich> jepler: thanks for figuring out the pluto thing - it was messing with the compile farm's mind
[19:35:23] <alex_joni> rayh: how confusing would it be for users if we change the ini?
[19:35:32] <alex_joni> AXIS_* -> JOINT_*
[19:35:39] <jmkasunich> if the farm scripts see changes to the local repository, they assume something is wrong, and pout about it
[19:35:49] <SWPadnos> alex_joni, quite, I imagine
[19:36:26] <SWPadnos> though it should be OK for 22, since ini changes are allowed for point revs
[19:36:28] <SWPadnos> 2.2
[19:36:49] <alex_joni> I'm thinking more like allowing both..maybe that's an alternative
[19:36:55] <jepler> jmkasunich: thanks for bringing it to my attention
[19:37:44] <SWPadnos> I'd want to see how many places read joint data. if it's only in inniaxis.ini, that's probably fine
[19:37:51] <SWPadnos> -n
[19:40:46] <rayh> okay I see the difference in the startup that caused the issue.
[19:40:58] <rayh> * rayh lights a joint.
[19:41:36] <alex_joni> try lighting an axis
[19:41:35] <alex_joni> :D
[19:41:46] <rayh> It will be confusing for a while.
[19:42:07] <rayh> They don't smell nearly as sweet.
[19:42:17] <jmkasunich> its one of those things.... we can confuse the majority of people for whom there is little or no distinction between joint and axis
[19:42:31] <jmkasunich> or we can really screw up those who really need to know the differnce
[19:42:44] <jmkasunich> (robot people, non-trivkins people, etc)
[19:42:58] <rayh> It would clarify joint v world a bit.
[19:43:05] <alex_joni> jmkasunich: that's why I'm starting to think to allow both
[19:43:46] <rayh> I saw some discussion about the [traj] limits applying to world and joint limits applying only to that axis.
[19:44:00] <jmkasunich> that joint ;-)
[19:44:54] <SWPadnos> rayh, that's an interesting point. what if you want to limit velocity in X to a value different from Y, on a non-trivkins machine?
[19:45:32] <SWPadnos> you would then need joint and world coordinate limits, in addition to overall TRAJ limits
[19:45:46] <alex_joni> don't forget A B C speed limits
[19:45:50] <alex_joni> in world coords
[19:45:51] <SWPadnos> sure
[19:45:51] <rayh> * rayh has a headache from thinking about the last thing.
[19:46:24] <alex_joni> here's another headache for you..
[19:46:32] <alex_joni> * alex_joni needs a way to switch to joint view from g-code
[19:46:34] <SWPadnos> I'm thinking about a robot or something that has an actuator - like a fork. left/right you can really move, but forward/back you can't or the item may fall out of the fork
[19:46:44] <alex_joni> s/joint view/joint control/
[19:47:00] <SWPadnos> alex_joni, that would likely be a big spec change
[19:47:12] <rayh> That linkage would certainly make more sense.
[19:47:12] <alex_joni> SWPadnos: I know :(
[19:47:33] <alex_joni> but you can't really drive a puma without
[19:47:43] <SWPadnos> and there are no letters left (except for E) :)
[19:47:58] <alex_joni> maybe a modal like G91
[19:48:15] <alex_joni> then XYZABC refer to J0..5 (although that's bad..)
[19:48:31] <alex_joni> * alex_joni writes other interp for robots on his wishlist
[19:49:03] <rayh> Pose is more adquately described as xyzrpw
[19:49:05] <SWPadnos> heh
[19:50:03] <alex_joni> SWPadnos: there are singularities through which you can't move a puma in worldview
[19:50:14] <alex_joni> at least not with the current kins.. it freaks out
[19:50:39] <SWPadnos> hmmm. what kind of pose do they show up at?
[19:51:11] <alex_joni> that's a tough one :)
[19:51:38] <SWPadnos> heh
[19:51:47] <SWPadnos> it's a singularity, dammit!
[19:52:01] <alex_joni> I know the joint locations.. but pose..
[19:52:15] <alex_joni> x_nr y_nr -inf ...
[19:52:17] <alex_joni> :-)
[19:52:29] <SWPadnos> heh
[19:52:38] <alex_joni> a funny tilted 8
[19:52:56] <SWPadnos> do you think it's a +/- pi thing?
[19:53:03] <rayh> A stewart platform has well defined singularities but we have no way of limiting motion around one.
[19:53:52] <alex_joni> SWPadnos: sure is
[19:54:01] <SWPadnos> yeah - I was just thinking about the discussions we had about workspace "keepouts"
[19:54:25] <rayh> They seem to be related
[19:55:33] <rayh> Like a very complex work envelope.
[19:55:50] <SWPadnos> yep - clamp avoidance and such
[19:56:35] <rayh> It is much larger than a single joint limit
[19:56:54] <SWPadnos> yeah - it's volumes to avoid
[19:56:58] <rayh> Yep.
[19:57:12] <rayh> and with a lathe chuck barriers is a biggie.
[19:57:19] <SWPadnos> and also more complex limits than "this parallelopiped XxYxZ in size"
[19:58:11] <rayh> at least in the case of a hexapod
[19:58:12] <alex_joni> SWPadnos: http://www.cloos.de/img/produkte/Systemloesungen/ROMAT/R320-350-410_Ue_Skizze.jpg
[19:58:43] <SWPadnos> that's a lotta axes
[19:58:47] <alex_joni> 6
[19:59:00] <SWPadnos> and presumably most/all of them can't execute a full rotation
[19:59:18] <SWPadnos> or at least, not beyond one rotation
[19:59:23] <SWPadnos> (ie, no sliprings)
[19:59:30] <alex_joni> Axa 1:340 ° (opþional 450 °)
[19:59:30] <alex_joni> Axa 2:215 °
[19:59:30] <alex_joni> Axa 3:290 °
[19:59:30] <alex_joni> Axa 4:358 °
[19:59:30] <alex_joni> Axa 5:270 °
[19:59:32] <alex_joni> Axa 6:600 °
[19:59:34] <rayh> that would be joint limits and would work now.
[20:00:00] <SWPadnos> yes, mostly
[20:00:02] <alex_joni> rayh: yes, but you can't limit it to go to X2300 Y2100 Z1800 A170 B20 C0
[20:00:17] <alex_joni> only after trying to get there you'll get joint errors
[20:00:18] <rayh> exactly
[20:00:35] <alex_joni> but task (commanding in carthesian coords) will be happy
[20:00:43] <alex_joni> trying to drive it
[20:00:46] <SWPadnos> kins needs to be able to tell motion the min and max extent of a given move
[20:00:55] <SWPadnos> for each joint
[20:00:54] <rayh> there are combinations of positions that must be further constrained.
[20:01:32] <SWPadnos> I don't think that's correctly done even for trivkins (ie, for an arc, are there mod echecks than start/end and maybe midpoint?)
[20:01:46] <SWPadnos> that was supposed to be "more checks ..."
[20:03:10] <alex_joni> SWPadnos: fixed the Docs page on linuxcnc.org
[20:03:18] <SWPadnos> of course, that's not a kins operation at the moment - it's traj/motion
[20:03:20] <SWPadnos> thanks
[20:03:33] <rayh> Hey alex. Thanks for fixing mini.
[20:04:14] <alex_joni> rayh: np, glad it works
[20:04:27] <alex_joni> * alex_joni feels proud to understand enough tcl to fix 6 lines :D
[20:05:59] <rayh> Glad also that we now have axis pins only for the number of joints we have defined.
[20:06:25] <rayh> I'd never have thought to connect the mini failure with the change there though.
[20:07:47] <SWPadnos> * SWPadnos feels proud that he can see differences in a diff file
[20:07:51] <SWPadnos> :)
[20:08:57] <SWPadnos> jepler, you have an edgy install (right?) - is that x86 or x86_64?
[20:09:19] <rayh> We gotta run to town. Catch you all later.
[20:17:05] <jepler> SWPadnos: x86 .. I think (vmware on an x86-64 machine)
[20:19:40] <jepler> SWPadnos: yes, x86
[20:35:41] <cradek> whee, jogwheel
[20:38:46] <SWPadnos> jepler, ok - I guess I'm in mostly uncharted territory on x86_64 + edgy then :)
[20:39:04] <SWPadnos> no SMP even]
[20:40:51] <SWPadnos> cradek, whee as in "you got the jogwheel working on your physical hardware" or some software thing? ;)
[20:41:10] <cradek> on physical hardware
[20:41:14] <SWPadnos> cool!
[20:41:23] <cradek> well it had worked before, but the mill has been "apart" for a while
[20:41:28] <SWPadnos> right.
[20:41:39] <SWPadnos> cool though - I think I bought my jogwheel at the same place you did :)
[20:41:45] <SWPadnos> hmm - maybe not
[20:42:00] <cradek> alex_joni: your changes does fix the machine-on problem! I just edited /usr/bin/emc of my 2.1.1 install
[20:42:14] <alex_joni> great..
[20:43:01] <cradek> you backported that, right?
[20:43:10] <alex_joni> right
[20:43:17] <cradek> cool
[20:43:19] <alex_joni> I also fixed mini ;)
[20:43:43] <cradek> I saw - thanks
[20:43:57] <alex_joni> (after breaking it first) :D
[20:43:56] <cradek> I guess we can't blame petev?
[20:43:59] <cradek> yeah :-)
[20:44:19] <alex_joni> I'd say it was bad design :P
[20:44:29] <alex_joni> the mini backplotter is copyrighted by paul_c
[20:44:53] <SWPadnos> incidentally - any thoughts on the error printing problem petev was working on?
[20:45:04] <cradek> not fair blaming the guy who's not here
[20:45:14] <SWPadnos> oh - that's normal
[20:45:19] <jepler> fair? bah
[20:45:22] <alex_joni> cradek: I was only kidding..
[20:45:25] <SWPadnos> I think the expression is "he's not here, he's the asshole"
[20:45:27] <alex_joni> should have tested it more
[20:45:35] <alex_joni> SWPadnos: where did you hear that?
[20:45:56] <SWPadnos> way back when at my old company :)
[20:46:08] <SWPadnos> oh- he's not here - it must be his fault
[20:46:14] <SWPadnos> several variations
[20:47:20] <alex_joni> ah-ha
[20:58:28] <cradek> strange - there's an interaction between jogwheel and keyboard jogging
[20:58:56] <SWPLinux> two points of control ...
[20:58:58] <cradek> sometimes if you play with the wheel while in a jog, it speeds up
[21:00:13] <SWPLinux> odd
[21:00:28] <SWPLinux> hmmm - I see some errors in the code petev sent
[21:01:13] <SWPLinux> but he's right - error returns from ini loads aren't always checked
[21:01:14] <alex_joni> he's not here ..
[21:01:19] <SWPLinux> nope
[21:01:19] <alex_joni> :-)
[21:01:22] <SWPLinux> heh
[21:01:41] <SWPLinux> neither is JonE, but I'm not sure we can pin this one on him ;)
[21:08:43] <cradek> another comp bug: http://pastebin.ca/389609
[21:09:21] <alex_joni> nan2 doesn't sounds good
[21:10:25] <cradek> (run with a .5 dia tool)
[21:10:53] <SWPLinux> hmmm. is the arc through the original endpoint checked for validity?
[21:11:16] <SWPLinux> oh - you used enough 9's to make ir pass the test
[21:11:18] <SWPLinux> it
[21:11:38] <cradek> yeah if you make it .25, it errors
[21:11:48] <cradek> but the .24999 passes whatever tests and then bombs
[21:12:07] <SWPLinux> it's actually an invalid acr, but not invalid ehough to be flagged
[21:12:10] <SWPLinux> arc
[21:12:19] <SWPLinux> gah
[21:12:21] <cradek> yes
[21:12:50] <SWPLinux> and you end up with a centerpoint somewhere beyond China? ;)
[21:13:04] <cradek> well, following errors
[21:13:08] <SWPLinux> odd
[21:13:15] <cradek> I haven't even looked at the output yet
[21:13:21] <alex_joni> hmm.. it didn't bomb here
[21:13:26] <SWPLinux> * SWPLinux is looking at ini error returns instead of comp right now
[21:13:31] <alex_joni> but it produced a weird result
[21:14:01] <cradek> alex_joni: in sim you may not see it - I think the tool flies away briefly
[21:14:06] <alex_joni> d5 is the diameter of tool #5 .. right?
[21:14:10] <cradek> yes
[21:14:14] <SWPLinux> hmmm. kp_enter should be bound the same as enter for pickconfig.tcl
[21:14:14] <cradek> make tool 5 .5inch
[21:14:20] <alex_joni> yeah, I did that
[21:14:28] <alex_joni> I get a square corner
[21:15:05] <cradek> that's right, except for the flying away that I think is happening
[21:18:01] <SWPLinux> it appears correct here as well, both in preview and when run (in sim)
[21:19:09] <alex_joni> yeah, but in stepper it jumps
[21:19:22] <alex_joni> it jumps in all 3 directions
[21:19:22] <alex_joni> even Z
[21:19:40] <SWPLinux> cool!
[21:19:48] <alex_joni> joint 1 following error
[21:19:50] <alex_joni> joint 2 following error
[21:19:50] <alex_joni> joint 0 following error
[21:19:50] <alex_joni> emc/task/taskintf.cc 595: Error on axis 0, command number 322
[21:19:50] <alex_joni> emc/task/taskintf.cc 595: Error on axis 1, command number 322
[21:19:52] <alex_joni> emc/task/taskintf.cc 595: Error on axis 2, command number 322
[21:22:42] <SWPLinux> weird - I'm trying to run ./bin/rs274 and the terminal beeps when I press "r"
[21:23:04] <SWPLinux> I can hit tab and get a list of executables, and I can type many other letters/symbols
[21:24:00] <SWPLinux> crap. I think I accidentally ran "bind rs" in that terminal
[21:59:51] <SWPadnos> geez Matt - make up your mind ;)
[22:30:05] <cradek> cut the first part with emc2.1.1
[22:30:56] <SWPadnos> ?
[22:31:18] <cradek> on the mill
[22:31:25] <SWPadnos> ah :)
[22:31:28] <SWPadnos> cool
[22:31:32] <alex_joni> cradek: any issues?
[22:32:21] <cradek> nope just those we already fixed
[22:32:41] <cradek> wonder if we should make 2.1.2 today
[22:33:46] <cradek> why is jack ensor messing with the SMI stuff? does he really have a SMI problem?
[22:37:49] <SWPadnos> I'm not sure he knows what kind of problem he has, nor how to find out ....
[22:38:10] <cradek> unless he's sure he has an SMI problem he's wasting a lot of effort (but you know this already)
[22:39:01] <SWPadnos> I think he mentioned his motherboard brand (QDI?), but I'm not sure what other hardware info he's mentioned
[22:39:28] <cradek> I suspect he's getting any old rt problem, and settled on SMI to try to fix it
[22:40:05] <SWPadnos> no - I think someone (Alex?) mentioned SMI as something that can cause RT overruns over long periods (64 seconds apart)
[22:40:14] <cradek> yes
[22:40:35] <cradek> I understand, but I'm saying that's probably not the problem he has
[22:40:40] <alex_joni> but it depends on him if he can count to 64 seconds
[22:40:53] <cradek> *sigh*
[22:41:34] <cradek> I really like jepler's quick gcode reference (and how it is on the menu) - I use that all the time
[22:42:29] <alex_joni> nice ;)
[22:42:39] <alex_joni> jepler: wonder if this would be any good for stippler: http://shop.elv.de/output/controller.aspx?cid=74&detail=10&detail2=14163&refid=
[22:44:03] <SWPLinux> oh - the applications menu - I was looking for it in Axis
[22:55:41] <cradek> does anyone want to look at the degenerate case in comp (nan2.ngc)? I'm tired of working on comp - if nobody else wants to, I'm tempted to make 2.1.2 release today
[22:56:15] <cradek> although jmk might want to do something to stepgen too
[22:56:20] <cradek> maybe I should wait
[22:56:31] <SWPadnos> yeah - I'd wait for at least the simple fix to stepgen
[22:56:45] <cradek> ok
[22:57:53] <alex_joni> cradek: I might give it a shot tomorrow
[22:57:56] <alex_joni> the comp stuff..
[22:58:11] <alex_joni> but maybe you can give me some hints where the magic happens
[22:58:21] <cradek> no pressure, it's been that way for a long time
[22:58:35] <SWPadnos> I'm about to respond to Stuart Stevenson - is this correct?
[22:58:37] <SWPadnos> The config files should work fine. You need to put the connections to AXIS in a separate hal file, and load that file with a line in the ini file as follows:
[22:58:38] <SWPadnos> [HAL]
[22:58:41] <SWPadnos> POSTGUI_HALFILE = my_hal_file.hal
[22:58:43] <cradek> the magic is all in interp_convert.cc
[22:58:56] <cradek> SWPadnos: yes that's what I did to get the jog wheel to work
[22:59:26] <SWPLinux> ok
[23:00:56] <alex_joni> cradek: and the error in nan2 is convert_arc related?
[23:01:05] <cradek> yes I think so
[23:01:17] <cradek> I think it will be in convert_arc_comp2
[23:01:34] <cradek> there may be a similar case in arc_comp1 (if the arc is the entry move)
[23:03:07] <alex_joni> oh fsck :)
[23:03:54] <alex_joni> this means I need to take out pen&paper
[23:09:26] <cradek> alex_joni: it's probably some terrible way the different tolerances interact
[23:13:30] <alex_joni> yuck
[23:13:55] <alex_joni> did you try making it verbose and check the ARC_FEEDs it calls ?
[23:14:08] <cradek> just now!
[23:14:09] <cradek> Issuing EMC_TRAJ_LINEAR_MOVE -- (+220,+88, +0,0.902616,-3.909346,0.079056,0.000000,0.000000,0.000000, +2,0.566700,0.566700,20.000000,)
[23:14:11] <cradek> Issuing EMC_TRAJ_CIRCULAR_MOVE -- (+221,+140, +0,0.902616,-3.909346,0.079056,0.000000,0.000000,0.000000,0.902616,-3.909346,0.079056,0.000000,0.000000,0.039370, -1, +3,1.000000,0.566700,20.000000,)
[23:14:30] <cradek> it looks like it's exactly degenerate - the start, center, and end points are the same
[23:14:42] <alex_joni> oh, so too small of a circle
[23:14:47] <cradek> yes
[23:14:57] <alex_joni> usually it catches a circle like that.. right?
[23:15:01] <cradek> maybe comp should just skip issuing the arc if it's too tiny
[23:15:01] <alex_joni> if you specify it with G2
[23:15:08] <alex_joni> (no comp involved)
[23:15:14] <cradek> let me try
[23:15:29] <cradek> error: "zero radius arc"
[23:15:44] <cradek> oh!!
[23:16:00] <cradek> when you use r format, it doesn't give that error, you get "isnan error in emcTrajCircularMove" on stdout
[23:16:03] <cradek> so that's a second bug
[23:16:14] <cradek> => g0x0y0; g2x0y0r0
[23:16:34] <cradek> should give an interp error, but it doesn't
[23:16:45] <alex_joni> oh-oh :)
[23:17:02] <alex_joni> I really wonder how it gets as far as emcTrajCircularMove
[23:17:16] <alex_joni> theta1 = atan2(canonEndPoint.y - center.y, canonEndPoint.x - center.x);
[23:17:21] <alex_joni> shouldn't that barf?
[23:17:29] <alex_joni> atan2(0,0) ?
[23:17:57] <cradek> probably get theta1=nan
[23:19:34] <cradek> a test shows theta1 = 0