Back
[00:38:40] <cradek> hi all
[00:39:29] <jmkasunich> hi
[00:40:30] <cradek> thanks for answering the hard questions about tp for me
[00:41:34] <jmkasunich> ?
[00:41:51] <jmkasunich> the one about g1 and g2 and short segments?
[00:41:52] <cradek> talking about the guy with the short segments
[00:41:54] <cradek> yeah
[00:42:07] <jmkasunich> the last answer (just a few mins ago) was very easy ;-)
[00:42:13] <cradek> heh yep
[00:42:28] <cradek> we eventually need something more complex.
[00:42:31] <jmkasunich> yes
[00:42:43] <cradek> I'm sad to say what we have kind of sucks for contouring.
[00:42:58] <jmkasunich> when I get done with these silly parts I'd like to sit down with you and come up to speed on how the TP works
[00:43:42] <cradek> I think you pretty much know, judging from your answers
[00:43:55] <jmkasunich> dunno whether I can make any usefull contributions or not, bit I certainly can't without understanding the code
[00:43:56] <jmkasunich> nope
[00:44:06] <jmkasunich> for instance, what's a tc?
[00:44:19] <cradek> a motion element that comes from one canon call
[00:44:27] <cradek> nfc what "tc" stands for
[00:44:32] <jmkasunich> aka one segment?
[00:44:35] <cradek> yeah
[00:44:43] <cradek> each one is either a line or arc
[00:45:26] <cradek> I kept the same filenames because of cvs...
[00:45:42] <jmkasunich> are you in the middle of anything right now? or can we do TP101?
[00:45:46] <jmkasunich> * jmkasunich opens an editor
[00:46:01] <cradek> I've got time, let me get to a real keyboard though, brb
[00:47:32] <jmkasunich> first I'd like to go thru the .h files
[00:47:40] <jmkasunich> what is TP_STRUCT, for instance...
[00:47:58] <jmkasunich> looks like there is one of those, it contains overall TP data, right?
[00:48:02] <cradek> yes
[00:48:14] <cradek> it maintains state that is added to incoming tcs
[00:48:24] <jmkasunich> wow, that .h flike is a lot shorter than I recall it being
[00:48:47] <cradek> there was a lot of unnecessary stuff
[00:49:55] <cradek> the interface between motion and tp is still kind of messy (all the tpXxxx() calls)
[00:50:04] <cradek> but I left it alone for compatibility when the new tp was a branch
[00:50:09] <jmkasunich> I assume create is called at startup only
[00:50:13] <cradek> it could be probably cleaned up somewhat now.
[00:50:25] <jmkasunich> clear clears queues and resets state info
[00:50:51] <jmkasunich> whats the diff between init and clear?
[00:51:17] <cradek> one calls the other
[00:51:26] <cradek> this is what I mean about this interface being sloppy still
[00:54:19] <cradek> and everything returns ints, but the only thing they ever return is zero - why?? nfc
[00:54:39] <jmkasunich> non-zero for error
[00:54:41] <jmkasunich> ?
[00:54:49] <jmkasunich> but I bet few callers check for it
[00:55:03] <cradek> doesn't matter, because the functions all end with "return 0"
[00:55:14] <cradek> I mean very few of them have any handled error condition
[00:56:31] <cradek> I'm wrong, many of them can return -1, forget it
[00:56:42] <jmkasunich> it would be nice to add anywhere from a sentence to a paragraph for each function in tp.h
[00:56:59] <jmkasunich> that basically defines the interface for a TP, even if the implementation is totally different
[00:57:14] <cradek> many of them are documented at the function
[00:57:28] <jmkasunich> the implementation?
[00:57:35] <cradek> yes
[00:57:41] <jmkasunich> ok,
[00:57:55] <cradek> the ones I touched anyway, not all
[00:57:56] <jmkasunich> I may take the liberty of copying those descriptions into the .h
[00:58:05] <cradek> // feed override, 1.0 = 100%
[00:58:08] <cradek> int tpSetVscale(TP_STRUCT * tp, double scale)
[00:58:11] <cradek> e.g.
[00:58:14] <jmkasunich> yeah
[00:58:35] <cradek> don't copy the comments - move them if you must, but don't make two that will end up out of sync.
[00:58:50] <jmkasunich> I was gonna say move ;-)
[00:59:30] <jmkasunich> how do you feel about that in general? I like to comment "what" a function does in the .h, (especially if there might be two or more implementations later) and documents "how" in the inplementation
[00:59:45] <cradek> if you want to document the motion->tp interface, I think it would be better to clean it up first
[01:00:09] <jmkasunich> I find writing the docs an excellent way to see what needs cleaned up ;-)
[01:00:19] <cradek> ok, no argument there
[01:00:41] <cradek> the whole tp is in its "get the thing to work right" stage - it could certainly use a second pass for cleanup.
[01:01:08] <jmkasunich> I'll probably do at least a little of that as soon as I can, it will help bring me up to speed
[01:01:11] <cradek> not just the API - also the code
[01:01:27] <jmkasunich> ok, back to tp.h
[01:01:32] <jmkasunich> theres a load of Set functs
[01:01:52] <jmkasunich> everything prior to SetId seems to set "global" stuff
[01:02:06] <jmkasunich> SedId sets the ID of an individual segment?
[01:02:20] <cradek> yes, comes from the program line number
[01:02:32] <cradek> that's what eventually ends up in the gui to tell it which line to display
[01:02:37] <jmkasunich> ok
[01:02:45] <jmkasunich> so that is called once per line
[01:02:58] <jmkasunich> cycle time is called only once at startup
[01:03:08] <cradek> yes I think so
[01:03:09] <jmkasunich> vmax and amax are called once with ini file values?
[01:03:20] <cradek> each tc can have its own cycle_time; I don't know why
[01:03:40] <cradek> vmax and amax are often called for every line
[01:04:01] <jmkasunich> I thought cycle time was the period of the thread?
[01:04:06] <cradek> it is
[01:04:31] <cradek> that could obviously be moved out of the tcs
[01:04:54] <jmkasunich> the original TP may have allowed a different cycle time for every tc as a theoritical thing, but barring major restructuring it is impossible now
[01:05:00] <cradek> hmm, nobody has tried using synced digital IO yet, it's not there
[01:05:19] <jmkasunich> I thought it worked?
[01:05:44] <cradek> maybe it did briefly, but it sure doesn't now
[01:05:48] <jmkasunich> ok
[01:06:46] <jmkasunich> seems kinda odd that scale (feed override) is applied to TCs
[01:06:55] <jmkasunich> I think of it as being immediate
[01:07:05] <cradek> it is
[01:07:17] <jmkasunich> tp.c line 191?
[01:07:29] <cradek> yes
[01:07:31] <jmkasunich> each tc has a feed_override field
[01:07:34] <jmkasunich> why?
[01:07:47] <cradek> legacy
[01:08:18] <cradek> since I was in a branch, I tried to not touch anything in these little API functions
[01:08:22] <cradek> needs cleanup
[01:08:53] <jmkasunich> I'm adding some notes about things like that
[01:09:00] <cradek> ok
[01:09:03] <jmkasunich> preceeding them with JMK so I can find them
[01:09:35] <jmkasunich> going back to Vmax vd Vlimit
[01:09:54] <jmkasunich> it actually has three fields, vMax, ini_maxvel, and vLimit
[01:10:08] <jmkasunich> that seems like a couple too many ;-/
[01:10:18] <cradek> nope, they all have different meanings
[01:10:24] <cradek> see explanation in tp.c
[01:10:31] <jmkasunich> looking at it
[01:11:08] <jmkasunich> the names suck ;-)
[01:11:14] <cradek> no kidding
[01:11:22] <jmkasunich> vMax is actually vDesired
[01:11:32] <cradek> all the function names and variables sucked
[01:11:38] <cradek> it was a major obstacle to understanding it
[01:11:45] <jmkasunich> and ini_maxvel is actualy vMax
[01:12:14] <jmkasunich> task does the nasty math associated with deriving ini_maxvel from the individual axis limits?
[01:12:19] <cradek> yes
[01:12:28] <jmkasunich> seems like it will be in deep trouble with non-trivial kins
[01:12:36] <cradek> that's why there's usually a new vel message with every segment
[01:12:53] <cradek> those should probably be squashed into one message
[01:13:07] <jmkasunich> which?
[01:13:18] <cradek> SET_VEL SET_ACCEL ADD_LINE
[01:13:22] <jmkasunich> oh
[01:13:24] <cradek> whatever they're called
[01:13:28] <cradek> they come in sets of three now
[01:13:45] <cradek> it was very busted before, vels and accels were often wrong
[01:14:00] <jmkasunich> the division of labor between user (task) and rt is "interesting"
[01:14:25] <cradek> well doing as much as possible outside kernelspace is good
[01:14:30] <jmkasunich> yeah
[01:14:44] <cradek> for one thing we can use a debugger
[01:15:15] <cradek> if blending/lookahead gets any more complex we should really figure out how to do it in userland
[01:15:15] <jmkasunich> ok, I think I grok vMax and ini_maxvel
[01:15:37] <cradek> hope so, I spent seconds and seconds writing that paragraph
[01:15:42] <jmkasunich> vLimit seems redundant, the ini_maxvel should take into account the [TRAJ] section limits
[01:16:01] <cradek> I think I agree
[01:16:16] <cradek> but then let's go ahead and say the whole [TRAJ] limits are redundant.
[01:16:32] <jmkasunich> the API may have been written generic so as not to enforce any particular division of labor
[01:16:34] <cradek> and stupid, because different axes can be in different units.
[01:16:41] <jmkasunich> [traj] isn'
[01:16:51] <jmkasunich> isn't redundant in the general case
[01:17:23] <jmkasunich> [traj] limits are limits in cartesean space, three linear (in linear units) and three angular (angle units)
[01:17:23] <cradek> well I have a rotary table at 100deg/sec and a linear axis at .5in/sec
[01:17:37] <cradek> so I have to set [traj] to 100
[01:17:38] <jmkasunich> axis limits should properly be called joint limits
[01:17:48] <cradek> but my linears still work the same, so it seems redundant
[01:18:09] <jmkasunich> for non-linear kins, I could probalby argue that both have meaning
[01:18:18] <cradek> I could probably agree too :-)
[01:18:27] <jmkasunich> but there should be separate linear and angular traj limits
[01:18:38] <cradek> maybe we need a non-trivkins thing at fest
[01:18:52] <jmkasunich> yes
[01:19:03] <cradek> well without kins, angular units are big unknowns as far as tooltip speeds
[01:19:11] <cradek> so there's no "right" answer to that
[01:19:17] <jmkasunich> not true
[01:19:42] <cradek> sure it is - if my A axis is turning at 100deg/sec, how fast is the tooltip moving WRT the work?
[01:20:00] <cradek> you don't know, so how can you have a tooltip vel limit?
[01:20:26] <jmkasunich> the problem is the unholy marriage of axis and joint terminology
[01:20:43] <cradek> ok
[01:20:59] <jmkasunich> in theory, the A,B,C in the g-code define roll, pitch, and yaw of the tooltip
[01:21:21] <jmkasunich> and an angular only g-code block would not result in _any_ linear movement of the tooltip wrt the part
[01:21:47] <cradek> hmm ok
[01:21:57] <cradek> but no mill+rotary table is that way
[01:21:59] <jmkasunich> otoh, an A _joint_ will almost always result in linear motion when it turns (unless the tooltip is on the axis
[01:22:33] <cradek> ok I see
[01:22:51] <cradek> so mill + rotary table guys are used to programming in joint space
[01:23:27] <cradek> because if their tooltip followed the current spot on the work when they program g0a90, they'd wet themselves
[01:26:39] <jmkasunich> yeah
[01:26:55] <jmkasunich> but suppose you have a hexapod
[01:27:28] <jmkasunich> if you do g0a30, you want to tool to tilt by 30 degrees and nothing else
[01:27:50] <jmkasunich> again, we're straying into the mindfield of non-trivial kins
[01:28:19] <jmkasunich> in most circumstances I'd say "implement on a non-triv system, and treate trivial as a simpler subset"
[01:28:23] <cradek> minefield even
[01:28:31] <jmkasunich> that too ;-)
[01:28:35] <cradek> yeah both
[01:29:02] <cradek> I'm not ashamed to say my goal was to get trivkins working well (xyz orthogonal + abc as defined in the kramer doc)
[01:29:06] <jmkasunich> the problem here is that the user doesn't expect triv to be a simplification of non-triv, he already has a mental model of what it should do
[01:29:10] <cradek> lots of other things are certainly wrong
[01:29:13] <jmkasunich> nothing wrong with that
[01:29:37] <cradek> for example four linear axes like the foamcutters want
[01:29:52] <cradek> it all works great until you program g21 and 3/4 of your axes change scale
[01:30:31] <jmkasunich> yep
[01:30:36] <cradek> seems like we have real architectural problems, although it often works anyway
[01:30:53] <jmkasunich> the foamcutter problem can't be solved by kins either
[01:31:31] <cradek> well that particular problem is solved by honoring the axis type (linear) that's in the ini - I think it's mostly ignored now
[01:31:36] <jmkasunich> because kins still assumes a single tool, moving in cartesean space - they want two tools
[01:32:08] <cradek> ok I see what you mean
[01:32:42] <cradek> well they cut with a line - I don't know how you use kins to make that simpler than two endpoints in planes (what they already have)
[01:33:07] <cradek> parallel planes
[01:33:11] <jmkasunich> the fundamental problem is that we don't make the disinction between axes in g-code, axes in cartesean space, and joints
[01:33:49] <jmkasunich> they are describing tool (wire) position with 4 linear coords
[01:34:14] <jmkasunich> the TP assumes cartesean coords (3 linear, 3 angular, nothing else allowed)
[01:34:29] <jmkasunich> and then kins translates it to joint space, which could be anything in theory
[01:34:49] <jmkasunich> imagine two robots holding the two ends of the wire
[01:34:53] <jmkasunich> ;-)
[01:36:08] <jmkasunich> the only simple way to give them what they want is to eliminate the intermediate cartesean stage, and map g-code axes one-to-one to machine joints
[01:36:27] <jmkasunich> something similar happens if you have a quill and knee, both powered
[01:36:37] <jmkasunich> which one is Z?
[01:36:51] <cradek> the one that's moving :-/
[01:37:21] <jmkasunich> the convention is to forget about the possibility of kins, and map Z to one, and W to the other
[01:37:31] <jmkasunich> (I think W is the aux linear that is parallel to Z)
[02:28:41] <skunkworks> logger_devel: bookmark
[02:28:41] <skunkworks> See
http://solaris.cs.utt.ro/irc/irc.freenode.net:6667/emcdevel/2006-03-24#T02-28-41
[02:42:39] <SWPadnos> jmkasunich, I like your latest response to C Bellee ;)
[02:44:27] <skunkworks> is that the "Yes, it would be a complex work." responce?
[02:44:57] <skunkworks> (there is a delay of what I can see on sourseforge)
[02:45:02] <SWPadnos> yep
[02:46:53] <jmkasunich> it certainly would be nice to have multi-segment lookahead, but it isn't gonna happen just because he wants it
[02:47:09] <SWPadnos> no. I agree that it would be a complex work
[02:47:46] <skunkworks> emc for only looking ahead one segment does quite well. (from what I have played with)
[02:48:20] <SWPadnos> exploring possible multi-segment lookahead options might be a good topic at Fest
[02:48:42] <jmkasunich> three topics so far I'd like to explore:
[02:48:45] <jmkasunich> 1) threading
[02:48:53] <jmkasunich> 2) better understanding of non-trivial kins
[02:49:01] <jmkasunich> 3) multi-segment lookahead
[02:49:13] <jmkasunich> what they all have in common is the TP
[02:49:19] <SWPadnos> yep
[02:49:31] <SWPadnos> then there's 4) "remote" operation
[02:49:42] <jmkasunich> remote GUIs you mean?
[02:49:43] <SWPadnos> halui, halvcp, pendants, etc.
[02:49:51] <jmkasunich> oh, that
[02:49:57] <jmkasunich> halui is started
[02:50:03] <SWPadnos> that would be the other end - the topside of NML
[02:50:07] <jmkasunich> halvcp is just a matter of time
[02:50:38] <SWPadnos> do you know if halui can run remotely?
[02:50:48] <SWPadnos> via NML, it should be possible
[02:50:52] <jmkasunich> I suspect it can, it uses NML just like any other GUI
[02:51:21] <SWPadnos> I was thinking that an interesting session could be "making a pendant"
[02:51:53] <skunkworks> one question - when you where discusing being able to string lines togather threading (g2 into a g1 then back into a g2) where you guy thinking of threading say the middle of a shaft (using arcs to lead in and out)
[02:51:57] <SWPadnos> of course there are about a billion possibilities for that
[02:52:19] <SWPadnos> I think cradek added that already, skunkworks
[02:52:35] <SWPadnos> multiple chained spindle-synchronized segments
[02:53:24] <skunkworks> that is very neat. going to have to get a laith cnc'ed.
[02:53:51] <skunkworks> one of those projects that has been on the back burner
[02:54:58] <SWPadnos> all I have is back burners, it seems
[02:56:29] <cradek> skunkworks: I haven't tried arcs yet, but the test program threading.ngc shows how to chain synchronized moves together
[02:57:14] <SWPadnos> so is the G33 just a modifier for other movement modes now?
[02:57:26] <SWPadnos> (ie, G33 G2 ... would do an arc)
[02:57:37] <cradek> umm no
[02:57:42] <cradek> so forget what I said
[02:57:46] <SWPadnos> ok ;)
[02:57:47] <cradek> there is no synchronized arc
[02:57:55] <cradek> duh
[02:58:16] <SWPadnos> jmk had suggested that it be a movement mode, and I may be starting to agree
[02:58:24] <cradek> I wanted to have a "start sync" and "end sync" gcode, and you can put anything between them
[02:58:30] <cradek> but I don't think that's typical
[02:58:42] <SWPadnos> I think the "standard" is that g33 affects only the block it's in
[02:58:57] <SWPadnos> but, there is a possibility that would work:
[02:59:29] <SWPadnos> G33 sets the movement mode to G1, unless another {G1, G2, G3} is on the same line
[02:59:49] <SWPadnos> in any case, spindle synch is turned on
[03:00:01] <SWPadnos> but only for that block
[03:00:09] <cradek> yes that's possible
[03:00:16] <jepler> would you ever want spindle sync plus arc movement?
[03:00:25] <SWPadnos> and the good news for you, is that it's all in the interp, so Alex gets to do it ;)
[03:00:34] <SWPadnos> jepler, apparently, yes
[03:00:42] <jepler> I should have read back
[03:00:45] <SWPadnos> it's used to exit from thread cuts
[03:01:11] <SWPadnos> well, it would be ... ;)
[03:01:23] <cradek> I don't see why it's better than a straight exit
[03:01:31] <SWPadnos> I don't know what the code looks like from a typical machine though
[03:01:32] <cradek> you just want to get out of the cut.
[03:01:44] <jmkasunich> a straight exit relies on blending to make the turn from parallel to angled
[03:01:45] <SWPadnos> yeah, it'll be an arc anyway, due to blending
[03:01:48] <jmkasunich> arc can be tangent
[03:02:12] <SWPadnos> right - if there's any tangential acceleration, then the end of the thread gets screwed up
[03:02:37] <cradek> I think you're missing something though
[03:02:49] <jepler> you want to keep moving the same way in X, but also move some in Z
[03:02:53] <jepler> isn't that another linear move?
[03:02:58] <jmkasunich> yes
[03:02:59] <cradek> yeah that
[03:03:04] <SWPadnos> only if you're careful with the feedrates
[03:03:15] <cradek> if you use an arc, you mess up the screw pitch
[03:03:21] <jmkasunich> not really
[03:03:23] <SWPadnos> otherwise the X changes speed
[03:03:32] <cradek> imagine you're cutting a thread a foot deep
[03:03:36] <jmkasunich> the pitch only changes after you begin to turn
[03:03:40] <jepler> you want to keep the same relationship between the distance moved in X and the spindle rate .. is that what the code would do? Or do you have to program a different value that depends on hypot(dx, dz)?
[03:03:51] <jepler> (the k-value?)
[03:03:52] <jmkasunich> and after you begin to turn, the nut isn't gonna fit anyway
[03:03:54] <cradek> you want to back out along an arc with radius 1
[03:04:18] <SWPadnos> jepler, I think you'd need the hypot(dx, dz) for k
[03:04:24] <cradek> jepler: see threading.ngc which is what I think is needed
[03:04:31] <jmkasunich> jepler: as written, the K param controlls the feed along the move, so if the angle changes, you need to set K = hypot
[03:04:41] <skunkworks> g33x0z.1k[sqrt[2]*.0625]
[03:04:41] <skunkworks> g33z.5k.0625
[03:04:41] <skunkworks> g33x.1z.6k[sqrt[2]*.0625]
[03:04:51] <cradek> but if it's an arc, you can't do that calculation since the projection of the motion onto the spindle axis gets shorter as you go along
[03:05:08] <jmkasunich> with an arc, you use the same K for all three moves
[03:05:21] <jmkasunich> and the portion of the move that is tangent to the straight move has the right picth
[03:05:23] <jmkasunich> pitch
[03:05:24] <jepler> cradek and jmkasunich are saying opposite things
[03:05:26] <jepler> it makes my head hurt
[03:05:32] <cradek> then one of us is wrong?
[03:05:49] <cradek> jmkasunich: unless your arc has a huge radius I think the thread will be wrong
[03:06:07] <cradek> jmkasunich: and if it has a huge radius, you'll take a long time to back out of the part
[03:06:10] <jepler> if k is in "projected distance" then maybe jmk is right
[03:06:14] <jmkasunich> cradek is saying that with a straight move you can set the feed so the feed parallel to the axis will be right all they way thru the outfeed move
[03:06:24] <cradek> right
[03:06:38] <jepler> but if it is, then how many turns should a pure "Z" move take?
[03:06:40] <cradek> jmkasunich: k can't be the projected distance, because the projection goes to zero
[03:06:42] <jepler> indeterminate?
[03:06:48] <cradek> err jepler:
[03:07:01] <jepler> cradek: that's exactly what I'm getting at
[03:07:07] <cradek> yes, I think we agree
[03:07:11] <jmkasunich> right, but as soon as you actually start to pull out its irrelevant because the diameter is changing, so a nut won't fit anyway
[03:07:20] <jepler> and in fact that condition exists at the end of the arc jmk is talking about
[03:07:49] <cradek> jmkasunich: I don't get why this is better than a (blended) line pullout. I think it's worse
[03:08:23] <jmkasunich> it isn't better, IF the blend maintains the proper feed
[03:08:48] <jmkasunich> but all I really know about the blending code is that the feed will be correct before and after the blend
[03:08:54] <jmkasunich> it might change speed during the blend
[03:09:12] <jmkasunich> all blend testing to date as examined path (as seen in axis) not speed
[03:09:22] <cradek> true
[03:10:10] <jmkasunich> by using an arc, you eliminate the blend (in theory, in practice I bet the blending code is still active, even if the joint between two segments is colinear and matched feedrate
[03:10:58] <cradek> that's actually a change I'd like to make to tp
[03:11:24] <skunkworks> That is the only reason I was thinking an arc would be nice. Like jmk said - the second you start pulling out the nut isn't going to work anyway.
[03:11:25] <jmkasunich> get busy! ;-)
[03:11:26] <cradek> if you can transition (not blend) from one segment to the next while respecting limits (and they match in velocity), just do it, don't blend
[03:12:13] <cradek> I think you can calculate that knowing vels (they match), maxaccel, and dot(end of first segment, beginning of next segment), cycle time
[03:12:30] <cradek> * cradek waves his hands
[03:12:49] <jmkasunich> maxaccel doesn't come into it directoy
[03:12:51] <cradek> colinear is the obvious example of when it works, but not-quite-colinear will work too, which might be important for contouring.
[03:12:52] <jmkasunich> directly
[03:13:08] <jmkasunich> oh, if "not quite collinear" then accel comes into it
[03:13:11] <cradek> right
[03:13:34] <cradek> for high accel/low speed, maybe you can do a lot of profiling without blending, I dunno without doing the math
[03:13:45] <cradek> err contouring, not profiling
[03:14:09] <jmkasunich> how do you define "not quite collinear"? maybe "delta V tangential and deltaV cross-path both less than accel * traj period"
[03:14:11] <cradek> also maybe the abomination known as arcs approximated with segments
[03:14:40] <cradek> jmkasunich: "not quite colinear" means I can go from one path to the next in one cycle
[03:14:54] <cradek> while respecting accel limits
[03:14:58] <jmkasunich> IOW, what I said ;-)
[03:15:08] <jmkasunich> deltaV < accel_limit * cycletime
[03:15:18] <cradek> yes
[03:15:49] <cradek> looks easy if your accels are all the same, but the calculation probably sucks otherwise.
[03:16:04] <jmkasunich> use the lowest and call it good enough
[03:16:11] <cradek> and if you throw in ABC as they currently work, it really sucks
[03:16:12] <skunkworks> would that help the guy with short line segments?
[03:16:25] <jmkasunich> ABC is a whole nother ball of wax
[03:16:30] <cradek> skunkworks: possibly, depends on a lot, and I haven't checked the numbers
[03:16:40] <cradek> ball of mud
[03:16:54] <jmkasunich> actually, is it?
[03:17:17] <jmkasunich> compare deltaVlinear to maxaccellinear * cycle time
[03:17:28] <jmkasunich> and deltaVangular to maxaccelangular * cycle time
[03:18:21] <jmkasunich> btw, if we don't have separate angular and linear maxvel and maxacc in the [TRAJ} section, we should
[03:18:33] <cradek> heh, we sure don't
[03:18:51] <jmkasunich> easier said that done, I know - it gets into the abomination of code that transfers stuff from ini to TP
[03:18:57] <jmkasunich> NML and all that rot
[03:19:04] <cradek> I'm still not convinced they're needed for trivkins + abc as defined in kramer
[03:19:07] <skunkworks> time for bed. have fun :)
[03:19:28] <cradek> goodnight skunkworks
[03:19:49] <jmkasunich> for trivkins, the entire TRAJ section is uneeded, cartesean coords map directly to AXIS sections, and the axis specs would be used
[03:20:52] <jmkasunich> gotta get back to lathing
[03:21:18] <cradek> ok
[03:30:22] <jmkasunich> waiting for the saw again ;-)
[03:30:51] <SWPadnos> that reminds me. any idea where to get replacement hydraulic cylinders for a horizontal bandsaw?
[03:31:04] <SWPadnos> (other than Dake, who want $1k for it)
[03:31:13] <jmkasunich> you mean with the needle valve and everything?
[03:31:27] <SWPadnos> I think so
[03:31:32] <SWPadnos> it won't stay up at all
[03:31:58] <jmkasunich> can the cylinder be disassembled? might be as simple as needing a new o-ring or something
[03:32:19] <SWPadnos> I replaced the O-rings already, and it seemed like it was working
[03:32:30] <jmkasunich> my only experience is with the old kalamazoo bandsaw at work
[03:32:37] <SWPadnos> I may have reassembled the valve incorrectly though
[03:32:50] <jmkasunich> cylinder, some piping, a one way valve and a needle valve
[03:32:53] <SWPadnos> well, this is an old Johnson, so probably similar
[03:33:21] <SWPadnos> yep, this one has a fluid cup on top, and a no-pressure return hose
[03:33:25] <jmkasunich> does it go down easy and up hard?
[03:33:54] <SWPadnos> well, it goes up hard because the ram weighs ~250 pounds, maybe more ;)
[03:34:05] <jmkasunich> then not the same as the kalamazoo
[03:34:13] <jmkasunich> that one you lift the arm manually with one hand
[03:34:13] <SWPadnos> but it isn't restricted by the cylinder, as far as I can tell
[03:34:26] <jmkasunich> is the arm manual lift?
[03:34:45] <SWPadnos> yes, you lift it manually. it's got a counterbalance spring, and the cylinder (plus the motor helps)
[03:35:08] <jmkasunich> if the valve was reassembled backwards that would do it
[03:35:19] <SWPadnos> true
[03:35:22] <jmkasunich> its a restriction one way (to adjust feed) and a bypass the other way
[03:35:59] <jmkasunich> the "ram" is the main part of the saw (motor, wheels, blade, etc)?
[03:36:06] <SWPadnos> hmmm - is that needle valve the moving piece inside the cylinder, or in the adjustment down below?
[03:36:07] <jmkasunich> does it tilt or rise vertically?
[03:36:12] <SWPadnos> tilt
[03:36:15] <jmkasunich> the adjustment
[03:36:28] <SWPadnos> http://cgi.ebay.com/Johnson-8-x14-Horizontal-Band-Saw-Excellent-Clean_W0QQitemZ7603413618QQcategoryZ12586QQssPageNameZWDVWQQrdZ1QQcmdZViewItem
[03:36:35] <jmkasunich> I would expect the only moving piece in the cylinder is the piston
[03:36:37] <SWPadnos> damn, I hate those long URLs
[03:37:17] <jmkasunich> no good shot of the cylinder
[03:37:21] <SWPadnos> wow - that one look like it's in great shape
[03:37:47] <jmkasunich> the needle valve is the feedrate control, probably on the lower cylinder port
[03:37:54] <SWPadnos> 2 and 6 show it, but they're not great shots
[03:38:04] <SWPadnos> ok, I'm pretty sure I didn't disassemble that
[03:38:18] <SWPadnos> can't remember - it's been 6 months or more
[03:38:19] <jmkasunich> you said there was moving pars inside the cylinder?
[03:38:39] <jmkasunich> parts
[03:38:53] <jmkasunich> it could be the bypass valve is integrated with the piston
[03:38:58] <SWPadnos> there's a "leather cup" and the piston, not much else
[03:39:00] <jmkasunich> think bicycle pump
[03:39:12] <jmkasunich> ok, thats exactly like a bicycle pymp
[03:39:14] <jmkasunich> pump
[03:39:17] <SWPadnos> I wasn't sure if the needle valve could have been in the assembly with the cup though
[03:39:19] <SWPadnos> yep
[03:39:40] <jmkasunich> when you lift up, the pressure drops, the cup collapses, and the oil flows past the cup from top of cylinder to bottom
[03:39:54] <jmkasunich> when you release, pressure expands the cup and it seals against the cylinder wall
[03:40:13] <jmkasunich> and the only path for the oil is out the lower port, thru the needle valve up the pipe and into the upper port
[03:40:32] <SWPadnos> yep, so a little bit of gunk inside the cylinder could do it
[03:40:41] <SWPadnos> or if the cup is worn out
[03:40:53] <jmkasunich> two possibilities - oil leaking past the cup, or oil leaking thru the needle valve
[03:41:01] <SWPadnos> yep
[03:41:19] <SWPadnos> I know the system is still sealed (still full of fluid), so that's a good thing
[03:41:23] <jmkasunich> if you can remove the needle valve and plug that port temporarily you can figure out which
[03:42:01] <SWPadnos> true. I'll have to look at the fittings and get a plug. (and clean it so I can save the fluid)
[03:42:27] <jmkasunich> is it your saw? (or a work saw)
[03:42:52] <SWPadnos> yes to both
[03:42:56] <jmkasunich> heh
[03:43:04] <jmkasunich> nice saw for a home shop
[03:43:08] <SWPadnos> yeah
[03:43:10] <jmkasunich> I have one of the harbor fright ones
[03:43:19] <SWPadnos> got a good deal on eBay - $350
[03:43:26] <jmkasunich> no cylinder at all, just an allegedly adjustable spring
[03:43:40] <SWPadnos> I thought it was the model K, which is closer to the HF size - about 300 pounds total
[03:43:50] <SWPadnos> then the guy told me it's a model J, which is 800 pounds
[03:43:55] <jmkasunich> HF size is about 100 lbs
[03:44:17] <jmkasunich> heavy is good (except when you are moving it)
[03:44:23] <SWPadnos> right. the next size up is in the 300 ballpark. you have the 4 1/2 or 4 1/4 size?
[03:44:32] <jmkasunich> 4x6
[03:44:52] <jmkasunich> dunno whether that is 4, 4-1/4, or 4-1/2
[03:44:55] <SWPadnos> ok. I think there's a slightly larger one, maybe 7x10 or so
[03:45:20] <jmkasunich> it has cast, not stamped, blade guides, so that makes it the better of the two cheap chinese models
[03:45:28] <jmkasunich> I think it was $139+tax
[03:45:30] <SWPadnos> ah
[03:45:46] <jmkasunich> the stand is crap
[03:45:54] <SWPadnos> yep.
[03:46:13] <SWPadnos> this is basically what you have:
[03:46:21] <SWPadnos> http://www.grizzly.com/products/G1010
[03:46:29] <SWPadnos> this is the one I was looking at
[03:46:34] <SWPadnos> http://www.grizzly.com/products/G4030
[03:46:37] <jmkasunich> duh
[03:46:54] <jmkasunich> * jmkasunich looks at label on saw, which says (in big letters) 4-1/2"
[03:46:59] <SWPadnos> heh
[03:47:11] <jmkasunich> yep, thats looks like the one
[03:47:37] <jmkasunich> nope, not quite
[03:47:46] <jmkasunich> those blade guides slide inside the main casting
[03:47:51] <jmkasunich> these slide outside
[03:48:04] <SWPadnos> it's a good deal, even after replacing the motor with a nice washdown duty Baldor, replacing the controls with a safety start/stop etc. ;)
[03:48:09] <SWPadnos> ah, ok
[03:48:18] <jmkasunich> and the vertical mode table doesn't have the miter guage slot
[03:48:22] <jmkasunich> (smaller too)
[03:48:57] <jmkasunich> I haven't done much at all with mine (except buying a good blade)
[03:49:08] <jmkasunich> motor starts smelling hot if you run it too long
[03:49:14] <SWPadnos> I have a friend with 2 BPs (one CNC now), plus a couple of lathes and other stuff, and he has the little Grizzly bandsaw
[03:49:32] <SWPadnos> it's good, because when he wants to cut hard or big things, I earn CNC time ;)
[03:49:35] <jmkasunich> yeah, they're handy as heck, and don't take up much space
[03:50:08] <SWPadnos> so one day, I may finish the designs for the motor mounts for my BP, and finally make it into a CNC
[03:50:13] <SWPadnos> (on his CNC)
[03:50:34] <jmkasunich> need a CNC to make a CNC ;-)
[03:50:41] <SWPadnos> it helps, for sure :)
[03:51:33] <jmkasunich> well, saw's done (been done for a while) back to lathe
[03:51:34] <SWPadnos> hmmm - maybe the cylinder was only $600, and it was the worm gear that was $1000
[03:51:38] <SWPadnos> have fun - thanks
[03:51:44] <jmkasunich> either way, its a ripoff
[03:51:49] <SWPadnos> I agree
[03:52:30] <jmkasunich> you could make a new cylinder out of a bicycle pump and a needle valve, probably less than $100 if you bought everything new
[03:52:43] <jmkasunich> salvage the needle valve and its under $20
[03:53:06] <jmkasunich> * jmkasunich is a CFE
[03:53:07] <SWPadnos> well, it's pretty likely that either the cylinder or the needle valve is OK
[03:53:14] <jmkasunich> right
[03:53:17] <SWPadnos> CFE?
[03:53:26] <jmkasunich> cheap fuckin' engineer
[03:53:29] <SWPadnos> heh
[03:53:44] <SWPadnos> I was wondering how "scrounger" could fit in there ;)
[03:53:56] <SWPadnos> CSE "certified scrounging engineer"
[03:57:14] <jmkasunich> trashpicker even
[03:57:20] <SWPadnos> heh
[04:16:13] <jmkasunich> the jigs are done! yay!
[04:16:21] <SWPadnos> now you can dance a jig
[04:16:35] <jmkasunich> (still have to dig up a box and some packing material and print and invoice and all that rot)
[04:16:36] <cradek> yay!
[04:21:37] <SWPadnos> I'm filling in stuff I plan to bring to Fest - any suggestions?
[04:21:42] <SWPadnos> (on the wiki)
[04:21:50] <jmkasunich> url?
[04:22:12] <SWPadnos> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?id=EMC_Fest_2006
[04:22:23] <SWPadnos> I'm editing now, so none of it is showing
[04:22:28] <jmkasunich> oh
[04:22:41] <SWPadnos> I can save it if you want to see what I've listed so far
[04:22:43] <jmkasunich> things to bring:
[04:22:48] <jmkasunich> computer(s) ;-)
[04:23:30] <jmkasunich> ethernet hubs/switches (shouldn't need many, I'll be bringing a 16 port but we might want more, not for ports but to avoid cables everywhere)
[04:23:36] <jmkasunich> power strips
[04:23:39] <jmkasunich> hand tools
[04:23:57] <jmkasunich> meters, oscopes, other test instruments
[04:24:57] <SWPadnos> ok. adding. I'll save in a minute
[04:27:32] <SWPadnos> OK - reload if you like
[04:27:45] <SWPadnos> I'm also adding stuff to category 6
[04:28:10] <jmkasunich> I get "invalid URL"
[04:28:15] <SWPadnos> hmmm
[04:28:19] <SWPadnos> lemme take a look
[04:28:35] <SWPadnos> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?EMC_Fest_2006
[04:28:45] <SWPadnos> oops = had id= in there the first time
[04:28:50] <SWPadnos> (from the edit url)
[04:28:55] <jmkasunich> mo betta
[04:30:11] <jmkasunich> swp: I forgot all about the G-rex, I have on of those too
[04:30:13] <SWPadnos> should we need measuring equipment like micrometers, depth gauges, and calipers?
[04:30:33] <jmkasunich> I'm not sure what all we're going to be doing
[04:30:42] <jmkasunich> probably wouldn't hurt
[04:30:43] <cradek> when in doubt bring everything?
[04:30:53] <jmkasunich> SWP: are you driving?
[04:30:55] <SWPadnos> remember - my van is 10 years old ;)
[04:31:04] <SWPadnos> with all that stuff, absolutely
[04:31:09] <cradek> 10 years old is a young car
[04:31:16] <SWPadnos> not for an American car
[04:31:24] <cradek> tell my bronco
[04:31:26] <SWPadnos> heh
[04:31:27] <cradek> it's just getting warmed up
[04:31:44] <SWPadnos> this is a Plymouth though - it got depressed when the company was closed down
[04:32:13] <jmkasunich> my old S-10 was 13 years old when I got rid of it
[04:32:27] <jmkasunich> ran fine, but the rust moths had chewed it pretty bad
[04:32:35] <cradek> actually the bronco is getting old - 150k miles, but with only basic repairs it's still a good truck
[04:32:50] <cradek> yeah sadly it's starting to rust
[04:32:58] <SWPadnos> the load capacity is only 1100 pounds or thereabouts, so I may need to be careful on 1000-mile (each way) trips
[04:32:59] <cradek> it's such a good looking truck too
[04:37:32] <SWPadnos> hmmm - do wither of you know how to prevent the wiki from "link-ifying" names like DeskCNC ?
[04:37:46] <jmkasunich> no
[04:38:01] <SWPadnos> ok - I'm sure it's on the BasicSteps page
[04:38:02] <jmkasunich> there;s a link somehwere (main page maybe) to a page with info about editing
[04:39:37] <cradek> Suppress wiki formatting and linking through escaped WikiWiki text -- <nowiki>WikiWiki</nowiki>
[04:39:45] <cradek> ??
[04:39:54] <SWPadnos> hmmm
[04:40:52] <SWPadnos> yes, thank you
[04:44:47] <SWPadnos> ok, reload if you like
[04:45:19] <jmkasunich> looks good
[04:45:26] <jmkasunich> I'll add my stuff one of these days
[04:45:30] <SWPadnos> heh
[04:45:52] <SWPadnos> there's a "swap meet" part to the workshop, right?
[04:46:02] <SWPadnos> so I can get rid of some of those motors and stuff ;)
[04:46:33] <SWPadnos> oh yeah - I can bring a bucketload of DIN-rail stuff as well, if you think it may be needed for whatever retrofitting will be going on
[04:46:54] <jmkasunich> yes, theres a swap meet
[04:47:07] <SWPadnos> woohoo - maybe the wife will be happy for me to go then ;)
[04:47:09] <jmkasunich> last year I was very rushed getting ready, and didn't bring anything to swap
[04:47:18] <jmkasunich> gonna try to bring more this year
[04:47:45] <SWPadnos> let me know if there's anything you're looking for. If I have it, I'll bring it for you
[04:48:13] <jmkasunich> ditto
[04:48:37] <jmkasunich> you don't have a time machine do you? 26, 30, 32 hours in a day would be nice
[04:48:51] <SWPadnos> no, but I can adjust your watch for you ;)
[04:49:28] <SWPadnos> I guess I should fork over the cash so Roalnd will let me in
[04:49:33] <SWPadnos> Roalnd, also
[04:49:37] <SWPadnos> no, Roland
[04:49:42] <SWPadnos> yes, Roland
[04:50:43] <jmkasunich> me too
[04:50:47] <jmkasunich> I haven't registered
[04:50:49] <jmkasunich> yet
[04:50:50] <cradek> me too
[04:50:51] <SWPadnos> I suppose I should bring some of my little programmable I/O boards, in case we want to do anything with them
[04:51:01] <SWPadnos> heh - we should get a group discount
[04:51:02] <jmkasunich> programmable IO boards?
[04:51:31] <SWPadnos> microcontroller + a bunch of transistor outputs + some inputs
[04:51:49] <SWPadnos> I brought one last year - my version of an MPG ;)
[04:51:58] <SWPadnos> pseudo-manual, I guess
[04:52:14] <jmkasunich> I see
[04:52:46] <SWPadnos> I may have a small FPGA board by then as well, with a few I/Os
[04:52:50] <jmkasunich> does it have a serial port? or other connection that could talk to a PC?
[04:53:09] <SWPadnos> one of them does, the other would need to be parallel I/O only
[04:53:13] <SWPadnos> (more like a PLC)
[04:53:31] <SWPadnos> right now it's a 16-channel PWM light controller
[04:53:47] <jmkasunich> neat
[04:54:00] <jmkasunich> I want to build some small, easily portable, unconventional machine
[04:54:08] <jmkasunich> dunno what it would do, just has to be different
[04:54:12] <SWPadnos> heh
[04:54:33] <SWPadnos> how about a robot that runs around the workpiece with a chisel? ;)
[04:54:53] <SWPadnos> the Michelangelo of CNC
[04:55:04] <jmkasunich> too hard to build
[04:55:11] <SWPadnos> well, it would be different ;)
[04:55:15] <jmkasunich> its gotta use stuff I already have in my junkbox
[04:55:19] <SWPadnos> oh
[04:55:25] <SWPadnos> that narrows it down a little
[04:55:31] <jmkasunich> I tore apart that CD library thing yesterday
[04:55:35] <SWPadnos> (but only a little, from what I know of your junkbox)
[04:55:57] <jmkasunich> I was expecting servos because I didn't feel cogging - it actually has steppers with flywheels
[04:56:11] <SWPadnos> "tuned dampers"
[04:56:14] <jmkasunich> some neat mechanical parts tho
[04:56:34] <jmkasunich> I could probably build a very fast (but very light duty) 12"x12" XY motion
[04:56:52] <jmkasunich> low resolution, maybe 0.010 or so
[04:56:57] <jmkasunich> useless for machining
[04:57:12] <SWPadnos> with all those motors (CD-rom spindles), you could make a massively parallel pick-n-place or something
[04:57:29] <jmkasunich> I scrapped the actual cdrom drives
[04:57:32] <SWPadnos> oh
[04:57:37] <jmkasunich> those motors need special electronics
[04:57:40] <SWPadnos> SCSI 1x?
[04:57:49] <jmkasunich> the stuff I kept was the CD handling things
[04:57:57] <jmkasunich> SCSI, dunno the speed
[04:58:06] <jmkasunich> non-standard mechanically
[04:58:28] <jmkasunich> the library used a little carrier for each disk, there were 50 carriers in each of 3 magazines
[04:58:28] <SWPadnos> hmmm - did it use a gripper or a tray-type CD manipulator?
[04:58:48] <jmkasunich> the carrier and the disk both go into the drive, and the drive lowers the carrier/disk onto the spindle
[04:59:01] <jmkasunich> so no way to substitute another kind of drive
[04:59:03] <SWPadnos> ok, like the old optical RW drives
[04:59:47] <jmkasunich> anyway, this XY thing could be fast (like move across the workspace in a half second or so)
[04:59:57] <SWPadnos> measurement
[05:00:09] <jmkasunich> probing?
[05:00:14] <SWPadnos> yeah, that kind of thing
[05:00:17] <jmkasunich> only about 0.01" accuracy
[05:00:33] <SWPadnos> put a camera on it, and make high res composite images
[05:00:37] <jmkasunich> drive by toothbelts - pseudo rack-and-pinion
[05:00:39] <SWPadnos> measure from those
[05:01:30] <jmkasunich> automated "Go" playing machine ;-)
[05:01:35] <SWPadnos> sorry - got cameras on the brain ;)
[05:01:45] <SWPadnos> yeah, if you can make a Go algorithm ;)
[05:02:17] <jmkasunich> one idea that struck me was to make a flat board with a grid of drill dimples in it, maybe 20x20 or more
[05:02:37] <jmkasunich> get a few hundred 1/4" or so ball bearings (cheap), put a magnet on the XY
[05:02:46] <jmkasunich> and let it make patterns with balls
[05:02:50] <SWPadnos> heh
[05:03:02] <SWPadnos> how do you let go?
[05:03:08] <jmkasunich> electromagnet
[05:03:18] <SWPadnos> well, that would work ;)
[05:03:23] <cradek> you could use alex's 3-wire scheme for that
[05:03:40] <jmkasunich> I'd like to do a wire thing one of these days too
[05:03:53] <cradek> yeah, it sounds fun
[05:04:12] <jmkasunich> the thing about wire tho - it makes large workspace almost as cheap as small
[05:04:25] <cradek> yes
[05:04:27] <SWPadnos> as long as you don't need any downforce
[05:04:40] <jmkasunich> if I do wires, I want a workspace measured in tens of square/cubic feet
[05:05:15] <SWPadnos> the wholse garage
[05:05:17] <SWPadnos> whole
[05:05:38] <jmkasunich> yeah (or in my case, a 6 ft circle in the basement)
[05:05:43] <jmkasunich> too cold in the garage
[05:05:47] <SWPadnos> heh
[05:05:48] <cradek> I'd keep mine < 10 ft3 or so, so it can fit on a table
[05:06:10] <cradek> I think small because my house is already full
[05:06:18] <jmkasunich> I have the same problem
[05:06:59] <jmkasunich> which is why I haven't done anything serious with wires
[05:07:17] <jmkasunich> small wire hexapod isn't nearly as much fun as a big one
[05:07:55] <jmkasunich> unless _very_ well made, a hexapod isn't going to have very high accuracy, so as a mill its pretty limited
[05:08:20] <jmkasunich> (if I'm doing it on the cheap - I know its possible to build accurate ones)
[05:08:55] <jmkasunich> one advantage of hanging it from the ceiling is it down
[05:08:55] <jmkasunich> oops
[05:08:58] <jmkasunich> it doesn't need table space
[05:09:04] <jmkasunich> (which I don't have much of)
[05:09:05] <SWPadnos> we recently toured Houston space center, and they have a huge hexapod for "dynamic stress testing"
[05:09:27] <cradek> hmm, hanging from the ceiling - cool
[05:09:48] <SWPadnos> it's about 15-20 feet high, and the moving platform is around 6-8 feet on a side
[05:12:19] <jmkasunich> you see my table space problem:
http://home.att.net/~JMKasunich/Pics/bench2s.jpg
[05:12:43] <jmkasunich> http://home.att.net/~JMKasunich/Pics/bench.jpg
[05:12:44] <SWPadnos> tell the cat to go inside ;)
[05:13:24] <cradek> cats sure have a way of helping
[05:13:30] <jmkasunich> yeah
[05:13:35] <SWPadnos> yeah - he's keeping the stuff warm
[05:14:29] <jmkasunich> like the "pile 'o computers" in the second pic?
[05:14:37] <cradek> what's the thing on top?
[05:14:40] <jmkasunich> I dunno why I had the compile farm out
[05:14:42] <jmkasunich> the farm
[05:14:44] <SWPadnos> yeah, with the compile farm on top
[05:14:54] <jmkasunich> which reminds me, its not working
[05:14:54] <cradek> huh, it's tiny
[05:15:00] <jmkasunich> gotta check that
[05:15:20] <jmkasunich> you jest, right?
[05:15:38] <jmkasunich> fscking thing weighs about 75 lbs
[05:15:38] <cradek> no, it's hardly bigger than a desktop pc
[05:15:54] <cradek> I expected something more like a rack
[05:15:56] <jmkasunich> fits a 19" rack, about 24" deep
[05:16:04] <cradek> yeah, tiny
[05:16:30] <cradek> that reminds me - you said you want me to bring you some 2G scsi hard drives, right?
[05:16:33] <jmkasunich> its not clear there, but it hangs over the PCs under it by at least 6" in front, 3" in back and 3" on the sides
[05:16:37] <jmkasunich> no
[05:16:44] <jmkasunich> I have disks squirting out my ears
[05:16:47] <cradek> ok, how many do you need?
[05:17:14] <cradek> I doubt I can find more than 10-12
[05:17:36] <cradek> sorry, just being an idiot
[05:17:57] <jmkasunich> be carefull, I might bring you some stuff
[05:18:19] <cradek> I'd like some servos and encoders to play with
[05:20:25] <jmkasunich> big or little?
[05:20:43] <jmkasunich> I have something like 7-8 of the ones from the tape library
[05:20:49] <cradek> in between I guess
[05:20:59] <jmkasunich> about 1.4" dia, 64 count (16ppr) encoders
[05:21:07] <cradek> might be fun to use them for a wire tripod
[05:21:09] <jmkasunich> 12V, 1A or so max
[05:21:24] <jmkasunich> not very torquey, need speed reducers
[05:21:25] <cradek> maybe too small...
[05:21:33] <SWPadnos> I have an ametek from Surplus center, but without an encoder
[05:21:45] <cradek> http://surpluscenter.com/item.asp?UID=2006032323164253&item=10-1834&catname=
[05:21:57] <cradek> I think these are interesting, also cheap and local
[05:22:06] <jmkasunich> the same things we used for the e-week project - with a 45:1 worm reduction they moved a 12 lb bowling ball and about 10-12 lbs of vehicle around at 15 inches/sec
[05:22:17] <jmkasunich> but I don't have any more worm gears
[05:23:11] <jmkasunich> have you dones a cvs up lately?
[05:23:18] <jmkasunich> I'm getting no response
[05:23:44] <jmkasunich> I can ping the cvs server fine, but cvs up just sits there
[05:23:54] <SWPadnos> SF was flaky earlier, when I was trying to update the wiki page
[05:24:09] <jmkasunich> seems like SF is flakey a lot lately
[05:24:22] <cradek> $ telnet cvs.sf.net ssh
[05:24:22] <cradek> Trying 66.35.250.207...
[05:24:26] <SWPadnos> developer access is fubar'ed
[05:24:35] <SWPadnos> localhost:/Project/emc2# cvs update -dP
[05:24:36] <jmkasunich> well thats annoying
[05:24:37] <SWPadnos> ssh: connect to host cvs.sourceforge.net port 22: Connection refused
[05:24:38] <SWPadnos> cvs [update aborted]: end of file from server (consult above messages if any)
[05:25:08] <SWPadnos> I wish I could do anonymous access at Dreamhost
[05:25:14] <jmkasunich> according to the logs the farm hasn;t worked since 3/10
[05:25:36] <cradek> is that when anoncvs broke?
[05:25:42] <cradek> or does it use devel?
[05:25:45] <jmkasunich> dunno, the farm uses developer cvs
[05:25:49] <cradek> ok
[05:25:49] <jmkasunich> (to avoid the delay)
[05:26:10] <jmkasunich> developer cvs certainly hasn't been broken since 3/10
[05:26:18] <cradek> agreed
[05:26:25] <jmkasunich> unfortuntely I only keep the log from the most recent cvs failure
[05:28:14] <jmkasunich> something funky is going on
[05:28:37] <jmkasunich> according to my logs, except for about 24 hours on 3/5, and for the last few hours, the farm was working fine
[05:28:54] <jmkasunich> but the pages at linuxcnc.org show data from 3/10
[05:29:05] <jmkasunich> you guys didn't change the DNS yet did you?
[05:29:07] <SWPadnos> hmm - so it's not noticing the cvs commits?
[05:29:10] <SWPadnos> nope
[05:30:03] <jmkasunich> its noticing the commits, doing the build, and it thinks is ftping the results to linuxcnc.org
[05:30:15] <cradek> Server: Microsoft-IIS/4.0
[05:30:30] <cradek> it's certainly the right machine
[05:30:35] <SWPadnos> yep -Steve's running it on a WinBox
[05:31:11] <SWPadnos> is it sending to ftp://ftp.linuxcnc.org, or ftp://linuxcnc.org?
[05:31:13] <jmkasunich> hmm, I tried to manually ftp into the box and got "connection refused"
[05:31:38] <cradek> yep
[05:31:39] <jmkasunich> "$ ftp -p linuxcnc.org"
[05:33:04] <jmkasunich> wonder if steve changed permissions or something?
[05:33:27] <jmkasunich> connection refused is more than permissions tho, that means he closed the FTP port completely
[05:33:40] <jmkasunich> (I think?)
[05:33:59] <SWPadnos> we did some experimentation on 3/19, so I don't think that was the cause of the trouble
[05:34:08] <cradek> it can just mean nothing is listening
[05:34:13] <cradek> i.e. the ftpd died
[05:34:47] <SWPadnos> no, it's being refused, not timing out
[05:35:02] <jmkasunich> telnet is refused too
[05:35:19] <SWPadnos> do you have an account, or do you use anonymous ftp?
[05:35:29] <jmkasunich> he gave me an account
[05:35:44] <jmkasunich> dunno if the account supports anything other than ftp
[05:35:48] <SWPadnos> you've been trying with that?
[05:35:53] <SWPadnos> or anonymous
[05:35:58] <jmkasunich> I don't even get that far
[05:36:04] <SWPadnos> true
[05:36:14] <jmkasunich> usually I do "ftp -p linuxcnc.org" and it asks for username and pw
[05:39:08] <jmkasunich> well, I'll email steve and see what he says
[05:40:15] <SWPadnos> hopefully his mail server is still working ;)
[05:40:32] <jmkasunich> meanwhile, it looks like jepler's attempt to fix compiles on 2.xx gcc broke things
[05:41:08] <jmkasunich> on slot 5 (bdi-4.20, gcc 3.xx) it worked at 3/23 2:something UTC, and failed at 3/23 14:something UTC
[05:41:16] <jmkasunich> I think that was his commit
[05:41:22] <jmkasunich> checking the other slots now
[05:43:27] <SWPadnos> was that gcc 3.xx a typo (should have been 2.xx?)
[05:47:18] <jmkasunich> slots 4 and 5 were working up until 1400 UTC today
[05:47:44] <jmkasunich> I think they use gcc 2.95 for the actual RT compile, but gcc 3.xx exists and is being used for the depends stuff
[05:47:57] <SWPadnos> oh, that could be a problem
[05:48:09] <jmkasunich> slots 2 & 3 don't have 3.xx at all, and they've been failing since the new build system came out
[05:48:19] <SWPadnos> so it looks like cvs has been screwed since 1400 or so?
[05:48:26] <jmkasunich> no
[05:48:41] <jmkasunich> the CVS outage is only a few hours old
[05:49:16] <jmkasunich> at 1400 and again at 1600 and again at 1900 IIRC, it successfully did a cvs up, saw a change, and tried a build- the build failed
[05:49:20] <SWPadnos> ah - whoops. I looked at the clock and forgot it's tomorrow ;)
[05:49:45] <jmkasunich> yeah, its already 500 UTC or so
[05:49:50] <SWPadnos> 600
[05:50:36] <jmkasunich> the CVS outage started between 2:48 and 3:50 UTC
[05:50:54] <jmkasunich> so we have three issues
[05:51:16] <jmkasunich> 1) something a linuxcnc, that's prevented the farm from updating since 3/10 or so
[05:51:46] <jmkasunich> 2) changes to CVS HEAD around 1400UTC yesterday that made HEAD stop compiling on slots 4 and 5
[05:52:02] <jmkasunich> 3) a CVS outage around 300 UTC today
[05:52:26] <jmkasunich> 1) is my problem (and steve S's)
[05:52:33] <jmkasunich> 2) is jepler's problem I think
[05:52:38] <jmkasunich> 3) is SF's problem
[05:52:55] <SWPadnos> do you know why BDI 4.30 would work when 4.20 doesn't?
[05:53:03] <jmkasunich> no idea
[05:53:11] <SWPadnos> then again, I may not have compiled after jepler's latest changes
[05:53:17] <jmkasunich> I can look at the most recent 4.20 compile log
[05:53:24] <SWPadnos> (and now I can't, due to (3) )
[05:54:17] <jmkasunich> "running make"
[05:54:24] <SWPadnos> SF is doing maintenance
[05:54:32] <SWPadnos> ( 2006-03-23 10:28:40 - Project CVS Service ) 2006-03-23: Starting at 19:00 PST, CVS services will be unavailable for approximately 8 hours as part of routine maintenance. We apologise for the inconvenience.
[05:54:37] <jmkasunich> "depending rtai_ulapi.c"
[05:55:00] <jmkasunich> "rm: cannot remove ./tmp, is a directory"
[05:55:15] <jmkasunich> so the make is failing very early
[05:55:56] <SWPadnos> OK, isn't that the problem jepler was trying to fix?
[05:56:16] <jmkasunich> he was trying to make it work on other systems - it already worked on slots 4 and 5
[05:56:25] <jmkasunich> now it doesn't work on any of them
[05:56:35] <SWPadnos> hmmm
[05:56:44] <jmkasunich> I guess consistency is good ;-/
[05:56:48] <SWPadnos> I assume it works on ubuntu, since that's what he's using
[05:56:56] <jmkasunich> I assume
[05:56:59] <SWPadnos> yes "older compilers now work just as well as GCC 3.x"
[05:58:52] <jmkasunich> definitely jepler's commit that busted it, just checked the commit logs against the farm logs
[06:00:00] <jmkasunich> damn, I finished my parts well before midnight, now its 1am and they're still not packed or invoiced
[06:00:21] <jmkasunich> you guys are evil - evil I tell you!
[06:01:43] <SWPadnos> heh
[06:02:09] <SWPadnos> there's a discussion of this problem, or one like it, on 3/18 (on #emc)
[06:02:29] <jmkasunich> its been discussed a couple times
[06:02:55] <jmkasunich> the usual result was "it can probably be fixed, but its a pain, and we're not gonna sweat support for older systems"
[06:02:57] <SWPadnos> yep, on 3/7 as well, with cncuser
[06:03:05] <jmkasunich> but today jepler decided to do something about it
[06:03:21] <SWPadnos> no, in both cases I'm referring to, the user did manage to get a successful compile, AFAIR
[06:03:46] <jmkasunich> with BDI-TNG or older?
[06:03:54] <jmkasunich> or with BDI-4.something?
[06:03:58] <SWPadnos> one with puppy, the other I'm not sure
[06:04:09] <SWPadnos> it was etla having the problem on 3/18
[06:04:47] <SWPadnos> ok, the problem for cncuser was the date being in the future
[06:05:52] <jmkasunich> well, its late here, and I still gotta do a few things
[06:05:54] <jmkasunich> goodnight all
[06:06:00] <SWPadnos> yepper - night
[06:06:11] <SWPadnos> SWPadnos is now known as SWP_Away
[12:39:43] <jepler> so what did you guys do about the compile errors? I don't see any new commits, but the 4.20 slot succeeded and the Makefile.inc doesn't have the line I added to Makefile.inc.in.
[12:41:53] <jepler> er, hm .. I must be looking at the wrong farm output
[12:41:56] <jepler> it's dated 3/7
[12:42:04] <cradek> the farm isn't working
[12:42:18] <cradek> well actually it is, but the results aren't getting to linuxcnc.org because of some problem at linuxcnc.org
[12:42:34] <jepler> oh
[12:43:46] <jepler> I did spot a stupid typo in depend.sh.in that would probably have the effect of making the depend step fail on systems where the ".tmp" directory (old object directory?) exists.
[12:44:16] <jepler> if that message from last night wasn't cut&paste, but really read ".tmp"
[12:44:24] <jepler> $CC -M "$@" | sed "1s|^.*:|$LHS:|" > $DEST.tmp && mv $DEST.tmp $DEST
[12:44:25] <jepler> -rm -f $TEST.tmp
[12:44:25] <jepler> +rm -f $DEST.tmp
[12:46:22] <cradek> aha
[12:46:54] <cradek> bbl
[12:56:30] <jepler> curses sf cvs
[13:47:48] <alex_joni> hi guys
[13:56:01] <rayh> Hi Alex
[13:56:11] <rayh> Didn't see you.
[13:56:19] <alex_joni> * alex_joni is around since 8:20 am
[13:56:28] <rayh> Your time.
[13:56:45] <alex_joni> yeah
[13:57:21] <rayh> How do you feel about the timing of the release?
[13:57:39] <rayh> Are we getting closer?
[13:59:51] <jepler> ssh: connect to host cvs.sourceforge.net port 22: Connection refused
[13:59:53] <jepler> sigh
[14:01:35] <alex_joni> rayh: sure, but one thing worries me though
[14:01:40] <alex_joni> and that is too much progress :D
[14:01:52] <alex_joni> keeping this pace up, we'll never have a release
[14:02:54] <rayh> Yep.
[14:03:26] <rayh> IMO for releases, as we approach them, we need to appoint a release manager who is god.
[14:06:36] <alex_joni> * alex_joni looks at jepler
[14:06:55] <alex_joni> he releases AXIS all the time
[14:07:02] <alex_joni> and it seems to work out ok
[14:07:54] <rayh> Yes he does seem to have the focus to see the issues and sort them out.
[14:09:59] <alex_joni> lets have a motion about that :D
[14:10:17] <alex_joni> I think cradek will be in favour too
[14:14:22] <rayh> Do we want to set this up for the first release? If so we should get four of us on IRC and vote it. Then we should make a bylaw change that does this on any release we plan.
[14:14:43] <rayh> Perhaps we can get jmk on line with us tomorrow.
[14:15:06] <alex_joni> yeah, and joke aside, I would want jepler in here before that
[14:15:45] <alex_joni> it's a free software afterall ;)
[14:17:15] <rayh> Right.
[14:26:13] <jepler> alex_joni: Half the axis releases are botched
[14:26:19] <jepler> alex_joni: that's why there are so many x.y.z releases
[14:26:41] <jepler> I don't think I'm that good a release manager.
[14:26:58] <alex_joni> jepler: better than the rest (which aren't at all)
[14:27:11] <alex_joni> jepler: and they are botched only because emc2 moves so fast
[14:27:53] <rayh> We were thinking of somebody to mannage this circus for short periods of time.
[14:29:54] <alex_joni> jepler: try to keep the messages to emc-commit to a small number, or better yet none at all ;)
[14:34:10] <jepler> alex_joni: oops, you mean I sent something there besides a commit?
[14:34:16] <jepler> I saw the "message held" message earlier
[14:34:56] <alex_joni> yup, I think you sent to both lists
[14:35:00] <alex_joni> but it's not a biggie
[14:35:06] <alex_joni> I let it through
[14:37:42] <alex_joni> rayh:
http://www.cncgear.com/joomla/index.php?option=com_weblinks&catid=14&Itemid=7
[14:38:01] <alex_joni> if you can find the time to look over linuxcnc.org and point me to what hasn't been moved yet
[14:38:58] <rayh> I'll look this weekend. Gotta make a run to town this morning.
[14:39:30] <alex_joni> ok, I'll make a run home
[14:39:32] <alex_joni> later guys
[14:39:54] <rayh> see you
[15:16:37] <SWP_Away> SWP_Away is now known as SWPadnos
[17:10:55] <alex_joni> * alex_joni is back
[17:11:07] <alex_joni> SWPadnos: you watching in here too?
[17:11:16] <SWPadnos> yep
[17:11:35] <alex_joni> ok ;)
[17:11:49] <alex_joni> * alex_joni thinks about anouncing cncgear.com/joomla/ on the lists
[17:12:06] <alex_joni> for people to look at and see if anything is still missing from the current linuxcnc.org
[17:12:11] <SWPadnos> hmmm
[17:12:37] <alex_joni> SWPadnos: hmmm?
[17:12:38] <SWPadnos> I expect to remove that mapping, if lkinuxcnc.org gets pointed there
[17:12:49] <alex_joni> yeah sure, but before the move
[17:13:03] <SWPadnos> yeah. maybe the devel list only at first
[17:13:03] <alex_joni> as long as people still can compare both sites
[17:13:07] <alex_joni> right
[17:13:11] <SWPadnos> true
[17:13:25] <SWPadnos> people on the devel list should be able to update their bookmarks ;)
[17:13:27] <alex_joni> you concearned that cncgear.com is in that addy?
[17:13:44] <SWPadnos> partly, because the site is otherwise embarrassing :)
[17:13:52] <alex_joni> need help on that? :D
[17:13:54] <SWPadnos> heh
[17:14:01] <alex_joni> * alex_joni could help there..
[17:14:05] <SWPadnos> I need to finish up some products for that
[17:30:56] <alex_joni> cradek: around?
[17:31:07] <cradek> yes
[17:31:46] <alex_joni> what are we gonna do about the release?
[17:32:07] <cradek> I don't know
[17:33:12] <alex_joni> the problem is that we all want to improve things
[17:34:07] <cradek> we need a feature freeze, a new testing release, then a release
[17:34:20] <jepler> In AXIS I create a 'maint' tag when I decide that it's time to stop adding features
[17:34:34] <jepler> er, 'maint' branch
[17:34:35] <cradek> yeah the feature freeze doesn't have to be on head
[17:34:35] <alex_joni> maybe even a feature revert.. even if I don't like that
[17:34:40] <jepler> then I am very strict about not adding features to the branch
[17:34:55] <jepler> but I can continue adding features on the HEAD when the urge strikes
[17:36:24] <jepler> the branch becomes
[17:36:33] <jepler> a "TESTING" that can be updated at any time with bugfixes
[19:50:20] <SWPadnos> hi Ray
[19:50:43] <rayh> Hi Steven
[19:50:54] <rayh> Making progress today?
[19:51:00] <SWPadnos> yes
[19:51:13] <SWPadnos> on what, I'm not sure though
[19:51:32] <rayh> The guy who wants the encoder to analog board wanted to know when It might be ready.
[19:51:38] <SWPadnos> heh
[19:51:47] <rayh> I said it would be a while yet.
[19:51:57] <SWPadnos> I won't be able to finish before mid-end April
[19:52:01] <SWPadnos> that's a good answer
[19:53:02] <SWPadnos> he can just use smoe specific encoder resolution, right?
[19:53:03] <SWPadnos> some
[19:55:46] <rayh> Yes I believe the encoder is built into the spindle motor on the one he was wanting to convert.
[19:56:20] <rayh> But I don't remember right off what count it was.
[19:57:39] <rayh> It was a 6k rpm motor.
[19:57:46] <rayh> or spindle
[19:59:21] <rayh> Seems like 360 came to mind but I'll have to ask next time he calls.
[20:00:02] <SWPadnos> I think you said 360 before
[20:00:53] <SWPadnos> and that would be cycles, right (rather than "quadrature counts", which would be 1440)
[20:04:43] <rayh> Yes.
[20:11:29] <SWPadnos> ok. I think if we get rid of the quadrature count multiplying thing, then a cheap microcontroller can do it, instead of the FPGA
[20:18:02] <rayh> As long as you have enough pins out to make the analog signal.
[20:18:44] <SWPadnos> 8 or 16 are easy
[20:19:25] <jepler> is the idea to turn encoder frequency into an analog voltage?
[20:19:58] <rayh> exactly
[20:20:21] <SWPadnos> I suspect there's a chip that does that, come to think of it
[20:20:28] <rayh> you were thinking of a current multiplier.
[20:20:46] <rayh> resistor network.
[20:20:54] <SWPadnos> R-2R ladder
[20:21:35] <rayh> With a 200 or more volt transistor on the output so that folk could put whatever dc voltage they needed
[20:21:52] <SWPadnos> err - I don't think I said that ;)
[20:22:02] <rayh> and an adjustable pot for tuning to volts per 1000 rpm.
[20:22:12] <rayh> Oh was that my part of this project?
[20:22:20] <SWPadnos> hmm - YES! :)
[20:22:33] <rayh> Darn. Thought I might slip it past you.
[20:23:51] <SWPadnos> http://www.usdigital.com/products/edac2/
[20:25:17] <SWPadnos> though I don't see how to tell it what resolution the encoder is
[20:25:51] <SWPadnos> ah - oops. that's a position -> analog converter, not rate -> analog
[20:26:19] <rayh> oh right I glanced at that a while back.
[20:27:23] <SWPadnos> http://www.usdigital.com/products/etach2/index.shtml
[20:27:28] <SWPadnos> kinda expensive though
[20:28:03] <rayh> Tell me. The three axis encoder reader board is 1.2 times the cost of a m5i20
[20:28:16] <rayh> and there you get the dacs, and 48 io
[20:28:34] <SWPadnos> well, it does havea box and everything ;)
[20:28:43] <rayh> I did just order their large hollow shaft encoder for my sherline mill.
[20:28:43] <SWPadnos> and you don't need to put it into a computer
[20:29:32] <SWPadnos> it's amazing. $12000 for a PCB/FPGA development kit, and the libraries don't even have an up/down counter
[20:29:45] <rayh> $240. Almost as much as the, not mill, lathe.
[20:30:00] <rayh> But the head could be used for either.
[20:32:08] <rayh> I've got a another question.
[20:32:22] <SWPadnos> yah
[20:33:10] <rayh> It's a serial link between HAL and an external pic or whatever.
[20:33:16] <cradek> rayh: I think somewhere on the sherline site I saw instructions for retrofitting their motor driver with a reversing switch - if we had that controlled by emc, we could do rigid tapping
[20:33:21] <jepler> seems like a microcontroller like avr could get you to the 1-2MHz quadrature state range, but not up to 10MHz..
[20:33:40] <SWPadnos> jepler, yep, I was jus tlooking at that
[20:33:48] <rayh> Right. I saw that someplace.
[20:34:01] <jepler> and an external DAC could easily provide a 12-bit (0-4.095v) output
[20:34:15] <rayh> I was thinking about fitting a stepper to the speed pot...
[20:34:17] <jepler> at 10kHz update rate, you can even use a serial interface DAC
[20:34:34] <cradek> rayh: I don't know how useful it would be, but it would be a pretty clever hack
[20:34:57] <jepler> rayh: I saw somewhere on the rtai lists that there's a real-time 16550 serial driver
[20:35:07] <jepler> rayh: are you talking about rs232 serial?
[20:35:33] <rayh> Yes rs232 to start.
[20:36:21] <rayh> I'd think that the guts of it could be generalized for any serial, 232, 48x, usb, sata?
[20:36:26] <rayh> but what do I know.
[20:36:52] <jepler> bit-banged i2c on the parallel port?
[20:36:59] <SWPadnos> that's true for any point-to=point serial bus
[20:37:27] <SWPadnos> but RS-485 can be multi-drop, so it can need some protocol manager
[20:37:35] <rayh> The first app I'd like to set up with it is the hardware buttons I described on the halui wiki page.
[20:37:36] <SWPadnos> depending on what's on the bus
[20:37:45] <jepler> but HAL doesn't seem to have any "serial-like" components, which allow you to shove in or pull out varying amounts of data
[20:37:56] <rayh> If you had connected the multidrop.
[20:38:06] <SWPadnos> that's something I can probably do with the AVR board I have, though the I/O is set up for pulse rate generation
[20:39:27] <SWPadnos> it's got 8 inputs (16 with a daughtercard), 4 outputs, and 2 digit LED display (expandable via daughtercard), plus a serial port.
[20:39:30] <rayh> This hardware panel has 40 indicator lamps, 40 momentary switches, an aux estop, and two rotary encoders, actually rotary switches.
[20:39:59] <SWPadnos> that's more than 8 or 16 inputs ;)
[20:40:34] <SWPadnos> how many poles on the rotary switches?
[20:41:12] <rayh> 15 on 1 and 12 on the other.
[20:41:31] <rayh> The actual number is less important than the concept of creating unique hal pins from a serial signal.
[20:43:23] <SWPadnos> that panel might be a bit big for the proof of concept ;)
[20:43:45] <rayh> a little jog pendant would be better, eh?
[20:43:56] <SWPadnos> possibly ;)
[20:44:23] <jepler> seems like you have to fix the details of the serial protocol, then writing the HAL component should be straightforward
[20:44:41] <rayh> You beat me to the protocol issue.
[20:45:05] <jepler> does this have to be a realtime component?
[20:45:14] <rayh> Don't most of the protocols have frontmatter, data, endmatter.
[20:45:33] <SWPadnos> jepler, if it's meant to be UI only, then probably not
[20:45:34] <rayh> No not really. It is an operator panel.
[20:45:46] <SWPadnos> but if it's intended for sensord / modbus, then yes
[20:45:50] <SWPadnos> sensors
[20:45:58] <jepler> "modbus"?
[20:46:08] <SWPadnos> isn't that one of the serial standards?
[20:46:24] <rayh> No. Only operator stuff for now.
[20:46:45] <rayh> devicenet, ...
[20:47:15] <SWPadnos> right - I think there are several
[20:47:44] <rayh> Some are proprietary and I think that applies to both ends.
[20:47:45] <SWPadnos> an RT component shouldn't be too hard, since the UARTs are pretty easy to deal with
[20:47:53] <SWPadnos> the problem is error handling
[20:47:55] <jepler> do these things tend to translate the entire state each time, or transmit when something changes state?
[20:48:15] <SWPadnos> some of them only tell you the state when you ask for it
[20:48:25] <jepler> ugh. and god said, let there be latency
[20:48:29] <SWPadnos> yep
[20:48:35] <rayh> Could be either. Full state might require less outboard but then the smallest pick could handle state for it's pins.
[20:48:47] <SWPadnos> serial always has latency, on the CPU timescale
[20:49:10] <SWPadnos> (ie, one byte takes an eternity to the PC CPU)
[20:49:58] <rayh> My working definition of latency for this system is when the operator releases the jog button, how long does it take to show up in axis stop.
[20:50:07] <jepler> shouldn't be too bad. If you're sending 40 switch states plus 2 8-bit encoder counts, that's less than 8 bytes, or less than 1ms.
[20:50:17] <jepler> over a 115200 serial link
[20:51:10] <rayh> I guess that I was thinking HAL because of the ease of signal connection.
[20:51:17] <SWPadnos> yep - you get 11 bytes/ms or thereabouts
[20:51:56] <rayh> and with alex working on halui it would be trivial to make the hal_serial talk to emc.
[20:53:42] <rayh> Then if the front and end matter were simply saved as a hal param, the module could assemble or disassemble each message based on the param.
[20:55:23] <SWPadnos> do you mean the panel configuration should be HAL parameters?
[20:56:35] <jepler> loadrt hal_serial protocol="some painful description of the structure of the bits on the wire"?
[20:56:46] <rayh> No the comm protocol should be parameters to the hal module
[20:56:48] <SWPadnos> yeah - that's what I was trying to find out about ;)
[20:56:58] <SWPadnos> that would be next to impossible, I think
[20:57:20] <jepler> but parameters can only be the basic HAL types, and I don't believe you can create new pins when a parameter is set
[20:57:38] <SWPadnos> I suspect that the best we might be able to get would be a serial driver that exports a U8 pin, and gets clocked to send successive bytes
[20:57:54] <jepler> so you can't use a parameter to say "the 8th byte of the packet gives the state of panel switches 24..31"
[20:58:03] <SWPadnos> the interpreter would need to be different for the various devices
[20:58:06] <SWPadnos> right
[20:58:25] <rayh> Sounds like you are on a good track.
[21:01:00] <SWPadnos> have you added this to the wiki page?
[21:01:31] <rayh> No I thought I'd try serial comm on you guys first.
[21:01:39] <rayh> Think it is worthy and doable.
[21:01:45] <SWPadnos> heh
[21:02:06] <SWPadnos> it's got to be doable. I'm not sure how worthy in the short run
[21:02:30] <rayh> If you could hang your AVR board off the end of 232 and see if we can get meaningful data in HAL ...
[21:02:38] <cradek> I know a language that's really good at byte and bit manipulation - C
[21:02:48] <SWPadnos> in RT it may be a real pain
[21:03:06] <jepler> You could define the "dumbest possible protocol": The MSBs of each byte are 00 if it is the first bit of a packet, 01 if it is the last, and 10 otherwise (or some other distribution of bits). hal_serial takes the packet length in bytes as the argument, and it creates 6*len bits
[21:03:16] <SWPadnos> but it's probably worthwhile to try to get a simple byte-banger driver in HAL
[21:03:47] <jepler> another "dumbest possible protocol" exposes the last byte read as 8 separate pins
[21:04:11] <jepler> but my first DPP gives you arbitrarily many bits
[21:04:12] <SWPadnos> that wouldn't work for anything beyond 9600 baud
[21:05:06] <rayh> If we are talking jog pendant that should be plenty of speed.
[21:05:06] <SWPadnos> you can make it 7 bits/byte by just using the first bit as a SOT marker, and have it 0 on all successive bytes
[21:05:28] <jepler> The two bit approach lets you at least verify that you saw the right number of bytes in the packet
[21:05:47] <SWPadnos> the driver resynchronizes when it sees 0b1xxxxxxxx, and ignores anything beyond num_bytes
[21:05:54] <SWPadnos> so does a software counter, I think
[21:06:16] <SWPadnos> error_out = (bytecount == num_bytes) when a new header is seen
[21:06:45] <jepler> OK, I like your DPP definition better.
[21:06:50] <jepler> I was clearly overly complicating things
[21:06:53] <SWPadnos> heh
[21:07:04] <SWPadnos> too clever - I'm dumber than you. nyah nyah :)
[21:07:41] <SWPadnos> wait a second though. my motto is "no project too simple to make too complex" - what am I doing?
[21:08:22] <jepler> The output side would work just the same: hal would latch the output bits, then put them on the wire in 7-bit chunks
[21:08:36] <SWPadnos> actually, an in-between protocol, that still contains the number of bytes is to have the header set bit 7, and the remaining bits are the packet length
[21:08:52] <SWPadnos> then you can do 8 bits per payload byte
[21:09:06] <SWPadnos> kinda analogous to RLL encoding (sort of)
[21:09:22] <SWPadnos> oops, RLE
[21:12:29] <jepler> and another new hal module would do bits<->integer conversion, with whatever frills seem necessary (e.g., values as deltas, or expanding n-bit counts to 32-bit counts)
[21:13:33] <rayh> Have we got the hardware and programming stuff laying around prototype something like this?
[21:13:47] <rayh> around TO proto
[21:13:55] <cradek> I intend to bring some avr stuff
[21:14:04] <cradek> is that what you mean?
[21:14:11] <rayh> typoing1o1 again.
[21:14:13] <rayh> Yes.
[21:14:15] <jepler> one entirely dumb way to do it is with a serial loopback. Have userspace write the signals you think the hardware would, and read them back in realtime
[21:14:27] <cradek> true
[21:14:29] <SWPadnos> I can bring some of that kind of thing
[21:14:57] <cradek> or just hook together two machines with nullmodem
[21:15:13] <rayh> Is it the sort of ability that would be good to have in 2.2
[21:15:15] <jepler> I might as well bring this ARM-based microcontroller I bought
[21:15:22] <jepler> it has a proper rs232-level serial port on it
[21:15:33] <cradek> yeah that's the only hard part - the level shifting
[21:15:42] <rayh> I've got a protoboard with maxim 232 chip and 9 pin
[21:15:59] <jepler> the laptop I'll be bringing doesn't have a hardware rs232 serial port at all
[21:16:01] <rayh> and a pic16877 i think
[21:16:52] <jepler> the ARM has over 40 available 5V tolerant I/Os .. still not enough to do this entire panel
[21:16:57] <cradek> jepler: I'm sure I'll have my laptop
[21:17:00] <SWPadnos> my board has the level shifter as well
[21:17:03] <jepler> http://futurlec.com/ET-ARM_Stamp.shtml
[21:17:30] <rayh> I've got a gateway/ubuntu laptop but no 232 out.
[21:17:49] <rayh> I've got an older hp with 232 out but winders98
[21:18:04] <jepler> if we make it a userspace component then USB serial should work too
[21:18:30] <SWPadnos> my laptop's got a serial port, and the kiosk PC has 4
[21:18:36] <jepler> I *could* bring a desktop machine with serial, but I certainly wasn't planning on it
[21:18:52] <cradek> jepler: we'll have plenty of serial ports, since I'm bringing desktop and laptop
[21:19:00] <rayh> I'll have several desktop machines with serial ports.
[21:19:19] <SWPadnos> jepler, what input voltage does the ARM board allow?
[21:20:16] <alex_joni> hello
[21:20:21] <alex_joni> * alex_joni was away for a while
[21:20:26] <alex_joni> seen you want to make a pendant
[21:20:32] <jepler> SWPadnos: The "ARM Stamp" itself needs a +3.3V power supply. The development kit takes a 7-12VAC/VDC (?) input and provides regulated 5V and 3.3V.
[21:20:38] <alex_joni> if you really want something nice.. get something like the ethernut
[21:20:41] <jepler> SWPadnos: the I/Os are "5V tolerante"
[21:20:41] <alex_joni> and make it talk NML
[21:20:46] <alex_joni> through ethernet
[21:20:47] <SWPadnos> ok
[21:20:59] <rayh> I've got an ethernut1 here that I can bring.
[21:21:04] <SWPadnos> I can bring one or two ethernet->serial adapters, if you like ;)
[21:21:19] <alex_joni> SWPadnos: ethernut has the advantage that you can program it
[21:21:30] <jepler> SWPadnos: I wrote a few notes about the board here:
http://emergent.unpy.net/projects/01141702410
[21:21:32] <SWPadnos> these, too
[21:21:39] <SWPadnos> Lantronix and Digi adapters
[21:21:39] <alex_joni> * alex_joni has done a few projects with ethernut
[21:21:48] <alex_joni> and I was thinking of a simple libnml on it
[21:21:54] <jepler> "There's a power jack, labeled 7-12V AC/DC, for which I happened to have a compatible AC adapter (12VDC). There's also a 2-pin connector for 7-12V AC/DC, as well as an input for regulated +5V."
[21:22:17] <rayh> alex. If you want to do that, I'll supply the nut.
[21:22:55] <alex_joni> rayh: I have a few
[21:23:02] <SWPadnos> ok. I almost always put a switcher on my boards these days - I like a wide input range
[21:23:03] <alex_joni> the question is: will anyone use it?
[21:23:12] <rayh> I have the jtag and spi progrmming cable.
[21:23:14] <jepler> alex_joni: you changed your mind yet, about coming to fest?
[21:23:28] <alex_joni> jepler: no :(
[21:23:30] <SWPadnos> Ray offered you a nut, you can't beat that ;)
[21:23:32] <jepler> SWPadnos: on this board, it's just a 7805
[21:23:36] <alex_joni> rayh: jtag & spi here too ;)
[21:23:37] <jepler> alex_joni: oh well
[21:23:54] <rayh> IMO a proof of concept at fest is more important than the cost or actual ability.
[21:24:28] <jepler> * jepler wanders off
[21:24:32] <alex_joni> I can probably hack up something by then (at least an LCD on the nut displaying position from emc)
[21:24:33] <rayh> I think this is a case of, "If we make it they will come."
[21:26:18] <rayh> Question is do we want to spend energy in that direction.
[21:26:30] <rayh> beyond today's discussion of it.
[21:27:16] <alex_joni> rayh: give me a few days to discuss it with some friends
[21:27:28] <alex_joni> they actually have time to play with this stuff ;)
[21:27:42] <rayh> Okay.
[21:28:27] <alex_joni> the problem is implementing nml in ure c
[21:29:34] <SWPadnos> can avr-gcc target the ethernut easily?
[21:36:13] <alex_joni> yes, but there is no avr-g++ afaik
[21:36:38] <alex_joni> hrmm.. it seems there is
[21:39:38] <alex_joni> http://winavr.sourceforge.net/
[21:39:47] <alex_joni> It includes the GNU GCC compiler for C and C++.
[21:42:54] <SWPadnos> I don't know how good the code is, but if the ethernut has a Mega128, it should be OK
[21:52:03] <alex_joni> yup
[21:52:29] <alex_joni> but porting the whole libnml is not trivial
[21:52:46] <SWPadnos> no, indeed
[21:52:50] <alex_joni> especially the os_intf/ and other platform specific stuff
[21:56:09] <alex_joni> but only a subset of it, might be easier
[21:57:09] <SWPadnos> I'd suspect that a bigger problem would be the size of the status struct, for anything that wants to display EMC information
[21:57:55] <alex_joni> too much for ram?
[21:58:13] <SWPadnos> oh right - it's ethernet - we were talking about serial so much, I forgot ;)
[21:58:25] <alex_joni> NML has other ways of comm besides encoded, ASCII works too
[21:58:40] <alex_joni> so it might be a simple way of parsing a text data flow
[21:58:42] <SWPadnos> encoded would be the smallest footprint, I think
[21:58:55] <alex_joni> although I never made it work with ascii encoding only
[21:58:58] <alex_joni> :(
[21:59:03] <alex_joni> didn't try very hard either
[21:59:06] <SWPadnos> actually, you can just filter out the bytes you want from a binary packet as well
[21:59:23] <alex_joni> yeah
[21:59:39] <SWPadnos> as long as the nut can handle processing a full ethernet frame before the next one arrives
[21:59:52] <SWPadnos> could be a problem with UDP, though possibly not for TCP
[22:00:54] <alex_joni> yes, but this is TCP usually
[22:01:00] <alex_joni> so not really a problem
[22:01:34] <SWPadnos> how much RAM does the ethernut have?
[22:02:30] <alex_joni> depends on the version
[22:02:38] <alex_joni> the latest ethernut (v3) is ARM based
[22:02:51] <alex_joni> and has lots of cojones ;)
[22:03:01] <SWPadnos> ok. do they generally have more than the processor internal RAM though?
[22:03:28] <alex_joni> ethernut 2.1 has 32kB internal + 30 banks * 16kB
[22:03:38] <alex_joni> 3.0 has 256kB RAM
[22:03:45] <alex_joni> http://www.ethernut.de/en/hardware/index.html
[22:03:53] <SWPadnos> ok, that should be ebough
[22:03:58] <SWPadnos> much better than the 4k internal ;)
[22:04:02] <SWPadnos> enough, even
[22:04:26] <alex_joni> that's what bill said a while ago
[22:04:36] <alex_joni> 32kB is internal afaik
[22:04:47] <SWPadnos> not on the '128 chip
[22:05:31] <alex_joni> right.. it's external
[22:05:35] <alex_joni> * alex_joni remembered ;)
[22:05:48] <alex_joni> I even built one of these a while ago:
http://www.ethernut.de/en/isa/index.html
[22:10:11] <jepler> how much for one of the 3.0 ethernuts? That does sound like quite the board.
[22:12:37] <jepler> ah, 170 euros. not cheap!
[22:13:46] <SWPadnos> hey Alex - have you heard of a resort town pronounced something like "Dorne Vatra" (transliterated to english from a yiddish speaker speaking a Romanian name ;) )
[22:14:17] <alex_joni> vatra dornei
[22:14:29] <SWPadnos> aha - backwards ;)
[22:14:37] <alex_joni> yes I did, was there a few times (once or twice)
[22:14:38] <SWPadnos> is that on the black sea?
[22:14:44] <alex_joni> no, very far
[22:14:57] <alex_joni> it's north-east romania
[22:15:05] <SWPadnos> ah, OK.
[22:15:18] <SWPadnos> (got my mother on the phone - finally mentioned the names you told me a while ago)
[22:15:18] <jepler> http://www.world66.com/europe/romania/vatradornei
[22:16:44] <SWPadnos> funny - it looks a lot like here
[22:17:46] <alex_joni> heh, nice
[22:39:14] <alex_joni> * alex_joni feels like working
[23:04:25] <alex_joni> hrmm.. wonder if I can change a default program for a certain filetype
[23:04:53] <SWPadnos> in ubuntu?
[23:06:02] <alex_joni> yes
[23:06:52] <SWPadnos> KDE or Gnome?
[23:07:37] <alex_joni> gnome
[23:08:23] <SWPadnos> http://ubuntuguide.org/#changedefaultfiletypeprogram
[23:08:36] <SWPadnos> that was for 5.04,but it may still work on 5.10
[23:11:56] <alex_joni> darn.. any idea how to lose a hickup?
[23:12:03] <SWPadnos> death
[23:12:04] <alex_joni> I've been having it for the last 5 minutes
[23:12:21] <SWPadnos> I'm not sure - nothing has ever worked for me
[23:12:30] <SWPadnos> except sufficient time
[23:13:14] <alex_joni> hmm.. holding my breath and bowing the head seemed to have helped
[23:15:52] <SWPadnos> heh
[23:19:15] <alex_joni> juve@ubuntu:~/emc2$ bin/halcmd show pin halui
[23:19:15] <alex_joni> Component Pins:
[23:19:15] <alex_joni> Owner Type Dir Value Name
[23:19:15] <alex_joni> 07 bit -W FALSE halui.0.general.0.machine-is-on
[23:19:15] <alex_joni> 07 bit R- FALSE halui.0.general.0.machine-on
[23:19:21] <alex_joni> ;-)
[23:37:33] <SWPadnos> SWPadnos is now known as SWP_Away
