Back
[01:01:36] <SWPadnos> jepler, thanks. I had looked at the comp wiki page, and the example was a joystick driver or something, so I wans't sure about realtime
[01:53:39] <jepler> hmph -- index.html isn't getting rebuilt just by adding more .1 manpages
[03:20:25] <SWPadnos> hi Pete
[03:20:28] <petev> hi
[03:20:48] <SWPadnos> what's up with you these days?
[03:21:02] <petev> busy with work
[03:21:07] <petev> I just updated to the trunk head rev and seem to have a problem with the PID maxoutput param setting
[03:21:10] <SWPadnos> heh - I know the feeling all too well
[03:21:24] <SWPadnos> what's the problem?
[03:21:28] <petev> it looks like the value from the HAL file is getting overwritten with something calced from max velocity
[03:21:44] <petev> but this doesn't leave the PID any headroom to catch up on rapids
[03:21:45] <SWPadnos> mmm
[03:21:52] <petev> was some change made in this area?
[03:22:10] <petev> I'm grabbing the latest source now on my doze box to take a look
[03:22:13] <SWPadnos> dunno. I don't remember seeing any changes there
[03:22:38] <petev> hmm, HAL does setp with 3.333 and I see 2.0 when EMC is started
[03:22:40] <SWPadnos> the last change was 3 weeks ago - I fixed a typo in a comment ;)
[03:22:56] <petev> yeah, I haven't updated in a while
[03:23:17] <SWPadnos> the previous change was in March of this year
[03:23:59] <petev> let me start a sim and see it I can confirm things
[03:25:02] <SWPadnos> there are no assignments to maxoutput in the pid source, except to set it to 0.0 at initialization
[03:25:21] <petev> yeah, I think it must be somewhere in the init code
[03:25:41] <SWPadnos> at least none where it's written by name - I guess it's possible there's a stray pointer somewhere, but that seems unlikely
[03:26:05] <petev> no, Im pretty sure it's getting a value calced from max velocity
[03:26:07] <SWPadnos> no, that's the only assignment. addr->maxoutput = 0.0;
[03:26:22] <petev> I don't think it's in PID
[03:26:26] <SWPadnos> grep for maxoutput in all your config files, it may be there twice
[03:26:41] <petev> I'll check, but I really doubt it
[03:26:45] <petev> I haven't touched them
[03:28:17] <SWPadnos> are you using at_pid or pid?
[03:28:44] <petev> both are the same, but I think it's a bug in the checked in boss.ini file
[03:28:46] <petev> hang on
[03:28:59] <petev> I mean boss.hal file
[03:29:58] <SWPadnos> yep - maxoutput is assigned both MAX_OUTPUT then MAX_VELOCITY
[03:30:28] <petev> yeah, the update must have over written my local file and I had never checked in the latest
[03:30:31] <petev> I'll fix it now
[03:30:37] <SWPadnos> okie dokie
[03:30:53] <SWPadnos> so, I finally got that analog card working right
[03:31:10] <SWPadnos> I was burned by the Xilinx tools using incremental compile by default
[03:31:27] <petev> dang, that sux
[03:31:40] <SWPadnos> yep. about a week of nearly sleepless nights sux
[03:31:48] <petev> sheesh
[03:32:09] <SWPadnos> but it's working great now - around 165 KHz scanning of all 6 inputs and 8 outputs, with simultaneous updates
[03:32:25] <SWPadnos> at 16 bits even
[03:32:40] <petev> cool
[03:33:04] <SWPadnos> now all I have to do is write the driver and the customer's application code by 9:00 AM tomorrow ;)
[03:33:20] <petev> no problem ;-)
[03:33:32] <SWPadnos> yeah, almost 9-1/2 hours to go - no sweat
[03:33:58] <SWPadnos> hey - you wouldn't happen to have a smallish machine wround, would you?
[03:34:01] <SWPadnos> around
[03:34:07] <SWPadnos> or is the boss it?
[03:34:22] <petev> boss it the only mill I have
[03:34:37] <petev> its not real big
[03:34:39] <petev> what did you need?
[03:34:56] <SWPadnos> it's too big to move into a conference room for a demo though ;)
[03:35:06] <petev> yes, it is
[03:35:38] <SWPadnos> Bill Gatliff popped onto the emc-board channel asking if someone might be able to do a talk at ESC next year, so I volunteered
[03:35:51] <petev> hmm
[03:36:01] <petev> how big is Jim's machine?
[03:36:06] <SWPadnos> jymmm has a machine, but it's a router
[03:36:08] <SWPadnos> heh
[03:36:31] <SWPadnos> it's small enough - I've asked him if I can use it, and he said it's OK, but it is a homebrew-looking thing
[03:36:39] <SWPadnos> which could be good or bad with that crowd
[03:37:34] <petev> hmm
[03:37:36] <DanielFalck> ask rayh if he has any small mills to use
[03:38:16] <SWPadnos> I could do that, byt ray is about 2000 miles away from the conference, and pete and jim are within 10 miles ;)
[03:38:20] <SWPadnos> but
[03:38:34] <DanielFalck> ok, sorry wrong side of country
[03:38:41] <SWPadnos> heh
[03:39:18] <SWPadnos> hmmm. actually, I may be able to arrange a mini-mill from some company, come to think of it
[03:39:44] <SWPadnos> but I suppose I should concentrate on tonight's job first, then writing the proposal, then dealing with procuring a machine if it's accepted.
[03:39:46] <DanielFalck> I have a large mill in my garage- near Portland, Oregon. If you ever have a conference here (near my garage)
[03:39:52] <SWPadnos> heh
[03:40:01] <SWPadnos> can I bring my brother in law over for a demo?
[03:40:08] <DanielFalck> sure
[03:40:09] <SWPadnos> he's in Beaverton
[03:40:23] <DanielFalck> I'm actually in Beaverton/Aloha
[03:40:30] <SWPadnos> oh, almost next door then
[03:41:03] <SWPadnos> let's see - there's an Albertson's near his neighborhood
[03:41:08] <SWPadnos> but that probably doesn't say much
[03:42:26] <DanielFalck> there might even be a Powell's near him, I bet
[03:42:37] <SWPadnos> and maybe Schlotsky's Deli
[03:43:21] <DanielFalck> come visit, if you're in the area
[03:43:45] <SWPadnos> will do. it's been a while, but we're probably due in the next year or two
[03:44:13] <DanielFalck> ray and paul have stayed with us in the past
[03:58:19] <petev> SWPadnos, can you run a sim to confirm something?
[03:58:37] <petev> looks like tkemc doesn't read G54 offsets correctly on startup
[03:58:46] <SWPadnos> I can't really check that at the moment
[03:58:57] <petev> EMC reads them correct, but both relative and machine show the same in tkemc
[03:59:18] <petev> yeah, I forgot you had the deadline
[03:59:30] <SWPadnos> also, I know almost nothing about G54 or tkemc ;)
[03:59:51] <petev> if I new anything about tcl, I might try and figure it out
[04:00:06] <petev> but last time I tried to do some tcl, it gave me a headache
[04:02:38] <SWPadnos> heh
[04:02:57] <SWPadnos> are you surethat G54 is supposed to persist across restarts?
[04:03:10] <SWPadnos> or is that default machine coords?
[04:03:13] <petev> yes, and EMC seems to get it right
[04:03:17] <petev> it just doesnt' display right in tkemc
[04:03:37] <petev> if I do a move, emc goes to the position with the offset in effect
[04:03:46] <petev> and tkemc shows g54 is active
[04:04:00] <petev> but the relative coord display in tkemc is wrong
[04:04:06] <petev> it's showing machine coords
[04:04:15] <SWPadnos> ok. I certainly can't help there
[04:04:31] <petev> loading the same offsets again fixes tkemc, but has no effect on emc
[04:04:39] <petev> yeah, the tcl code is ugly
[11:01:04] <alex_joni> morning fenn
[11:58:15] <fenn> howdy.
[11:58:31] <fenn> computer just turned off on its own
[12:02:07] <alex_joni> odd.. :)
[18:17:55] <skunkworks> wooo hoo - the guy finally paid me for the engraver.
[18:18:12] <skunkworks> fenn: good mornging
[18:18:15] <skunkworks> morning
[18:41:44] <alex_joni> morning?
[18:43:25] <alex_joni> cradek: around?
[18:43:38] <alex_joni> * alex_joni has some further info regarding the small circle stuff..
[18:44:05] <skunkworks> uh oh...
[18:45:07] <alex_joni> it'
[18:45:12] <alex_joni> it's a mm config
[18:45:19] <alex_joni> I'm putting it on pastebin now
[18:45:58] <alex_joni> http://pastebin.ca/741464
[18:46:23] <alex_joni> he says the following snippet takes about 70s to complete:
[18:46:25] <alex_joni> F1000
[18:46:25] <alex_joni> G91
[18:46:26] <alex_joni> G03 X0 Y0 Z-1 I0.00001 J0
[18:46:48] <cradek> helix, not circle then
[18:47:10] <cradek> does the I0.00001 circle do it too?
[18:47:33] <alex_joni> yes
[18:47:40] <cradek> same 70s?
[18:48:07] <alex_joni> he said the reported velocity goes down from 1000 to 1.286
[18:48:18] <alex_joni> (I assume that's mm/min)
[18:48:28] <SWPadnos> how can he even do that move with those settings?
[18:48:35] <SWPadnos> he's got INPUT_SCALE at 533.333
[18:48:58] <SWPadnos> and MIN_FERROR at 0.01
[18:49:28] <alex_joni> SWPadnos: weeell..
[18:49:35] <alex_joni> maybe it's G20 ? :P
[18:49:37] <cradek> g3x0y0i-.000001f100
[18:49:46] <alex_joni> (debugging through a forum sucks)
[18:49:47] <cradek> I don't see any problem in sim/axis (inch)
[18:50:48] <alex_joni> * alex_joni tries stepper_mm
[18:50:55] <cradek> SWPadnos: regardless of whether he gets any steps or not, emc should make the move in the right time
[18:51:15] <SWPadnos> sure, it just seems that the move should degenerate into a linear Z plungs
[18:51:21] <SWPadnos> plunge
[18:51:26] <cradek> sure, it will
[18:52:08] <cradek> ohhhhh
[18:52:16] <cradek> I get something wrong when I try the helix
[18:52:17] <cradek> the arc works fine
[18:52:26] <cradek> * cradek grumbles about bad bug reports
[18:52:40] <alex_joni> * alex_joni passes teh grumbles on
[18:53:11] <cradek> oh wait, my config is screwy
[18:53:19] <cradek> I took some Z stuff out to test the last bug :-/
[18:54:29] <cradek> yeah I get what appears to be a wrong feed if the arc part of the helix is tiny
[18:55:30] <alex_joni> g3x0y0i-.000001f100 is way slower than g3x0y0i-.1f100
[18:56:54] <cradek> I'm not seeing that
[18:57:02] <alex_joni> I tried axis_mm
[18:57:28] <alex_joni> err.. wait
[18:57:35] <alex_joni> I had an z in there.. it dissapeared
[18:57:42] <alex_joni> disappeared?
[18:58:47] <alex_joni> ahh.. I think I know what happens
[18:59:06] <alex_joni> cradek: emccanon.cc line 1085
[18:59:39] <cradek> ohhhhh
[19:00:05] <cradek> man I hope I didn't write that crap
[19:00:07] <alex_joni> err.. no
[19:00:23] <alex_joni> ini_maxvel is the one that remembers the min value
[19:00:27] <cradek> 1.44 (cradek 12-Mar-06): if(axis_len > 0.001) {
[19:00:30] <cradek> dangit
[19:00:32] <alex_joni> * alex_joni feels blind
[19:01:18] <cradek> but, I don't think that's the problem either
[19:01:30] <alex_joni> what's the printf for double?
[19:01:39] <cradek> %g
[19:01:42] <alex_joni> thanks
[19:03:58] <alex_joni> the canon stuff seems to produce the right values
[19:04:26] <alex_joni> I get the same params to EMC_TRAJ_CIRCULAR_MOVE for both moves (the slow and the fast one)
[19:05:51] <cradek> yeah I was just checking that stuff too
[19:05:58] <cradek> it does look right
[19:06:03] <alex_joni> * alex_joni points at motion/tp
[19:06:17] <cradek> * cradek goes to find some coffee while alex continues to find the bug
[19:07:57] <cradek> Issuing EMC_TRAJ_CIRCULAR_MOVE -- (+221,+168, +0,0.000000,0.000000,-1.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,-0.000010,0.000000,-1.000000,0.000000,0.000000,0.039370, +0, +3,1.200000,1.200000,20.000000, +0,)
[19:08:05] <cradek> I don't know what all these numbers are, but 1.2 and 20 are vel/acc
[19:08:21] <cradek> the 0.03937 worries me - wonder what it is
[19:08:34] <SWPadnos> mm vs inch, of course
[19:08:35] <cradek> it's always a bad sign when you see that
[19:08:56] <SWPadnos> divide mm by inch^2, then add (or subtract) sqrt(pi)
[19:09:05] <SWPadnos> or get more coffe
[19:09:08] <SWPadnos> e
[19:09:09] <cradek> uh
[19:09:22] <SWPadnos> I'll take option 2
[19:09:22] <cradek> I know what that number is (1/25.4) but seeing it here is suspicious
[19:09:24] <SWPadnos> heh
[19:09:56] <cradek> circularMoveMsg.normal.z = TO_EXT_LEN(normal.z);
[19:09:59] <cradek> I bet it's this
[19:10:20] <cradek> probably harmless, but also probably wrong
[19:11:28] <cradek> normal = {x = 0, y = 0, z = 0.03937007874015748},
[19:11:29] <alex_joni> Issuing EMC_TRAJ_CIRCULAR_MOVE -- (+221,+168, +0,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,-0.000000,0.000100,0.000000,0.000000,0.000000,1.000000, +0, +3,16.666667,30.480000,508.000000, +0,)
[19:11:29] <cradek> yep
[19:12:10] <alex_joni> running mm only, I don't get that
[19:12:37] <cradek> right
[19:12:53] <alex_joni> so even if that's wrong, it's not the cause of this..
[19:12:59] <cradek> right
[19:13:29] <alex_joni> btw, he reported exact stop vs. blending doesn't make any difference
[19:13:54] <cradek> I'm not surprised since we are even seeing it in mdi
[19:13:59] <alex_joni> right
[19:15:10] <alex_joni> ferror doesn't do anything
[19:15:19] <alex_joni> if I go to 0% it obviously stops
[19:15:35] <alex_joni> but over 4-5%? it stays at the same speed (limited by something else)
[19:16:01] <alex_joni> make that 1%
[19:16:24] <cradek> strange - at tpAddCircle I get turn=11
[19:16:24] <SWPadnos> heh - there's that "debug_velacc = 1" thing again
[19:16:40] <cradek> oh hell did I do that again!?
[19:16:43] <cradek> coffee, now
[19:16:46] <SWPadnos> yep :)
[19:16:47] <alex_joni> leave it in for nwo :D
[19:16:48] <alex_joni> now
[19:17:20] <cradek> something is wrong with "turn" and then I bet pmCircleInit screws something up
[19:17:43] <alex_joni> what's turn?
[19:18:15] <cradek> an argument to pmCircleInit which I think should be 1 or -1 for any arc/helix from gcode
[19:19:39] <alex_joni> depending on direction.. right (read it up in pmCircleInit)
[19:20:13] <alex_joni> it then scales the normal based on the turn value
[19:22:34] <alex_joni> mind a longer paste? or should I pastebin?
[19:23:57] <alex_joni> http://pastebin.ca/741504
[19:26:50] <alex_joni> * alex_joni watches a show about XM312
[19:28:13] <alex_joni> that's one crazy gun
[19:55:03] <alex_joni> cradek: what is pmSqrt(tc->maxaccel *tc->coords.circle.xyz.radius) ?
[19:56:04] <cradek> constrain the centripetal accel
[19:56:22] <cradek> is that the problem?
[19:56:26] <alex_joni> newvel = ...
[19:56:51] <alex_joni> dunno, you're better with gdb than me
[19:57:03] <alex_joni> * alex_joni uses the "debug by staring" method
[19:57:24] <cradek> :-)
[20:00:45] <alex_joni> * alex_joni loves adding printf's into tcRunCycle
[20:01:51] <alex_joni> newvel1=16.6667
[20:01:53] <alex_joni> newvel2=0.159374
[20:02:03] <alex_joni> the first is before the centripetal clamp
[20:03:15] <cradek> oh hmmmm
[20:03:18] <cradek> that's mm/sec
[20:03:35] <cradek> correct for the circle, but is it also correct for the helix?
[20:03:47] <cradek> maybe it is!
[20:04:22] <cradek> I bet it's technically right, but unnecessary
[20:04:31] <SWPadnos> it seems that should be the velocity in the plane of the circle
[20:04:46] <SWPadnos> but the helical component should be combined with that for the overall vel
[20:05:06] <alex_joni> yes, that should be checked against the XY vel, not against the tooltip vel
[20:05:16] <cradek> you guys are right
[20:05:39] <cradek> this is stupid. that test can be in emccanon.
[20:05:47] <cradek> (with the others)
[20:10:45] <alex_joni> removing that check makes it work right
[20:12:33] <alex_joni> SWPadnos: are you familiar with the XM312?
[20:13:12] <alex_joni> .50 cal
[20:13:20] <SWPadnos> no - I just looked it up.
[20:13:44] <cradek> alex_joni: I recommend moving the centripetal test into emccanon.cc (and fixing it)
[20:13:54] <SWPadnos> the old .50 cal had an effective range of "as far as the eye can see", so I'm not sure why they say this one is more accurate ;)
[20:14:40] <alex_joni> cradek: yeah, me too :D
[20:15:25] <alex_joni> SWPadnos: better eyes
[20:15:40] <alex_joni> they say 2000m is no issue
[20:25:01] <alex_joni> cradek: any idea how to fix it?
[20:27:22] <SWPadnos> newvel2 is detived from both X and Y, right?
[20:27:25] <SWPadnos> derived
[20:27:45] <alex_joni> vel = acc * radius
[20:27:58] <SWPadnos> is that already limited by machine constraints?
[20:28:00] <alex_joni> let me start with stating what's in emccanon first..
[20:28:02] <SWPadnos> X+Y acc/vel
[20:28:14] <alex_joni> we're in XY_plane
[20:28:23] <alex_joni> we check for min(x_vel, Y_vel)
[20:29:00] <alex_joni> if z travels more than 0.001 then min(x_vel,y_vel,z_vel)
[20:29:47] <alex_joni> (that's because it's a bit conservative... it could pick a slightly faster speed, and not violate machine constraints)
[20:29:58] <cradek> I think like the rest of the stuff in emccanon, calculate times based on each constraint being matched, then use the max time
[20:30:08] <alex_joni> right
[20:30:14] <cradek> the new constraint is the centripetal one
[20:30:14] <SWPadnos> sounds good to me.
[20:30:18] <SWPadnos> print it!
[20:30:33] <SWPadnos> I think I need to eat. bbl
[20:30:48] <cradek> beware I think some of those are time^2, be careful
[20:31:09] <alex_joni> * alex_joni still wonders how to express the centripetal constraint as time
[20:31:30] <cradek> * cradek loans alex_joni his calculus textbook
[20:33:47] <alex_joni> ok, the point is to have centripetal_accel smaller than max_accel.. right?
[20:34:19] <cradek> yes
[20:34:49] <cradek> (sorry for not wanting to figure this out right now)
[20:35:10] <cradek> the vel/acc you need to calculate are the ones along the helix
[20:36:54] <alex_joni> Tcircle = 2 * pi * r / vel_circle
[20:37:13] <alex_joni> Thel = dhel / vel_helix
[20:37:25] <alex_joni> T = Tcircle + Thel ?
[20:38:19] <SWPadnos> T=max(Tcircle, Thel)
[20:39:33] <alex_joni> err.. right
[20:42:06] <SWPadnos> damn. I never ate
[20:42:09] <SWPadnos> bbl
[21:03:00] <alex_joni> cradek: here it goes.. hope it's right
[21:10:31] <alex_joni> cradek: maybe (hopefully) you can take a look at it sometimes later..
[21:26:17] <cradek> thanks alex
[21:27:19] <cradek> I think you might be missing an acceleration constraint
[21:28:13] <cradek> since the output is acceleration along the helix
[21:28:41] <cradek> err, that doesn't contribute to centripetal does it
[21:29:51] <alex_joni> I have no idea :/
[21:30:42] <cradek> heh