jmkasunich_ is now known as jmkasunich
jmkasunich_ is now known as jmkasunich
+ rsync --delete --bwlimit=20 -zrtlv EMC2_Developer_Manual.pdf EMC2_Integrator_Manual.pdf EMC2_User_Manual.pdf HAL_User_Manual.pdf html linuxcnc.org:docs/devel/
ssh: linuxcnc.org: Name or service not known
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
I have been getting this intermittently over the last few days .. maybe 1 out of 20 runs. anyone else seeing name lookup issues for linuxcnc.org?
I haven't seen that...
I won't sweat it then
can you do me a favor? Set one of the PWMs to its most positive value and make sure it gives a 100% duty cycle. Then do the same for the most negative value
I haven't tested that yet but I think I got it right
did bill share the spice cake with you?
yes it was very good
I'm getting 70000nsec motion-controller.tmax
does that mean I could run 10kHz servo cycle?
motion-controller is the whole thread?
* cradek shrugs
04 s32 RW 20424 motion-command-handler.tmax
04 s32 RW 69015 motion-controller.tmax
09 s32 RW 58627 pluto-servo.read.tmax
09 s32 RW 29143 pluto-servo.write.tmax
the EPP communication takes a substantial length of time too
(and remember -- those are cycles, not ns)
chris@max:~$ units 69015/800MHz kHz
I'd start with a more modest 2kHz or 4kHz .. and see if you can detect any improvement
I'm at 2kHz now
I think you need to add them all up: $ units "(24014+69015+58627+29143)/800MHz" kHz
ok I'll leave it at 2
there's a few other things in there too (some ddt, pid)
yuck, I sure think it's a bug that homing moves honor FO
if I have FO set at 200% the axis bumps the stop
that just isn't good
it just can't decelerate in time?
no the switch travel is pretty short
that's why there are homing velocities
someone always says "it's always been that way" when I bring this up (which is true)
so fix it and then it will never be that way again
'its always been that way.'
that's a decent idea
you can say 'yeah, it used to be that way, but I fixed it'
skunkworks: I imagine you've been watching this conversation with interest
I need atleast 10 more hours each day :)
skunkworks: me too
well I wrote "honor FO only when homing" - is that close enough?
that's probably not going to meet with wide approval
backport that to 2.1?
you are gonna get grief for that one
nobody will argue that 200% FO is good while homing
but some will argue that 10% has value
surely you don't get the same home position at 10% FO
if not, your 100% value is too fast
on average the switch actually closed 50% of the way into the servo cycle. That's a different distance at 100% than at 10%. It may not be a big difference, but it's a difference.
you mean into the 1mS cycle?
* jepler does the math
the variability from 0.001mS to 0.999mS is always going to be a random error
jepler: thanks for arguing about this so I don't have to
if that error is greater than one count at 100%, then 100% is too fast
if someone wants to change it to <= 100%, I won't argue
btw, if you have a fanch hardware encoder reader, the servo cycle doesn't matter
OK, maybe you're right -- the truly interested party should complicate the whole planner by adding support for "obey FO but cap at 100%" and use it in the homing code
* jepler laughs
jepler: you mean cap the product of all the feed override override overrides at 100%
the hardware should latch/reset the counter at the instant of the index pulse
"the argument from sematics" says e.g. HOME_SEARCH_VEL should be HOME_SEARCH_MAXVEL if that's what we mean
I didn't say _I_ was gonna argue with you
you know darn well you can't please everybody
* jmkasunich looks for a ballscrew source
I need 18" of ballscrew, 3/4 or smaller (not much smaller) in diameter
with a preloaded nut
and preferrable _finer_ than the usuall 0.200 pitch
5 tpi * 2:1 belts * 200 full steps/rev = 2000 full steps/inch
I will be doing 10x microstepping, but dunno how fine a step you can actually get
this is the lathe cross-slide, so I want it as good as I can get
for precision bores, etc
you could definitely get 1/4000 then
10 tpi screws?
I mean half steps are pretty much real
the existing acme screws are 10 TPI
but I haven
on my motors they don't seem to really be halfway, but they are certainly 'between' the full steps
haven't seen ballscrews that fine
can you even measure 1/4000 inch?
even with a micrometer that's really pushing it
1/4000 on the radius is a half-thou on the diameter
I can measure that
that's easy to forget
heh - etch-cnc got mentioned here: http://hackaday.com/2006/05/01/team-hack-a-day-cnc/
seems like you want more than .0005 dia resolution
jmkasunich: I think they've linked to me twice now
this one is old, maybe the same?
I bet so -- look at the spike in the #hits on axis.unpy.net back in may: http://unpy.net/usage_axis/
are you serving unpy from home?
it's just on my dsl
what are you using?
the dsl is 384kbps up; the server is apache/fedora core
the blog software is called "aether" and it's really not high performance -- but that was by no means a "slashdotting"
wow - I won't be getting ballscrews from mcmaster
20mm dia 5mm pitch, 149 for the screw and 200 for the nut
for 18" of screw?
ground screw? with preloaded nut?
ground yes, preloaded no (I don't think)
all the inch ones have too long of a lead
oh, I read that wrong (damn fractions)
13/64 is 0.203, so that is OK
5/8 dia x 13/64 lead, $1.27 per inch
nuts only 23.85 in!
s/in!/in that size!/
3/4 x same lead $2.00 per inch, and $36.20 nut
all the other sizes are from twice to 10 times the price
looks like theres enough room under the table to mount 2 nuts
I wonder how much preload is appropriate
looks like I can get 50 to 100 lbs pretty easily
19692.3 steps/inch with 10x microstepping.....
build times: BDI-4.51 - 23 minutes, Breezy RT 16 min, nonRT 8 min (non-rt doesn't build everything)
dapper, running on a non-virtual machine: 3-4 minutes
jmkasunich: that's quite a wide range of build times
I've started thinking about rigid tapping again
(without a servo spindle)
there has to be allowance for the tap to go further than you specify, since the spindle has to stop
so I wonder how you should specify a tap cycle in gcode
aren't some of the G8x or G7x rigid tapping cycles?
you mean currently?
yeah, at least in the spec, if not in the code
not in the code :-)
thanks for the duh, I'll look in the spec
no problem - I'm good with duhs :)
it looks like G84 is the one
interesting that there isn't a left-hand version
I don't like how they use S/F, I prefer a pitch (P word) in the gcode like I did for threading
it seems that would be easier
is there any G84 support in the code?
if not, then there can't be any programs that will break if the spec is changed ...
it currently does nothing except give an error if the spindle isn't turning
oh, well that's helpful
it tries to support multiple planes I think (not mentioned in the spec)
I think all the G8x canned cycles support the planes
what are R- L-?
is that the repeat stuff?
if I remember correctly, there's some generic text to that effect at the top of the G8x
(I have never used that)
"All canned cycles are performed with respect to the currently selected plane. Any of the three planes (XY, YZ, ZX) may be selected. Throughout this section, most of the descriptions assume the XY-plane has been selected. The behavior is always analogous if the YZ or XZ-plane is selected. "
isn't R the "retract height"?
err - retract position, for generic planes
if I have a motor on my lathe's tailstock, what axis would that typically be?
(I doubt it's any of X,Y,Z)
is Z along the axis? (X=radius or diameter)
then tailstock would be W
UVW are parallel to XYZ
when I tap by hand I almost always "peck" - is that not normal when tapping on a mill?
cradek: not usually
(I do the same thing unless I want the tap to break off in the part ;))
do people not generally tap blind holes on a mill?
they use spiral taps that the shavings come out the top
or do they generally use much bigger taps than I do
why are all taps not spiral? harder to start by hand?
I don't think I've ever used a spiral tap
I think it is mostly cost
I we have some spiral taps that I use by hand with no isse
where's the password?
isn't that more of an alex question? :)
SWPadnos: mail is coming through now
I saw the Gomez mail ...
yeah, that one ;)
it was trapped by beeing sent when not subscribed
so - this is kind of cool: http://www.trolltech.com/products/qtopia/greenphone
not quite cheap
no, not quite ;)
but actually not all that expensive, compared to other non-plan-provided GSM phones (though I'm not sure that one works in the US, since our system is so backward)
a non-plan-provided GSM phone is 100-600 over here
one comparable is 200 maybe
without the SDK though
I was looking at GSM and CDMA/TDMA, and those are generally more expensive
I may finally buy a UK SIM card and I'll have to rent a phone while I'm there, so I figured I'd look at the price of buying one
phones that don't work in the US are cheap, phones that work in the US aren't as cheap, and phones that can have reasonable rates and work in the US and elsewhere are very not cheap ;)
what do people think about stepgen aborting (failing to load) if its maxvel can't be reached according to the period and hold times etc? It already does the math, but it lowers its maxvel silently and then you are guaranteed to get following errors, which I think is a crappy way to report a misconfiguration
I'm looking at Ed's hal file - he has a high scale (16000) and very long hold times set (5-7? periods per step)
I think it's crappy, but I don't think that can be done
what am I missing?
that "does maxvel exceed what is possible" check is done in the slow thread, well after the setps, and even longer after the loadrt
it could still log an error I guess
but I'd rather it would not run if misconfigured
another option is to remove the limits from stepgen
though that turns it into freqgen, for the most part
I'm not talking about the limiting, I'm talking more about the max step rate allowed by the period
true - I noticed that after my remarks ;)
the limiting *setting* does give you the number the user hopes he can get
well, one sneaky thing to do is add an output bit that tells whether the requested settings are valid
but there isn't a good way of reporting that to the user
yes I agree that is the problem
stepgen knows when you're out of luck, we should figure out something smarter to do
it only knows after it's been loaded, and all signals/parameters have been set ...
sure, jepler said that too
and since the parameters can change after load, it gets even more fun
maybe we can't check it inside stepgen itself then
well, one generic way of doing it would be to add maxaccel and maxvel inputs to the motion controller, that the lower level drivers can output
I hate to put stepgen-specific validation into emc proper though
the motion controller can then decide that the capabilities aren't good enough to do what's in the ini, and either tell the user or lower the limits
can %f formats be used in rtapi_print_msg?
well, the same is true for other systems
SWPadnos: that sounds like a good possible approach
or a possibly good approach ;)
actually, making maxaccel and maxvel into inputs could have other uses (though I can't think of any right now)
does the TP do any precalculation of time constants or the like at startup, or is all that just data-dependent?
I'm pretty sure motion can set maxvel/accel anytime and TP will honor it
I think that's what you're asking?
that must be the password
the problem is there are lot of maxvels/accels
SWPadnos: spam again
cradek, yes - that was what I was asking
seems like the base problem is that we need an error reporting mechanism from hal into emc other than dmesg
that could be a separate problem
STEPGEN: Channel 0: The requested maximum velocity of 559999 steps per second is not attainable.
STEPGEN: The maximum number of steps possible is 800 per second
getting this into dmesg is not hard: ^^^
I hate all these problems where the user has to get a calculator (or ask us) to figure out what his misconfiguration is
if the low level driver can tell motion what the underlying hardware can do, then motion can limit itself to that
jepler: that's a great start
SWPadnos: but if the user asked for more in his ini, it's arguably a misconfiguration/error
I'd rather report the error than silently change the numbers
hm that 800 per second must be wrong
though having those pins would allow us to do a lot of tuning without restarting emc
two observations: this calculation doesn't happen until you turn the machine on, and after that it happens every cycle
but instead, it reports that the requested maximum velocity of 800 steps per second is not attainable
the maximum number of steps possible is 800 per second
maybe what HAL or RTAPI needs is a way to register a function to send the formatted result of rtapi_print_msg to -- by default it would go to dmesg, but emc could patch it so that RTAPI_MSG_ERR are shown to the user via the GUI
I guess it would be in RTAPI
or add RTAPI_MSG_USER
not that it's an RT function, but that's a needed library
there is report_error
alex_joni: but that's not rtapi, that's emc
oh wait -- that 800 is probably right. this is the config where I set weird setup and hold times
use your web config checker and fine out ;)
* alex_joni has trouble understanding what's going on in Device_EncoderRead(void *arg, long period)
it seems somehow unfinished
there isn't aq lot of info about how the hardware works
no, just some comments at the begining of the file
*(pEncoder->pIndex) = (status >> (MOTENC_STATUS_INDEX_SHFT + j)) & 1;
*(pEncoder->pIndexLatch) = (status >> (MOTENC_STATUS_INDEX_LATCH_SHFT + j)) & 1;
those two do the same thing.. I don't see any difference anywhere
INDEX_SHIFT vs. INDEX_LATCH_SHIFT
it's getting late :(
pCard->fpga[i].encoderCount[j] = *(pEncoder->pLatchIndex);
that also seems odd
encoderCount[j] holds the counts presumably
setting it with a bit seems odd
one ould think
* alex_joni would think
but who knows :)
I know how indexing works on my own FPGA :-P
jepler: hmm.. then you could change the FPGA on the motenc
oh sure - take the easy way out and make your own
I don't know about the motenc but I've sure been thinking about the m5i20
yeah - that's an interesting card
300k gates and all
or is it 200k?
I don't recall
bigger than the acex1k that's for sure
but a bit more expensive too
they're not too bad if you can get a few friends to buy at the same time
$159 in qty. 5
which is an excellent discount, if ou ask me
actually I didn't know the qty 1 price was so low
I thought it was at least $100 more than that
eyah - $199 isn't bad either
that's why I was saying that the pluto and/or PCI-8255 may not be the best deal around (especially if you need both)
they'd have to be local friends -- if you have to split up the 5 and re-ship 4 of them yourself it's barely a savings
but if you want 4 I'll sure buy the 5th from you :-P
well, fest is coming ...
good night all