Back
[00:18:24] <elson> 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.
[00:18:51] <elson> Is there a test file, Chris, for the g76?
[01:35:13] <jmkasunich> jepler: you around?
[01:53:41] <jepler> jmkasunich: what's up?
[02:00:01] <jmkasunich> I seemed to recall a random number component
[02:00:08] <jmkasunich> but I couldn't find it
[02:00:14] <jmkasunich> until I looked in docs/src/hal
[02:00:22] <jmkasunich> is that really where rand.comp belongs?
[02:01:03] <jepler> looks like it's there as an example of a userspace component
[02:01:26] <jmkasunich> ha
[02:01:32] <jmkasunich> ah I mean
[02:01:40] <jmkasunich> I was thinking of using it as a motor torture device
[02:01:43] <jepler> I am not convinced it is useful in that form, but it depends what you want "random" to do
[02:02:17] <jepler> I used something similar to test the HAL adaptive feed pin
[02:02:26] <jepler> (to check that everything stayed in limits)
[02:02:45] <jmkasunich> I've been trying to hunt down the source of lost steps, finally found it
[02:02:55] <jmkasunich> had to set stepgen.0.stepspace to 2
[02:03:09] <jmkasunich> with it at 1, I sometimes got spaces between step pulses as low as 2.2uS
[02:03:12] <jepler> (the makefile system doesn't even know how to build a .comp into a userspace component yet)
[02:03:16] <jmkasunich> even tho my period is 20uS
[02:03:34] <jmkasunich> damned jitter...
[02:03:37] <jepler> wow and yuck
[02:04:07] <jepler> move parport write to the start of the thread and you may find the jitter reduced
[02:04:41] <jepler> depends whether it's being late to start, or having more stuff cold in cache
[02:05:17] <jepler> matt t. named that as one of the important things in quickstep
[02:05:32] <jmkasunich> went from 2.24uS to 2.82uS worst case
[02:06:24] <jepler> with stepspace of 2 * 20uS periods you still get pulses 2.8uS apart?
[02:06:39] <jmkasunich> no, with stepspace = 1
[02:06:50] <jepler> oh
[02:07:13] <jmkasunich> steplen = 1 also leads to 2.8uS step pulses, but that is ok, the gecko responds to low times of about a half-microsecond
[02:07:20] <jmkasunich> but it needs high times around 4uS
[02:08:55] <jmkasunich> stepspace = 2 sucks, because it limits max speed to 16KHz
[02:10:16] <jepler> clearly you need hardware stepgen
[02:11:32] <jmkasunich> yep
[02:11:48] <jepler> or stepper translators that aren't so timing-sensitive
[02:12:09] <jmkasunich> I'm getting 18-25uS latencies regularly (on the rtai latency test), max so far is 28.5uS
[02:12:13] <jmkasunich> makes it hard to run a 20uS period
[02:12:26] <jmkasunich> I wonder if vmware is contributing to the total
[02:12:40] <jmkasunich> eww, 31.7uS
[02:12:40] <jepler> they do insert modules in the kernel
[02:13:10] <jepler> I have to go, bbl
[02:13:10] <jmkasunich> and there is a process called vmware-rtc
[02:41:34] <jmkasunich> wow - thats some serious accel
[02:43:32] <jmkasunich> 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
[02:43:57] <jmkasunich> the tyrap on the shaft comes to a visible stop every 90 degrees, its not losing steps or anything
[04:28:02] <steves_logging> steves_logging is now known as steve_stallings
[15:01:39] <jepler> 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?
[15:02:34] <cradek> at that stage you know nothing about machine constraints, so no
[15:02:52] <cradek> (unfortunately)
[15:03:06] <cradek> and yes it would depend on radius because of centripetal accel
[15:03:51] <jepler> getStraightVelocity and getStraightAcceleration look at the machine constraints
[15:04:33] <cradek> oh, right, duh
[15:07:19] <cradek> I suppose it also depends on the angles at the ends of the segments and the tolerance setting
[15:07:38] <cradek> (looking at blend_vel calcs in tp.c)
[15:09:18] <cradek> jepler: you could do the most basic tests to get close: length vs tooltip accel (maybe capped by centripetal)
[15:17:22] <jepler> cradek: for beziers, the ends are always tangent
[15:18:14] <jepler> so I want to compare length to tooltip accel less centripetal acceleration, and if length is greater then there's a cruise phase?
[15:18:54] <cradek> yes I think so
[15:19:33] <cradek> 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?
[15:20:02] <jepler> yes, if there is a tolerance spec
[15:20:10] <jepler> if there's not, I want the arcs to have cruise phases so the planner does well
[15:20:22] <cradek> ok I see
[15:20:28] <jepler> and I think this is easier than tolerance mode
[15:20:56] <jepler> just like everything else about splines, accurately computing the maximum distance between a spline and an arc is not trivial
[15:21:35] <cradek> no doubt
[15:24:37] <jepler> a=v^2/r ?
[15:26:48] <cradek> maxvel = sqrt(maxaccel * rad)
[15:42:49] <skunkworks> jepler: do you have a wiki on what your doing? Is it going to be a gcode command or something different?
[15:44:51] <jepler> skunkworks: just the blog entry
[15:46:02] <jepler> 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
[15:46:54] <jepler> you can see the g-codes in this screenshot:
http://emergent.unpy.net/index.cgi-files/sandbox/gcode-spline-working.png
[15:47:05] <skunkworks> unreal. thanks
[15:47:17] <jepler> and here's an explanation of what the numbers mean:
http://emergent.unpy.net/index.cgi-files/sandbox/g5-spec.png
[15:48:29] <jepler> 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)
[15:51:43] <jepler> 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
[15:53:02] <skunkworks> 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.
[15:54:37] <jepler> 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)
[15:55:28] <cradek> that would let you cut a pocket with a splined shape
[15:55:30] <jepler> but I would like to permit the plane to by XY or YZ like we allow for arcs
[15:55:54] <cradek> radius comp will just work, since it's arcs, right?
[15:56:05] <cradek> if you can manage an entry move, that is
[15:56:07] <jepler> cradek: no -- the conversion to arcs happens after the radius compensation step
[15:56:15] <cradek> oh, ouch
[15:56:22] <cradek> I see that now
[15:57:14] <skunkworks> ah - that makes sense
[15:57:16] <cradek> but you have enough info to give errors right?
[15:57:23] <jepler> I think you'd have to offset the curve in your CAD or CAM software
[15:57:38] <cradek> "can't do g5 in radius comp mode"
[15:57:57] <jepler> XZ or YZ splines would be useful for programs like image-to-gcode
[16:12:35] <skunkworks> 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
[16:20:41] <steve_stallings> Matt looked, but never really got as far as trying to integrate it.
[16:27:55] <jepler> I think SWPadnos also has a grex, but I don't know of any serious work going on to use it
[16:28:08] <jepler> before you can do anything you have to incorporate real-time usb, and that's a drag
[16:28:47] <skunkworks> eww
[16:29:43] <steve_stallings> .... or real time ethernet, which was what was being considered
[16:31:11] <steve_stallings> 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
[16:33:32] <jepler> yuck
[16:34:41] <steve_stallings> Yeah, but it is an OK toolkit for soft realtime projects developed on Windows.
[16:39:28] <jepler> cradek: I don't see in ini_homing where it describes the behavior if the home switch starts closed
[16:40:20] <cradek> I agree
[16:40:23] <jepler> (when not HOME_IS_SHARED)
[16:40:27] <cradek> but I'm pretty sure that's what it does
[16:40:38] <jepler> will you update the docs?
[16:40:49] <cradek> I'm looking in the source
[16:42:58] <cradek> case HOME_INITIAL_BACKOFF_START:
[16:42:58] <cradek> /* This state is called if the homing sequence starts at a
[16:42:58] <cradek> location where the home switch is already tripped. It
[16:42:58] <cradek> starts a move away from the switch. */
[16:50:03] <jepler> cradek: thank you
[16:50:04] <jepler> !
[16:50:21] <cradek> welcome
[16:50:32] <cradek> I'm not very happy with the prose, but at least it's there
[16:50:47] <jepler> that describes way too much of the documentation
[17:17:29] <jepler> I wonder if it's a mistake for 'halcmd linkXX' or 'halcmd net' to silently unlink pins from their old signal
[17:17:41] <jepler> it is an error in the startup hal files in emc, that's for sure
[17:18:19] <SWPadnos> another option is to have that operation "join" nets, but that's probably not what you want either (most of the time)
[17:18:42] <cradek> I agree it's a mistake
[17:32:23] <SWPadnos> ah - that's the reason for te comment about automatic unlinking - duh me
[18:25:41] <lerneaen_hydra_> lerneaen_hydra_ is now known as lerneaen_hydra
[18:36:12] <steve_stallings> steve_stallings is now known as steves_logging
[18:48:03] <SWPadnos> hmmm. the debounce component uses "periods" as the debounce delay time. should that be nanoseconds?
[18:48:32] <SWPadnos> it is easier to deal with "this many samples", but it may cause issues if the period changes
[19:18:36] <jepler> different components seem to do different things
[19:18:48] <jepler> for instance, oneshot uses seconds (a float) which is not a great idea either
[19:19:04] <SWPadnos> right
[19:19:13] <SWPadnos> stepgen was (is?) also step periods
[19:19:32] <jepler> yes. usc was 100ns periods but jmk changed it to be ns (rounded up)
[19:19:37] <SWPadnos> yep
[19:20:02] <jepler> the only problem with integer ns is that you can't represent times longer than 4.2 seconds or so
[19:20:09] <SWPadnos> there are two downsides as I see it:
[19:20:13] <SWPadnos> ok, three downsides :)
[19:20:43] <SWPadnos> 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")
[19:21:11] <SWPadnos> second is that the code is slightly more complex since you need to add/subtract / deal with actual numbers instead of ++/-- operations
[19:21:37] <SWPadnos> that one isn't so big a deal, but the user impression that the system is hard to use may be
[19:21:46] <jepler> 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
[19:21:58] <SWPadnos> that's true
[19:22:05] <jepler> and if you decide you need a higher step rate you have to change all the time constants
[19:22:21] <SWPadnos> right - that's what I was thinking about when I posed the question
[19:24:19] <jepler> 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
[19:24:31] <SWPadnos> yep
[19:24:49] <SWPadnos> I'd love to have a "microseconds" or "milliseconds" unit in there
[19:25:13] <SWPadnos> 2E32 microseconds is plenty of time for most machine settings
[19:25:45] <jepler> having a 64-bit type would solve things to
[19:26:13] <jepler> too
[19:26:22] <jepler> well, not the "it's hard to get the right number of digits for 1 second" problem
[19:26:25] <jepler> but the dynamic range problem
[19:26:27] <SWPadnos> 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
[19:27:13] <jepler> I might want to use EMC to control my grow lights: 16 hours on, 8 hours off
[19:27:15] <SWPadnos> or just use microseconds externally, if you really need 45 minute delays
[19:27:20] <SWPadnos> true
[19:27:25] <SWPadnos> but you can just write new code :)
[19:27:31] <jepler> bah
[19:28:16] <jepler> 2^64 nanosecond is 5.8 century
[19:28:21] <SWPadnos> heh
[19:28:25] <SWPadnos> that should be enough
[19:28:51] <SWPadnos> but you only get 2^64-1, so it's 5.8 century - 1 nanosecond
[19:28:56] <SWPadnos> that may not be enough
[19:29:31] <jepler> 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?
[19:29:59] <SWPadnos> that's a possibility, but it would probably require multiple functions, since we don't want floats in the base thread
[19:30:05] <jepler> right
[19:30:11] <SWPadnos> I was thinking of ns, not seconds
[19:30:41] <jepler> you could have a -high and a -low, each 32 bit types
[19:30:44] <jepler> the updates are not atomic, so be it
[19:31:03] <SWPadnos> seconds and nanoseconds, I think
[19:31:10] <SWPadnos> like a timespec
[19:31:35] <SWPadnos> 127 years (or whatever 2e32 seconds is) should be fine as well
[19:32:12] <jepler> yeah, anything longer than the anticipated lifetime of a single computer
[19:32:17] <SWPadnos> heh
[19:32:19] <jepler> you know -- 6 months or so
[19:32:26] <SWPadnos> that's a good way to look at it
[19:32:37] <SWPadnos> or anything beyond the expected time between reboots
[19:37:02] <jepler> seconds and nanoseconds might be a good way to approach it
[19:47:42] <jepler> these are all trivial functions, but I wonder if they capture the important operations with times:
[19:47:45] <jepler> http://pastebin.ca/363889
[19:49:02] <SWPadnos> those are good for anything that counts down. it may also be useful to have addition and comparison functions
[19:49:46] <SWPadnos> 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
[19:50:41] <jepler> yeah I hadn't thought about timing an external event and reporting its duration
[19:51:17] <SWPadnos> also comparisons are good for when the delay time changes
[19:51:46] <SWPadnos> counting up and comparing (>=, not =) has the advantage of immediately timing out if the limit is adjusted downward
[19:51:55] <SWPadnos> stupid smilies
[19:52:34] <jepler> so if oneshot starts a pulse and its pulse length parameter is increased, you'd like to see the pulse length increase
[19:52:44] <SWPadnos> I think so
[19:53:08] <SWPadnos> 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
[19:54:19] <jepler> I guess I imagined the one-shot latching the timeout when the pulse starts but I doubt that's what the current implementation does.
[19:55:00] <SWPadnos> that makes sense, though counting up will fix some pathological problems
[19:55:25] <SWPadnos> like someone setting seconds to what they should have set nanoseconds to, then setting it lower after an event has occurred
[19:57:32] <jepler> added addition and comparison:
http://pastebin.ca/363903
[19:58:07] <SWPadnos> looks good to me
[19:58:53] <jepler> because the contents of a hal_timespec are hal_s32_t you can make them parameters
[19:59:24] <SWPadnos> true
[20:00:30] <jepler> all the routines assume the timespec are normalized: 0 <= ns < 1000000000 which might not be true for a parameter
[20:00:54] <SWPadnos> timespec_normalize ...
[20:12:19] <jepler> OK, added
[20:18:24] <jepler> also added hal_timespec_greater and 4 others (>, >=, ==, <=, <)
[20:27:36] <jepler> 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
[20:31:29] <SWPadnos> are you adding those to hal_lib?
[20:32:41] <jepler> I'm thinking about it
[20:32:56] <jepler> I'd like to hear what jmk says first
[20:33:29] <SWPadnos> yep
[20:40:06] <SWPadnos> the ns units thing came from the kernel not having float types in sscanf, right? (at least mostly)
[20:42:17] <jepler> for inifile PERIODs, yes.
[20:42:46] <jepler> since parameters are (generally) set with halcmd from userspace, it seems like that's not the issue
[20:42:56] <jepler> the precision of hal_float_t is
[20:44:33] <SWPadnos> ok, so there are two problems. one is module load parameters and the other is precision
[20:45:19] <SWPadnos> I think there was brief discussion of writing a strtod function, but it seems pretty complex to get it right
