Back
[06:49:24] <SWPadnos> argh
[18:18:19] <SWPadnos> hi Ray
[18:18:34] <rayh> Hi Steve.
[18:18:44] <rayh> You home for a while now?
[18:18:55] <SWPadnos> a couple of weeks, I think ;)
[18:19:31] <alex_joni> hi ray
[18:19:41] <SWPadnos> I have no scheduled trips until April, but one never knows
[18:21:22] <rayh> Hi alex
[18:21:34] <alex_joni> what's up ray?
[18:22:06] <rayh> Dr gave me some new meds. This is supposed to cure or else terminate.
[18:23:40] <alex_joni> ouch :(
[18:23:44] <alex_joni> heard about dave?
[18:23:54] <rayh> How fast have you been running those steppers with the gecko?
[18:23:59] <rayh> Dave?
[18:24:03] <SWPadnos> dave-e
[18:24:14] <rayh> Just on the phone with him.
[18:24:20] <alex_joni> yeah, he's fully running emc2 now.. he said ;)
[18:24:59] <rayh> Oh right. He's still a bit confused about some tuning stuff but he's got it going.
[18:25:05] <alex_joni> great news
[18:25:19] <alex_joni> regarding the geckos & sherline, about 10mm/sec
[18:25:25] <alex_joni> but that was before the realtime fix
[18:25:43] <alex_joni> didn't try lately.. no time, the machine is at work, didn't find time to play with it
[18:32:19] <rayh> Looks like cncuser isn't having much fun.
[18:32:47] <alex_joni> he's trying real hard, and he's messing with it for 30 hours now (he said)
[18:33:21] <alex_joni> I usually lose my fun after 10-12 hours too ;)
[18:33:22] <rayh> I guess we all do that now and then.
[18:33:31] <rayh> exactly.
[18:34:19] <rayh> Got a few minutes to talk interpreter?
[18:34:23] <alex_joni> sure
[18:34:52] <rayh> For edm backup, we need to either build a backup stack or
[18:35:07] <rayh> build a stack in the interpreter and use a pointer.
[18:35:28] <alex_joni> I think I like your approach better ;)
[18:35:42] <alex_joni> kidding..
[18:35:51] <SWPadnos> aren't there two or three different needs for reversal?
[18:35:53] <rayh> okay
[18:36:00] <SWPadnos> (ie, Z retract, path retrace, ...)
[18:36:04] <rayh> Yes.
[18:36:18] <alex_joni> a stack (actually a circular list) is not that hard
[18:36:31] <alex_joni> but the stack will work only for path retrace
[18:36:32] <alex_joni> I think
[18:36:44] <SWPadnos> yep. Z retract isn't a reversal
[18:36:47] <rayh> It could consume large hunks of memory.
[18:37:02] <alex_joni> rayh: depending on how much you want to be able to reverse
[18:37:20] <rayh> I was thinking the entire gcode file.
[18:37:25] <alex_joni> what for?
[18:37:36] <alex_joni> how much do you need to back up?
[18:37:38] <SWPadnos> that's not practical, since files can be larger than memory
[18:37:41] <alex_joni> usually .. a few microns?
[18:37:52] <alex_joni> a mm ?
[18:37:54] <rayh> So we could point to current line and know things like current state rather than look ahead state.
[18:37:57] <alex_joni> an inch ?
[18:38:23] <rayh> Some wire edm users say the back all the way out of a cut regardless of the complexity.
[18:38:32] <SWPadnos> actually, the retract thing is useful for non-EDM as well - consider using a keyway cutter, that breaks ...
[18:38:55] <alex_joni> here's a thought
[18:39:02] <alex_joni> how about interpreting it backwards?
[18:39:41] <rayh> That is what I was doing and only saving a few of the last moves.
[18:39:46] <alex_joni> not really backwards, it's a matter of forward-backwards
[18:40:17] <rayh> The last block is the backup from the current one.
[18:40:36] <alex_joni> yup, the only problem is feedrate and other special codes
[18:40:41] <rayh> Dave-e did some testing and arcs with R work fine for backup.
[18:40:44] <alex_joni> M-codes, S-Codes, F-codes
[18:41:27] <rayh> i,j,k are more of a problem because you must know exactly where abort happened.
[18:41:42] <alex_joni> you have the current position
[18:42:07] <rayh> just not in a usable way in the gui.
[18:43:14] <alex_joni> no, but in status
[18:43:20] <alex_joni> and you can get it to interp
[18:44:04] <alex_joni> GET_EXTERNAL_POSITION() should do that
[18:44:26] <rayh> I think the delays between gui rate, tp rate, and actual abort would kill the accuracy.
[18:45:28] <rayh> Dave tried a few with i,j,k and always found the same endpoint error message.
[18:45:29] <alex_joni> no, this comes right from pos = emcStatus->motion.traj.position;
[18:45:41] <alex_joni> so right out of the motion controller
[18:45:49] <alex_joni> which should be stopped by now
[18:45:52] <alex_joni> as it aborted
[18:46:20] <rayh> Sure and it should keep counting on a servo system
[18:46:48] <rayh> a stepper system would seem to be less reliable with coasting and all.
[18:47:31] <alex_joni> there are a few approaches to this:
[18:47:34] <cradek> hi all
[18:47:45] <rayh> So you think a stack inside the interpreter that holds the entire program is not a workable idea?
[18:47:46] <alex_joni> 1. keep a list of positions, and use those in the inversed order
[18:47:52] <rayh> Hi Chris.
[18:47:54] <alex_joni> this inside the motion controller
[18:48:32] <rayh> How is any of the rest of EMC going to follow a reversal if it exists only in motion?
[18:48:45] <alex_joni> 2. keep a stack/list of canon calls inside the interp, and do the same thing at task/interp level
[18:48:53] <alex_joni> rayh: that's the least of my worries
[18:49:03] <rayh> Okay.
[18:49:09] <alex_joni> basicly communication between motion and the rest can be extended
[18:49:22] <rayh> Sure.
[18:51:50] <cradek> stacking and reversing canon isn't going to give you the same path, since lots of canon is stateful (think SET_VEL etc)
[18:52:10] <alex_joni> right
[18:52:49] <rayh> True. That's why I was doing it at the gcode level.
[18:53:01] <cradek> well gcode is exactly the same way
[18:53:06] <rayh> Each restart reads state to that point.
[18:53:27] <cradek> for each line you move backwards, you would have to start at the beginning of the program
[18:53:47] <alex_joni> cradek: I think we need to reinterpret it, but backwards
[18:53:50] <rayh> And that's exactly what I did.
[18:53:52] <alex_joni> and slightly rewritten
[18:53:59] <alex_joni> moving the F's around and so on
[18:54:08] <rayh> Not each line but the start of the reverse and the start of the restart.
[18:55:55] <alex_joni> well, the idea is that you probably end up somewhere in the middle of a move
[18:56:07] <alex_joni> with god-knows what speed & accels
[18:56:32] <alex_joni> the TP needs to replan the inverse move starting from there, going the other way
[18:58:36] <cradek> and it has to blend exactly the same
[18:58:36] <alex_joni> so either way both Interp and TP need to know about the revers ?
[18:59:11] <cradek> are we talking about backing up "a bit" or to the beginning of the program?
[18:59:12] <alex_joni> cradek: I think it has to use the previous blend but going from 1 to 0
[18:59:24] <alex_joni> eventually to the beginning of the program :/
[18:59:28] <alex_joni> that's the hard part
[18:59:56] <cradek> sure is
[19:00:28] <alex_joni> and to make it hardest you don't a�ways back up the path you came
[19:00:39] <alex_joni> always ;)
[19:00:52] <cradek> I think there's no alternative to doing it from the gcode, since you can't just save up the moves (as SWPadnos said)
[19:01:05] <cradek> what do you mean?
[19:01:35] <alex_joni> there is path-backing up, and there is Z-backing up (as I understand, and I'm no expert, you only back up Z+)
[19:01:50] <cradek> ok, Z is easy
[19:02:10] <cradek> "easy"
[19:02:23] <alex_joni> yeah, but allowing more than one option is "messy"
[19:02:39] <alex_joni> or easily gets "messy"
[19:03:56] <rayh> Sorry phone -- Blending won't be much of an issue at edm speeds.
[19:05:06] <rayh> We might think about treating all axes the same. There are 4 axis wire machines.
[19:05:20] <rayh> and I imagine someone will build a hexapod edm sinker.
[19:05:46] <alex_joni> ouch, just when I thought this can't get more complicated
[19:06:14] <rayh> complex is my specialty.
[19:06:25] <rayh> If it's easy anyone will do it.
[19:06:51] <alex_joni> lol, bet so..
[19:08:16] <cradek> I think I just fixed constraint handling for >3 axes, even with some in different units
[19:10:02] <alex_joni> I think we need to start fixing emc2 to properly do non-carth. machines
[19:10:10] <rayh> Wah! That sounds great.
[19:10:12] <alex_joni> before attempting backing up & such for those
[19:10:36] <rayh> How does emc2 handle kinematics differently than EMC?
[19:10:51] <alex_joni> not differently, just as bad
[19:11:12] <rayh> ??
[19:11:18] <alex_joni> rayh: most of the code is mixed between joints and axes
[19:11:35] <alex_joni> for example: the constraints from the ini, those are joint constraints
[19:11:46] <alex_joni> but are used as axis constrains (vel & accel)
[19:12:09] <alex_joni> don't think anyone can specify for a haxapod what the max_vel & max_accel for axis X is..
[19:12:18] <alex_joni> yet, that's the way canon does it
[19:13:35] <rayh> Sure. The max vel in world space does not equal joint max vel
[19:13:52] <rayh> The critical constraint is joint though.
[19:13:58] <alex_joni> yet the TP plans in world space
[19:14:04] <alex_joni> and the canon above
[19:14:14] <alex_joni> they don't know/give a damn about joint constraints
[19:14:24] <rayh> Are you saying that f10 in world is NOT f10
[19:14:48] <alex_joni> no, I'm saying that F10 in world might get F200 on joint 0 which has a max_vel of 100
[19:15:16] <cradek> I don't understand what a joint maxvel would be. What units if it's rotary?
[19:15:34] <rayh> degrees?
[19:15:39] <alex_joni> degs/second
[19:15:56] <alex_joni> cradek: the problem is how that relates to world model
[19:16:09] <alex_joni> and that's where the inverse & forward kins come handy
[19:16:13] <cradek> sure
[19:16:38] <alex_joni> imagine a puma robot
[19:16:44] <cradek> for kins you have to give position equations and their first couple derivatives?
[19:16:45] <alex_joni> * alex_joni knows those best
[19:16:50] <alex_joni> yes
[19:16:59] <cradek> that doesn't sound too bad
[19:17:22] <cradek> ... if you can take a derivative
[19:17:29] <cradek> you can't always, can you?
[19:17:40] <alex_joni> I know on emc1 besides the inverse/forward kins, thre were inverse/forward Jacobians
[19:17:54] <cradek> what's that mean?
[19:18:10] <alex_joni> some other functions that handled velocity mapping
[19:18:23] <alex_joni> a bit over my head too, didn't investigate very much
[19:18:25] <alex_joni> :(
[19:20:43] <alex_joni> it's not actually used in emc1
[19:21:00] <cradek> rayh: does your sherline test machine have the rotary axis?
[19:21:02] <alex_joni> I just grepped, only defined in genhexkins
[19:21:12] <rayh> I'm still thinking joint v world. If I set max_vel on the first axis.
[19:21:24] <rayh> Yes. I've got a couple of rotaries.
[19:21:50] <cradek> great, it would be nice if you could test the rotary/linear moves for me, I don't have one
[19:22:40] <cradek> well I do, but no driver for it
[19:22:59] <alex_joni> rayh: I think we all agree, it easily gets confusing when thinking about joint v. world
[19:23:25] <rayh> Sure. I'll have to get it setup later today.
[19:23:58] <rayh> I thought that when considering a joint, the ini stuff only worked for that motor.
[19:27:33] <alex_joni> well, the ini stuff never gets treated as joint stuff.. that's why I say it's borked :(
[19:27:41] <alex_joni> maybe not borked, mixed-up..
[19:29:10] <rayh> Okay. I believe you.
[19:29:29] <rayh> Did you look at the puma stuff in emc1
[19:29:48] <alex_joni> not closely, I tried to follow the calcs, that's pretty ok
[19:30:10] <rayh> First time I was at NIST, Fred ran it for me.
[19:31:22] <rayh> What you're saying is that we need an ini axis to represent a motor and only a motor.
[19:31:33] <alex_joni> yes
[19:31:44] <alex_joni> call it [JOINT_0]..
[19:32:02] <alex_joni> and "maybe" it's needed to have AXIS_X, Y, Z etc constraints
[19:32:04] <rayh> Then we have to honor that joint's max stuff
[19:32:17] <rayh> on the world side of things.
[19:32:31] <alex_joni> because getting AXIS_X out of f(j0,j1,j2,j3,j4..) is not trivial
[19:32:57] <rayh> right.
[19:33:20] <alex_joni> it might not be too complicated, but it's not something fixed or linear
[19:33:28] <alex_joni> so that easily confuses people ;)
[19:33:32] <rayh> Even more confusing to me is how to set soft limits to avoid singularities.
[19:33:54] <alex_joni> rayh: at least on welding robots, you don't
[19:34:10] <alex_joni> you just need to be carefull how you program, so you don't enter that area
[19:34:22] <rayh> True
[19:35:06] <rayh> a similar problem is rho theta and crossing zero creates infinite feedrate.
[19:35:34] <alex_joni> yup, I know those problems :(
[19:36:02] <alex_joni> always when you don't want them.. they keep turning up ;-)
[19:36:24] <rayh> How true!
[19:36:42] <alex_joni> on our robots it's this problem:
[19:36:58] <alex_joni> when joint 5 is at position 0, joint 4 and 6 are collinear
[19:37:22] <alex_joni> now try to move it in cart...
[19:37:33] <alex_joni> the TP has no idea how to move joints 4 & 6
[19:37:46] <alex_joni> total indecision ;)
[19:38:36] <alex_joni> finally it usually decides on a scheme, and then it ferrors..
[19:38:46] <alex_joni> turning 4 one way, 6 the other one
[19:39:49] <rayh> cradek, Thanks for adding the source directory to your script. That will help a lot of folk.
[19:40:09] <cradek> sure
[19:40:13] <cradek> it was a mistake to not add it at first
[19:40:33] <rayh> eh how would we learn if it weren't for mistakes.
[19:40:34] <cradek> rayh: I checked in my four axis sample config for you to use if you like
[19:40:58] <rayh> I saw that problem alex on a robot at Ford.
[19:41:08] <alex_joni> rayh: they all have it ;)
[19:41:16] <rayh> Okay. What's its name.
[19:41:27] <cradek> stepper-xyza
[19:41:32] <alex_joni> who's?
[19:41:43] <rayh> Great. I'll try it later this evening.
[19:41:56] <lilo> [Global Notice] Hi all. If you are running a Netgear model WGT624 (the white enclosure) and you would like to test their fix for the recent DCC exploit, the one that's probably knocking you offline when some childish person sends it to you, please send me your email address and I'll forward it to them. Thanks!
[19:42:07] <cradek> thanks
[19:42:29] <cradek> rayh: I think I got some things right that have never been quite right :-)
[19:42:42] <alex_joni> cradek: what took you so long?
[19:42:45] <alex_joni> :-)
[19:43:08] <cradek> alex_joni: I don't know, I missed the obvious the first time I "fixed" it
[19:43:14] <rayh> rofl
[19:43:25] <rayh> I miss a lot of obvious.
[19:43:30] <cradek> alex_joni: now tooltip accel can exceed axis accels, just like velocity
[19:43:41] <alex_joni> right
[19:44:30] <lilo> [Global Notice] In the meantime, please remember, if you're getting hit, disconnect from freenode and reconnect to chat.freenode.net, port 8001. If you use port 8001, rather than port 6667, it should render the attack ineffective. Thanks!
[19:44:40] <cradek> g0x1y1z1a90 is a thing of beauty
[19:44:47] <rayh> so g0 x1 y1 will accel along the diag at the individual accel rates?
[19:45:10] <cradek> at the min(x accel, y accel) * sqrt(2)
[19:45:24] <cradek> or something like that
[19:45:30] <SWPadnos> does it complete the rotary move in the same time as the linear? (ie, is the angular feedrate time-controlled)
[19:45:31] <cradek> yeah, I think that's right
[19:45:36] <cradek> SWPadnos: yes
[19:45:45] <SWPadnos> ok. that makes sense
[19:45:57] <cradek> SWPadnos: without exceeding the angular axis's constraints, which are in different units altogether
[19:46:02] <SWPadnos> yep ;)
[19:46:44] <SWPadnos> I was just thinking of how the machine construction is important once you add anything that rotates
[19:46:59] <alex_joni> it is important
[19:47:14] <cradek> yep, can of worms
[19:47:19] <alex_joni> if you guys care I can share how this works on my robots ,)
[19:47:35] <SWPadnos> yep. a 2-axis head on an otherwise 3-axis machine is very different from a 3-axis mill with two rotary tables
[19:48:00] <rayh> Constant surface speed on rotaries would be nice.
[19:48:21] <alex_joni> that's what we need when welding
[19:49:02] <alex_joni> basicly I need to define each axis
[19:49:40] <alex_joni> that is done by 3 points, the robot tracks that specific axis which gets moved to three locations, and the same relative point gets saved
[19:49:44] <SWPadnos> there's a problem with constant speed on rotaries - you need nonlinear rates on the rotary axis, depending on what movements are done on the cartesian axes
[19:49:56] <SWPadnos> (and vice versa, I imagine)
[19:49:59] <alex_joni> SWPadnos: right, but neglectable
[19:50:21] <SWPadnos> depends on the machine and tool length
[19:50:31] <alex_joni> depending on the feedrate, an change in feedrate
[19:50:46] <SWPadnos> a rotary head spinning in A will move the tool in YZ
[19:51:05] <SWPadnos> a rotary table in A will move the tool in Y, and possibly Z
[19:51:18] <SWPadnos> (relative to the work)
[19:51:30] <alex_joni> yes, but remember that ABC are special cases ;)
[19:51:48] <alex_joni> usually moving a joint moves in all 6 dof's
[19:52:00] <SWPadnos> yeah - the G-code needs to be generated with advanced knowledge of teh machine
[19:55:09] <SWPadnos> I guess it would be ideal for G-code to specify XYZRPW of the tooltip, and let the kinematics take care of all the rest (which is what you want with the TOV thing)
[19:56:04] <rayh> Ideally feedrate needs to be tool tip
[19:56:34] <SWPadnos> yep, but "machine independent" G-code isn't trivial once rotation is taken into account
[19:57:02] <rayh> I thought that Graham was working on a stacked rotary 4 and 5.
[19:57:12] <alex_joni> Graham Bell?
[19:57:17] <SWPadnos> heh
[19:57:31] <alex_joni> rayh: sorry, couldn't resist ;9
[19:57:42] <rayh> Graham Sperry-Taylor or some such.
[19:57:53] <SWPadnos> Stabler?
[19:58:19] <alex_joni> rayh: I am thinking about adding ddt's to all configs.. how does that sound?
[19:58:21] <rayh> now my head really hurts.
[19:58:38] <SWPadnos> on the servo timescale?
[19:58:44] <alex_joni> yup
[19:58:51] <alex_joni> maybe commented out
[19:59:20] <SWPadnos> how about making a ddt.hal file, that connects to the "standard" signal names?
[19:59:32] <cradek> alex_joni: I have ddts in stepper-xyza
[19:59:45] <alex_joni> SWPadnos: interesting
[19:59:50] <alex_joni> cradek: I thought you would
[19:59:50] <SWPadnos> ddt is a part of blocks, right?
[19:59:53] <alex_joni> right
[20:00:06] <SWPadnos> that could be a problem
[20:01:21] <cradek> alex_joni: jepler says (and I agree with him) that halscope should do the ddts, not realtime modules
[20:01:32] <cradek> alex_joni: (if all you want to do is display them)
[20:01:41] <SWPadnos> scope_rt then
[20:01:59] <SWPadnos> or in halscope itself, using the raw data?
[20:02:21] <SWPadnos> erm - wait. it has to be in scope_rt, so that triggering will work
[20:03:57] <cradek> true, I didn't think about triggering.
[20:04:16] <cradek> I was thinking of a halscope feature "show me the first few derivates of channel 1"
[20:04:27] <SWPadnos> right - that would also be useful
[20:04:41] <cradek> instead of wasting your precious channels on derivates (since you already have the information anyway)
[20:04:50] <SWPadnos> it's still better to do the derivative in scope_rt, to reduce the call chain for the thread
[20:05:02] <SWPadnos> (assuming you need to trigger on it)
[20:05:16] <rayh> I put all the ddt testing stuff in an ini and labeled it xx_test.ini
[20:08:33] <alex_joni> cradek: interesting point
[20:09:28] <cradek> with 4 channels I would love to get XYZA position/velocity/accel and maybe someday jerk
[20:09:40] <cradek> but as SWPadnos says you can't trigger.
[20:10:20] <SWPadnos> it would be nice to change the ddt (or add another) so you can specify the derivative you want
[20:10:37] <SWPadnos> rather than calling 37 functions
[20:10:49] <cradek> also true
[20:26:22] <alex_joni> * alex_joni finished dinner
[20:35:44] <cradek> as you can see, you didn't miss much
[20:39:19] <alex_joni> missed my health.. ate bad things again ;)
[20:42:12] <cradek> I was playing with my 4-axis setup again
[20:42:29] <cradek> jogs on the rotary are very slow, because they use the same [TRAJ]DEFAULT_VELOCITY as the linears
[20:42:49] <cradek> there needs to be a different DEFAULT_VELOCITY for angular units, or it should be axis-specific
[20:44:35] <alex_joni> or you could specify the jog speed in the GUI
[20:45:13] <cradek> well there's really no appropriate slider - the sane ranges are completely different
[20:45:17] <alex_joni> cradek: pulling your leg, but that's how the others do it ;)
[20:45:33] <cradek> I know, but it's not a gui issue
[20:45:50] <alex_joni> does the axis have a max_speed?
[20:45:56] <cradek> yes
[20:46:06] <alex_joni> why not use a slider from 0 to that?
[20:46:18] <alex_joni> in that particular axis units of course
[20:46:25] <cradek> because max speed in degrees is 90, max speed in inches is 1
[20:46:39] <cradek> approximately
[20:46:47] <cradek> factor of 100 different
[20:46:48] <SWPadnos> use radiand ;)
[20:46:50] <SWPadnos> radians
[20:46:59] <alex_joni> oh.. and you have ONE speed for jogging..
[20:47:07] <cradek> alex_joni: right
[20:47:16] <cradek> alex_joni: you would have to slide the slider from 1 to 100 every time you change axis
[20:47:20] <alex_joni> teleop does that better
[20:47:34] <alex_joni> cradek: maybe remember the last value?
[20:47:40] <alex_joni> of course with proper canon support
[20:47:45] <alex_joni> not inside the GUI
[20:47:56] <cradek> no no no
[20:48:01] <cradek> there needs to be separate defaults
[20:48:06] <cradek> you're ignoring the base problem
[20:48:18] <cradek> either per unit, or per axis
[20:48:19] <alex_joni> no, that's what I'm saying actually
[20:48:22] <SWPadnos> add a second jog speed control if there are any angular axes
[20:48:43] <alex_joni> DEFAULT_SPEED is used only for jogging?
[20:48:47] <cradek> yes
[20:49:01] <cradek> and I don't think DEFAULT_ACCEL is used at all
[20:49:05] <cradek> nfc why it's there
[20:49:07] <alex_joni> then it really should be in various units
[20:49:24] <SWPadnos> the DEFAULT_* are used to seed the axis structs, I think
[20:49:25] <cradek> or per-axis.
[20:49:34] <SWPadnos> so if an axis doesn't have the setting, it'll get default
[20:49:46] <cradek> SWPadnos: ok, didn't know that
[20:50:03] <alex_joni> SWPadnos: right, and there are some precompiled defaults too
[20:50:11] <alex_joni> that get replaced during seeding
[20:50:25] <SWPadnos> right - the inifind functions take a default value in case the setting isn't found (or is that only on Windows?)
[20:50:40] <alex_joni> always
[20:52:47] <alex_joni> I think ;)
[20:53:02] <SWPadnos> heh
[20:53:31] <alex_joni> I bet no-one can say anything for sure about emc ;)
[20:53:44] <SWPadnos> I can: "It's overly complicated"
[20:53:47] <SWPadnos> :)
[20:53:57] <alex_joni> it's all about probability
[20:54:07] <SWPadnos> "It's probably overly complicated"
[20:54:23] <alex_joni> SWPadnos: only probably, it might even be under-complicated
[20:54:27] <alex_joni> for certain things
[20:54:30] <SWPadnos> indeed
[20:54:31] <alex_joni> like EDM ;)
[20:54:45] <SWPadnos> overcomplicated and under-functional (in some areas) ;)
[20:54:49] <alex_joni> but it will get there
[20:54:55] <alex_joni> lol
[20:55:02] <SWPadnos> emc2 will, anyway
[20:55:12] <alex_joni> bet in ten years, you won't be able to read any of the code =))
[20:55:56] <SWPadnos> reversal along a path would also be very good for things like manual control of G-code execution (manual encoder to jog fwd/rev along the progammed path)
[20:55:58] <alex_joni> kidding, it's actually getting better lately
[20:56:10] <SWPadnos> we'll have computers to read the code for us ;)
[20:56:27] <alex_joni> that's bad
[20:56:34] <alex_joni> remember that's where we came from
[20:56:38] <SWPadnos> heh
[20:56:41] <alex_joni> computers writing the software for us
[20:56:48] <alex_joni> like the NML generating tools
[20:56:49] <alex_joni> ROFL
[20:56:55] <SWPadnos> well now they'll have to translate *back* in to human ;)
[20:57:09] <alex_joni> they quit
[20:57:12] <SWPadnos> heh
[20:57:26] <alex_joni> so we're left to clean up after 'puters
[20:57:41] <SWPadnos> I say "make the computers clean up after themselves"
[20:57:56] <SWPadnos> but until then, I guess there's still code to fix
[20:58:01] <alex_joni> I say "ban them"
[20:58:08] <alex_joni> till they learn to behave
[20:58:19] <SWPadnos> new license terms: this code may not be run on any computers
[20:58:49] <alex_joni> it can be run on any computers, just not by any computers
[20:59:15] <SWPadnos> OK. so a hierarchy of EMC machines isn't allowed?