Back
[00:32:54] <SWPadnos> I was just thinking that the kinematics module should export joints
[00:33:19] <jmkasunich> export? you mean to HAL?
[00:33:23] <SWPadnos> yes
[00:33:43] <SWPadnos> ie, kins becomes the interface between cartesian space and the hardware
[00:33:57] <jmkasunich> there is a lot that happens between kins and HAL
[00:34:00] <SWPadnos> I haven't thought it through fully yet, so there may be really big problems with the idea
[00:35:27] <jmkasunich> http://jmkasunich.com/pics/emc2-motion-dataflow.pdf
[00:35:35] <SWPadnos> I think a big stumbling block is that there needs to be some back and forth data flow
[00:36:29] <jmkasunich> we don't want kins to be burdened with all the stuff that is on the right half of that drawing
[00:36:45] <jmkasunich> but it would be nice if kins could cause the per-joint stuff to be created
[00:36:46] <SWPadnos> hmmm
[00:36:54] <SWPadnos> yeah, that's what started me on that path
[00:37:03] <SWPadnos> there should be 6 joints if you load genhexkins
[00:37:11] <SWPadnos> anything else is confusing and meaningless
[00:37:50] <jmkasunich> I bet we could have num_joints = 0 in motion, and have a function motion_init_joints(num_joints) that is part of motion but called by the init code of kins
[00:38:23] <SWPadnos> actually, if there's a good "joint function library", then that stuff on the right wouldn't need to be rewritten for each kins, it would just need to be "included"
[00:38:33] <SWPadnos> (though the code would probably reside in each kins module)
[00:38:43] <jmkasunich> no
[00:38:46] <jmkasunich> twice ;-)
[00:38:51] <SWPadnos> heh
[00:39:54] <jmkasunich> 1) the stuff to the right has nothing to do with kins - motion should do the stuff on the bottom right, call fwd kins, do the stuff on the bottom left, do the stuff on the top left, call inv lins, do the stuff on the top right
[00:40:18] <jmkasunich> 2) modules can call each other, so the code wouldn't be reside in kins
[00:41:18] <jmkasunich> kins should stick to doing what kins is supposed to do - transforming between cartesean and joint coordinates
[00:42:15] <SWPadnos> the library I was thinking of would just ahve the code to export all the pins/params (call the function with a struct pointer and a count), and it would have a "feedback_process" function and a "compensation" function, each of which also takes a struct pointer
[00:42:41] <jmkasunich> you're glossing over all the tricky stuff
[00:42:42] <SWPadnos> the "hard part" is all the decision making between jogs of various types, homing, etc
[00:42:44] <SWPadnos> heh
[00:42:54] <jmkasunich> that is in motion, and IMO should stay in motion
[00:43:12] <jmkasunich> it has absolutely nothing - less than nothing even - to do with kinematics
[00:43:57] <SWPadnos> it doesn't have much to do with cartesian trajectory planning/following either
[00:44:01] <SWPadnos> for non-trivkins machines
[00:44:08] <jmkasunich> it doesn't have to
[00:44:38] <SWPadnos> (my understanding is that some of that is in motion, but I know I've been wrong more than I've been right about how that code works)
[00:44:52] <jmkasunich> "motion" is the skeleton that holds all the disparate things together (coord motion, teleop motion, free motion, homing, etc)
[00:45:33] <jmkasunich> "motion" is actually control.c mostly, plus command.c
[00:45:49] <jmkasunich> motion.c is init and export code
[00:46:55] <SWPadnos> yeah - there are a lot of things that "motion" encompasses: decisions about the source of commands, limits on commands, path following, world/joint space conversions, etc.
[00:47:20] <jmkasunich> control.c and command.c handle some of the messy integration stuff - flags for what mode we're in; is there a keyboard jog going on, if so don't allow wheel jogs; are we homed
[00:47:49] <jmkasunich> I don't see any reason to duplicate any of that in multiple kins modules
[00:48:51] <SWPadnos> I don't see any reason to duplicate the source code, but I wouldn't refuse to have multiple modules with that object code in them, if it made more sense at the source level (and it's necessary)
[00:49:00] <jmkasunich> I do like the idea of the kins module calling the portion of motion.c that sets up joint data and joint processing
[00:49:25] <SWPadnos> or at least having a callback or variable available that tells motion.c how many joints to set up
[00:49:41] <jmkasunich> its not neccessary to duplicate the object code - insmod is basically a linking operation
[00:49:44] <SWPadnos> it could be as simple as that - a variable that gets initialized to the number of joints needed
[00:49:47] <SWPadnos> yep
[00:49:57] <jmkasunich> actually, kins would have to call something
[00:50:09] <jmkasunich> (assuming you insmod motion first, which I think we would do)
[00:50:19] <SWPadnos> or motion calls a kins function that returns the number of joints
[00:50:27] <SWPadnos> oh, right -I see the problem
[00:50:31] <jmkasunich> when you insmod motion, the init code in motion.c runs - in kernel space, but not in realtime
[00:51:00] <jmkasunich> if it doesn't export any joints, and sets num_joints to zero, nothing bad will happen when the RT parts start to run
[00:51:25] <jmkasunich> then when you insmod kins, they can call "export_joints(N)" in motion.c which would export stuff and set num_joints non-zero
[00:52:20] <SWPadnos> yep - I was forgetting that (1) modprobe can't know which kins module to automatically load and (2) init has to finish in motion before kins can be loaded
[00:52:21] <jmkasunich> the RT code has several places where it does "for ( joint_num = 0 ; joint_num < num_joints ; joint_num++)"
[00:52:41] <jmkasunich> once num_joints is non-zero, the joint processing code actually does something
[00:52:48] <SWPadnos> yep
[00:55:26] <jmkasunich> I'd kind of like to have HAL pins named something-X, something-Y, -Z, -A, .... -V, -W, instead of axis.<number>.whatever
[00:55:43] <jmkasunich> joint pins would be joint.N.whatever
[00:56:13] <SWPadnos> I'm not sure if the hardy-based release is the right time, but if we're going to change ini names, let's do all of that stuff
[00:56:25] <jmkasunich> yeah
[00:56:37] <jmkasunich> I'm not sure we want to tie EMC2 released to ubuntu releasesd
[00:56:41] <jmkasunich> -d
[00:56:43] <SWPadnos> I was thinking of changing mesa to have names like parport (even though I don't like it :) ) - m5i20.0.P2-3-out
[00:56:53] <SWPadnos> sure
[00:57:05] <jmkasunich> we're gonna want a Live CD with Hardy and EMC2.2.latest-bugfix-release
[00:57:07] <SWPadnos> I'm expecting that to be the next "major release"
[00:57:28] <SWPadnos> ie, the first 2.3 will likely be hardy-based
[00:57:29] <jmkasunich> 2.3.0 is the next major
[00:57:51] <SWPadnos> yes, I agree that a "stable but new OS" release would also be good :)
[00:57:53] <jmkasunich> 2.3.0 will likely be hardy, but hardy won't start with 2.3.0
[00:58:33] <jmkasunich> I want this joint/axis stuff to be in 2.3
[00:58:49] <SWPadnos> yes
[00:58:52] <jmkasunich> otherwise it has to wait for 2.4, and that is likely to be close to a year
[01:00:13] <jmkasunich> I suppose if I want it to happen I need to work on it
[01:00:29] <SWPadnos> heh
[01:00:39] <jmkasunich> its been several weeks since I made that drawing, and said that I was gonna work on state tables showing what switch settings are in effect for each state
[01:01:05] <jmkasunich> hmm, not as bad as I thought - only about 2 weeks
[01:01:07] <jmkasunich> march 2
[01:01:12] <SWPadnos> phew!
[01:01:44] <jmkasunich> maybe this weekend
[01:06:40] <SWPadnos> argh. it would be much easier if I weren't a perfectionist
[01:06:51] <jmkasunich> what are you trying to perfect?
[01:07:05] <SWPadnos> a coherent paper on the history of EMC :)
[01:07:23] <SWPadnos> part of the problem may be that the history isn't coherent
[01:07:49] <jmkasunich> history tends to be messy like that
[01:07:53] <SWPadnos> indeed
[01:09:02] <jmkasunich> I think I'll make some parts - the sooner they're done, the sooner I can do other stuff
[02:53:14] <cradek> jmkasunich: just remember, you touched the planner last
[02:53:31] <jmkasunich> crap
[02:53:37] <cradek> (I know that arc thing isn't your area)
[02:53:49] <cradek> besides, SWPadnos said he'd fix it
[02:53:53] <SWPadnos> I was looking at that earlier
[02:53:55] <SWPadnos> :P
[02:53:57] <jmkasunich> oh, good ;-)
[02:54:30] <SWPadnos> when did he say that? :)
[02:56:03] <cradek> jepler and I talked about it. I think we can fix it. there is a maximum radius that can be handled because of precision. we only have to error for arcs larger than that.
[02:56:24] <cradek> (or, I suspect we could just convert them to a line)
[02:56:34] <jmkasunich> I was about to wonder if that was doable
[02:56:49] <cradek> nobody would write that arc by hand, but some software sure could
[02:57:23] <SWPadnos> if the radius is > 1/(some SCALE), then it's impossible to resolve it anyway
[02:57:36] <SWPadnos> not quite a specific joint scale, but something like that
[02:58:28] <jmkasunich> I'm not sure thats entirely true
[02:58:48] <jmkasunich> imagine the arc is roughly at a 45 degree angle to X and Y
[02:59:08] <jmkasunich> IOW, it goes from 44.999999 degrees to 45.0000001
[02:59:22] <jmkasunich> both axes are moving during the move
[02:59:57] <SWPadnos> somewhere up there, the step/feedback resolution is insufficient to distinguish between a chord and its arc
[03:00:03] <jmkasunich> yeah
[03:00:14] <SWPadnos> I don't know where yet :)
[03:00:19] <cradek> but that's an unrelated issue
[03:00:28] <jmkasunich> its probably a function of both scale and travel limits
[03:00:44] <jmkasunich> the worse case chord is one that goes from one corner of machine travel to the other
[03:00:47] <cradek> this is a numeric problem in cartesian-land
[03:00:48] <SWPadnos> well, it could be used as the threshold instead of whatever limit <double> has
[03:00:59] <SWPadnos> eys, that's true
[03:01:01] <SWPadnos> yes
[03:02:30] <cradek> it's a problem in the posemath arc stuff. the interp gets it right
[03:02:49] <SWPadnos> true, the preview was correct, which does eliminate a lot of code
[03:02:56] <cradek> the fundamental problem is it's hard to guess when the user wants a full circle and when he wants a tiny arc
[03:03:21] <cradek> fwiw, the preview also fails at a larger number
[03:03:32] <SWPadnos> anything with R>min(extents of the two axes of the selected plane) can't be a full circle
[03:03:34] <cradek> (radius of 0.2 lightyears)
[03:03:36] <SWPadnos> heh
[03:04:00] <SWPadnos> however, that doesn't mean the tiny arc should be chosen instead of an error
[03:04:07] <cradek> it's true full circles can't be very big.
[03:04:17] <SWPadnos> (ie, you're right, it's hard to tell what the user wanted and do the right thing)
[03:04:22] <jmkasunich> we could probably calculate a radius much less than 0.2ly that can be rejected (or replaced with a line)
[03:04:34] <cradek> especially since we require X and/or Y words with arcs
[03:04:44] <SWPadnos> [22:56:52]<cradek>jepler and I talked about it. I think we can fix it. there is a maximum radius that can be handled because of precision. we only have to error for arcs larger than that.
[03:04:57] <jmkasunich> if the radius is such that an arc from one corner of the travel to the other would deviate from a straight line by less than one count, it might as well be a line
[03:04:59] <cradek> g3i1 should be a valid arc (obviously a full circle)
[03:05:17] <cradek> jmkasunich: no such thing as a count at this level
[03:05:38] <jmkasunich> and no access to any info that would tell us what a count is?
[03:05:43] <cradek> of course g3i1 today is an error
[03:05:48] <SWPadnos> G91 G2 X0 I1 ??
[03:05:53] <cradek> jmkasunich: not without nasty layering violation
[03:06:09] <cradek> SWPadnos: that might actually be accepted. (bogus, isn't it)
[03:06:13] <SWPadnos> full circle, but X/Y word still required, right?
[03:06:15] <SWPadnos> heh
[03:06:50] <cradek> I think there's several bugs that add up to a problem that seems harder than it is
[03:06:54] <SWPadnos> it's quite valid to have the lower levels tell the upper levels what the effective resolution is
[03:06:59] <cradek> we only need to tackle them one at a time
[03:07:27] <cradek> SWPadnos: I can only use my powers for good, not evil
[03:07:30] <SWPadnos> heh
[03:07:35] <SWPadnos> I wonder ... :)
[03:07:47] <SWPadnos> "with great power comes great responsibility"
[03:07:48] <cradek> it's possible you could get joint resolution. but this is cartesian space
[03:08:40] <SWPadnos> there are several places where the step resolution is used by higher level code, such as GUIs that want a single step jog
[03:08:43] <cradek> we should use all the available precision at each level, and throw it out when we don't need it anymore
[03:08:49] <SWPadnos> sure
[03:09:16] <cradek> SWPadnos: (I think that incremental jog in the gui is the only place)
[03:09:32] <SWPadnos> yes, in several GUIs though, I believe
[03:09:33] <cradek> of course that's a broken assumption for nontrivkins
[03:09:36] <SWPadnos> yes
[03:09:50] <SWPadnos> hence the desire for a "better" way, that's actually useful
[03:10:16] <SWPadnos> but I don't want to digress into a discussion of EMC3 or EMC4 at the moment ;)
[03:10:56] <cradek> yeah this is just a bug (and one that nobody has run into but me with my crappy cam output)
[03:11:33] <jmkasunich> true
[03:11:45] <cradek> I bet all real cam has a max arc radius. I can only imagine what BOSS would do with arcs like that
[03:11:48] <SWPadnos> * SWPadnos punts it back at cradek
[03:12:18] <jmkasunich> but its one of those annoying bugs that could be dealt with by saying "any arc with a radius greater than Rmax is actually a line"
[03:12:29] <jmkasunich> end of problem
[03:12:37] <cradek> ... or an error
[03:12:43] <jmkasunich> as long as you can calculate a reasonalbe Rmax
[03:13:08] <cradek> yes that can be based on the numeric precision where it craps out
[03:13:40] <jmkasunich> two different approaches to calculating Rmax
[03:14:00] <jmkasunich> you are going for "figure out where (and thus why) it craps out, and cut it off just short of that point"
[03:14:16] <cradek> it's not R, it's R vs arc length (proportion) that causes the problem
[03:14:31] <jmkasunich> I'm going for "figure out the minimum that we'll need, and cut it off there, probably very far short of the error"
[03:14:53] <cradek> I didn't mean to be coy, I already know the why
[03:15:06] <jmkasunich> oh
[03:15:17] <SWPadnos> so it did turn out to be precision related?
[03:15:26] <cradek> yes
[03:15:33] <jmkasunich> I saw something about dot products when I read back, but without context I didn't know how far you got
[03:16:31] <cradek> think of pacman. his mouth is two vectors. in posemath if their dot is near 1, it's made into a full circle
[03:16:57] <cradek> even if you change the test to == 1, if you make the radius big enough you'll eventually get that for a short arc
[03:17:32] <cradek> AXIS uses atan2 instead to figure out the two angles. eventually (at still larger radii) the two atan2s will return the same value
[03:18:11] <jmkasunich> that seems like an odd way to decide if you are doing a full circle
[03:18:42] <jmkasunich> of you know where the center is, and where you are, you can compute the vector that is tangent to the circle at your start point
[03:18:53] <jmkasunich> if it points toward the end, its a short arc
[03:19:06] <jmkasunich> if it points away, its a long (>180 deg) arc, or a full circle
[03:19:12] <cradek> if what points?
[03:19:18] <jmkasunich> the tangent
[03:20:49] <cradek> I don't know what you mean by towards/away from the end
[03:21:13] <SWPadnos> the tangent line is a vector pointing one way or the other based on G2/G3
[03:21:21] <jmkasunich> if the center is at Xc,Yc, and I'm at Xs,Ys, I know that ANY G2 arc must start off going in a particular direction
[03:21:37] <jmkasunich> actually, for IJ arcs its even easier
[03:21:55] <cradek> at this stage, these are generalized arcs (helixes)
[03:22:12] <cradek> not necessarily planar anymore
[03:22:14] <jmkasunich> if the center is I,J from start, then the initial vector is IJ rotated 90 degrees ccw
[03:22:19] <SWPadnos> you test for whether the endpoint is on one side or the other of the diametric line from the start point through the center and out the other side (opposite the start point)
[03:22:24] <jmkasunich> the Z component can be ignored
[03:22:39] <jmkasunich> or do you mean that the circle is tilted?
[03:22:53] <cradek> yes it can be any arc
[03:22:58] <cradek> (helix)
[03:23:10] <jmkasunich> SWPadnos said what I was aiming at another (better) way
[03:23:15] <SWPadnos> a helix isn't tilted
[03:23:28] <SWPadnos> it's like a rotary/linear combined move
[03:23:35] <jmkasunich> there is helix, and there is tilted arc, and then there can be tilted helixes
[03:23:45] <cradek> I know very well what a helix is
[03:23:56] <cradek> posemath can have them in any direction
[03:23:56] <jmkasunich> I'm afraid cradek is talking about tilted
[03:24:03] <SWPadnos> in any case, you'd do the line test in whatever plane the arc is in, tilted or otherwise
[03:24:07] <SWPadnos> heh
[03:24:42] <cradek> SWPadnos: the trouble case is when your test is impossible due to precision
[03:24:55] <jmkasunich> cradek: and when is that?
[03:25:03] <SWPadnos> float precision or G-code precision?
[03:25:23] <cradek> imagine it in the plane: the obvious way to do the test is to use atan2 for center->start and center->end, see which is greater
[03:25:32] <cradek> well atan2 returns the same value for both
[03:25:48] <cradek> out of the plane, you use dot(start - center, end - center)
[03:25:49] <jmkasunich> cradek: I think the problem with the existing test is that it uses two vectors, both heading 0.2 ly off towards a very remote center point
[03:25:51] <cradek> well, you get 1
[03:25:56] <jmkasunich> difference of two large things = bad
[03:26:13] <jmkasunich> if you use the actual vector from start to finish its not the difference of two large things
[03:27:20] <jmkasunich> what would happen if you dot(start-center, start-finish)?
[03:27:26] <cradek> (arg, posemath handles helixes with more than one turn too)
[03:27:38] <SWPadnos> jmkasunich, in this case, center is a light year away
[03:27:44] <SWPadnos> heh
[03:27:53] <cradek> jmkasunich: you get 0 regardless of the direction :-(
[03:28:18] <cradek> (because they're perpendicular)
[03:28:38] <jmkasunich> I'm short one point
[03:29:02] <jmkasunich> if we're doing helixes, and we allow the axis to be tilted, we need more points
[03:29:33] <jmkasunich> if we're not doing a helix, then start, finish, and center define a plane, and the circle is in that plane, the axis is perpendicular to that plane
[03:29:35] <cradek> a helix is represented by the projected circle and a perpendicular offset of the endpoint
[03:30:01] <cradek> yes that's pretty much the general description I think
[03:30:08] <jmkasunich> so "finish" = the point on the circle, or the final point (with the offset)?
[03:30:26] <SWPadnos> you'd need XYZ for start,end,and center, plus W or something for helix height
[03:30:33] <cradek> on the circle I think
[03:30:36] <SWPadnos> (for a tilted helix)
[03:30:48] <jmkasunich> ok, so then we can ignore the helix problem (but not the tilt problem)
[03:31:05] <cradek> have a look at pmCircleInit()
[03:31:18] <jmkasunich> what file?
[03:31:20] <cradek> it's actually pretty readable
[03:31:39] <cradek> _posemath.c
[03:32:38] <jmkasunich> ok, we do have four points
[03:32:42] <jmkasunich> start, end, center, normal
[03:33:10] <cradek> sort of - normal is a vector of course
[03:33:27] <jmkasunich> no, its a point
[03:33:35] <SWPadnos> I think that's overdefined if the normal is a vector
[03:33:47] <jmkasunich> oh, wait, its a vector, from 0,0,0 to normal
[03:34:10] <jmkasunich> SWPadnos: the comments acknowledge that it can be overconstrained
[03:34:15] <SWPadnos> ok :)
[03:35:55] <jmkasunich> what is rTan?
[03:36:16] <jmkasunich> duh, never mind
[03:36:17] <cradek> start - center vector
[03:36:56] <jmkasunich> it seems like rPerp is the "tangent vector" I was talking about earlier
[03:37:19] <cradek> yes "starting direction"
[03:37:34] <jmkasunich> ok
[03:37:52] <jmkasunich> what happens if you dot (start-end) with (starting_direction)
[03:38:10] <jmkasunich> doesn't that give you the same info that dotting (start-center) with (end-center) does?
[03:38:53] <jmkasunich> well, not quite the same, but similar, at least in the case where abs(start-end) < abs(start-center)
[03:38:58] <cradek> you could get anything including 0
[03:39:29] <jmkasunich> because it might be a helic?
[03:39:31] <jmkasunich> x
[03:39:39] <cradek> semicircle would give 0 I think
[03:40:06] <jmkasunich> semi-circle doesn't satisfy the condition that abs(start-end) < abs(start-center)
[03:40:32] <jmkasunich> I think I'm suggesting that we switch between the two dot tests based on the relative size of start-center and start-end
[03:41:30] <cradek> I'm baffled by the dot>1.0 and dot<-1.0 tests here
[03:41:31] <jmkasunich> the original test works fine as long as start-end isn't tiny compared to radius
[03:42:09] <cradek> I agree your test sounds better if you can get the same information. but, one of the goals is to get the included angle of the arc, you still need that
[03:42:40] <jmkasunich> included angle is approaching zero (and will eventually be rounded to zero) as radius gets huge
[03:42:47] <jmkasunich> If you need it, you are in trouble
[03:43:24] <cradek> there will always be trouble somewhere. I'm losing track of what's going on here I think.
[03:43:41] <jmkasunich> I never had track of it, so I might just be muddying the waters
[03:44:10] <jmkasunich> but in general, I
[03:44:12] <jmkasunich> oops
[03:44:21] <jmkasunich> I'm suggesting that we do this:
[03:44:48] <jmkasunich> 1) detect when we are in the danger zone - one possible test is abs(start-end) much less than radius
[03:45:18] <jmkasunich> 2) use a different set of calculations in that limited area, ones that don't blow up there, but aren't valid for larger angles
[03:45:46] <jmkasunich> for example, for small angles, sin(theta) approaches theta
[03:46:09] <jmkasunich> so angle = length / radius
[03:46:41] <SWPadnos> abs(start-end)<radius gives you +/- 60 degrees, I think
[03:46:52] <SWPadnos> so as you said, << radius may be better
[03:46:58] <jmkasunich> yeah
[03:47:12] <jmkasunich> abs(start-end) < radius*1e-6 or something
[03:47:22] <SWPadnos> only for large radius, length/radius approaches 0
[03:47:34] <jmkasunich> so does the angle
[03:47:51] <SWPadnos> yes
[03:48:39] <jmkasunich> wow, sin(theta) very rapidly approaches theta when theta gets small
[03:48:56] <jmkasunich> sin(.01 radian) = 0.00999983
[03:49:28] <jmkasunich> sin(.001radian) = 0.001
[03:49:43] <jmkasunich> according to the calculator application
[03:49:45] <SWPadnos> it's that higher order term in the denominator - only the first term in the series is significant
[03:50:10] <SWPadnos> though I don't remember the Taylor series for sin/cos, so I'll shut up now :)
[03:51:15] <jmkasunich> bah, stupid calculator
[03:51:20] <jmkasunich> it was in fix
[03:52:10] <SWPadnos> heh
[03:52:35] <jmkasunich> but it sin(theta) does = theta (to the full resolution of the calc) for theta <= 0.00001
[03:53:05] <SWPadnos> and it's very very close for 0.001 (radians)
[03:53:14] <SWPadnos> to 5 places anyway
[03:53:15] <jmkasunich> for theta=0.001, its about 9 nines
[03:53:20] <SWPadnos> right
[03:53:39] <SWPadnos> 6 (then an 8) using the flawed windows calculator
[03:53:54] <jmkasunich> right, another operator error
[03:54:03] <jmkasunich> 0.001 = 6 nines and an 8
[03:54:13] <jmkasunich> 0.0001 = 8 nines and an 8
[03:54:51] <SWPadnos> ie, close enough
[03:54:51] <jmkasunich> 0.00001 = more nines than the calculator wants to show
[03:56:06] <jmkasunich> so, if len(start-end) < (radius * 0.00001), then use len/rad for included angle, and use a dot between (start-end) and (start-center) instead of a dot between (start-center) and (end-center)
[03:56:41] <jmkasunich> for whatever the dot is used for
[03:57:12] <jmkasunich> while we've been spitting angles at each other cradek got very quiet
[03:57:18] <jmkasunich> he's probably fixing instead of talking
[03:57:43] <cradek> sorry, I went on to start on (what I percieve as) the interpreter bug
[03:58:23] <SWPadnos> :)
[03:58:59] <cradek> I tried this before and got bogged down, I'm trying not to remember that
[03:59:30] <SWPadnos> that's the spirit!
[04:04:00] <cradek> jmkasunich: he used the wrong cd
[04:04:57] <SWPadnos> yes, that's getting more and more obvious
[04:04:57] <jmkasunich> probably, thats why I'm trying to get him to do a uname
[04:05:24] <SWPadnos> use backquotes - then copy/paste still works :)
[04:09:01] <jmkasunich> dog is whining and its past midnight
[04:09:07] <jmkasunich> you know what that means - goodnight
[04:09:12] <cradek> goodnight
[04:09:52] <SWPadnos> night
[04:09:59] <SWPadnos> hmmm - that's too many zeroes leading the time
[04:12:33] <cradek> hmm, this was trivial. I wonder what I missed that I caught last time (and got bogged down by)
[04:21:30] <cradek> oh, now I see it
[04:21:32] <cradek> **sigh**
[04:21:39] <SWPadnos> heh
[04:35:56] <jmkasunich> while I was walking the dog I had arcs in my head
[04:36:28] <jmkasunich> thinking about deviation between arc and line (chord) - its easy to compute for smallish angles
[04:36:48] <jmkasunich> its basically 1-cos(theta/2)
[04:37:09] <jmkasunich> for all I know that is geometry 101...
[04:38:14] <fenn> 1 - r * cos(theta/2)
[04:38:28] <SWPadnos> for theta near 0, cos ~=1-theta
[04:38:38] <jmkasunich> r*(1-cos(theta/2)) ;-)
[04:39:04] <SWPadnos> so 1-cos(t/2) ~= t/2
[04:40:06] <jmkasunich> thats not what my calculator is saying
[04:40:25] <SWPadnos> hmmm
[04:40:48] <jmkasunich> for theta = 0.01, 1-cos(theta/2) = 0.0000125
[04:41:00] <SWPadnos> oh true - there's a square in there
[04:41:46] <jmkasunich> at theta = 0.000001 or so, 1-cos(theta) rounds off to zero
[04:41:56] <jmkasunich> (12 digits of zero)
[04:42:04] <SWPadnos> yep
[04:42:26] <SWPadnos> sp when you get to the ratio where the sin is ~=theta, 1-cos(theta/2) ~=0
[04:42:28] <SWPadnos> so
[04:42:44] <jmkasunich> except its not - more nasty roundoff stuff
[04:42:56] <jmkasunich> cos(theta/2) is approaching 1, and eventually rounds off to 1
[04:42:57] <SWPadnos> did you notice that cradek fixed something?
[04:43:07] <SWPadnos> or at least found the problem
[04:43:42] <jmkasunich> but if you did the 1-cos(theta) in infinite precision, the result would just get smaller and smaller, it wouldn't suddenly dissappear
[04:44:01] <jmkasunich> no commit - I don't know what he did
[04:44:13] <cradek> who me?
[04:44:13] <SWPadnos> heh - me either, but it was trivial ;)
[04:44:18] <cradek> uh no
[04:44:24] <SWPadnos> "this was trivial ..."
[04:44:36] <cradek> followed shortly by ...
[04:44:45] <jmkasunich> sigh
[04:44:52] <SWPadnos> heh
[04:45:19] <cradek> I really don't know what should be accepted
[04:45:22] <cradek> g0x0y0z0
[04:45:23] <cradek> g3i1
[04:45:29] <cradek> ^ obviously a circle
[04:45:32] <cradek> i2
[04:45:34] <cradek> ^ another circle
[04:45:37] <cradek> g2
[04:45:42] <cradek> ^ what the hell is this supposed to do?
[04:45:46] <SWPadnos> error
[04:45:58] <cradek> why? it makes perfect sense if all the words are kept the same
[04:46:04] <fenn> no i or j words
[04:46:12] <SWPadnos> I'd say you have to specify I/J
[04:46:35] <SWPadnos> but then again, I suppose you could do it without that
[04:46:41] <SWPadnos> err - accept it
[04:46:41] <cradek> yeah I have that so far I think
[04:46:47] <fenn> did you mean g3?
[04:46:53] <SWPadnos> either
[04:46:56] <cradek> either
[04:47:13] <SWPadnos> if IJK are also the same (like XYZ) when not specified, then you'd have a fully specified center and end
[04:47:13] <jmkasunich> I don't see the problem with a statement that says "at least one of X,Y is needed", ditto for "at least one of I,J"
[04:47:44] <cradek> jmkasunich: if at least one of X,Y is needed, the most obvious way to surely make a full circle (g3i1) is disallowed for no good reason
[04:48:11] <cradek> and, it's contrary to how all the rest of gcode works, where you don't have to respecify an axis value that's already set in an above block
[04:48:16] <fenn> if you use R arcs you need X and/or Y
[04:48:24] <cradek> fenn: yes
[04:48:25] <fenn> if you use IJ arcs you need one of I or J
[04:48:31] <cradek> and, I think that's broken too
[04:48:33] <cradek> g0x1
[04:48:37] <cradek> g3x1r1
[04:48:44] <cradek> ^ gives a circle
[04:48:55] <cradek> (probably shouldn't)
[04:48:56] <jmkasunich> where is the center?
[04:49:06] <cradek> I agree that's the interesting question
[04:49:13] <jmkasunich> I could draw 100 circles that satisfy that
[04:49:24] <jmkasunich> (which is why I don't use R arcs)
[04:49:29] <cradek> sure, I could draw 101, emc picks one of them
[04:49:30] <fenn> maybe r arcs need X and Y
[04:49:44] <cradek> no, X OR Y
[04:50:03] <cradek> that's the current rule, but that's clearly not sufficient
[04:50:08] <jmkasunich> not so much need X and Y, but need the end pos to NOT equal the start position
[04:50:15] <cradek> right
[04:50:15] <fenn> yeah that's what i meant :)
[04:50:21] <jmkasunich> R arcs are undefined if start = end
[04:50:42] <fenn> the circle center could be on any point on a circle with radius R around the current point
[04:50:43] <cradek> can someone try that? my tree is all fuxored
[04:50:54] <jmkasunich> hairy for angles near 0 or 180, and completely undefined for angles of exactly 0
[04:50:56] <cradek> maybe I broke it
[04:51:40] <fenn> it was fragile
[04:51:43] <cradek> g0x0y0z0
[04:51:47] <cradek> g3i1
[04:51:52] <cradek> ^ obvious arc
[04:51:55] <cradek> g3j1
[04:52:02] <cradek> ^ where is the center? 0,1 or 1,1?
[04:52:25] <jmkasunich> how is the first one an obvious arc? its a complete circle
[04:52:33] <cradek> sorry, I meant circle
[04:52:49] <jmkasunich> oh, I see what you are getting at
[04:53:05] <jmkasunich> if you follow convention, it will be 1,1
[04:53:20] <jmkasunich> cause I is still 1
[04:53:45] <cradek> I have no idea if that's what anyone else does
[04:53:48] <fenn> the second arc would be at 0,1 because I and J are incremental
[04:54:09] <cradek> fenn: only if you're assuming they aren't sticky
[04:54:16] <fenn> and incrementals shouldn't add up or suddenly you're doing a velocity command
[04:54:33] <jmkasunich> how does incremental g-code work? if I go into incremental mode and do G1X1; G1Y1, what do I get?
[04:54:45] <SWPadnos> only the specified axes move
[04:54:59] <fenn> you end up at 1,1 - NOT at 2,1
[04:55:01] <SWPadnos> which isn't possible for arcs/circles, since the "unspecified" values would still affect the motion
[04:55:13] <jmkasunich> so in incremental mode, it is interpreted as G1X1Y0; G1X0Y1
[04:55:15] <SWPadnos> so they need to be specified or set to 0
[04:55:29] <cradek> I bet this is why cam programs have "always output all words for arcs"
[04:55:37] <jmkasunich> while in regular mode, it would be interpreted as G1X1Ywhatever-it-was, G1X1Y1
[04:56:26] <jmkasunich> if G1 X and Y values aren't sticky in incremental mode, then I and J (which are always incremental) shouldn't be sticky either
[04:56:42] <cradek> in G91 mode the named axes move the given distance
[04:57:07] <jmkasunich> then in G2/3, the named (I/J/K) axes should offset the given distance
[04:57:08] <cradek> that seems like a stretch. they aren't really much like incremental motion
[04:57:17] <SWPadnos> unspecified values for endpoints are OK, but for arc center, they should be set to 0, not sticky
[04:57:37] <jmkasunich> they are offsets from the current position, just like G91 X and Y, hence incremental
[04:57:40] <cradek> I'm leaning to setting them to 0, but I can't quite describe why
[04:57:55] <SWPadnos> because they are unseen but they still affect the shape of motion
[04:57:56] <jmkasunich> well, I agree with you, and I did describe why ;-)
[04:58:33] <SWPadnos> G91G0X1 obviously does something to X - it would be a surprise if something happened to YZ
[04:58:53] <cradek> it would break the simple rule "you must output a word and its new value if it's different from previously"
[05:00:06] <jmkasunich> actually (semantics) the rule it would break is "you don't have to output a word and its value if the value hasn't changed"
[05:00:13] <cradek> right
[05:00:15] <SWPadnos> jmkasunich had it right - unspecified absolute values are unchanged. to get the same effect for unspecified relative values, the relative offset has to be set to zero, not the previous value
[05:00:39] <SWPadnos> err - not the previously specified offset ...
[05:01:22] <cradek> I still think equating G91's XYZ and G90's IJK is a stretch, even though they specify a relative/offset point
[05:01:33] <jmkasunich> it is, a bit
[05:01:47] <SWPadnos> it's the unchanged thing that makes them similar
[05:01:57] <SWPadnos> an offset of 0 = no change
[05:02:10] <SWPadnos> an absolute value = last specified = unchanged
[05:02:17] <jmkasunich> the difference is that in G91, non-zero values change the base point every time
[05:02:31] <jmkasunich> in G2/G3, non-zero offsets don't move the base point
[05:03:22] <cradek> maybe I should ask stuart to take a poll of this behavior on all his controls again (that must be so tedious)
[05:03:41] <SWPadnos> I'd say it's acceptable to say that IJK default to 0, and that you also can't have the center = an endpoint. those two conditions would require at least one of IJK to be specified and nonzero
[05:04:22] <cradek> yay, you're arguing for what I've already done
[05:04:33] <SWPadnos> good deal! :)
[05:04:34] <cradek> I think we all agree that's least surprising
[05:04:35] <jmkasunich> we have three choices, right? 1) require I and J, even if they are zero 2) use zero for I or J if unspecified 3) use previous value of I or J if unspecified
[05:04:57] <cradek> 1) would be contrary to even the old behavior
[05:05:04] <cradek> oh hey, the old behavior
[05:05:08] <cradek> wonder what it did
[05:05:13] <SWPadnos> heh
[05:05:20] <cradek> can someone try it?
[05:05:25] <SWPadnos> I think the problem was that you had to specify XYZ
[05:05:31] <cradek> sure
[05:05:32] <SWPadnos> that's what you were trying to fix, right?
[05:05:45] <cradek> but you could try g0x0y0z0; g3x0i1; g3x0j1
[05:05:51] <SWPadnos> one sec
[05:05:53] <SWPadnos> or3
[05:05:54] <cradek> the location of the second circle would tell you if I is sticky
[05:06:02] <SWPadnos> I'm betting it isn't
[05:06:05] <cradek> me too
[05:06:16] <SWPadnos> that would be exceedingly surprising
[05:06:21] <cradek> would you also try g0x0y0z0; g3x0r1; g3x0r1
[05:06:38] <jmkasunich> that should be an error
[05:06:41] <cradek> hoping I haven't made that worse
[05:06:50] <cradek> yes, it's currently not, in my tree
[05:07:15] <jmkasunich> I suppose I should fire up emc an try some of these, but its past my bedtime
[05:07:28] <cradek> me too, but I feel like this is close
[05:08:53] <SWPadnos> I was not sticky for the first set
[05:08:58] <cradek> yay
[05:09:50] <SWPadnos> g3x0r1 gives an arc centered at 0,1
[05:09:58] <SWPadnos> lemme try one other thing
[05:09:58] <cradek> ouch
[05:10:06] <cradek> at least I didn't make it worse
[05:10:16] <cradek> that's a separate issue then
[05:10:28] <SWPadnos> hmmm. interesting
[05:10:46] <cradek> ooh this time I got "Current point same as end point of arc"
[05:10:57] <SWPadnos> I got the 0,1-centered circle after doing G3X0J1
[05:11:08] <SWPadnos> I got the error after G3X0I1
[05:11:21] <cradek> I'm lost
[05:11:31] <SWPadnos> and that's repeatable
[05:11:41] <jmkasunich> ditto, I have no idea what you got
[05:12:07] <SWPadnos> ok, when I issue G3 X0 R1, I get different results depending on what the previous move was
[05:12:28] <jmkasunich> the test was G0X0Y0Z0, the G3X0R1
[05:12:28] <SWPadnos> if the previous move was G0 X0 I1, I get an error about start and end points being the same
[05:12:43] <jmkasunich> what? why I on a G0 move?
[05:12:44] <SWPadnos> yes - sorry, substitute G3 for G0 above
[05:12:53] <jmkasunich> don't mix I and R yet
[05:12:58] <SWPadnos> ok, let me start over
[05:13:00] <jmkasunich> just do G0, then G3 with R
[05:13:11] <SWPadnos> yes, I did that, then went on from there :)
[05:13:22] <jmkasunich> so, what did that do?
[05:13:26] <SWPadnos> G0 then G3+R worked fine
[05:13:34] <SWPadnos> G0 then G3+I worked fine
[05:13:40] <jmkasunich> slow down
[05:13:46] <jmkasunich> there is no "worked fine" for the first one
[05:13:59] <jmkasunich> an R arc with the end = the start is undefined
[05:14:12] <SWPadnos> I'm saying that I got an arc with center 0,1
[05:14:14] <jmkasunich> EMC may have picked something and drawn it, but that is not "working fine"
[05:14:22] <SWPadnos> so that's not "worked fine" - you're right
[05:14:59] <SWPadnos> however, when I do "G3 X0 I1" then "G3 X0 R1", I do get the correct error message and no motion
[05:15:33] <SWPadnos> so G3 X0 J1 then G3 X0 R1 does a circle when it shouldn't, centered at 0,1
[05:16:00] <SWPadnos> also, G0 X0 Y0 Z0 then G3 X0 R1 does the same circle centered at 0,1, no error
[05:19:11] <cradek> -2.79741e-16 5.59482e-16 -> 0 5.59482e-16
[05:19:28] <cradek> g0x0y0; g3x0r1
[05:19:35] <cradek> the zeroes don't match
[05:21:35] <cradek> another case of
http://timeguy.com/cradek/01201480454
[05:22:48] <cradek> I so hate floating point
[05:22:53] <SWPadnos> heh
[05:23:37] <cradek> well heck, I think I'll commit this
[05:23:47] <cradek> the R problem is minor
[05:23:57] <cradek> (and I didn't just cause it)
[05:24:09] <CIA-22> EMC: 03seb 07v2_2_branch * 10emc2/src/hal/drivers/mesa7i43-firmware/to-header.py: add m7i43_hm2 driver (version 0.4) from TRUNK
[05:24:10] <CIA-22> EMC: 03seb 07v2_2_branch * 10emc2/src/hal/drivers/ (m7i43_hm2.comp m7i43_hm2.h Submakefile): add m7i43_hm2 driver (version 0.4) from TRUNK
[05:24:11] <CIA-22> EMC: 03seb 07v2_2_branch * 10emc2/src/hal/drivers/mesa7i43-firmware/hostmot2/ (9 files): add m7i43_hm2 driver (version 0.4) from TRUNK
[05:24:11] <CIA-22> EMC: 03seb 07v2_2_branch * 10emc2/src/hal/drivers/mesa7i43-firmware/hostmot2/src/ (24 files): add m7i43_hm2 driver (version 0.4) from TRUNK
[05:24:29] <seb_kuzminsky> hope that worked
[05:24:41] <seb_kuzminsky> first time using branches in CVS...
[05:24:49] <cradek> the messages look right
[05:25:48] <cradek> I'm still worried because when I tried this interp fix last time, it was worse
[05:26:03] <cradek> either I'm smarter now (unlikely) or I'm missing something I didn't miss before (likely)
[05:26:09] <CIA-22> EMC: 03seb 07v2_2_branch * 10emc2/debian/ (changelog drivers.files.in emc2.files.in): Include the m7i43_hm2 driver in emc2.deb
[05:26:10] <CIA-22> EMC: 03seb 07v2_2_branch * 10emc2/docs/AUTHORS: Include the m7i43_hm2 driver in emc2.deb
[05:27:08] <seb_kuzminsky> not sure what the policy is on changing debian/changelog, i used dch and it put my name & email as the maintainer
[05:27:28] <cradek> that's fine, jepler's will end up there when he makes the release
[05:27:36] <seb_kuzminsky> makes sense
[05:28:22] <SWPadnos> cradek, you could well be smarter about this problem - you've already looked at it once
[05:28:25] <SWPadnos> at least once :)
[05:28:28] <CIA-22> EMC: 03cradek 07TRUNK * 10emc2/src/emc/rs274ngc/ (interp_internal.cc interp_convert.cc):
[05:28:28] <CIA-22> EMC: Allow full circle arc specifications like "g3i1". This also means
[05:28:28] <CIA-22> EMC: sticky XYZ words are honored for arcs - they weren't before, causing
[05:28:28] <CIA-22> EMC: trouble for cam packages.
[05:29:03] <cradek> seb_kuzminsky: that's great, I'm anxious to hear that more people are using those boards. They seem like a good alternative to pluto.
[05:29:24] <seb_kuzminsky> thanks! I hope people use them too
[05:29:35] <SWPadnos> hmmm. I guess I never ordered any
[05:29:38] <SWPadnos> bummer
[05:30:04] <cradek> I'd like one too, but would have no immediate plans for it
[05:30:22] <SWPadnos> same here :)
[05:30:29] <seb_kuzminsky> i'm not real familiar with FPGAs, but so far i like the Spartan 3 on the 7i43 - lots of gates & free (gratis) linux dev tools
[05:30:41] <SWPadnos> yes, Xilinx is good that way
[05:30:58] <SWPadnos> Altera, Lattice, and Actel could use a similar polic
[05:31:00] <SWPadnos> y
[05:31:40] <seb_kuzminsky> i'm excited to hack on the 5i22, 1.5 Mgates :-)
[05:31:50] <SWPadnos> heh - yep. it's a lot
[05:32:15] <SWPadnos> I think I built hostmot2 with every pin used (twice), and it was still ~400k gates or something
[05:32:39] <seb_kuzminsky> yeah, the io pins are definately the limiting resource on these boards
[05:32:42] <SWPadnos> heh
[05:32:48] <seb_kuzminsky> kind of a bummer
[05:33:05] <fenn> only 72 i/o you poor poor man
[05:33:09] <SWPadnos> well, there are other things that can be done in gates
[05:33:12] <SWPadnos> 96 on the 5i22
[05:33:20] <cradek> goodnight folks
[05:33:24] <SWPadnos> night cradek
[05:33:32] <seb_kuzminsky> goodnight cradek
[05:33:35] <SWPadnos> the inputs could use good debounce
[05:33:43] <seb_kuzminsky> 48 pins on the 7i43
[05:33:59] <SWPadnos> one way to do that is to hang a counter on each input, and count up when the input is 1 and down when the input is 0
[05:34:17] <seb_kuzminsky> the encoders are heavily debounced, not sure if the pins in gpio mode are
[05:34:25] <SWPadnos> when you hit a threshold (like 10% o 90% of the counter range), you signal a change
[05:34:32] <seb_kuzminsky> right, that makes sense
[05:34:34] <SWPadnos> nope, not that I've seen
[05:34:46] <seb_kuzminsky> i'm not sure how pcw implemented the debouncing on the encoder inputs
[05:34:55] <SWPadnos> that would be 96 counters at 10-16 bits each, plus comparators ...
[05:35:09] <SWPadnos> I think it was just 4 or 8 clocks the same
[05:35:10] <seb_kuzminsky> there's a register where you specify 3x or 15x oversampling on the pins, iirc
[05:35:23] <SWPadnos> hmmm - ok. I should look at hostmot2 again
[05:35:33] <SWPadnos> he was developing it when I last saw it, I think
[05:35:57] <SWPadnos> or he had just done the config for the 5i22 or something
[05:36:21] <seb_kuzminsky> supposedly the hostmot2 code is portable between all the "anything i/o" boards
[05:36:52] <SWPadnos> yes, as long as it fits :)
[05:37:12] <SWPadnos> you also need to have the correct pin file, and change the constants defining how many headers and instances of things you want
[05:37:12] <seb_kuzminsky> right :-)
[05:37:18] <SWPadnos> as well as the register map
[05:38:47] <seb_kuzminsky> the register map is provided to the driver by the firmware's "idrom" header
[05:39:14] <seb_kuzminsky> it tells you how many instances of each function are compiled into the firmware, and what pins each instance is hooked to
[05:39:35] <SWPadnos> interesting
[05:40:05] <SWPadnos> pete probably split the register space into large-ish blocks that aren't fully used
[05:40:09] <seb_kuzminsky> the *meaning* of the registers needs to be known a-priori by the driver of course
[05:40:13] <SWPadnos> sure
[05:40:13] <seb_kuzminsky> yes he did
[05:40:54] <seb_kuzminsky> he just added something he calls Translation RAM to make the large sparse address space managable for DMA and EPP
[05:41:02] <SWPadnos> the address decoding was something that looked fairly "manual" in the VHDL code - not generated by the constants that define how many instances are generated of each thing
[05:41:23] <SWPadnos> interesting
[05:41:39] <SWPadnos> I'll have to grab a copy sometime when I have time to look at it again
[05:41:50] <seb_kuzminsky> sure, it's in the EMC2 tree now :-)
[05:41:59] <SWPadnos> the hostmot2 source?
[05:42:10] <seb_kuzminsky> yes, for the 7i43 at least
[05:42:12] <SWPadnos> ok
[05:42:20] <seb_kuzminsky> src/hal/drivers/mesa7i43-firmware/hostmot2
[05:42:44] <SWPadnos> oh - I have a driver I got from U Twente, which has support for a /proc interface for programming these cards (not the 7i43)
[05:43:08] <SWPadnos> you get nodes like /proc/anythingIO/card0 ...
[05:43:27] <seb_kuzminsky> exposing the cards register file in /proc, then all the smarts to talk to the firmware resides in userspace?
[05:43:33] <SWPadnos> userspace code can do I/O, though the driver itself isn't RT at the moment
[05:43:45] <SWPadnos> no, it's in kernel - think like a serial port
[05:43:56] <SWPadnos> you write to the "file" and the driver deals with the hardware
[05:44:18] <SWPadnos> similar deal here
[05:44:42] <seb_kuzminsky> sure, but at what level of abstraction? does the driver expose encoders, pwmgens, etc in /proc, or does it expose a flat register file for userspace to parse?
[05:45:11] <SWPadnos> their driver exposes the programming interface (to root), and the memory map of the card
[05:45:17] <seb_kuzminsky> right
[05:45:28] <SWPadnos> the memmap is available in kernel, or to root in userspace
[05:45:37] <seb_kuzminsky> that seems like the easy part :-)
[05:45:55] <SWPadnos> it's the part that we don't want to deal with though
[05:46:00] <SWPadnos> the "generic" part of the driver
[05:46:22] <seb_kuzminsky> hm, i thought i understood you before but now i'm not so sure
[05:46:24] <SWPadnos> we should be concerned with using HAL stuff, not dealing with pci_find_device()
[05:46:32] <seb_kuzminsky> ok, i see
[05:46:33] <SWPadnos> heh - lemme find the link to the paper :)
[05:46:49] <seb_kuzminsky> U Twente is a person?
[05:46:59] <SWPadnos> http://www.ce.utwente.nl/rtweb/publications/MSc2007/pdf-files/023CE2007_Molanus.pdf
[05:47:07] <seb_kuzminsky> a university?
[05:47:08] <SWPadnos> University Twente
[05:47:12] <SWPadnos> yep
[05:47:40] <seb_kuzminsky> wow
[05:47:51] <SWPadnos> I emailed the guy (Jeffry Molanus), and he sent me the code this past Monday
[05:48:14] <SWPadnos> it does look useful to me - just use a userspace app to program the card, then load the HAL driver
[05:48:34] <SWPadnos> it supports different cards (mostly the PC104 ones at the moment)
[05:48:41] <seb_kuzminsky> yeah, you convinced me that's the way to do it last time we spoke :-)
[05:48:44] <SWPadnos> heh
[05:49:01] <SWPadnos> of course, you have to build the FPGA code for each specific card
[05:49:20] <seb_kuzminsky> i think there are three different devices that need I/O drivers: two different PCI chipsets and the EPP board
[05:49:36] <SWPadnos> I can email you the code if you like
[05:49:39] <seb_kuzminsky> each kind of device gets its own firmware uploading program in userspace
[05:49:46] <seb_kuzminsky> i'd love it! seb@highlab.com
[05:49:57] <SWPadnos> for the parport, I think it's necessary to have a different one
[05:50:07] <seb_kuzminsky> heh - we'll see ;-)
[05:50:41] <seb_kuzminsky> the low-level i/o drivers will basically export read() and write() functions, implemented however the underlying hardware wants to talk
[05:50:51] <seb_kuzminsky> epp, pci pio, or pci dma
[05:51:19] <seb_kuzminsky> the low-level i/o drivers discover their cards and register them with a generic hm2 driver
[05:51:21] <SWPadnos> but if it presented the same proc interface, that would make the userspace programming code trivial:
[05:51:33] <SWPadnos> cp bitfile > /proc/anythingIO/card0_program :)
[05:51:47] <seb_kuzminsky> which knows how to think about hm2, and calls back into the low-level i/o drivers to do th i/o
[05:52:07] <seb_kuzminsky> thanks
[05:52:33] <SWPadnos> the drivers would get a memory pointer - they don't necessarily need to know if that goes directly to PCI memory or if it gets downloaded throgh the parallel port
[05:52:35] <SWPadnos> sure
[05:54:57] <SWPadnos> gotta hit the sack. see you later
[05:55:26] <seb_kuzminsky> ok, thanks for the U Twente code and the talk
[05:55:40] <SWPadnos> sure - thanks for the driver work :)
[09:32:13] <alex_joni> SWPadnos: how about sticking that in VCS on a branch, if it's GPL ?
[11:22:46] <alex_joni> I meant CVS..
[18:15:16] <SWPadnos> alex_joni, yes, I think I can stick it in CVS
[18:22:35] <alex_joni> SWPadnos: great
[18:23:02] <SWPadnos> I just sent an email to the author, asking if it was OK with him. I'll wait for the reply (which I'm sure will be positive :) )
[18:23:26] <SWPadnos> they have an SVN repo, but it's not publically accessible
[19:14:49] <jepler> cradek:
http://www.rtai.dk/cgi-bin/gratiswiki.pl?LXRT_FAQs Q: I noticed that linux's /proc/loadavg shows unusual linux load when a RTAI scheduler runs(even when RTAI tasks are almost idle)?
[19:14:53] <jepler> A: This comes from the fact that some internal daemons started by LXRT (kthread_b, kthread_m) are waiting for requests in TASK_UNINTERRUPTIBLE state, so their cumulated wait time is charged as being actual load by Linux.
[20:00:44] <LawrenceG> cradek: meep?
[20:02:52] <LawrenceG> cradek: who has done most of the work on classic ladder? I am considering a port of the control portion to a PIC
[20:03:35] <fenn> pete vavaroutsos and chris morley
[20:03:50] <fenn> fwiw petev hasn't touched it in years
[20:07:43] <alex_joni> LawrenceG: the most work did a guy from france :)
[20:07:58] <alex_joni> but porting has been done by 3 persons
[20:12:13] <LawrenceG> cradek: I have several home applicances with brain dead controllers (my heat pump and my stove) that need new smarts
[20:12:26] <alex_joni> petev did the first port, then jepler did one and now cmorley is working actively on it
[20:12:43] <alex_joni> * alex_joni wouldn't put his own software in critical places
[20:13:54] <LawrenceG> hey.. its got to be better than the crap that is in them currently....
[20:14:49] <LawrenceG> I have a heat pump that insists on defrosting every 30 minutes even when it has no potential for iceing up
[20:15:58] <LawrenceG> and a stove that the control board (worth $400) burnt up last night because of poor soldering of the oven control relay to the PCB
[20:16:32] <LawrenceG> 240v arc with 11amp oven element made for a spectacular display
[20:16:53] <jmkasunich> OUCH
[20:17:02] <jmkasunich> oops, caplock
[20:17:13] <LawrenceG> big ouch!
[20:17:17] <jmkasunich> LawrenceG: remember the spring steel screw covers?
[20:17:30] <jmkasunich> I submitted a request for quote last Sunday, they never replied
[20:17:53] <LawrenceG> ahh yes...
[20:18:08] <jmkasunich> I tried calling them a few times during the week, but I was in training classes Mon-Thur, so I could only call around lunchtime or late in the day, never got thru
[20:18:27] <jmkasunich> I tried on Friday, also didn't get thru, but maybe they were off (Good Friday)
[20:19:00] <jmkasunich> I'll try again next week, but my thoughts toward that company aren't very kind at the moment
[20:19:41] <LawrenceG> yes... I wonder if the cover could be replaced with just a top cover and bolt the nut to a vertical bracket...
[20:20:02] <jmkasunich> I did find that McMaster sells a few sizes of those covers - not suitable for a shoptask tho - the ones that are long enough are too fat
[20:20:19] <jmkasunich> from McMaster they run $60-80 each
[20:21:47] <jmkasunich> for acme screws I might risk a top cover only
[20:21:52] <jmkasunich> but for ballscrews, I want better
[20:23:11] <LawrenceG> with a totally enclosed screw, it would be hard to tell when it needs lube... need an hour meter and a maintenance schedule
[20:23:39] <LawrenceG> maybe emc needs to keep a running total of feet moved
[20:23:55] <jmkasunich> a few years ago I scrounged a Bijur electric oiler - I'm planning on plumbing the saddle to oil ways and ballnuts
[20:24:13] <LawrenceG> var 5005 says oil x axis
[20:24:56] <LawrenceG> yea... I dont do enough work to need auto oiling.... I pretty much clean it using fresh oil each time I use it
[20:25:42] <LawrenceG> wipe the table, ways and screws
[20:25:42] <jmkasunich> I don't need auto oiling either
[20:26:03] <LawrenceG> how did the nut reduction job go?
[20:26:05] <jmkasunich> but getting oil onto the table ways in particular involves defying gravity
[20:26:14] <jmkasunich> the nuts are done
[20:26:28] <jmkasunich> now I have to make the blocks themselves - the metal arrived yesterday
[20:27:27] <LawrenceG> for the wyas, I usually just oil my finger and run it down the underside of the ways then wipe them down to get rid of the drips
[20:29:13] <LawrenceG> I like the idea of a PIC interfaced to solid state relays for appliance control... serial interface for programming/debugging, but I dont know enough of the classic ladder structure to know if it is feasible
[20:29:14] <jmkasunich> another idea that has crossed my mind for screw guards (somebody here mentioned it I think)
[20:29:27] <jmkasunich> rigid sides, and a wide steel tape measure on top
[20:29:46] <LawrenceG> yea... 1" wide tape measures are cheap
[20:29:53] <cradek> I think that sounds very clever
[20:30:26] <jmkasunich> the trick will be keeping the tape down flat on the sidewalls
[20:30:42] <LawrenceG> I would run it in a groove
[20:30:50] <jmkasunich> I'd want to put the tape convex side up to shed crap, and I would want the walls to be under it
[20:31:15] <jmkasunich> if the tape runs in a groove, crap that lands in the tape won't slide off, it will hit the sidewalls
[20:32:55] <LawrenceG> true... still some cleanup required, but the swarf would not get in and the fine particles and oil would still keep clear of the screw
[20:33:51] <jmkasunich> well, I'm off for a bit - its kind of nice out, and I want to try my new tripod head
[20:34:06] <jmkasunich> old one broke - cheap plastic and cold weather don't mix
[20:34:13] <cradek> you must be pretty far away if it's nice out
[20:34:21] <LawrenceG> have fun... I am going to cruise the classic ladder code
[20:34:43] <jmkasunich> I think you'll fund that CL isn't very lightweight
[20:34:53] <jmkasunich> but the vast majority of the code is the ladder editor
[20:35:07] <jmkasunich> I think the RT part that actually executes the ladder isn't so bad
[20:35:18] <SWPadnos> I think the meat of the executor is in the file calc.c
[20:35:22] <jmkasunich> (but I'm talking out my hat here, I've only given it the briefest glances)
[20:36:00] <LawrenceG> thanks.. leaving the editor on linux would be very nice.... I would try and put just the exec on a PIC
[20:36:19] <jmkasunich> test on the PC, then move to the PIC ;-)
[20:36:55] <LawrenceG> yea... I need to see how much rtai code I would need to replace
[20:36:57] <jmkasunich> the editor has a live display of the ladder state (rungs, contacts, and coils change color), very nice for troubleshooting
[20:37:49] <LawrenceG> searching the inet for classic ladder doest seem to bring up any hits of a PIC port so far
[20:37:57] <jmkasunich> since the RT part is a hal component, interaction with RTAI is very well layered
[20:38:14] <jmkasunich> the RT part of CL exports a HAL function, which is really just a C function
[20:38:24] <jmkasunich> and HAL calls it periodically
[20:38:30] <jmkasunich> that should be easy to do on a bare CPU
[20:38:41] <LawrenceG> I figured the emc port would be the best starting point because of that
[20:39:15] <jmkasunich> it would be interesting to try to make a HAL "shell" that would work on a microcontroller
[20:39:25] <jmkasunich> couldn't use floating point comps most likely
[20:39:29] <LawrenceG> is the programming/realtime interaction shrough shm currently?
[20:39:39] <jmkasunich> yes
[20:40:11] <SWPadnos> in calc.c, the function "RefreshAllSections" is the heavy lifter
[20:40:12] <LawrenceG> the 30fxxxx pics I have been using have wonderfull FP performance.... I am doing complex number math on them
[20:40:48] <LawrenceG> not pentium class, but far better than 8bit micros!
[20:40:56] <SWPadnos> real FP?, or "FP" = fixed point? :)
[20:41:18] <LawrenceG> real floating point complex math libs
[20:41:32] <jmkasunich> hmm
[20:41:37] <SWPadnos> cool. what kind of performance do you get? (FLOPS)
[20:42:45] <jmkasunich> it would be slick as snot to have a HAL system where you can "loadrt" and the code goes into a microcontroller, but you can still somehow use halscope etc for testing, then disconnect from the PC and let it run
[20:43:53] <SWPadnos> hmmm
[20:44:12] <LawrenceG> not sure, but one project
http://members.shaw.ca/swstuff/vna.html has pretty brutal math and I also have
http://members.shaw.ca/swstuff/dspic-servo.html which does floating point PID up to at least 4khz loops
[20:44:30] <SWPadnos> that's at ~30 MHz?
[20:44:56] <LawrenceG> I think the current clocks are about 1/2 the max possible
[20:45:08] <LawrenceG> speed never became an issue
[20:45:11] <SWPadnos> heh
[20:45:22] <SWPadnos> CL doesn't really need FP anyway
[20:45:45] <SWPadnos> it can use floats for time delays, but that can easily be implemented as int or fixed point
[20:46:34] <SWPadnos> the PIC will bite you because of the lack of working registers, plus the bank switching (unless the dspic is significantly different)
[20:46:42] <LawrenceG> cool I like the hal plugin idea.... then I dont have to write as much of the user side interface
[20:47:18] <LawrenceG> dspic is a 24bit instruction, 16 bit data bus processor, so no bad
[20:47:29] <LawrenceG> not bad
[20:48:07] <SWPadnos> for relatively low sample rates that could be done with a hardware SPI interface. But, you can only get up to ~20 MHz clocks from SPI, so the total HAL data from the uC would be limited to something in that range
[20:48:29] <SWPadnos> that's not bad though - 2.5 mbytes/sec
[20:49:12] <LawrenceG> It takes a lot of C to fill up the 48k address space on the devices I am using (biggest through hole parts) dspic 30f4011
[20:49:17] <SWPadnos> LawrenceG, yeah - I know the dsPic is a wider instruction set/data bus device. I haven't looked at it enough to see if they have more than the W register though :)
[20:49:19] <SWPadnos> heh
[20:49:58] <LawrenceG> they are a lot like the 68000 if you get to register level... I have been doing everything in C
[20:50:17] <SWPadnos> hmmm - complete with 16 or 32 registers?
[20:50:24] <SWPadnos> "usable registers" :)
[20:50:24] <LawrenceG> I think 16 16bit registers
[20:50:29] <SWPadnos> oh, that's cool
[20:50:41] <SWPadnos> since they have PIC in the name, I've kind of ignored them
[20:51:24] <LawrenceG> one is stack pointer and one is program counter, so really 14 GP regs
[20:53:27] <LawrenceG> I havent messed with the 40bit dsp part of them... I hope the C libs use some of those features
[20:53:42] <SWPadnos> $$$
[20:53:55] <SWPadnos> gcc may not, but the "official development tools" likely do
[20:53:59] <SWPadnos> I don't know for sure though
[20:54:20] <SWPadnos> if gcc even supports the dspic
[20:54:44] <SWPadnos> ah - it does - helps to have only 2 "c"s in gcc :)
[20:55:49] <LawrenceG> barely.... microchip supply GPL sources... some of their libs are closed source... I have been running the student version under mplab on a windows box
[21:02:02] <SWPadnos> weird - the stack is a bottom-up affair
[21:02:24] <SWPadnos> the PC is separate, though the SP is W15 (so you get 15 registers to wrok with)
[21:03:47] <LawrenceG> nice simetrical auto increment and indexing instructions... not related to xx86 trash
[21:05:00] <LawrenceG> mov [w1++],[w2++]
[21:05:49] <LawrenceG> like the 68000 or old PDP11
[21:14:52] <SWPadnos> they don't seem to make it easy to find the instruction set
[21:15:33] <SWPadnos> I have the family overview document loaded, and although it has a section titles "Addressing Modes Overview", it only has fluff about how great the features are, not an actual list of addressing modes
[21:15:45] <SWPadnos> which are also missing from the instruction set section
[21:16:25] <LawrenceG> yea a lot of reading in a 400page datasheet... figuring out some of the config registers is a whole lot of fun
[21:16:31] <SWPadnos> heh
[21:16:59] <SWPadnos> that's often no picnic. for a really good time, try the Motorola DSP56F800E series
[21:17:24] <LawrenceG> I have a current project on the go using an 18f2550 usb chip and it seriously is breaking the linux usb subsystem!
[21:17:34] <SWPadnos> those have about 1k-2k of configuration registers, including such nuggets as the clock PLL
[21:17:59] <SWPadnos> the USB device system?
[21:19:05] <LawrenceG> yes... some part of the usb hotplug system goes away and the olny repair I have found is a powerdown of the linux box.... I tried restarting various subsystems, but no luck so far...
[21:19:20] <SWPadnos> ok - so the host USB stack ;)
[21:19:25] <SWPadnos> not the device
[21:19:41] <LawrenceG> I really hate USB... it has been around for 15 years and it still has issues...
[21:19:50] <SWPadnos> it was designed with issues
[21:20:47] <LawrenceG> an ethernet card is a much easier high speed device to write code for... the os support actually works
[21:21:42] <SWPadnos> um - it's possible that it's the device that's causing some trouble (much as I know you'd like to think that's impossible :) )
[21:22:28] <SWPadnos> though the host drivers should be robust enough to allow for whatever convoluted mischief a device does without harm
[21:23:14] <LawrenceG> plugging in my homebrew usb midi device takes down the usb audio headset I have plugged in but leaves the usb mouse running.... strange
[21:24:03] <SWPadnos> different hub/controllers?
[21:25:23] <LawrenceG> it could be a hub issue, but moving the devices to a new port or controller doesnt fix the problem.... something in the hotplug system dies with no kernel messages
[21:27:49] <SWPadnos> I was wondering if all devices on a particular hub get disconnected when the device gets plugged in
[21:29:26] <LawrenceG> could be... the lsusb command hangs forever once the problem occurs, so it is something that command uses
[21:31:49] <LawrenceG> there are lost of web hits for "lsusb freezes" but no solutions I have found
[21:38:03] <SWPadnos> well, I guess I should figure out why my big computer just decided to stop booting. sigh
[21:38:55] <LawrenceG> I just noticed a couple of days ago that this motherboard has the dreaded bursting capacitor problem
[21:39:29] <LawrenceG> new parts from ebay on order, but chances of trashing MB are rather high