Back
[02:28:48] <jmk_sleep> jmk_sleep is now known as jmkasunich
[08:56:37] <jmkasunich> jmkasunich is now known as jmk_sleep
[16:46:47] <rayh> alex_joni: I see that make clean is broken in rip.
[17:42:15] <cradek> howso?
[17:44:33] <rayh> Maybe it's not supposed to but it leaves all the .o and .ko files behind.
[17:45:11] <cradek> in src, or in rtlib?
[17:45:25] <rayh> does remove both
[17:45:26] <cradek> it does leave .ko in rtlib for me
[17:45:56] <rayh> My head is not working yet.
[17:46:26] <rayh> the .ko files remain in rtlib and the .o files remain in src at least in hal
[17:46:29] <cradek> hmm it does leave a lot of .o files in various dirs
[17:46:37] <cradek> agreed
[17:47:44] <rayh> This may not be an issue with the new make stuff.
[17:47:52] <cradek> I think it is
[17:48:26] <cradek> ok it's leaving all the results of the kbuild step
[17:48:46] <cradek> yuck
[17:48:51] <cradek> it's too bad about kbuild.
[17:49:02] <rayh> How so
[17:49:27] <cradek> well, it kind of sucks
[17:49:45] <cradek> it's hard to integrate properly with our build
[17:50:22] <rayh> Is the kbuild step where it looks for xxx=m
[17:50:29] <cradek> yes
[17:50:39] <jepler> http://axis.unpy.net:8080/
[17:51:09] <cradek> hi jeff
[17:52:27] <cradek> jepler: that looks great but I got a technicolor traceback when I clicked finish
[17:52:40] <jepler> ouc
[17:52:41] <jepler> h
[17:52:55] <cradek> and ... kind of having trouble reading it
[17:53:04] <jepler> it looks like you didn't fill in the axis 1 information
[17:53:10] <jepler> probably float("") -> exception
[17:53:14] <cradek> yes I did
[17:53:24] <jepler> 65.28.182.171 - - [22/Feb/2006:11:52:01] "GET /download/?axis0_scale=8000&axis0_vel=.5&axis0_accel=15&axis0_min=-10&axis0_max=10&axis0_backlash=0&axis1_copy=&axis1_scale=&axis1_vel=&axis1_accel=&axis1_min=&axis1_max=&axis1_backlash=&axis2_copy=&axis2_scale=&axis2_vel=&axis2_accel=&axis2_min=&axis2_max=&axis2_backlash= HTTP/1.1" 200 8183
[17:53:24] <cradek> ohhhh
[17:53:36] <cradek> I selected "copy from" first
[17:53:39] <jepler> here it has axis1_xxx=(empty string)
[17:53:42] <cradek> right
[17:53:58] <cradek> I thought "I know they're all the same so I'll tell it I just want to fill out the top one"
[17:54:23] <jepler> I should disclaim that I haven't tested any of these .inis
[17:54:45] <cradek> wow, this is great, jeff
[17:55:36] <jepler> I think it might be an OK starting point
[17:56:02] <cradek> I would like for it to ask for machine speed in MHz and guess a period
[17:56:29] <rayh> I tried some of that but the guess wasn't real good.
[17:56:58] <jepler> hey, I thought I had a breakthrough user-interface by prompting in microseconds!
[17:57:00] <rayh> Big differences between processors and bridges
[17:57:15] <cradek> rayh: a conservative guess is needed
[17:57:20] <rayh> Yep. Microseconds is good.
[17:57:46] <cradek> rayh: I think prompting for something the new user knows is better than prompting for something he has no idea about, even if our guess is not perfect
[17:58:01] <rayh> The period does affect max vel.
[17:58:03] <cradek> (because our guess is better than a new user's guess)
[17:58:17] <jepler> The software could look at SCALE and MAXVEL and choose PERIOD...
[17:58:25] <cradek> jepler: true
[17:58:37] <cradek> jepler: it could detect the "that seems impossible" case
[17:59:03] <rayh> and then tell the user "no way is anyting short of xxx gz gonna do that."
[17:59:34] <cradek> jepler: I like it. It's a great start.
[17:59:44] <rayh> Nice job. I really like the concept.
[17:59:56] <jepler> the problem with it is that it's in bizarro web framework nobody else has ever heard of
[18:00:08] <rayh> I was thinking of something similar using a database for possibles.
[18:00:10] <jepler> otoh it's under 200 lines of code
[18:00:27] <jepler> lunchtime, guys ..
[18:05:49] <rayh> Fantastic job.
[18:21:32] <alex_joni> hi ray
[18:21:44] <rayh> hi alex
[18:22:20] <alex_joni> lets move to board
[19:02:15] <rayh> That cleans it up, cradek
[19:26:51] <jepler> If the "A" axis is a rotary table without limits, what does one put for MIN_, MAX_LIMIT?
[19:27:03] <jepler> -1e6, 1e6?
[19:28:56] <rayh> big is what I do.
[19:30:37] <rayh> What you've got is about 270 turns in each direction from zero.
[19:48:25] <jepler> What's a credible formulat for PERIOD in terms of SCALE and MAXVEL? 1 / (k * SCALE * MAXVEL), with k=5 to 10?
[19:50:16] <rayh> Sherline has 16k for scale and 24 for max vel
[19:50:55] <rayh> so 6400 pps
[19:51:53] <rayh> Smithy has 4032 scale and 160 ipm for max vel
[19:53:25] <jepler> with k=5 my formula would give 31.25 micro seconds and 18.6 micro seconds respectively
[19:55:15] <rayh> let me switch over to the smithy box and try the 18.6
[19:55:21] <rayh> brb
[19:55:25] <jepler> what is it set to currently?
[20:00:38] <rayh> They run emc1 and its about 20
[20:04:21] <jepler> then regardless of whether emc2 can do it reliably, my formula might be in the right neighborhood
[20:04:38] <jepler> (I assume that's why you mentioned it was emc1)
[20:05:08] <rayh> Right. I'm seeing following errors but let me test more.
[20:09:02] <alex_joni> jepler: emc2 is a bit slower than emc1
[20:09:12] <alex_joni> because it doesn't hold optimisations
[20:09:48] <alex_joni> although emc2 is lots faster than I would have expected it..
[20:11:05] <alex_joni> it's only a bit slower then emc1 ( afew usecs)
[20:12:47] <rayh> Manual jog seems to be fine with 18.6. Startup and display seem good.
[20:13:17] <alex_joni> rayh: I ran my box at 7.5 the other day, I really found that AMAZING for emc2 ;)
[20:14:38] <rayh> I'm seeing 17600 for base thread.
[20:15:01] <rayh> That is great alex
[20:19:40] <alex_joni> one of these days I'll plug that parport card in, and push it further
[20:25:08] <rayh> I've got 10054 or so for base now but still get axis 2 following error in cds
[20:25:17] <rayh> where it switches from rapid down to feed down.
[20:26:39] <rayh> 2.5 max vel and 3.2 stepgen maxvel
[20:28:50] <alex_joni> yup, that's a blending problem I think
[20:29:01] <alex_joni> it's a collinear move.. right?
[20:31:11] <rayh> Sounds like it to me. Yes the move is in the same direction but switches from rapid to feed.
[20:32:21] <alex_joni> so ideally it shouldn't do anything
[20:32:39] <rayh> except decel from rapid.
[20:32:45] <alex_joni> yes
[20:33:27] <alex_joni> I suspect it does, but when it needs to go back up to speed it accels too fast
[20:34:07] <rayh> I can try turning down accel.
[20:37:39] <rayh> okay. I've seeing overshoot at those places where there were problems before.
[20:38:03] <rayh> And why do I see what appears to be exact stop rather than corner blending?
[20:40:06] <alex_joni> rayh: dunno.. that is odd
[20:40:15] <alex_joni> maybe you have the improper G active?
[20:42:15] <rayh> It says g64
[20:43:20] <alex_joni> I can't (no matter how hard I try) remember which one does what..
[20:43:38] <rayh> I'll look
[20:45:10] <rayh> G61Exact Path Mode
[20:45:10] <rayh> G61.1Exact Stop Mode
[20:45:11] <rayh> G64Continuous Mode
[20:45:15] <jepler> are there images somewhere that show the "standard" and "xylotex" pinouts?
[20:45:56] <alex_joni> jepler: I think in the HAL_Introduction
[20:46:12] <alex_joni> rayh: bummer.. then it's ok
[20:46:29] <alex_joni> try changing it a few times (G61, G64, G61, G64)
[20:46:38] <alex_joni> and try again
[20:48:24] <jepler> alex_joni: I don't see it in there...
[20:48:37] <alex_joni> * alex_joni looks
[20:49:04] <jepler> I have the one from emc2 cvs
[20:49:45] <jepler> page 57 has a picture of the parallel port
[20:50:25] <jepler> but not of the particular pinouts
[20:52:24] <alex_joni> darn, you are right.. it's not in there
[20:52:36] <alex_joni> but I could have sworn I've seen one sometime
[20:52:47] <alex_joni> I think it was in the old handbook for emc1
[20:53:34] <alex_joni> there is one, but only shows the pin names, and there's a table afterwards with the connections
[20:53:44] <alex_joni> around page 34-35 in the integrator handbook
[20:57:01] <jepler> thanks, that's still not quite what I was hoping to find
[20:57:13] <rayh> Right and the image just uses the port names.
[20:57:21] <alex_joni> jepler: I know..
[20:58:13] <rayh> I'm seeing a lot of overshoot with stepper_inch and it still appears to stop at each corner.