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