Ah, Chris, that sounds like it, maybe. I rigged an encoder so that A was providing the index, and it missed the index a LOT.
Is there a test file, Chris, for the g76?
jepler: you around?
jmkasunich: what's up?
I seemed to recall a random number component
but I couldn't find it
until I looked in docs/src/hal
is that really where rand.comp belongs?
looks like it's there as an example of a userspace component
ah I mean
I was thinking of using it as a motor torture device
I am not convinced it is useful in that form, but it depends what you want "random" to do
I used something similar to test the HAL adaptive feed pin
(to check that everything stayed in limits)
I've been trying to hunt down the source of lost steps, finally found it
had to set stepgen.0.stepspace to 2
with it at 1, I sometimes got spaces between step pulses as low as 2.2uS
(the makefile system doesn't even know how to build a .comp into a userspace component yet)
even tho my period is 20uS
wow and yuck
move parport write to the start of the thread and you may find the jitter reduced
depends whether it's being late to start, or having more stuff cold in cache
matt t. named that as one of the important things in quickstep
went from 2.24uS to 2.82uS worst case
with stepspace of 2 * 20uS periods you still get pulses 2.8uS apart?
no, with stepspace = 1
steplen = 1 also leads to 2.8uS step pulses, but that is ok, the gecko responds to low times of about a half-microsecond
but it needs high times around 4uS
stepspace = 2 sucks, because it limits max speed to 16KHz
clearly you need hardware stepgen
or stepper translators that aren't so timing-sensitive
I'm getting 18-25uS latencies regularly (on the rtai latency test), max so far is 28.5uS
makes it hard to run a 20uS period
I wonder if vmware is contributing to the total
they do insert modules in the kernel
I have to go, bbl
and there is a process called vmware-rtc
wow - thats some serious accel
0 to 17 KHz steps in about 8-9mS, cruise for 20mS, decel to a stop in another 8-9mS - total time for a quarter rev = 38mS - then wait 25mS, and do it again
the tyrap on the shaft comes to a visible stop every 90 degrees, its not losing steps or anything
steves_logging is now known as steve_stallings
cradek: in the xxx_FEED canon calls is there an easy way to find the length of an arc required to have a cruise phase? Does this depend on the radius of the arc as well as the requested f-number?
at that stage you know nothing about machine constraints, so no
and yes it would depend on radius because of centripetal accel
getStraightVelocity and getStraightAcceleration look at the machine constraints
oh, right, duh
I suppose it also depends on the angles at the ends of the segments and the tolerance setting
(looking at blend_vel calcs in tp.c)
jepler: you could do the most basic tests to get close: length vs tooltip accel (maybe capped by centripetal)
cradek: for beziers, the ends are always tangent
so I want to compare length to tooltip accel less centripetal acceleration, and if length is greater then there's a cruise phase?
yes I think so
I don't quite see why you want this - don't you want to use the minimum number of arcs that meets the tolerance spec?
yes, if there is a tolerance spec
if there's not, I want the arcs to have cruise phases so the planner does well
ok I see
and I think this is easier than tolerance mode
just like everything else about splines, accurately computing the maximum distance between a spline and an arc is not trivial
maxvel = sqrt(maxaccel * rad)
jepler: do you have a wiki on what your doing? Is it going to be a gcode command or something different?
skunkworks: just the blog entry
skunkworks: I have implemented two new g-codes, G5 (cubic bezier) and G5.1 (conic) which are currently cut using a number of arcs which are tangent at the endpoints
you can see the g-codes in this screenshot: http://emergent.unpy.net/index.cgi-files/sandbox/gcode-spline-working.png
and here's an explanation of what the numbers mean: http://emergent.unpy.net/index.cgi-files/sandbox/g5-spec.png
but the current implementation is not complete (only XY-plane curves are permitted) or sophisticated enough (it doesn't choose the "right" number of arcs, right now a hard-coded number of arcs no matter the details of the particular spline curve)
for instance, for 1 inch tall letters produced by truetype-tracer, many of the splines are less than 1/2" long. Breaking those down into 20 arcs gives motions that are about .025 inch long which is getting into the territory where the planner slows down
that is neat - and makes sense to me.. you would use then ijk and pqr or something like that for 3 dimentional curves? (I suppose no 'r') but whatever.
The method I've used does not permit non-planar curves. At best, I can allow a Z-coordinate to be specified, and move along the Z coordinate while the X and Y move through the curve (like helical arcs do now)
that would let you cut a pocket with a splined shape
but I would like to permit the plane to by XY or YZ like we allow for arcs
radius comp will just work, since it's arcs, right?
if you can manage an entry move, that is
cradek: no -- the conversion to arcs happens after the radius compensation step
I see that now
ah - that makes sense
but you have enough info to give errors right?
I think you'd have to offset the curve in your CAD or CAM software
"can't do g5 in radius comp mode"
XZ or YZ splines would be useful for programs like image-to-gcode
here says matt shaver is also working on getting the grex working with emc :) is he? http://www.cnczone.com/forums/showthread.php?t=11665&highlight=grex
Matt looked, but never really got as far as trying to integrate it.
I think SWPadnos also has a grex, but I don't know of any serious work going on to use it
before you can do anything you have to incorporate real-time usb, and that's a drag
.... or real time ethernet, which was what was being considered
and then there was the drag that the internal CPU of the GREX is a Rabbit (Z80 superset) with proprietary tools that do not run under Linux and requires licenses
Yeah, but it is an OK toolkit for soft realtime projects developed on Windows.
cradek: I don't see in ini_homing where it describes the behavior if the home switch starts closed
(when not HOME_IS_SHARED)
but I'm pretty sure that's what it does
will you update the docs?
I'm looking in the source
/* This state is called if the homing sequence starts at a
location where the home switch is already tripped. It
starts a move away from the switch. */
cradek: thank you
I'm not very happy with the prose, but at least it's there
that describes way too much of the documentation
I wonder if it's a mistake for 'halcmd linkXX' or 'halcmd net' to silently unlink pins from their old signal
it is an error in the startup hal files in emc, that's for sure
another option is to have that operation "join" nets, but that's probably not what you want either (most of the time)
I agree it's a mistake
ah - that's the reason for te comment about automatic unlinking - duh me
lerneaen_hydra_ is now known as lerneaen_hydra
steve_stallings is now known as steves_logging
hmmm. the debounce component uses "periods" as the debounce delay time. should that be nanoseconds?
it is easier to deal with "this many samples", but it may cause issues if the period changes
different components seem to do different things
for instance, oneshot uses seconds (a float) which is not a great idea either
stepgen was (is?) also step periods
yes. usc was 100ns periods but jmk changed it to be ns (rounded up)
the only problem with integer ns is that you can't represent times longer than 4.2 seconds or so
there are two downsides as I see it:
ok, three downsides :)
the other two are that there are a lot of zeroes in a coupe of milliseconds, so it's easy to screw up the configs (and they "look bad")
second is that the code is slightly more complex since you need to add/subtract / deal with actual numbers instead of ++/-- operations
that one isn't so big a deal, but the user impression that the system is hard to use may be
specifying number of periods means you don't know the exact length of time that N periods is -- I'm not talking about jitter, but about getting e.g., 19.mumble KHz instead of 20kHz when you ask for BASE_PERIOD=50000
and if you decide you need a higher step rate you have to change all the time constants
right - that's what I was thinking about when I posed the question
hal_float number of seconds is not great, because there are only 24 bits (I think) of mantissa, so 1000 seconds - 50 microseconds may be 1000 seconds
I'd love to have a "microseconds" or "milliseconds" unit in there
2E32 microseconds is plenty of time for most machine settings
having a 64-bit type would solve things to
well, not the "it's hard to get the right number of digits for 1 second" problem
but the dynamic range problem
well, 4.2 seconds is a long time as well, and the 64-bit accumulators would be internal, so there's no atomic update problem
I might want to use EMC to control my grow lights: 16 hours on, 8 hours off
or just use microseconds externally, if you really need 45 minute delays
but you can just write new code :)
2^64 nanosecond is 5.8 century
that should be enough
but you only get 2^64-1, so it's 5.8 century - 1 nanosecond
that may not be enough
backing up a second, were you suggesting to use a floating-point number of seconds at the interface, and a 64-bit integer counter internally?
that's a possibility, but it would probably require multiple functions, since we don't want floats in the base thread
I was thinking of ns, not seconds
you could have a -high and a -low, each 32 bit types
the updates are not atomic, so be it
seconds and nanoseconds, I think
like a timespec
127 years (or whatever 2e32 seconds is) should be fine as well
yeah, anything longer than the anticipated lifetime of a single computer
you know -- 6 months or so
that's a good way to look at it
or anything beyond the expected time between reboots
seconds and nanoseconds might be a good way to approach it
these are all trivial functions, but I wonder if they capture the important operations with times:
[19:47:45] <jepler> http://pastebin.ca/363889
those are good for anything that counts down. it may also be useful to have addition and comparison functions
countdown can do the same thing as count up and compare, but is may be nice to have actual elapsed time available in some cases
yeah I hadn't thought about timing an external event and reporting its duration
also comparisons are good for when the delay time changes
counting up and comparing (>=, not =) has the advantage of immediately timing out if the limit is adjusted downward
so if oneshot starts a pulse and its pulse length parameter is increased, you'd like to see the pulse length increase
I think so
but more importantly if the limit is decreased and we've already exceeded the new lower time limit, I'd like the pulse to end immediately
I guess I imagined the one-shot latching the timeout when the pulse starts but I doubt that's what the current implementation does.
that makes sense, though counting up will fix some pathological problems
like someone setting seconds to what they should have set nanoseconds to, then setting it lower after an event has occurred
added addition and comparison: http://pastebin.ca/363903
looks good to me
because the contents of a hal_timespec are hal_s32_t you can make them parameters
all the routines assume the timespec are normalized: 0 <= ns < 1000000000 which might not be true for a parameter
also added hal_timespec_greater and 4 others (>, >=, ==, <=, <)
though it might make sense to decide which type of counting and comparing to prefer -- e.g., count up from 0 and compare for being strictly less than the limit
are you adding those to hal_lib?
I'm thinking about it
I'd like to hear what jmk says first
the ns units thing came from the kernel not having float types in sscanf, right? (at least mostly)
for inifile PERIODs, yes.
since parameters are (generally) set with halcmd from userspace, it seems like that's not the issue
the precision of hal_float_t is
ok, so there are two problems. one is module load parameters and the other is precision
I think there was brief discussion of writing a strtod function, but it seems pretty complex to get it right