Back
[01:45:34] <cradek> jmkasunich: how important do you think it is to have angled entry and exit both on the same cut?
[01:46:04] <cradek> obviously you can't screw anything onto that thread, but is there a case where it's needed?
[01:52:12] <cradek> 17:25:34 <cradek> you can't (and shouldn't try to) do everything for everyone
[01:57:08] <jmkasunich> if that is the best way to acomplish it I guess it works
[01:57:20] <cradek> ?
[01:57:35] <jmkasunich> angle cut on one end or the other, but not both
[01:57:47] <cradek> I'm considering g76.1 g76.2
[01:57:54] <cradek> maybe
[01:58:04] <jmkasunich> oh
[01:58:19] <jmkasunich> going back to what you asked first, about both ends
[01:58:25] <jmkasunich> what if you put the same angle on both ends
[01:58:30] <cradek> or if I read E use that for the angle, and then one of the remaining integers (L?) for which end
[01:58:32] <jmkasunich> usually one end or the other is in air
[01:58:35] <jtr_away> what about making a worm?
[01:58:51] <jmkasunich> jtr_away: right
[01:58:50] <cradek> that's a good question
[01:58:57] <jmkasunich> angles on both ends would cover that case
[01:59:03] <cradek> yes
[01:59:14] <jmkasunich> the only thing not covered is _different_ angles on both ends
[01:59:16] <cradek> remember, if the canned cycle doesn't work you can still build up arbitrary threads with g33
[01:59:36] <cradek> g76 is a convenience, not a replacement
[01:59:52] <jtr_away> jtr_away is now known as jtr
[02:00:01] <jmkasunich> E for angle, the int for end: 1 = start, 2 = end, 3 - both
[02:01:03] <cradek> I wonder if they avoided E so "G0 X1.50e-2" would give an error
[02:02:19] <cradek> well I'd refuse it on any line not g76 and that would still be fine
[02:23:12] <jmkasunich> halsampler accepts several options, and the channel number is "-c <num>"
[02:23:27] <jmkasunich> halstreamer only accepts one, the channel number, so I didn't do - c
[02:23:36] <jmkasunich> I wonder if I should make them consistent?
[02:25:50] <cradek> http://timeguy.com/cradek-files/emc/the-end.png
[02:26:10] <jmkasunich> ?
[02:26:58] <jmkasunich> thats what emc does when it sees something that could be a scientific notation number?
[02:26:58] <cradek> I guess I messed up the error list
[02:27:55] <jmkasunich> does the spec say that numbers cannot be scientific notation?
[02:28:13] <jmkasunich> if not, I'm not so sure you want to use E
[02:28:21] <cradek> I don't know, but it has always been an error to have an E in the gcode
[02:28:34] <jmkasunich> ok
[02:28:43] <cradek> let me see if I can find something that says that
[02:29:38] <cradek> http://www.isd.mel.nist.gov/personnel/kramer/pubs/RS274NGC_3.web/RS274NGC_33a.html#1001409
[02:29:59] <jmkasunich> good enough
[02:30:24] <cradek> "digits" is defined above to be 0-9 only
[02:35:40] <jmkasunich> I should write man pages more often - helps find bugs
[02:36:18] <cradek> heh
[02:37:59] <jmkasunich> streamer and sampler were using the same shmem ID
[02:38:20] <jmkasunich> so the user part of streamer could access the sampler's fifo, and vice versa
[02:38:38] <jepler> cradek: I'm not quite sure how to word this question -- people have wanted other kinds of interpolation than line and arc. If I create a new curve 'xyz = f(t)' what important characteristics must the function have?
[02:39:07] <jepler> It seems that it must: have an equal distance per time, and have an easily-computable upper bound on its acceleration and velocity
[02:39:41] <cradek> and length
[02:39:48] <jepler> well, if it has an equal distance per time, I guess you know its velocity
[02:40:14] <cradek> yeah all that comes together I guess
[02:40:53] <cradek> it seems all those things are hard for splines
[02:41:09] <jepler> yeah
[02:45:40] <jepler> I wonder if you can compute another function g(t) so that xyz = f(g(t)) comes very close to satisfying the constant-velocity requirement for some traditional spline function f(t)
[02:46:14] <jmkasunich> probably depends on f(t)
[02:46:23] <jepler> yes, it would be depdent on f(t)
[02:46:33] <jmkasunich> some splines (with certain control points) can have zero initial velocoty
[02:46:40] <jmkasunich> so g(0) would have to be infinite
[02:46:44] <jepler> http://www.saccade.com/writing/graphics/RE-PARAM.PDF
[02:47:28] <jepler> Abstract
[02:47:28] <jepler> It is often desirable to evaluate parametric spline curves at points based on their arc-length instead of the curveÕs original parameter. Techniques are presented here for computing a reparameterization curve allowing approximate arc-length evaluation.
[02:47:34] <jepler> This reparameterization curve is also expressed as a spline, allowing rapid evaluation as a function of arc-length.
[02:47:40] <jepler> ^^^ this is almost exactly what I was thinking
[02:47:41] <jepler> maybe this guy's done the math
[02:48:08] <jmkasunich> cool
[02:50:25] <jmkasunich> jepler: do any of your tests use multiple streamer fifos?
[02:50:30] <jepler> jmkasunich: no, they don't.
[02:51:18] <jmkasunich> ok - then its probably safe to change "halstreamer [<chan_num>]" to "halstreamer [-c <chan_num>]"
[02:53:13] <jepler> actually none of the tests yet use halstreamer
[02:53:23] <jmkasunich> oh, just sampler?
[02:53:24] <jmkasunich> ok
[02:53:31] <jepler> and this is a typical use of halsampler: ./stepgen.0/test.hal:loadusr -w halsampler -n 3500
[02:53:45] <jmkasunich> halsampler already uses the -c syntax for channel numbers
[02:56:36] <jepler> if I follow the method of this paper, I think I can find the constant-velocity spline in userspace, and ship it off to realtime as, effectively, a series of polynomials
[02:56:54] <jepler> evaluating some polynomials at 100Hz shouldn't be too taxing
[02:59:06] <cradek> can you bound the accel caused by going around the curves?
[02:59:45] <cradek> centripetal I think it's called?
[03:00:05] <cradek> also find beginning and ending unit vectors
[03:00:45] <jepler> I think so -- if it's just 3 polynomials xyz=f(t) I think it's basic calculus
[03:01:03] <jmkasunich> I think accels add
[03:01:26] <jmkasunich> so the total accel just equals the sqrt of the sum of the squares of the axis acels
[03:01:42] <jmkasunich> by "series of polys" do you mean a poly per axis?
[03:01:44] <jepler> right
[03:01:53] <jepler> x=f_x(t) y=f_y(t) z=f_z(t)
[03:01:59] <jmkasunich> right
[03:02:41] <jepler> the accel of the curve is no bigger than sqrt(x_accel^2 + y_accel^2 + z_accel^2) though it could be lower
[03:02:54] <jmkasunich> is there an extra poly that is used to modify t to get constant velocity>
[03:03:39] <jepler> f(u) and g(t) are both polynomials, so f(g(t)) is a (higher-degree) polynomial
[03:03:53] <jepler> f(u) being the non-constant-time spline
[03:04:01] <jepler> er, non-constant-velocity
[03:04:38] <jmkasunich> ok - does the method result in new splines h(t) = f(g(t)), or do you ship g(t) as well as the original splines down to the TP?
[03:05:00] <jepler> I think h(t)
[03:05:15] <jmkasunich> seems like if g(t) is the same for all axes, might be simpler to compute u = g(t) once and use the lower degree axis poiys unmodifoed
[03:05:18] <jmkasunich> unmodified
[03:06:05] <jepler> that's true
[03:06:07] <jmkasunich> otoh, if you have h(t), maybe you can compute h'(t) and h''(t) (velocity and accel) splines
[03:06:10] <jepler> I haven't digested this paper yet, just started reading it
[03:06:16] <jmkasunich> understood
[03:14:12] <jepler> In the example above, the original curve has 10 control points, and the reparameterization curve has 17. The composition of the two curves, however, requires over 50 control points.
[03:14:18] <jepler> Thus it usually more efficient to store the reparameterization curve separately and evaluate both l (u) and Q(u) to find a point on the curve. The computational cost of two low-order spline evaluations is not significantly different from a single high order evaluation.
[03:15:02] <cradek> variable length data is going to be a whole new ball of worms
[03:15:25] <jmkasunich> what are I and Q? the f(u) and g(t) functions?
[03:15:27] <jepler> not as long as the length's bounded
[03:15:53] <jepler> yes, that's the paper's names for the original spline and the velocity-correcting spline
[03:16:06] <jmkasunich> is that 10 control points for a single spline segment?
[03:16:37] <jmkasunich> most of the splines I'm familiar with break the overall path into individual segments, each of which has a fixed number (often 4) of control points
[03:16:49] <jepler> their example is a closed "C-shaped" curve
[03:17:39] <jmkasunich> if the algorithm generated multiple segments (even if more than the original path had), each of which had a fixed number of coefficients, then each segment could be a single entity to be sent to the motion controller queue
[03:27:29] <jepler> yeah -- there's no reason you can't get more than one trajectory item from a single line of G-code -- canned cycles do this, for instance
[03:31:12] <jepler> * jepler links to this paper from
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Whitepapers_For_Reference so it's not forgotten
[03:36:00] <jmkasunich> I never realised how time consuming writing man pages could be
[03:36:29] <jmkasunich> I really want to figure out a way to include the man pages in the HAL manual, instead of manually duplicating information there
[03:37:24] <jmkasunich> some things benefit from the extra stuff you can include in lyx, like drawings, etc... but others just need the man page
[03:39:28] <jepler> you can convert man pages to postscript, html, and pdf
[03:39:49] <jepler> e.g., groff -Tps -man man3/hal_pin_new.3hal
[03:39:52] <jmkasunich> which, if any, of those can be included inline in a Lyx file?
[03:39:52] <jepler> then ps2pdf
[03:40:05] <jepler> probably none of the above
[03:40:23] <jmkasunich> (the challenge is the Lyx side of the equation, not the man side)
[03:48:03] <jepler> hint to others: never search google for 'latex man'
[03:48:11] <jmkasunich> lol
[03:48:14] <cradek> haha
[03:48:49] <jmkasunich> lyx can include other files, and there is an option called "verbatim", which won't treat the inserted files as latex or lyx source
[03:49:25] <jmkasunich> but they won't be treated as groff source either....
[03:49:53] <jmkasunich> I wonder if a catable man file would appear correctly if included in verbatim mode?
[03:50:08] <jepler> it would all be in typewriter font..
[03:50:17] <jmkasunich> man pages usually are
[03:50:35] <jmkasunich> I'd be perfectly happy to have the man page info appear exactly as it does when viewing with man
[03:50:48] <cradek> it will probably have an inappropriate width in the output then
[03:51:13] <cradek> but if it's sort of close to as wide as a page, probably good enough
[03:51:25] <jmkasunich> yeah
[03:51:52] <cradek> yay I think the hairy interp work is done
[03:51:58] <jepler> if we can't think of anything better, and if including manpages in the pdfs is important, I'm sure I can figure out how to do it in the Submakefile
[03:52:16] <jmkasunich> I have a dead tree book called "linux in a nutshell" which is a mix of normal "book style" info, and chunks of handy reference information that are printed not to differently than man page style
[03:53:55] <jepler> goodnight guys
[03:54:02] <jmkasunich> goodnight
[03:54:19] <cradek> goodnight
[03:54:51] <cradek> hmm there's still a possible problem with g76
[03:56:24] <jmkasunich> now what? ;-)
[03:56:44] <cradek> it goes rapid in, cut over, rapid out
[03:57:02] <cradek> if you hit pause during the cut, it waits til the end like it's supposed to, but it actually needs to wait until after the rapid out
[03:57:18] <cradek> FO is disabled for those rapids now that we have that canon call, but we don't have a disable-pause canon call
[03:57:47] <cradek> brb
[03:57:48] <jmkasunich> can those "rapids" be implemented as normal moves with a differnent feedrate?
[04:05:23] <cradek> especially the move out should be "as fast as possible"
[04:05:35] <cradek> and that wouldn't help the pause problem would it?
[04:06:12] <jmkasunich> well, "as fast as possible" is a known number, so you could program a regular move at that speed
[04:06:31] <jmkasunich> the pause thing is differnent - somehow I had in my mind that the issue was the rapid
[04:06:45] <jmkasunich> but a pause can happen between any two moves, even in sync mode?
[04:07:09] <jmkasunich> I thought pause was blocked until you ended sync mode
[04:07:14] <cradek> that's right, it is
[04:07:28] <cradek> the rapid out is not synced
[04:07:39] <cradek> but it still needs pause avoidance
[04:07:53] <jmkasunich> I'm getting confused
[04:08:03] <cradek> and 'as fast as possible' is not known in the interp
[04:08:08] <cradek> that's why there's a rapid canon
[04:08:12] <jmkasunich> is the rapid the "outfeed move" that you are talking about?
[04:08:35] <cradek> yes with no angle, it goes out (perpendicular) as fast as possible
[04:08:50] <jmkasunich> but with an angle, what does it do?
[04:08:58] <cradek> that's not implemented yet
[04:09:08] <jmkasunich> ;-)
[04:09:25] <jmkasunich> an unsynced move while still in the metal worries me
[04:09:27] <cradek> but it will angle out while still synced, then rapid back out to the drive line
[04:09:50] <jmkasunich> suppose the first cut is made at a fairly slow spindle speed, so it gets out over 1 rev
[04:10:02] <jmkasunich> same for the next 10 passes
[04:10:09] <jmkasunich> but for pass 11 the spindle is going faster
[04:10:25] <jmkasunich> now it takes 1.5 turns to get out, and it digs in deep for the last 1/2 turn
[04:10:27] <cradek> yeah, that is a bit of a problem
[04:11:02] <cradek> but I couldn't think of any other way to end the thread as fast as possible
[04:11:20] <cradek> a lot of times you want to turn a full depth thread right up to a shoulder, then get out
[04:11:22] <jmkasunich> the interp has no information about the machine limits, max_vel, etc?
[04:11:34] <cradek> no, the interp makes canon calls, that's it
[04:11:37] <jmkasunich> damn
[04:11:45] <cradek> not damn, it's a feature
[04:11:56] <cradek> it's madness otherwise
[04:12:03] <jmkasunich> IMO, the "fastest possible out" is just a special case of "angled out", where the angle is as steep as the machine can do
[04:12:41] <cradek> yes but the 'angle as steep as the machine can do' changes based on spindle speed, so you're still screwed
[04:12:56] <jmkasunich> true
[04:13:12] <cradek> we're stuck with "don't change the spindle speed much during threading" which we all pretty much knew already
[04:14:14] <jmkasunich> ok
[04:14:28] <jmkasunich> I give up ;-)
[04:14:42] <cradek> bah
[04:14:52] <cradek> don't say ok because you want me to shut up, say ok if it's the best we can do
[04:16:08] <jmkasunich> well, you came here with one problem - rapids and pauses - and I changed the subject to angled "normal" synced moves, then you convinced me that it won't work for the "as fast as you can" case
[04:16:16] <jmkasunich> so we're back to the original problem
[04:16:30] <cradek> ok
[04:16:48] <cradek> so DISABLE_PAUSE() etc?
[04:17:05] <cradek> in the bitmap just like the others?
[04:17:12] <cradek> or am I missing a better solution
[04:17:40] <cradek> or we could stick with "don't pause in the middle of a thread" which we all pretty much knew already :-)
[04:17:42] <jmkasunich> do you currently disable pausing between subsequent synced moves, or only during a single synced move?
[04:18:03] <cradek> "during any" synced move
[04:18:19] <jmkasunich> so my idea wouldn't have worked anyway
[04:18:54] <cradek> /* handle pausing */
[04:18:54] <cradek> if(tp->pausing && !tc->synchronized) {
[04:18:54] <cradek> tc->feed_override = 0.0;
[04:18:55] <jmkasunich> and the infeed angled thing will still be vulnerable to pauses between the straight and angled moves, even tho the angled move is synced
[04:19:20] <cradek> no that's not right
[04:19:25] <jmkasunich> I know there are places where you look at both the current and upcoming moves
[04:19:48] <cradek> pause waits until sync is off
[04:19:52] <cradek> sync remains on between synced moves
[04:20:04] <cradek> you can have an arbitrary chain of synced moves
[04:20:09] <jmkasunich> ok
[04:20:23] <jmkasunich> so then the angled case is OK, but the rapid case is the troublesome one
[04:20:28] <cradek> so using an angle that goes all the way out does fix this problem
[04:20:32] <cradek> yes
[04:20:56] <jmkasunich> what happens if the angle is 90 degrees?
[04:21:04] <jmkasunich> probably a divide by zero or something....
[04:21:17] <cradek> that divide by zero is not coded yet
[04:21:50] <jmkasunich> never mind... I was thinking that the sync tried to maintain constant velocoty (synced) along Z
[04:21:59] <cradek> two perpendicular g33 moves are just fine. the pitch is per length, not per length of Z projection
[04:22:01] <jmkasunich> but it maintains constant V along the toolpath
[04:22:05] <jmkasunich> right
[04:22:07] <cradek> yes if you do that, you're in trouble at 90 degrees
[04:22:40] <jmkasunich> if you command a 90 degree curve, you'll get out in roughly one turn
[04:22:52] <jmkasunich> given that the thread depth isn't too differnet from the picth
[04:23:16] <cradek> g76 will keep the Z projection pitch constant, so there will be limits? to the angle
[04:23:35] <cradek> that's an interesting point
[04:23:53] <cradek> you're pretty sure to be able to do it too assuming your axes are about the same
[04:24:07] <jmkasunich> not neccessarily
[04:24:17] <jmkasunich> you can't actually make a sharp 90 turn
[04:24:27] <jmkasunich> its accel limit vs velocity limit
[04:24:33] <cradek> yes
[04:24:40] <cradek> it would blend like normal
[04:24:51] <cradek> but you'll always have a messy last full thread with this scheme
[04:25:31] <cradek> when I rapid out, it gets out in 10 degrees?, makes a very neat thread end
[04:25:49] <jmkasunich> wow, thats fast
[04:25:56] <jmkasunich> (or your spindle is slow)
[04:26:12] <cradek> 500rpm? 60ipm?
[04:26:20] <jmkasunich> is the rapid out at 90 degrees?
[04:26:23] <cradek> now tell me how my math is wrong
[04:26:24] <cradek> yes
[04:26:26] <jmkasunich> ie, is the Z stopping?
[04:26:41] <cradek> well it blends
[04:26:48] <cradek> but yeah, Z stops
[04:27:07] <jmkasunich> thread depth?
[04:27:13] <cradek> 25.4 mm/s, 500? mm/s2
[04:27:19] <cradek> ~ .045 (1/4-20)
[04:27:25] <jmkasunich> whats this mm crap?
[04:27:28] <jmkasunich> ;-)
[04:27:34] <cradek> just to make it harder for you
[04:27:43] <jmkasunich> what is the ini file specs for accel and vel
[04:27:50] <jmkasunich> (please let them be in inches)
[04:28:14] <cradek> 25.4 mm/s, 400 mm/s2
[04:28:42] <jmkasunich> thread depth = 0.045in = 1.143mm
[04:28:52] <jmkasunich> d = 1/2 at^2 solve for t
[04:29:10] <jmkasunich> 1.143 = 1/2 * 400 * t^2
[04:29:38] <jmkasunich> t^2 = 0.005715
[04:29:40] <cradek> .075
[04:30:27] <jmkasunich> ok, 600 rpm = 10 rps * 0.075 = 0.75 revs
[04:30:32] <jmkasunich> not 10 degrees....
[04:31:46] <cradek> something must be funny because it's nothing like .75 revs, maybe I was going a lot slower
[04:32:02] <cradek> but what a sidetrack anyway
[04:32:14] <jmkasunich> scope the position and see how long it takes to back out 0.045 inches
[04:32:58] <cradek> if it was .75 revs the top two threads would touch badly
[04:33:09] <cradek> well, maybe not with the blending, hmm
[04:33:22] <jmkasunich> yeah, Z will take the same amount of time to slow down
[04:34:15] <cradek> I'll take a picture for you next time I have it running
[04:35:32] <cradek> maybe you're right and I should stay synced all the way out, using the same pitch
[04:35:52] <cradek> then it would always use approximately the whole last rev for withdrawal
[04:36:05] <cradek> that sure solves the pause problem
[04:36:07] <jmkasunich> that will make it impossible to get out in a small fraction of a rev, no matter how slow you run the spindle
[04:36:22] <cradek> very true
[04:36:27] <jmkasunich> unless you can change the pitch on the fly as you begin the out move
[04:36:41] <cradek> it's impossible to know what it's safe to change it to
[04:37:21] <cradek> even keeping it the same is risky - maybe X is slower than Z
[04:38:05] <jmkasunich> going back to what you already suggested - maybe pause could be inhibited just like feedhold and all the rest
[04:38:38] <cradek> yeah we keep coming back to that
[04:40:29] <jmkasunich> actually, you have a fair amount of code dedicated to preventing pauses during synced moves, preventing feed override during synced moves, etc
[04:41:02] <cradek> yes there are several checks
[04:41:06] <jmkasunich> maybe using the new method to prevent pauses _and_ all the rest, then setting those bits when you queue a synced move, is actually cleaner?
[04:41:48] <cradek> I guess it'll still be the same number of checks, but no more that way
[04:42:51] <cradek> I hope emc is almost done because it's getting pretty complicated
[04:42:57] <jmkasunich> the feed override stuff is already there, so those sync related checks could come out
[04:43:32] <jmkasunich> just have the interp remember the current "user desired" state of all those bits, turn em off before any synced move, and restore the user state for the first unsynced move
[04:43:34] <cradek> I only really see the one on line 667
[04:43:56] <jmkasunich> tp.c
[04:43:59] <jmkasunich> ?
[04:44:01] <cradek> yes
[04:44:41] <jmkasunich> so pausing is done using feed override?
[04:44:44] <cradek> yes
[04:45:25] <jmkasunich> no
[04:45:32] <jmkasunich> at least not they way I meant
[04:45:44] <jmkasunich> net_feed_scale is the product of adaptive, override, and hold
[04:45:51] <cradek> tc->feed_override is set to 0 to pause
[04:45:59] <cradek> yes, not outside of tp
[04:46:02] <jmkasunich> pause does _not_ modify the net value, it overrides it
[04:46:16] <cradek> the element in tc might be named a little wrong
[04:46:30] <jmkasunich> it probably predates all the things that got folded into scale
[04:46:36] <cradek> yes
[04:47:03] <jmkasunich> what I was thinking (and this may be totally dumb) was that pause could also be folded into net_feed_scale
[04:47:35] <cradek> I don't want to break it, I just want to add a feature
[04:47:41] <jmkasunich> the stuff around line 654 would go away too
[04:49:00] <jmkasunich> I guess another way of describing what I mean is:
[04:49:21] <jmkasunich> right now, you have a single bit "synchronized" that both does the sync, and disables various things that can fsck it up
[04:49:27] <jmkasunich> what if you had two bits
[04:49:38] <jmkasunich> so the rapid move can be unsynced, but still disable the bad things
[04:50:06] <jmkasunich> maybe the new bit would be handled like the override enables, maybe not
[04:50:20] <jmkasunich> maybe you handle it like the synch bit, since its only used by the tp
[04:50:20] <cradek> hey that makes me think of the simple fix
[04:50:38] <cradek> tp already knows if a move comes in as a result of a rapid
[04:50:55] <cradek> a "synced" rapid could have special meaning
[04:51:01] <jmkasunich> yeah
[04:51:22] <jmkasunich> synced rapid means disable all the things that can interfere, but don't try to sync, move as fast as possible
[04:51:28] <cradek> yes
[04:52:32] <cradek> hmm, a mess though
[04:52:41] <cradek> SYNC() FEED() RAPID() FEED() UNSYNC()
[04:52:59] <jmkasunich> whats wrong with that?
[04:53:15] <cradek> the second FEED would (I guess) have to wait for index etc
[04:53:23] <cradek> a lot more special cases in the code than I thought
[04:53:26] <jmkasunich> oh, I see... whats wrong with it is that is messes up the existing implementation
[04:53:34] <cradek> yeah
[04:53:41] <cradek> and not just a little mess
[04:53:48] <jmkasunich> no, nothing should wait except the very first one
[04:54:09] <jmkasunich> you know, I always had some reservations about g33 being a move, instead of just setting a flag
[04:54:33] <jmkasunich> if it set a flag, then the next move would wait for index and sync, and all the rest would just keep on trucking
[04:55:00] <cradek> you have to be able to chain them
[04:55:01] <jmkasunich> until the flag is cleared
[04:55:23] <jmkasunich> "keep on trucking" means continue to use the spindle as a reference
[04:55:47] <jmkasunich> the entire sequence would be chained
[04:55:48] <cradek> I don't understand - that's what it does
[04:55:55] <cradek> SYNC() sets a flag and UNSYNC() clears it
[04:56:31] <jmkasunich> but if you do G0 G33 G0, the flag is set for only the middle move, and you can't change that
[04:57:09] <cradek> oh you're talking about way back in the gcode level
[04:57:27] <jmkasunich> yeah
[04:57:32] <cradek> I understand the whole world does it this way
[04:58:01] <jmkasunich> where are you implementing the canned cycle? (maybe I bought into lerman's scheme, and was thinking you were using g-codes to do the cycle)
[04:58:20] <cradek> but an interesting point is if someone does this threading loop themselves they won't be able to protect that G0
[04:58:41] <cradek> unless we have a disable-pause gcode
[04:58:51] <cradek> what a mess!
[04:59:00] <jmkasunich> yeah
[04:59:20] <cradek> convert_threading_cycle() in interp_convert.cc
[04:59:35] <cradek> which I just noticed should probably be in Interp::
[05:06:28] <cradek> you're speechless, I can tell
[05:06:34] <jmkasunich> I'm sleepy
[05:06:57] <jmkasunich> and I realize that I've thown all kinds of wrenches into the works
[05:07:03] <cradek> we should forget it for tonight
[05:12:12] <cradek> yeah that seems like a good idea
[05:12:18] <jmkasunich> agreed
[05:12:18] <cradek> goodnight jmk
[05:13:16] <jmkasunich> goodnight
[10:55:55] <Lerneaen_Hydra> logger_dev: bookmark
[10:55:56] <Lerneaen_Hydra> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2006-11-20.txt
[14:11:35] <rayh> Hi guys.
[14:11:42] <rayh> Got a question about cvs.
[14:11:54] <rayh> I want to add some images in docs/config
[14:12:07] <rayh> They should be binary I suppose.
[14:12:25] <rayh> cvs add -b or what is the proper command.
[14:19:08] <rayh> Berkley tells me I need to run a script to do this.
[14:19:26] <rayh> http://elib.cs.berkeley.edu/admin/cvs/cvsaddko.html
[14:19:40] <rayh> Is that the way we are handling these kinds of files.
[14:23:56] <jepler> rayh: no, you should use "cvs admin -kb" instead of -ko
[14:24:08] <jepler> you can use a script like that to do the commit if you like, or you can run "cvs admin" at a later time
[14:24:53] <cradek> I think these are normally auto-detected correctly today
[14:25:05] <cradek> although I can't find that in the man page...
[14:25:49] <cradek> http://cvs.linuxcnc.org/cvs/documents/images/
[14:26:17] <cradek> in cvsweb, the icon will tell you whether it's binary or not, and as jepler said you can fix it with cvs admin -kb [files...]
[14:26:46] <cradek> (I see some of them are wrong in this directory)
[14:26:53] <rayh> So I just add and commit them and it knows what to do with them
[14:27:14] <cradek> yes, but to be sure, check for the right icon in cvsweb
[14:27:19] <rayh> The wrongs are probably my commits from long ago.
[14:27:42] <cradek> or sf screwups, or buggy cvs programs, hard to say
[14:28:42] <rayh> Okay.
[14:29:01] <rayh> * rayh moves to cvs commit with fear and ...
[14:35:20] <cradek> looks like they are not set right by default, I was wrong
[14:39:18] <rayh> life's like that.
[14:39:42] <cradek> if only I could fix life with 'cvs admin'
[14:40:17] <rayh> Right that would be real nice these days.
[14:43:23] <rayh> cvs admin is a command line thing?
[14:43:41] <cradek> yes
[14:43:44] <rayh> * rayh goes looking at the cvs book.
[14:44:28] <cradek> just like cvs commit file1 file2, you just do cvs admin -kb file1 file2
[14:48:09] <rayh> I see that now, thanks.
[14:56:53] <cradek> http://cvs.linuxcnc.org/cvs/emc2/docs/src/config/
[14:57:02] <cradek> looks right to me
[14:58:22] <rayh> I just changed the homing eps to binary also.
[14:58:40] <rayh> Probably means that each repository out there will have to download it again.
[14:58:50] <cradek> I couldn't decide whether that should be binary
[14:59:49] <rayh> I don't believe that you can patch an eps.
[15:00:18] <rayh> even though it looks like text.
[15:00:24] <cradek> I think you can, since it's just source code (ascii)
[15:00:34] <cradek> just like a lyx file
[15:00:47] <rayh> I can change it back.
[15:03:13] <rayh> IMO using a text editor on an eps is very near fatal.
[15:04:34] <jepler> is the eps file generated from some other file in CVS?
[15:09:45] <rayh> That I don't know.
[15:10:05] <rayh> I just did a small mod using gimp and got 2000+ lines of difference.
[15:10:06] <jepler> ^
[15:10:06] <jepler> v
[15:10:06] <jepler> ^
[15:10:06] <jepler> v
[15:10:08] <jepler> ops
[15:10:16] <jepler> oops
[15:10:20] <jepler> gimp is probably not a good program for editing eps files
[15:10:35] <jepler> eps files are usually vector files, but gimp will convert it to a low-resolution bitmap
[15:11:02] <rayh> But it does support the point that only the original program used to generate the file is good to treat it as a text based thing.
[15:11:49] <jepler> %%Title: D:\JMK\Drawings\emc2-motion-homing-diag.FC7
[15:11:57] <cradek> %%Title: D:MKawingsmc2-motion-homing-diag.FC7
[15:12:03] <jepler> these were made by jmk with his windows-only cad program
[15:12:04] <cradek> arrgh
[15:12:15] <jepler> even if most of us can't use it, we should get the "source" (those .FC7 files) into CVS
[15:13:11] <rayh> sorry I stirred the pot.
[15:13:22] <jepler> no need to apologize
[15:13:25] <rayh> gotta run. Thanks for the help guys.
[15:13:29] <jepler> see you
[15:13:33] <cradek> I was arrghing about my failed paste
[15:13:58] <jepler> is your irc client or your screen doing that?
[15:14:07] <cradek> screen, backslashes
[15:14:30] <jepler> there's got to be a better character
[15:15:27] <jepler> stty quit undef and use ctrl-\
[15:15:33] <jepler> or do you want an unmodified character?
[15:16:17] <cradek> I like it like this, except when I'm trying to paste stupid windows pathnames
[15:17:18] <cradek> I type backslash-space 9999 times a day
[15:17:50] <cradek> looks like you can cvs add -kb too
[15:18:04] <jepler> I use ^X for my screen key but most of the time I run with special bindings in my rxvt
[15:18:07] <jepler> URxvt*keysym.Control-Tab: \030\030
[15:18:18] <jepler> so I can hit control-tab to toggle between two screens
[15:19:13] <cradek> not an emacs user, I can tell
[15:19:34] <jepler> heaven forbid
[15:20:50] <jepler> though I hear vim has some kind of emacs-emulation mode
[15:21:16] <jepler> (not joking:
http://www.vim.org/scripts/script.php?script_id=300)
[15:21:31] <cradek> I used a vi that used emacs commands for split windows C-x 2, C-x o, etc
[15:21:39] <cradek> vile maybe
[15:21:51] <jepler> I have a vague memory of that too -- was it something on the bsdi2 machines?
[15:22:13] <cradek> could be, it was my preferred vi for a long time
[15:22:43] <cradek> I still haven't learned vim's split commands
[15:22:50] <cradek> so I just do without
[15:22:56] <jepler> they kinda suck but I'm sure you could fix it woth some :map
[15:23:49] <cradek> huh, vimacs looks nice
[15:24:04] <cradek> I miss some of those emacs things
[15:31:32] <jepler> map <C-x>1 :only<CR>
[15:31:32] <jepler> map <C-x>2 <C-W>s
[15:31:32] <jepler> map <C-x>3 <C-W>v
[15:31:32] <jepler> map <C-x>o <C-W><C-W>
[15:31:45] <jepler> this in .vimrc gets some of the basic C-x bindings to work
[16:01:10] <jepler> I ask about lifting the "zero velocity at the end of each segment" limitation because I get the impression that this method will often give small subdivisions of the original spline, which will in turn give undesirable behavior in the TP
[16:04:44] <cradek> you can bound vel/accel for the whole subdivided spline right?
[16:05:16] <cradek> and the ends of the subsplines are tangent right?
[16:20:44] <jepler> yes
[16:34:50] <cradek> does seem like they could be planned together then
[16:35:42] <cradek> how do you intend to represent these splines with gcode and who do you think might use them?
[16:39:58] <cradek> I think the superspline is the thing you would plan, and dealing with the subsplines is just a detail of finding your vectors and position along it
[16:45:40] <cradek> seems like once you've changed to constant velocity, you can consider t to be just user length units
[16:51:49] <jepler> I'm not sure if the amount of data in a "superspline" has a reasonable limit, because it is generated by a recursive subdivision method. You might get 2^N but usually you'll get much fewer.
[16:52:24] <cradek> that's ok, you have to send it through realtime in chunks anyway
[16:53:15] <jepler> then realtime has to be able to handle the case where userspace doesn't get all the parts of the superspline through "in time"
[16:54:32] <cradek> true - if there are no more subsplines, you have to stop
[16:56:20] <jepler> do you think the "tangent ends" case can be improved, whether it's for subsplines or line-arc or arc-arc joins?
[16:57:00] <jepler> or would this be some subspline-specific code?
[16:57:18] <cradek> seems like it could work for any join
[16:57:52] <jepler> task would juset set a "tangent to last segment" flag and the planner would use it?
[16:57:58] <cradek> but you don't always want to join - imagine a tiny arc between two lines with all things tangent - the vel bound is going to be low because of the centripetal accel in the arc
[16:58:34] <cradek> for that case you definitely want the existing blend to happen
[16:59:25] <jepler> at the end of the previous segment you want to be moving at min(this_vel, next_vel)
[16:59:29] <jepler> including the "tiny arc" case
[17:00:08] <cradek> I'm thinking of linking criteria that allow you to zip through all the linked motions at constant velocity
[17:00:20] <cradek> (like your superspline)
[18:07:54] <Lerneaen_Hydra_> Lerneaen_Hydra_ is now known as Lerneaen_Hydra
[20:16:27] <jepler> the HTML conversion of the documentation is terrible
[20:16:46] <jepler> sigh
