#emc | Logs for 2005-03-20

[00:00:19] <jmkasunich> not me... I've never even looked at the interp code
[00:01:01] <rayh> * rayh looking back
[00:01:01] <jmkasunich> based on his emails to date, he seems pretty level headed... I wouldn't be afraid to give him write access and tell him where we'd like the stuff to go
[00:01:09] <paul_c> not me - I am tired of taking the flak when someone doesn't like my choice.
[00:01:39] <jmkasunich> this is a two step process... 1) decide what and where, 2) do the grunt work
[00:01:56] <jmkasunich> 1) should be by concensus... and I think we're working toward that on the list
[00:02:05] <rayh> IMO if the originals came from emc1 then we should give him access and let him dump them in there.
[00:02:07] <paul_c> Do new features get added to EMC-1 ?
[00:02:25] <jmkasunich> dunno
[00:02:28] <rayh> What's the worse case, we have to back up a bit and alienate one more developer.
[00:03:04] <paul_c> if EMC-1 keeps getting all the new features & development, no one will take a look at emc2
[00:03:39] <rayh> If the features work out migrate them.
[00:04:02] <rayh> You said you didn't have m101 in bdi or emc2
[00:04:23] <paul_c> Custom M codes are in bdi-4
[00:04:51] <rayh> So if the revised interp works we can just put it in there eh?
[00:05:27] <rayh> I believe that I'd favor letting keith and ken have at the interp in emc for a bit.
[00:07:54] <paul_c> might be interesting to see how that would pan out...
[00:08:14] <rayh> jmkasunich: Got the message. It was burried between viagra and ejac something or another.
[00:08:15] <jmkasunich> paul_c: features that affect the interpretation of G-code should be done in both, if practical... we don't want two "EMC dialects"
[00:09:01] <rayh> jmkasunich: Absolutely. As soon as the work they've done is tested.
[00:09:32] <jmkasunich> once EMC2 is truly functional and ready for widespread use, then I might agree that adding new features to 2 only is a way to motivate folks to change over
[00:09:41] <SWPadnos> the interpreter code is the same in both versions, right?
[00:09:42] <jmkasunich> but I don't think the time is ripe for that yet
[00:10:03] <jmkasunich> SWPadnos: as far as I know, yes
[00:10:09] <paul_c> Changes in the interp need to be transparent, documented, and in line with accepted expectations.
[00:10:36] <jmkasunich> from Ken's emails, he seems to be pretty good at documenting his work
[00:10:56] <rayh> paul_c: That should be as true of any changes.
[00:11:19] <jmkasunich> rayh: true, but there is more at stake in the interp
[00:11:33] <rayh> But it
[00:11:39] <rayh> 's cvs
[00:12:43] <rayh> As long as the new works as well, with the same codes, as the old...
[00:13:02] <rayh> even though it has new features users should be able to survive with it.
[00:13:15] <jmkasunich> as long as...
[00:13:36] <jmkasunich> and some of the Ken's ideas are not transparent - they will change existing behavior
[00:13:36] <rayh> That is the way I thought about Paul's additions of some starting lathe code.
[00:14:19] <jmkasunich> paul_c: I know you don't like new directories, but what do you think of Ken's test programs directory?
[00:14:21] <rayh> How so?
[00:14:36] <jmkasunich> * jmkasunich needs to go back and read the emails for details
[00:14:57] <paul_c> I took a diff of Ken's mods, nothing really intrusive, and I don't think it will break in any nasty way.
[00:15:49] <rayh> How does he handle world model with looping.
[00:16:49] <jmkasunich> I may also be confusing ken's changes with keith's... who was planning to change G92?
[00:16:57] <paul_c> I didn't look at how the code worked, just at the way it was hooked in.
[00:17:16] <paul_c> jmkasunich: K.Rumley was after G92
[00:17:29] <jmkasunich> ok - that's the one that will be non-transparent, I think
[00:17:31] <rayh> Yes. Keith had some big changes to g92. Most of which I thought were unnecessary.
[00:17:57] <rayh> Yes. But the whole g92 is rather muddy.
[00:18:01] <jmkasunich> he's also the one with the reformatting isn't he
[00:18:10] <rayh> Matt has repented that he made Fred put it in there.
[00:18:38] <jmkasunich> my opinion... give Ken CVS access, ask him to commit his changes, in steps
[00:19:38] <paul_c> jmkasunich: Ken's changes are limited to a couple of complete blocks plus one or two minor hooks to call the new code...
[00:19:56] <jmkasunich> wait, I just found what I was looking for:
[00:19:58] <paul_c> I don't think it practical to force commits in stages
[00:20:20] <jmkasunich> Ken: Comments on changes I made:
[00:20:29] <jmkasunich> Ken: 0 -- I've tried to add features in a way that it wouldn't break existing use if you didn't use the new features. I have NOT succeeded. If someone feels strongly about this (after understanding the differences), let me know, and I'll do something about it.
[00:20:37] <paul_c> and Ken has also stuck with the existing style with his changes.
[00:20:58] <rayh> I favor the access. Ask him to modify the docs for the interpreter. Once in there, we post a note for test folk.
[00:21:02] <jmkasunich> ken: 2 -- The relational operators (LE, LT, EQ, NE, GE, GT) have precedence 3, and plus and minus operator have been moved to precedence 4, while the logical operators (and, or, exclusive or) are at precedence 2. The logical operators were originally intended to be used as bitwise operators -- but do not seem very useful. Now, they are logical operators, e.g.: if [#1 eq #2 & #3 ne #4]. For that reason,
[00:21:19] <jmkasunich> ken: Not knowing the standard left me handycapped, so I tried to make this as useful as I could. If I've broken anything serious, please let me know. Code that does not use the relational operators WILL NOT WORK THE SAME. Prior to this change, the two groups (logical operators), (plus minus) executed strictly left to right. Now the logical operators execute before the plus/minus. I could fix
[00:21:53] <jmkasunich> oops, some of that got chopped
[00:22:10] <paul_c> OK.. Just one section that has changed based on current expectations.
[00:23:50] <paul_c> Perhaps the logical operators should be committed as a separate diff then.
[00:23:59] <jmkasunich> better to read it in the original message anyway: http://sourceforge.net/mailarchive/message.php?msg_id=11199663
[00:24:06] <rayh> Can they be?
[00:24:33] <paul_c> I would have thought so.
[00:24:51] <paul_c> take a diff, remove the operator section
[00:24:55] <paul_c> commit...
[00:25:18] <SWPadnos> The logicals will need to precede the looping
[00:25:19] <paul_c> take a second diff, and apply the remaining canges.
[00:25:38] <SWPadnos> the loop constructs will depend on the changes in logicals, I'd bet
[00:26:10] <jmkasunich> this isn't the board channel, but since three is a quorum (I think), I move that we give Ken CVS access and ask him to commit his changes, doing the logical ops as a separate commit
[00:26:11] <rayh> I've never figured out what value the logicals would serve a part code anyway.
[00:26:23] <SWPadnos> they help in ending loops, for instance
[00:26:33] <rayh> aye
[00:27:15] <SWPadnos> also, for a program that uses variables, you can do something like "if VAR > 0.1 depth = 0.1 else depth = VAR"
[00:27:25] <SWPadnos> (for a max cut depth of 0.1)
[00:27:35] <jmkasunich> IOW, they are only needed if you have the flow control operations
[00:27:43] <SWPadnos> or variables
[00:28:02] <SWPadnos> but yes - the usefulness increases greatly with looping :)
[00:28:11] <jmkasunich> if/then/else is flow control
[00:28:29] <SWPadnos> true - my example was just a poorly coded min() function
[00:29:30] <jmkasunich> paul_c: care to comment on the motion?
[00:29:47] <paul_c> motion for ?
[00:30:07] <jmkasunich> * jmkasunich said: this isn't the board channel, but since three is a quorum (I think), I move that we give Ken CVS access and ask him to commit his changes, doing the logical ops as a separate commit
[00:30:20] <jmkasunich> ray said: aye
[00:30:28] <jmkasunich> which I think means "I second"
[00:31:08] <paul_c> considered it carried - with a second motion....
[00:31:34] <paul_c> Ken is encouraged to add a GPL notice to the files he has changed.
[00:31:47] <jmkasunich> takes three aye votes to pass (still need a majority of the board members, even if they're not here)
[00:32:08] <rayh> second
[00:32:13] <jmkasunich> aye
[00:32:22] <rayh> aye
[00:32:38] <paul_c> yes - Motion carried.
[00:32:55] <jmkasunich> re: gpl... you want that done in emc1 as well?
[00:33:39] <paul_c> regardless of where the files are committed, I feel GPL should be attached.
[00:33:46] <rayh> Perhaps paul could suggest the headers he might use.
[00:33:49] <jmkasunich> I kinda like that... prevent future use of the new interp features by copycats
[00:33:54] <jmkasunich> I second pauls motion
[00:34:07] <rayh> Add a line thanking Tom for his original work.
[00:34:30] <paul_c> It's not about copycats, more about getting access to any "bug" fixes.
[00:34:32] <rayh> You bet.
[00:35:06] <rayh> That ass ripped and flipped...
[00:35:06] <jmkasunich> that's an aye?
[00:35:53] <rayh> Sure hope he doesn't show at Roland's cnc-camp
[00:36:07] <jmkasunich> how do you guys feel about Steve Hardy using the interp for the G200x?
[00:36:28] <rayh> I might not have enough xanax to resist the urge to give him hell.
[00:36:50] <paul_c> thought S.H. was ust using the traj planner.
[00:36:51] <rayh> Compiled in would mean the whole thing is gpl.
[00:37:21] <Jymmm> rayh: "You have the right to remain silent. Though, you may not have the ability to" =)
[00:37:21] <jmkasunich> SH is using the interp, I believe - I think he's using the Mariss "moving average" algorithm as a planner
[00:37:49] <rayh> Jymmm: Exactly. Restraint is not my best act.
[00:38:12] <paul_c> That would make the planner GPL then (if he used the latest changes under GPL)
[00:38:13] <jmkasunich> rayh: it simply means that someone wanting to use the interp in non-GPL work would have to pull a CVS snapshot before Kens modifications were committed
[00:38:14] <rayh> Does it get linked?
[00:38:25] <paul_c> aong with the USB & tcp stack code..
[00:38:29] <rayh> True.
[00:38:53] <jmkasunich> huh? SH is using the PD interp...
[00:39:08] <paul_c> It's running on a Z80 - There is no way it can do memory management.
[00:39:21] <jmkasunich> put it this way.. if he isn't, he will when you try to tell him Rabbit's TCP stack is GPL
[00:39:57] <Jymmm> jmkasunich: Um, correct me if I'm wrong, but does the GPL have something along the line that basically says if you use gpl and distribute in binary form, that you just have to make available the source (which I think a url will cover that) ?
[00:40:11] <SWPadnos> I believe that the source code to Steve's version is in the tarball in the Gecko newsgroup files section
[00:40:12] <rayh> But does that mean that stuff passing through the stack must be infected.
[00:40:45] <Jymmm> s/does/doesn;t/
[00:41:58] <paul_c> It ends up being a very messy argument about what constitutes linking and other such issues.
[00:42:08] <jmkasunich> I dunno, but I also don't care... I don't want to get into a viral GPL argument
[00:43:03] <Jymmm> jmkasunich never was my intenion.
[00:43:21] <jmkasunich> Jymmm: I know...
[00:43:59] <jmkasunich> conclusions:
[00:44:06] <jmkasunich> 1) we give Ken CVS access
[00:44:12] <rayh> So we approved both Ken as developer, with staged commit and recommended gpl
[00:44:16] <jmkasunich> 2) we ask him to commit his changes
[00:44:26] <jmkasunich> 3) we ask him to make his code GPL
[00:44:36] <jmkasunich> which will apply GPL to the entire file(s)
[00:44:48] <paul_c> agreed on all three counts.
[00:44:54] <jmkasunich> non-GPL users will have to use the PD version prior to those commits
[00:45:29] <jmkasunich> ok, does anybody know his SF username? I'll add him right now
[00:45:47] <paul_c> Does he have one ?
[00:45:56] <jmkasunich> I nominate Paul to write the email telling him how we'd like him to commit and license his code
[00:46:06] <jmkasunich> dunno... I'll email him and ask
[00:46:39] <paul_c> * paul_c passes the buck to the President.
[00:47:13] <jmkasunich> you (and AFIAK only you) have looked at the code in question and can talk intelligently about it
[00:53:12] <paul_c> If it's all the same, I would rather the email came from Matt.
[00:53:46] <jmkasunich> ok (will you write up the tech part at least, then forward to matt?)
[00:55:52] <jmkasunich> IOW, what parts to commit separately)
[00:56:20] <paul_c> I reckon I can do that.... Remind me tomorrow.
[00:56:33] <jmkasunich> will do
[00:56:59] <jmkasunich> I'll take responsibility for getting Ken CVS access, including pointing him at the SF signup page if needed
[00:58:24] <jmkasunich> you know, we just set a precedent that may or may not be good... we just voted on whether to accept someone as a developer
[01:06:03] <rayh> Yes we did and I'll comment on that off this list.
[01:06:14] <jmkasunich> board channel, or board mail?
[01:06:34] <rayh> Right now?
[01:06:35] <jmkasunich> dinner time here, mail would be better for me
[01:06:42] <rayh> Okay.
[01:06:58] <jmkasunich> (could you also let me know travel plans - re: that AB stuff email)
[01:07:46] <paul_c> catch you all tomorrow.
[01:07:53] <jmkasunich> turns out there are three folks on SF named "Kenneth Lerman" (more likely ken just has three IDs)... I sent him an email asking which one I should make an emc developer
[01:07:56] <jmkasunich> bye paul
[01:08:02] <robin_sz> rayh: im confused .. why would you object to steve hardy using the emc interp at all?
[01:08:24] <SWPadnos> see ya Paul
[01:09:45] <robin_sz> I cant believe some of you lot somedays .. you get all "ooh GPL is the one true way" "its good to share" etc and when someoen goes and does just that, you go all "I'm going to give him hell"
[01:10:15] <jmkasunich> on that note
[01:10:22] <jmkasunich> jmkasunich is now known as jmk_dinner
[01:10:33] <SWPadnos> hold on robin - there wasn't any knowledge of whether the source was available or not
[01:10:46] <robin_sz> well you only have to go and look
[01:10:48] <rayh> * rayh is back
[01:10:58] <rayh> * rayh is back
[01:11:00] <SWPadnos> I know - but you can speculate before looking
[01:11:03] <SWPadnos> hi ray
[01:11:09] <rayh> Hey.
[01:11:16] <SWPadnos> really back, I see :)
[01:11:19] <rayh> * rayh brb
[01:11:27] <SWPadnos> that was quick
[01:11:31] <rayh> I'm using that ksirc and...
[01:11:38] <rayh> * rayh is away: rayh
[01:11:46] <rayh> Ah figured it out.
[01:12:01] <jmk_dinner> foo
[01:12:08] <jmk_dinner> having fun ray
[01:12:11] <SWPadnos> foo bar
[01:17:53] <robin_sz> SWPadnos: actually, what was said was "prevent future use of the new interp features by copycats" .. which is a weird concept in a gpl thing .. surely the whole idea is to spread the word/code .. more other GPL projects that build on this the better, no???
[01:19:00] <rayh> A bit of explanation.
[01:19:16] <rayh> We don't mind anyone using the code. That is the GPL.
[01:19:16] <SWPadnos> note the response: "It's not about copycats, more about getting access to any "bug" fixes."
[01:19:47] <rayh> But at least one user of the interp said there were bugs but refused to
[01:19:55] <rayh> say what or where they were.
[01:20:16] <SWPadnos> I interpreted john's statement as "... no copycats ... without them honoring the GPL"
[01:21:32] <robin_sz> well, I'm still confused by rays "I might not have enough xanax to resist the urge to give him hell."
[01:21:45] <gezr> does xanax help?
[01:21:58] <SWPadnos> calms the psyche (or so I hear :) )
[01:22:30] <robin_sz> but the guy has published all his stuff under GPL, so whats the problem?
[01:23:09] <SWPadnos> I think the problem is that ray didn't realize that the source was available when he made that statement (correct, ray?)
[01:23:17] <robin_sz> sigh ...
[01:24:52] <Jymmm> * Jymmm sends robin_sz viagra, prozac, xanax, and a tequilia sampler pack =)
[01:25:21] <Jymmm> (make that a SMALL tequilia sampler pack)
[01:25:48] <robin_sz> I just remember the ebo disaster
[01:25:50] <Jymmm> robin_sz: I jsut think there was some confusion is all.
[01:27:18] <rayh> * rayh is back
[01:33:55] <rayh> SWPadnos: My reference to restraining myself was regarding the other guy who
[01:34:11] <rayh> ripped our stuff and then refused to help us when he said our stuff had bugs.
[01:34:25] <robin_sz> that was mainly due to the way he was approached
[01:34:46] <SWPadnos> OK - it was a little ambiguous in this context
[01:34:48] <rayh> Um no.
[01:34:50] <robin_sz> shrug
[01:35:13] <robin_sz> ever phoned him up and asked him?
[01:35:21] <Jymmm> Sp, anyone use EMC by chance?
[01:35:30] <rayh> I've got copies of the initial contacts after the "This shit is buggy" post
[01:35:48] <rayh> It was a simple request for the nature of the bugs.
[01:35:50] <SWPadnos> not that I've seen
[01:36:05] <rayh> Yep.
[01:36:12] <rayh> I was the one who gave him the interp.
[01:36:28] <rayh> When he asked, the 6 axis was not even available.
[01:36:54] <Jymmm> Ya know, there are many ppl out there that say "this or that os a POS and has bugs", it doens't mean they're correct; could be envirment, setup, etc.
[01:37:00] <robin_sz> when I spoke to him, he just seemed to want to get on and didn't have time for arguments about random stuff ...
[01:37:04] <SWP_EMC> * SWP_EMC is away: "Trying ksirc"
[01:37:17] <rayh> I also gave it to Fred at imserv along with the stuff required to compile it under MS.
[01:37:26] <rayh> Fred at least thanked me.
[01:37:36] <robin_sz> fair enough
[01:37:51] <rayh> nuff of the past.
[01:37:59] <robin_sz> whenever ive asked for stuff from the other guy, iv got it .. no problem
[01:38:11] <SWP_EMC> * SWP_EMC is back
[01:38:24] <rayh> Yep and he was asked in a very polite way by Matt.
[01:38:46] <robin_sz> shrug
[01:38:50] <robin_sz> anyway ..
[01:39:03] <robin_sz> I just remember the ebo disaster ..
[01:39:15] <robin_sz> ffs, lets NOT wind up Steve Hardy
[01:39:18] <rayh> Okay. As do I. Whatchathinking?
[01:39:45] <robin_sz> most of his code is his own, the interp is pre-gpl
[01:39:57] <robin_sz> he doesnt have to release anyting under GPL
[01:39:58] <rayh> I know nothing!
[01:40:04] <robin_sz> but so far he has
[01:40:20] <rayh> GPL guarantees the right to public code.
[01:40:30] <robin_sz> not quite
[01:40:45] <rayh> But it also guarantees the right of return of public mods.
[01:41:00] <robin_sz> not quite either
[01:41:21] <robin_sz> but anyway
[01:41:25] <robin_sz> as i said
[01:41:26] <SWPadnos> it prevents any restriction on public mods
[01:41:34] <robin_sz> thats more like it
[01:42:03] <robin_sz> anyway .. steve hardy used a pre-gpl interpm and wrote the other 75% on his own
[01:42:10] <rayh> Public is the key.
[01:42:23] <SWPadnos> the finer point of that is that he can release under GPL, and NOT give the code to anyone except those who buy the product
[01:42:24] <robin_sz> hes under no obligation to release any code if he doesnt want to
[01:42:26] <rayh> And he is entitled to it all.
[01:42:35] <SWPadnos> but he can't *prevent* his customers from sharing the code they receive
[01:42:45] <robin_sz> well, he could ...
[01:42:55] <rayh> Certainly he can.
[01:42:57] <SWPadnos> right - if it were GPL, ...
[01:43:00] <robin_sz> he doesnt HAVE to release under GPL
[01:43:23] <robin_sz> and I DO want him to ...
[01:43:25] <rayh> He can release under his own copyright and do anything he wants with it.
[01:43:32] <robin_sz> exactly
[01:43:52] <Jymmm> s/copyright/license/
[01:43:54] <rayh> It matters not that much of it is not his original work.
[01:44:07] <SWPadnos> not in the legal sense, no
[01:44:22] <robin_sz> and the included stuff was PD anyway
[01:45:35] <robin_sz> anyway, I want to see that project release under GPL
[01:45:36] <rayh> If the revised interp is GPL, and he takes it and makes a product with it.
[01:45:48] <robin_sz> well, that would be different
[01:45:54] <rayh> Then he would have more obligation to us.
[01:46:01] <robin_sz> no
[01:46:11] <robin_sz> he would only have an obligation to his customers
[01:46:16] <robin_sz> none to us
[01:46:42] <rayh> But any customer is free to do whatever he wants with it.
[01:46:46] <robin_sz> correct
[01:47:01] <rayh> And the code as well as the bin is required.
[01:47:07] <robin_sz> correct
[01:47:10] <rayh> to be available.
[01:47:15] <robin_sz> to the customer
[01:47:49] <robin_sz> who is then free to give it to us
[01:47:53] <robin_sz> etc
[01:48:02] <robin_sz> anyway .. thats a technicality
[01:48:27] <Jymmm> http://www.gnu.org/licenses/gpl-faq.html
[01:48:28] <SWPadnos> there's at least one person here who wil lbe buying a G200X :)
[01:48:34] <robin_sz> true :)
[01:48:42] <robin_sz> infact I have 2 on order :)
[01:48:49] <SWPadnos> so I wouldn't worry about the availability of any GPL code :)
[01:48:56] <SWPadnos> are you going to fest?
[01:49:06] <robin_sz> well I do worry, incase it doesnt appear as GPL
[01:49:13] <robin_sz> nah, too far.
[01:49:22] <SWPadnos> if the current tarcavll is GPL, then there's no problem
[01:49:25] <SWPadnos> tarball
[01:49:50] <SWPadnos> OK - I may buy one to bring - just so a driver of some sort can be made
[01:50:17] <robin_sz> could be fun
[01:50:26] <SWPadnos> yes :)
[01:50:30] <robin_sz> mariss' design is not gpl of course
[01:50:41] <SWPadnos> of course, there may be too much "real work" to do
[01:50:56] <SWPadnos> true, but the general schematics are out there
[01:50:59] <robin_sz> true
[01:51:11] <robin_sz> of course you dont know what goes on in the fpga
[01:51:17] <robin_sz> its quite different
[01:51:45] <SWPadnos> It's not that hard to duplicate, except for the niggling details
[01:51:47] <robin_sz> and thats not been revealed, nor will it be,
[01:51:52] <robin_sz> just the API
[01:51:54] <rayh> It's been fun guys. Gotta run.
[01:52:01] <SWPadnos> see ya tomorrow
[01:52:07] <robin_sz> * robin_sz waves
[01:52:18] <SWPadnos> too late :)
[01:52:33] <robin_sz> interestingly, the G200X software loads the fpga
[01:52:55] <SWPadnos> true - that would be reverse-engineerable, but that's a sleazy path to take
[01:53:02] <robin_sz> so we will have access to the jtag bin
[01:53:08] <robin_sz> yeah
[01:53:37] <SWPadnos> The oepration of the FPGA is pretty simple, except for exactly duplicating the register interface
[01:53:42] <robin_sz> the truly sleazy way would be to just use the jtag bin anyway .. but that would be unethical
[01:53:48] <SWPadnos> which isn't necessary for a re-implementation of the control code
[01:53:55] <SWPadnos> yes indeed
[01:54:38] <SWPadnos> you'd also have to exactly duplicate the board connections, which might be hard to reverse-engineer, since it's really likely the board is 4 or 6 layer
[01:54:47] <robin_sz> in effect, the code loaded onto the rabbit will be the GPL'd code and the proprietary FPGA code
[01:55:05] <robin_sz> i expect it to be 2 layer
[01:55:23] <SWPadnos> Probably not with a many-pin TQFP
[01:55:30] <robin_sz> 100 pin
[01:55:44] <robin_sz> seen the jpegs?
[01:56:28] <SWPadnos> yeah - the top is way too clean for a 2-layer board
[01:56:41] <SWPadnos> but I could be wrong
[01:56:41] <robin_sz> in effect the GPL code can only really run on Mariss' board right now
[01:56:52] <robin_sz> but thats OK, as its cheap enough
[01:56:59] <SWPadnos> yeah - it's a steal
[01:57:16] <SWPadnos> at least, the one without USB or connectors
[01:57:34] <robin_sz> he seems to work on components * 4 for pricing
[01:57:45] <SWPadnos> that's about right
[01:57:50] <SWPadnos> *5 is common for many items
[01:58:11] <robin_sz> the fpga is sub $10
[01:58:24] <robin_sz> �4.80 in the UK
[02:00:25] <robin_sz> anyway ... all I care about is being able to get the boards cheap and get at the code to make ti do my thing
[02:00:25] <Jymmm> are you all talking about some gecko board?
[02:00:30] <robin_sz> yeah
[02:00:39] <SWPadnos> it's a controller for step/direction drivers
[02:00:50] <robin_sz> and IO
[02:01:01] <SWPadnos> yes - much I/O
[02:01:04] <robin_sz> and it has A-D and D-A
[02:01:28] <robin_sz> and it has 6 channels of directly accesible encoder input, with index pulses ..
[02:01:53] <Jymmm> and is the same code you've been discussing for the past hour or so?
[02:02:12] <SWPadnos> some of it, in one of the discussion threads
[02:02:37] <SWPadnos> but not the nastier thread, I believe
[02:02:39] <Jymmm> the access to CVS and hope he makes it GPL stuff?
[02:02:54] <robin_sz> that was Ken wotshisname and the interp mods
[02:03:15] <Jymmm> oh, so two different subject. nm
[02:03:19] <robin_sz> sorta
[02:03:40] <Jymmm> sorta?
[02:03:43] <robin_sz> the G200X code also uses a non-gpl version of the emc interp
[02:03:50] <SWPadnos> OK - there's a lot of history that isn't apparent in irc.
[02:03:57] <robin_sz> correct :)
[02:04:29] <Jymmm> Um, so emc started out at one point not being gpl?
[02:04:35] <robin_sz> yes
[02:04:46] <robin_sz> some may even say it still is non-gpl in places ;)
[02:05:10] <SWPadnos> the earlier code was public domain, because it was developed with government money
[02:05:31] <SWPadnos> which I think still applies to most of emc1
[02:05:38] <SWPadnos> (?)
[02:05:41] <Jymmm> and the g200x is based in part o the PD stuff?
[02:05:48] <SWPadnos> yes
[02:05:49] <robin_sz> yep
[02:05:51] <SWPadnos> (?)
[02:06:27] <robin_sz> theres some confusion in my mind how to place emc under GPL
[02:06:38] <Jymmm> and now you guys fucked it all up, made a zillion changes and hope the he bases his new board on the new code, but make it gpl?
[02:06:42] <robin_sz> new stuff, I can understand
[02:07:12] <robin_sz> but the old stuff, I dont see how anyone other than NIST can place that under GPL
[02:07:19] <SWPadnos> confusion as to how it would work, or why to do it?
[02:07:31] <SWPadnos> ok - how it works
[02:07:42] <Jymmm> PD is PD
[02:07:49] <robin_sz> right
[02:07:54] <SWPadnos> If I take a PD file, and make a change, I can license the entire file (with my changes) under the GPL
[02:08:04] <Jymmm> no
[02:08:12] <robin_sz> so, you are claining copyright on the entire file?
[02:08:13] <Jymmm> that's not entirely truew
[02:08:16] <SWPadnos> PD doesn't prevent me from licensing under whatever license I want (even unchanged)
[02:08:27] <Jymmm> SWPadnos not ture
[02:08:30] <robin_sz> well, not true
[02:08:35] <SWPadnos> but I can't prevent someone from grabbing a PD version (without my changes)
[02:08:40] <SWPadnos> absolutely true
[02:08:55] <robin_sz> to be effective, you have to claimn the copyright and then license others to use it under certain conditions
[02:09:07] <SWPadnos> Any customer would be stupid to buy from me, with my restrictive license, if they can also obtain it freely in PD
[02:09:40] <SWPadnos> I can't prevent the distribution of the file in the public domain, but I can charge for my "Gold Version" (that has my name in it)
[02:09:59] <Jymmm> If I grab a bunch of PD storys and compile them into a book, I can copyright the compilation.
[02:10:27] <SWPadnos> true, but you can't prevent someone from making an exact duplicate, from the original PD sources
[02:10:39] <SWPadnos> they just can't copy *your* book
[02:10:48] <robin_sz> I tink they can
[02:10:58] <robin_sz> because he cant claim the copyright
[02:11:09] <Jymmm> robin_sz: They can't, but who can tell the difference.
[02:11:14] <SWPadnos> Once I make changes (a derivative work), I can apply any license I want, as long as it's compatible with the license I originally received the work under
[02:11:15] <robin_sz> that is vested in the original author
[02:11:28] <SWPadnos> in this case, there are no restrictions on a PD work, so any license is compatible with it
[02:12:25] <robin_sz> I guess it depends on whther you make many chages .. I suspect the derivative work needs to have "some" or "substantial" mods .
[02:12:38] <SWPadnos> technically, you don't have to change it at all
[02:12:38] <Jymmm> robin_sz: A children's story can be PD, but If I make a website, that COLLECTION of PD content is now copyright me.
[02:12:42] <SWPadnos> look at this scenario:
[02:13:16] <SWPadnos> I make something and tell you ( robin_sz ) "you have nonexclusive rights to do absolutely anything you want with this code"
[02:13:34] <robin_sz> thanks :)
[02:13:54] <Jymmm> robin_sz except you can't read it =)
[02:13:59] <SWPadnos> You do nothing to it, and then tell Jymm "I give you nonexclusive right to use this code, but you must give me any changes you make"
[02:14:04] <SWPadnos> you're welcome
[02:14:08] <SWPadnos> (I'm such a nice guy)
[02:14:31] <SWPadnos> There is no conflict with the original license I gave you, because I said you can do anything with it
[02:14:47] <robin_sz> right
[02:14:57] <SWPadnos> However, you can't prevent me from calling Jymm and saying "you're an idiot - I'll give you that for free"
[02:15:01] <SWPadnos> :)
[02:15:23] <robin_sz> lets say Jymm decided to make changes and keep them secret and sell the binaries
[02:15:38] <Jymmm> * Jymmm then screws robin_sz license over because he said any changes *I* made, so I let other ppl make the changes.
[02:15:41] <SWPadnos> He can't do it with the file you gave him, but he can with the one I gave him.
[02:15:49] <robin_sz> I ring him up and he says "so sue me"
[02:15:54] <robin_sz> so i sue him
[02:16:02] <robin_sz> for breach of copyright
[02:16:09] <SWPadnos> technically, there would have to be at least one change - the addition of the GPL license notice
[02:16:19] <Jymmm> * Jymmm tells robin_sz "your momma!"
[02:16:32] <SWPadnos> * SWPadnos moves back to Mars
[02:16:42] <robin_sz> and I go to court and he says "so, when did you write this then"
[02:16:51] <Jymmm> * Jymmm says "I didn't"
[02:16:55] <robin_sz> and I say, "well I didnt"
[02:17:04] <robin_sz> and the judge dies laughing
[02:17:11] <SWPadnos> and you say "I obtained it under a non-restrictive license"
[02:17:17] <robin_sz> so,
[02:17:22] <Jymmm> * Jymmm then bribs the judge to slap robin_sz
[02:17:23] <robin_sz> doesnt make it my copyright
[02:17:32] <SWPadnos> "which I then modified before selling it for $1 million to Jymmm "
[02:17:54] <robin_sz> I guess it depends onhow "modified" it is
[02:18:06] <SWPadnos> well - you added the GPL notice, didn't you? :)
[02:18:14] <Jymmm> * Jymmm then reports SWPadnos to the DEA... becasue "He's on crack if he thinks I'm pating for free stuff"
[02:18:16] <robin_sz> probably insufficient
[02:18:20] <Jymmm> paying
[02:18:26] <SWPadnos> hey - I gave it to you
[02:18:28] <SWPadnos> (ingrate)
[02:18:50] <robin_sz> minor changes and "those parts that have to be there" arent copyrightable anyway
[02:18:59] <Jymmm> SWPadnos: then wth the $1M come into play? for the crack stupid! =)
[02:19:07] <SWPadnos> Look at the Qt dual license
[02:19:36] <robin_sz> so basically,
[02:19:49] <robin_sz> if the files are largely simlar to unmodified PD code
[02:19:58] <robin_sz> then they are probaly not GPL'd
[02:20:08] <robin_sz> regardless of the license header
[02:20:16] <robin_sz> but then it doesnt matter anyweay
[02:20:21] <SWPadnos> if they've never been released under GPL, then they're not GPL
[02:20:51] <Jymmm> The copyright holder can license their works any way they choose to, even in multiple ways. The difference is that PD doesn't not have a copyright owner.
[02:20:58] <SWPadnos> it would probably take a court case to decide for sure, but AFAIK it's perfectly fine to re-license PD code any way you want
[02:21:11] <robin_sz> so, the earier in the dev cycle we release emc2 code under gpl, the more chanegs it gets, so the mroe defendbel it gets
[02:21:21] <Jymmm> bbl DVD
[02:21:22] <SWPadnos> you only have that right for the file *you* have though - all the other copies are still PD
[02:21:41] <SWPadnos> probably
[02:21:52] <robin_sz> right
[02:21:54] <robin_sz> anyway
[02:22:05] <SWPadnos> clear as milky mud now? :)
[02:22:29] <robin_sz> so long as Steve Hardy does release his home-grown stuff under GPL, I'll be very very happy
[02:22:40] <SWPadnos> (one of the classes I attended at ESC was on using GPL code in embedded projects :) )
[02:22:48] <robin_sz> heh
[02:23:05] <SWPadnos> nobody seemed to disagree with my analysis, so it must be true :)
[02:23:34] <robin_sz> gpl in embedded is always going to be dangerous .. to gpl anyway
[02:23:47] <robin_sz> difficult to prove its in there msot times
[02:23:48] <SWPadnos> yes and no - there's always LGPL
[02:23:54] <SWPadnos> true
[02:24:29] <robin_sz> LGPL has a lot to recommend it for provifding well defined interfaces to stuff
[02:24:46] <robin_sz> helps draw a line
[02:24:50] <SWPadnos> yes
[02:25:12] <robin_sz> over here its gpl, over there .. do whatever you like
[02:25:32] <SWPadnos> right - you only have to publish any hooks you put in the GPL code
[02:25:51] <robin_sz> right
[02:26:09] <robin_sz> which is where the G200X and Ats code will become interesting ;)
[02:26:15] <robin_sz> Art's
[02:26:39] <SWPadnos> depends on where the Machx code is from
[02:26:55] <robin_sz> presumably Steve will either give art a non-gpl licence, or publish a LGPL api
[02:26:58] <SWPadnos> the interface between the G200X and the PC is pretty clear
[02:27:19] <SWPadnos> I think he sent an API description to the Gecko list
[02:27:23] <robin_sz> he did
[02:27:29] <SWPadnos> at least, the communications protocol
[02:27:41] <SWPadnos> then Art can make his own lib :)
[02:27:41] <robin_sz> you could always write a closed source app to the API
[02:27:48] <robin_sz> * robin_sz nods
[02:28:32] <robin_sz> I guess you could do the same to emc
[02:28:44] <robin_sz> make up your own nml header file ...
[02:28:51] <robin_sz> wirte a closed source gui
[02:29:24] <SWPadnos> as long as the app that sends NML messages doesn't have to include any GPL headers, that's pretty cut-n-dry
[02:29:38] <SWPadnos> otherwise it can be dicey
[02:29:47] <robin_sz> after all, thats what the Samba guys did with the smb protocol ;)
[02:30:38] <robin_sz> well, technically, a header file isnt "linked" into the final code ;))
[02:30:40] <SWPadnos> yes - if you start from documentation and write your own headers and libraries, it's pretty clearly not infringing
[02:30:45] <robin_sz> * robin_sz plays devils advocate
[02:31:03] <SWPadnos> that is a point of discussion
[02:31:08] <SWPadnos> I'd rather be coding
[02:31:10] <SWPadnos> :)
[02:31:12] <robin_sz> :)
[02:31:14] <robin_sz> too true
[02:31:31] <SWPadnos> I wish the FPSLIC chips weren't so darned expensive
[02:31:41] <robin_sz> shrug ...
[02:31:50] <robin_sz> what are they?
[02:32:05] <SWPadnos> AVR core with a FPGA fabric around them
[02:32:13] <robin_sz> coo
[02:32:29] <SWPadnos> but more expensive than a big Spartan or Cyclone - dumb
[02:32:31] <robin_sz> just buy a big spartan and throw a core in :)
[02:32:44] <SWPadnos> yep - there's an AVR core on opencores.org
[02:33:42] <robin_sz> only 40k gates on the fpslic
[02:33:57] <SWPadnos> big enough for a lot of stuff - like an extra 32-bit CPU
[02:34:17] <SWPadnos> (depending on how their cells compare to Altera)
[02:36:55] <SWPadnos> well - gotta run
[02:37:04] <SWPadnos> SWPadnos is now known as SWP_Away
[03:12:40] <A-L-P-H-A> quiet in here.
[03:50:58] <jmk_dinner> jmk_dinner is now known as jmk_away
[05:07:30] <gezr> hmm
[07:04:56] <Jymmm> boo
[07:13:03] <Jymmm> Jymmm is now known as CodesWithIdiots
[07:41:27] <CodesWithIdiots> CodesWithIdiots is now known as Jymmm
[11:10:58] <anonimasu> good morning
[11:30:45] <CIA-7> 03paul_c 07BDI build system * 10Babylon Cluster/qemccommand.cc: File changed. New revision:qemccommand.hh
[12:31:46] <anonimasu> hm..
[12:31:49] <anonimasu> this is strange
[12:41:16] <anonimasu> my program works with my connection to the box..
[12:41:20] <anonimasu> but not when I run it locally
[12:44:38] <paul_c> NML ?
[12:46:49] <anonimasu> nope
[12:46:56] <anonimasu> using the serial port..
[12:48:22] <anonimasu> might have to do with the fact that I havent closed the port.. properly
[12:53:44] <anonimasu> yep..
[12:58:10] <robin_sz> meep?
[12:59:14] <anonimasu> hello
[12:59:36] <robin_sz> is it hanging well?
[12:59:40] <anonimasu> not really
[12:59:45] <anonimasu> messing around with the serial port ;)
[12:59:47] <robin_sz> oh foo
[12:59:54] <robin_sz> I was up till 6am
[13:00:04] <robin_sz> sorting out servers after a power outage
[13:00:56] <anonimasu> ouch
[13:01:25] <robin_sz> one had just made it to years uptime too
[13:01:30] <robin_sz> 368 days
[13:03:12] <robin_sz> several had to be fsck'd
[13:03:31] <anonimasu> :)
[13:03:32] <robin_sz> one, I screwed up the raid configuration
[13:03:36] <anonimasu> ouch
[13:03:40] <anonimasu> * anonimasu did that recently too
[13:03:49] <robin_sz> well, we added a new scsi drive
[13:03:54] <robin_sz> copied the array
[13:04:15] <robin_sz> made changes to fstab and unplugged the old raid scsi's
[13:04:26] <robin_sz> everything perfect
[13:04:54] <robin_sz> except I forgot to run lilo again :( .. so it didn't know about the changes at bootitime .. still looke for the raid
[13:05:17] <anonimasu> :(
[13:06:42] <robin_sz> my bad
[13:07:07] <anonimasu> brb.. trying my code
[13:07:11] <robin_sz> 'k
[13:07:26] <robin_sz> * robin_sz reads about GSM encryption
[13:07:57] <robin_sz> seems it was written by the Swedish Chef
[13:08:53] <anonimasu> lol
[13:09:48] <robin_sz> because its bork bork borked :)
[13:10:35] <anonimasu> are you implying swedes suck at code?
[13:10:37] <anonimasu> ^_^
[13:10:42] <anonimasu> * anonimasu seconds that
[13:12:04] <robin_sz> remember, GSM uses the A5 algorithm .. implemented in hardware
[13:12:14] <robin_sz> so good even governments cant crack it
[13:12:32] <robin_sz> and, theyd prefer to keep its details secret
[13:12:42] <robin_sz> not that theres a back door, oh no.
[13:13:28] <robin_sz> some israelies have cracked it by analysis in .. 10ms :)
[13:18:13] <anonimasu> ^_^
[13:18:35] <anonimasu> hm this is strange
[13:19:12] <anonimasu> localhost:~/SERIAL# ./a.out
[13:19:13] <anonimasu> starting program loop.
[13:19:13] <anonimasu> :1
[13:19:13] <anonimasu> :1
[13:19:13] <anonimasu> :TEST
[13:19:21] <anonimasu> that should work locally too..
[13:20:02] <CIA-7> 03paul_c 07BDI build system * 10Babylon Cluster/qemccommand.cc: File changed. New revision:qemccommand.hh
[13:20:06] <anonimasu> * anonimasu sighs
[13:20:09] <anonimasu> this is getting annoyed
[13:20:41] <anonimasu> annoying
[13:21:10] <anonimasu> hm generating a unique key on gsm should be easy..
[13:21:34] <anonimasu> voice/backgroundnoise
[13:22:12] <robin_sz> the basic alogrithm A5, is weak
[13:23:00] <robin_sz> and since it has to implememted at both ends of the call
[13:23:07] <robin_sz> its hard to change to soemting better
[13:23:29] <anonimasu> yep
[13:23:32] <anonimasu> http://www.dia.unisa.it/professori/ads/corso-security/www/CORSO-9900/a5/Netsec/netsec.html#chap31
[13:23:46] <anonimasu> you could crack it in realtime.. almost with a fpga..
[13:24:29] <robin_sz> 10ms apparetnly
[13:25:01] <anonimasu> yep..
[13:25:10] <anonimasu> they talked in that paper that you couldnt do it in realtime..
[13:25:13] <robin_sz> http://www.gsm-security.net/faq/gsm-a5-broken-security.shtml
[13:25:46] <anonimasu> yeah..
[13:25:49] <robin_sz> I tink the correct term is "cracked black and blue"
[13:25:57] <Phoebe> hi all
[13:25:59] <anonimasu> but it depends
[13:26:05] <robin_sz> hi Phoebe
[13:26:08] <robin_sz> on?
[13:27:02] <robin_sz> all you need is signal acquisition, which is not hard, and a PC ...
[13:27:16] <anonimasu> on how you crack it..
[13:27:16] <anonimasu> :)
[13:27:48] <robin_sz> moving on ..
[13:28:24] <robin_sz> just been drawing up eagle libraries for the G200X :)
[13:32:09] <anonimasu> nice
[13:32:11] <anonimasu> :)
[13:32:22] <anonimasu> I dont understand this :[
[13:32:29] <anonimasu> this program works when I run it remotely
[13:32:33] <anonimasu> but not when I run it locally
[13:32:35] <robin_sz> uh huh
[13:32:38] <anonimasu> on the same box..
[13:32:47] <robin_sz> and?
[13:32:51] <anonimasu> it just grabs data off the serial port and prints it out,..
[13:33:04] <anonimasu> when I run it via a ssh session it works nicely..
[13:33:08] <anonimasu> but not locally on the box
[13:33:19] <robin_sz> gotta be enviroment vars
[13:33:34] <anonimasu> printf() should work.. anyway..
[13:33:42] <anonimasu> but it might be the xterm eating the output..
[13:35:07] <robin_sz> perhaps the printf() thing is new and not fully tested yet ;)
[13:35:32] <anonimasu> lol
[13:35:34] <anonimasu> yeah
[13:41:28] <anonimasu> hm weird.
[13:42:39] <anonimasu> hm seems to lock up once I write to the port.
[14:02:50] <anonimasu> I found out the error.
[14:10:13] <Phoebe> hi all, excuse me! who come from china as same as me?
[14:12:07] <anonimasu> I dont think anyone in here is from china
[14:13:35] <Phoebe> I am come from china
[14:13:42] <Phoebe> sorry
[14:13:47] <Phoebe> I come from china
[14:14:27] <anonimasu> :)
[14:14:46] <Phoebe> :)
[14:14:49] <Phoebe> nice to meet u
[14:16:19] <anonimasu> Nice to meet you too
[14:16:27] <anonimasu> Are you interested in CNC?
[14:16:57] <Phoebe> yes
[14:17:09] <Phoebe> and I am just a newbie
[14:17:24] <Phoebe> install it yestody
[14:17:28] <anonimasu> :)
[14:19:26] <Phoebe> It is still a long way to study it
[14:19:39] <robin_sz> many years :)
[14:19:52] <A-L-P-H-A> morning folks.
[14:20:49] <Phoebe> now it's evening in china :P
[14:21:15] <A-L-P-H-A> Phoebe, gotta be evening somewhere. :) but it's morning here :)
[14:21:39] <A-L-P-H-A> somehow I doubt you're in China though. :)
[14:21:55] <Phoebe> why?
[14:22:00] <SWP_Away> A-L-P-H-A: bzzzt - wrong! :)
[14:22:06] <A-L-P-H-A> he really is?
[14:22:12] <SWP_Away> so s/he says
[14:22:15] <A-L-P-H-A> he/she/it
[14:22:45] <A-L-P-H-A> SWP_Away! :) I game out on top last night.
[14:22:53] <SWP_Away> Great!
[14:22:56] <SWP_Away> what?
[14:23:00] <SWP_Away> nevermind :)
[14:23:10] <A-L-P-H-A> pok(h)er. :)
[14:23:40] <SWP_Away> excellent - well, I'm still away - see ya :)
[14:23:49] <A-L-P-H-A> 1.) tourney, 3rd out. 2.) Came in 2nd place. 3.) Tied 1st, so we split the pot.
[14:24:46] <anonimasu> why do you doubt that?
[14:24:55] <anonimasu> * anonimasu got this working
[14:25:03] <anonimasu> now I just need to write good routines to send nml messages..
[14:25:14] <anonimasu> easily
[14:25:20] <A-L-P-H-A> nml?
[14:25:53] <A-L-P-H-A> NML is an acrhonym to a porno series...
[14:26:25] <Phoebe> good night everyone! see you next time
[14:26:37] <A-L-P-H-A> bye Phoebe. :)
[14:27:17] <Phoebe> bye all :)
[14:27:36] <anonimasu> goodnight Phoebe
[14:27:49] <anonimasu> if you have any trouble ask here and somone usually will be able to help you out
[14:28:41] <Phoebe> ok,thanks. now I have something to do. see you next time
[14:28:54] <Phoebe> maybe I will come back soon :P
[14:36:27] <alex_joni> greetings
[14:38:44] <stevestallings> morning alex
[14:39:10] <alex_joni> hey steve
[14:39:15] <alex_joni> how's it going?
[14:39:56] <stevestallings> life is busy lately, getting ready to exhibit at NAMES
[14:40:18] <alex_joni> cool.. what are you going to exhibit?
[14:41:03] <stevestallings> PMDX is my company, break-out boards, motor drivers etc., usually have EMC, Mach2, and TurboCNC running in my booth
[14:41:25] <alex_joni> nice
[14:41:32] <anonimasu> hey alex
[14:41:36] <anonimasu> how's it going?
[14:41:39] <alex_joni> I just had a fair last week (welding stuff)
[14:41:43] <alex_joni> hey anders
[14:41:43] <alex_joni> pretty good
[14:41:45] <alex_joni> quiet day today
[14:41:58] <alex_joni> but I got some family business I gotta take care of
[14:42:05] <anonimasu> I've gotten the serial part of my program working and I'll soon add the nml stuff..
[14:42:10] <alex_joni> so I'll be back a while later
[14:42:15] <alex_joni> an0n: nice
[14:51:55] <alex_joni> * alex_joni is going to be back later
[14:52:59] <anonimasu> while ( TRUE ) { // enter the realm of the inifinite loop and leave the rest to the sigint handler
[14:57:14] <anonimasu> ^_^
[15:03:34] <rayh> brb coffee run
[15:03:49] <stevestallings> good idea
[15:07:58] <rayh> Hi Steve.
[15:08:40] <stevestallings> um, coffee good, better w/donut 8-)
[15:10:15] <robin_sz> and a beagle
[15:11:01] <stevestallings> yea, but donuts are an excellent delivery system for my drug of choice, sugar....
[15:11:25] <rayh> So is my coffee.
[15:12:30] <stevestallings> looks like the CodeFest will have some lively sessions this year
[15:13:14] <robin_sz> yeah
[15:13:17] <robin_sz> and remembver
[15:13:26] <stevestallings> hopefully I will be able to get back from NAMES early enough to be there from the start
[15:13:26] <robin_sz> no bare knuckles, only gloves
[15:14:33] <rayh> no pistols at sunrise NIST has a policy.
[15:15:05] <stevestallings> I expect more public interest in the proceedings this year. Is there any way to stream audio, or at least tape it?
[15:15:06] <robin_sz> sounds fair
[15:15:19] <robin_sz> yeah
[15:15:21] <robin_sz> many :)
[15:15:25] <rayh> Well tape should be easy.
[15:15:32] <robin_sz> I suggest asterisk for audio
[15:15:58] <robin_sz> let them call in :)
[15:16:11] <rayh> Streaming AV is something I know nothing about.
[15:16:18] <robin_sz> audio is easy
[15:16:30] <robin_sz> just set it up as a conference room on asterisk ..
[15:16:35] <robin_sz> I have asterisk servers running
[15:16:51] <robin_sz> people connect with a VOIP client
[15:17:01] <robin_sz> either listen-only
[15:17:07] <robin_sz> or as contributors
[15:17:44] <robin_sz> requires ~3kbs between client and swerver
[15:18:24] <rayh> The outbound from NIST should not be a bandwidth problem.
[15:18:37] <stevestallings> Conference bridges are sound weird enough, adding VOIP must make it really fun.
[15:19:04] <robin_sz> works fine
[15:19:07] <rayh> They have some fairly strict policy
[15:19:14] <robin_sz> who do?
[15:19:19] <rayh> NIST
[15:19:23] <robin_sz> on?
[15:19:47] <rayh> subnet and connection out.
[15:20:05] <stevestallings> Perhaps we can stream audio out and have IRC live for inbound questions.
[15:20:10] <robin_sz> well, if you can get a voip connection, its sorted
[15:20:17] <robin_sz> tje server will handle all the clients
[15:20:28] <stevestallings> Few people have VOIP setup at home.
[15:21:00] <robin_sz> they dont need to
[15:21:16] <robin_sz> all they need is the ability to click on a web page
[15:21:24] <robin_sz> I have an activeX client
[15:21:39] <robin_sz> or they can instal firefly in about 2 minutes
[15:21:40] <stevestallings> activeX on Linux?
[15:21:49] <robin_sz> no one has linux at home ;)
[15:22:19] <robin_sz> ive not got any of the linux based voip clients to work
[15:22:23] <robin_sz> all seem broken
[15:22:35] <robin_sz> the doze ones just work straight out of the box
[15:23:22] <robin_sz> dont you just hate it when that happens??
[15:23:46] <robin_sz> thers is always VAT if you are brave
[15:24:04] <robin_sz> Visual and Audio conferencing Tool
[15:24:08] <stevestallings> I must note that it was not Steve Stallings that is talking windows here....
[15:24:18] <jmk_away> noted
[15:24:25] <jmk_away> jmk_away is now known as jmkasunich
[15:24:42] <robin_sz> used by several universities on linux etc for remote clasroom type stuff
[15:25:14] <stevestallings> JMK - scroll back, I opend a bag of worms for you, proposed streaming audio and IRC access for the public to our CodeFest at NIST
[15:25:51] <robin_sz> if its for a discussion session, say 2hrs or so, i think it would be fun
[15:25:54] <rayh> * rayh phone
[15:26:05] <robin_sz> but listening to coders coding ... nah.
[15:26:23] <robin_sz> <scratch scratch> <slurp> <fart>
[15:27:03] <jmkasunich> I saw that... I am all in favor of IRC, but personally I have no use whatsoever for voice, nor am I competent to set it up... my boxes don't even have sound cards
[15:27:20] <stevestallings> perhaps an hour of scheduled interaction each day?
[15:27:51] <stevestallings> absent audio, someone will have to be the "logger" and type fast
[15:28:30] <stevestallings> or maybe the attendees could all go live on IRC while at NIST
[15:28:38] <paul_c> Steve's keyboard skills are legendary...
[15:29:14] <jmkasunich> my problem with audio: I've been in plenty of phone conferences at work... I'm one of those folks who can't communicate without drawing pictures, so audio only doesn't work very well... the reason for the Fest is to allow face to face interaction
[15:29:38] <stevestallings> legendary typos....
[15:30:59] <Imperator_away> Imperator_away is now known as Imperator_
[15:31:14] <Imperator_> Hi all
[15:31:19] <jmkasunich> hi Martin
[15:32:24] <jmkasunich> that does bring up another item for fest
[15:32:40] <jmkasunich> last year there was a large tablet of paper that much interesting stuff got written on
[15:33:01] <jmkasunich> once fest was over, it vanished
[15:33:05] <Imperator_> Hi John
[15:33:29] <stevestallings> most digital cameras today can do a decent job of capture
[15:33:56] <jmkasunich> that's the first step... second step is to either post the pics, or transcribe them and post the info
[15:34:29] <jmkasunich> I'm willing to bet that the paper from last year did _not_ get trashed, but it never got transcribed and posted
[15:34:46] <stevestallings> well since I cannot do much in the way of coding, I will try to capture info for the web site
[15:35:00] <Imperator_> is it possible to record some speeches ?
[15:35:06] <robin_sz> sure
[15:35:08] <jmkasunich> I think I can bring a digital camera
[15:35:09] <stevestallings> I left early and have no idea where the table went.
[15:35:20] <stevestallings> tablet
[15:35:32] <stevestallings> great typos, hey?
[15:35:34] <jmkasunich> robin_sz: you bringing the recorder?
[15:36:57] <robin_sz> jmkasunich: I think I was answering a different question
[15:37:31] <jmkasunich> I thought you were answering Imperator: is it possible to record speeches
[15:37:45] <Imperator_> :-)
[15:38:04] <robin_sz> no, I was just agreeing with stevestallings
[15:38:23] <jmkasunich> Imperator_: I don't have the equipment to record things, but if somebody else want's to volunteer.....
[15:38:31] <robin_sz> laptop?
[15:38:55] <robin_sz> stright to .wav or mp3
[15:39:04] <Imperator_> a 64kbit mono mp3 file is good enough for speeches, i think
[15:39:04] <jmkasunich> not me
[15:39:15] <robin_sz> more than enough
[15:39:22] <robin_sz> 16k ...
[15:39:28] <jmkasunich> I might have a laptop with me, dunno yet... but it doesn't have audio recording software on it
[15:39:47] <Imperator_> a good microfone is needed
[15:40:03] <Imperator_> a external one
[15:40:25] <stevestallings> at least two mics, one for speaker, plus conference mike for table
[15:40:50] <Imperator_> jep, that would be perfect
[15:41:37] <Imperator_> I can spend the webspace to make it public
[15:41:42] <jmkasunich> still need a volunteer to provide and set up that stuff
[15:42:51] <jmkasunich> sorry, I have a bias against audio... horrible data transfer medium... strictly serial access, like a tape drive, impossible to skim the information
[15:43:44] <Imperator_> shure, but good to get a fealing what was realy going on
[15:43:47] <jmkasunich> doesn't convey drawings, sketches, or people pointing to things
[15:43:55] <stevestallings> JMK - can you investigate the issues with IRC and/or streaming audio access from NIST networks
[15:44:19] <Imperator_> streaming video :-)
[15:44:31] <jmkasunich> I can ask Fred... I suspect IRC will be no problem, and I for one will have an IRC window open pretty much full time
[15:44:56] <paul_c> * paul_c removes the first presentation from the agenda...
[15:45:00] <stevestallings> well, IRC is what has brought most of the developers together so far
[15:45:19] <Imperator_> but useles for a conference
[15:45:48] <Imperator_> only if somebody types everything in :-)
[15:46:24] <paul_c> jmkasunich: Can we borrow a couple of girls from the typing pool
[15:46:52] <jmkasunich> you'd need stenographers at the rate we'll likely be talking
[15:47:09] <jmkasunich> and don't be caught calling them "girls" either
[15:47:20] <paul_c> "Young ladies"
[15:47:25] <narnia> jmkasunich, just get a couple court reporters. ;-)
[15:47:37] <stevestallings> perhaps we should try to see who is really interested in "consuming" the remote access
[15:47:51] <stevestallings> it may be that only a few people would, and IRC could work
[15:48:00] <Imperator_> here is one !
[15:48:18] <jmkasunich> if somebody actually wants to participate, that would need a conference call of some sort
[15:48:23] <narnia> stevestallings, i will probably be using irc. i was hoping to attend but that is looking doubtful.
[15:48:37] <Imperator_> maybe some importand speeches can be recorded to video
[15:49:56] <stevestallings> the most important "speechs" are often the ones that were not planned, and the camera operator is likely to be too caught up in what is happening to capture the video 8-)
[15:51:33] <paul_c> not sure I want to be videod....
[15:51:55] <jmkasunich> video is also a massive bandwidth hog for later distribution
[15:52:26] <jmkasunich> and just like streaming audio, it is one-way...
[15:52:35] <Imperator_> have enough bandwidth
[15:55:28] <rayh> Good discussion
[15:56:06] <rayh> Is there any way to chunk up IRC and make it available for part time IRC readers.
[15:56:31] <jmkasunich> was thinking about that... something like an IRC to webpage bot
[15:57:15] <rayh> Since Steve and I will be sitting in the back row, perhaps we can put together a highlights set of pages for linuxcnc.org.
[15:57:22] <stevestallings> that would solve our problems with posting IRC logs regularly in the general case, not just for the Fest
[15:57:23] <Imperator_> what about alex's logger
[15:57:45] <jmkasunich> as for one-way audio and/or video, I have little personal interest in it and am too busy/underqualified to set it up, but I will cooperate with folks who want to do the work
[15:58:12] <jmkasunich> two-way audio (teleconferencing, conference call) would be nice, IMO, it would let remote people actually participate in the discussions
[15:58:16] <rayh> Paul and I can slip over to NIST on Friday before if some things need to be tested.
[15:58:16] <paul_c> * paul_c woud rather not have video/audio recordings...
[15:58:52] <rayh> I'm thinking that we subnet all of our machines and use a single router to NIST.
[15:58:57] <jmkasunich> paul_c: code is like sausage, better not to see how it's made?
[15:59:08] <jmkasunich> rayh: NIST doesn't want it done that wa
[15:59:11] <jmkasunich> way
[15:59:22] <jmkasunich> they will assign static IPs to each participant
[15:59:23] <stevestallings> video is unrealistic, what about pre-arranged audio "statement" captured periodically?
[15:59:27] <jmkasunich> no DHCP
[15:59:48] <rayh> But that does not eliminate a router.
[15:59:56] <jmkasunich> if it's a "statement", it could be typed as easily as spoken
[15:59:58] <rayh> It only means that we are all static.
[16:00:14] <stevestallings> can we run a DHCP server behind one of the assigned static IP's?
[16:00:31] <jmkasunich> don't know what you are getting at Ray
[16:00:40] <rayh> We would not need to If each box in the door takes a number
[16:00:57] <jmkasunich> stevestallings: they don't want that... if something bad gets sent out from one of our boxes, they want to know _exactly_ who did it
[16:01:34] <jmkasunich> they don't want bad stuff going out onto the inet as a whole that appears to have come from within NIST
[16:01:58] <rayh> I favor asking Matt to work out the network details with whomever Fred points him to.
[16:02:11] <stevestallings> make sure you get name server IP for us also
[16:02:22] <stevestallings> DNS
[16:02:30] <jmkasunich> Matt because he's closer? I've already talked to Fred about some of this
[16:03:00] <rayh> Yes. Seems to me face-to-face is clearer.
[16:03:16] <rayh> NIST has to be doing this all the time.
[16:03:24] <rayh> With links all over the globe.
[16:03:24] <jmkasunich> keep me in the loop
[16:03:36] <jmkasunich> time for food...
[16:03:45] <jmkasunich> jmkasunich is now known as jmk_breakfast
[16:04:06] <paul_c> * paul_c notes the time is 16:15 (ish)
[16:04:16] <rayh> paul_c: Why did you remove the first item from the monday list?
[16:04:39] <stevestallings> doesn't want to be recorded?
[16:04:46] <rayh> Brunch or brupper.
[16:05:31] <rayh> Ah. Well we can certainly turn the AV stuff off during that.
[16:05:43] <rayh> If we wind up with av stuff at all.
[16:06:01] <stevestallings> looking less likely....
[16:06:08] <rayh> I've no doubt but that we need wider input than those of us in the same room.
[16:06:31] <robin_sz> well, a voip conference is fine for that
[16:06:35] <robin_sz> users authenticate
[16:06:36] <rayh> The trick is to provide distant participants the essential stuff so they can contribute.
[16:07:03] <rayh> We can easily snap images and post to a site.
[16:07:03] <robin_sz> just ask for people who wish to take part to email a user/pass pair before the meeting
[16:07:12] <rayh> and connect them into html for viewing.
[16:07:23] <robin_sz> then its sort of open, but not just broadcast
[16:07:33] <robin_sz> that may satisfy the NIST peepl
[16:08:08] <stevestallings> I think we need to identify the "consumers" and ask if they will actually be available "real time" and what they are equipped to support
[16:08:09] <rayh> So one thing we want the committee of jmk and matt to do is ask about voip.
[16:08:49] <robin_sz> "anyone wishing to participate, download firefly from <here> email in your usernam, well' give you a password"
[16:09:53] <rayh> Will paul_c permit voip?
[16:10:06] <rayh> for his part
[16:10:25] <robin_sz> what is "his part" ??
[16:11:20] <robin_sz> I keep losing track of the schedule
[16:11:47] <rayh> The monday BDI directions and 2.6 info presentation.
[16:12:02] <rayh> I really don't want to loose that.
[16:12:05] <robin_sz> doesnt sound particularly secretive
[16:12:59] <rayh> I don't think secretive was the issue. I think becoming a tv star was closer.
[16:13:31] <robin_sz> fat chance. i suspect you'll get half a dozen people, maximum listening remotely
[16:15:26] <rayh> paul_c: Hey. Will paul_c permit voip during his presentation?
[16:15:56] <paul_c> voip is crap from what I've heard of it
[16:16:53] <robin_sz> fsck it then, lets not bother
[16:17:21] <paul_c> "we send you free hone, all you is ive ank etails..."
[16:17:39] <stevestallings> back to small steps, lets work on making IRC useful
[16:17:40] <rayh> ifndef voip ->
[16:17:49] <paul_c> (might be a crap connection from India..)
[16:18:11] <rayh> Might be crap connection from the U.P. 'eh.
[16:18:36] <paul_c> 4B/day isn't enough bandwidth..
[16:19:22] <robin_sz> stevestallings: irc can be runs as moderated, might work OK, if someone could type fast enough
[16:20:01] <robin_sz> just have to "give voice" to ppl from time to time
[16:20:03] <paul_c> robin_sz has never heard Fred talk...
[16:21:14] <robin_sz> never will at this rate
[16:22:03] <SWP_Away> SWP_Away is now known as SWPadnos
[16:23:23] <stevestallings> fast talk about complex issues will make IRC a limited way to participate, but if there is real interest on the part of a remote, I think some interaction could be possible
[16:25:21] <stevestallings> perhaps the screen of the IRC host at the Fest could be projected at all times so the people at Fest could see traffic live
[16:26:06] <SWPadnos> Does anyone have access to a SmartBoard?
[16:27:19] <stevestallings> NIST has all kinds of goodies, but not likely in the room we will be using.
[16:27:37] <SWPadnos> can we "liberate" one for the Fest? :)
[16:28:31] <stevestallings> again, before we commit lots of effort, we need to identify consumers and their ability to interact in real time
[16:28:49] <SWPadnos> The smartboard a llows capture of drawings on a whiteboard
[16:29:06] <SWPadnos> the data is a serial file which can be saved, copied, and played back later
[16:30:36] <robin_sz> is there a particpants/exhibitors list for NAMES yet?
[16:31:01] <stevestallings> NAMES or CodeFest?
[16:31:09] <robin_sz> NAMES
[16:32:43] <robin_sz> was wondering who the CNC participants might be
[16:33:10] <robin_sz> I take it the no-mains-power nonsense has been sorted in advance this time??
[16:33:28] <stevestallings> They seem to let you assume that vendors will be "similar" to prior years. Catalog is published at last minute. Their webmaster has quit.
[16:33:32] <rayh> Roland F says that cnc could have what used to be the Detroit Metalworking booth.
[16:33:55] <rayh> Only one, what they call a 20 amp circuit.
[16:34:24] <robin_sz> but thats been guaranteed in advance, after the last debacle??
[16:34:46] <rayh> That's a #16 extension cord plugged into a 15 amp duplex outlet connected to a 20 amp breaker a half mile away.
[16:35:20] <rayh> Three years ago I heated my coffee on the one running Rolands mill.
[16:35:28] <robin_sz> heh
[16:35:48] <robin_sz> it was last year when it all went tits-up wasn't it??
[16:35:48] <rayh> I'm not going to be there at all. Steve will be and has generously offered to share his
[16:35:56] <rayh> cord and a table.
[16:36:00] <stevestallings> Vendors that I expect - Sherline, IMServ (Vector), PMDX (me), Smithy ?
[16:36:43] <rayh> They "retired" the guy who was pushing CNC and helping Roland.
[16:37:00] <stevestallings> and I am still waiting to see if anyone will demo EMC, I can bring machine but need someone to run it
[16:37:02] <rayh> Next year the show moves to Ohio
[16:37:31] <rayh> I'll be in DC during NAMES.
[16:39:07] <robin_sz> so the CNC presence at NAMES will be smaller, and limited to commercial vendors?
[16:39:29] <robin_sz> no CNC fest @ names as such?
[16:39:46] <rayh> No.
[16:40:03] <rayh> We will need to figure out a mechanism for board election.
[16:40:20] <jmk_breakfast> jmk_breakfast is now known as jmkasunich
[16:40:22] <stevestallings> correct, the local guys usually demo some hands on machine, one has a small CNC mill running KellyCAM
[16:40:28] <rayh> I favor a list vote.
[16:41:50] <stevestallings> worked well enough last time
[16:42:33] <rayh> We can put that one off a bit.
[16:42:35] <robin_sz> heh, from the NAMES site:
[16:42:36] <robin_sz> The NAMES Board is not taking new memberships and not renewing old memberships for the time being.
[16:42:46] <robin_sz> sounds like they are fscked
[16:43:05] <stevestallings> rigid old blood doesn't like new ideas
[16:43:24] <robin_sz> sounds like its dead or dying
[16:44:04] <stevestallings> I think it will continue, but there is likely to be some turnover.
[16:44:27] <jmkasunich> * jmkasunich is catching up
[16:44:35] <jmkasunich> board elections should be on list, IMO
[16:44:47] <jmkasunich> (like last year)
[16:45:55] <robin_sz> why not just continue as you are?
[16:47:00] <rayh> cause " rigid old blood doesn't like new ideas"
[16:47:20] <stevestallings> easy to continue, just re-elect the same people
[16:47:44] <robin_sz> whatvere
[16:48:54] <robin_sz> the board doesn't seem to affect normal users in anyway
[16:49:08] <robin_sz> I suggest whoever it is on it just continues
[16:49:15] <jmkasunich> robin is an agitator
[16:49:28] <robin_sz> actually, ive even forgotten who is on it ...
[16:49:39] <SWPadnos> The last election was around August - is there some impetus to have another one before that time this year?
[16:49:47] <jmkasunich> ray, paul, matt, jon elson, me
[16:50:13] <jmkasunich> I asked that question on the board list in Jan... was met by deafening silence
[16:50:19] <stevestallings> no intent to move up, just a history of "electing" a president during the "Fest"
[16:50:41] <robin_sz> I cant remember reading much interaction between the mailing list and the users or dev list ...
[16:50:47] <stevestallings> I would propose that the election of a president be rolled into the regular election
[16:50:57] <SWPadnos> OK - I joined just after the call for votes went out, so I don't know any history behind that :)
[16:50:58] <jmkasunich> I agree with steve
[16:51:37] <stevestallings> This years "Fest" is looking like it will be smaller than last years, and it will focus more on technical issues.
[16:51:51] <SWPadnos> In the context of EMC, what do the board and president do?
[16:51:54] <jmkasunich> definitely
[16:52:02] <jmkasunich> not much
[16:52:22] <SWPadnos> well - I can do that :)
[16:52:27] <robin_sz> without wishing to be provocative ... ;)
[16:52:34] <SWPadnos> (yeah, right)
[16:52:45] <robin_sz> the biggest amount of board releated traffic Isaw on the dev list ..
[16:52:47] <robin_sz> was ...
[16:52:49] <robin_sz> the election
[16:52:56] <jmkasunich> that's about it
[16:53:04] <stevestallings> http://linuxcnc.org/EMC_news_history/Board-election.html - read near bottom of page
[16:53:26] <rayh> IMO this is not a top down org.
[16:53:27] <SWPadnos> there's the super secret board IRC channel and list as well - who knows what goes on behind "closed electrons" ;)
[16:53:47] <jmkasunich> again not much
[16:54:04] <jmkasunich> the archives of the board list are available to all registered developers
[16:54:05] <robin_sz> so, I presume the people doing it are happing doing it?
[16:54:56] <stevestallings> well the idea is to encourage participation, not stagnation
[16:55:12] <jmkasunich> another reason for annual elections... the existing members can decline nomination if they want to stop doing it
[16:56:51] <jmkasunich> the role of the board could stand to be re-examined
[16:57:43] <robin_sz> well, why not just have the usual thing they do at clubs ... ask if the committee are happy to continue, ask for any objections, job done
[16:57:45] <rayh> * rayh remembers long heated discussions re this. I think that's a reflection of your lack of enthusiasm for any kind of control.
[16:58:00] <jmkasunich> me?
[16:58:01] <rayh> We did succeed in refusing the offer of money from a commercial vendor.
[16:58:05] <rayh> Yea
[16:58:52] <jmkasunich> * jmkasunich tries to remember the details of that
[16:58:55] <rayh> I thinki saying "not much" ignores the needed guidance for things like ebo and Keith and others.
[16:59:10] <jmkasunich> I don't think I ever knew all the details
[16:59:15] <robin_sz> refusing money? coo. another success :)
[16:59:17] <rayh> Like I say this is not a top down org.
[16:59:28] <rayh> But any org needs some coordination.
[16:59:59] <jmkasunich> saying "not much" doesn't mean there isn't much to be done, just that we haven't been doing it
[17:00:12] <jmkasunich> look at the traffic (or lack thereof) on the board list
[17:00:17] <paul_c> * paul_c slips another Apis Mellifera under Ray's hat ;)
[17:00:27] <rayh> * rayh aka grandpa needs to participate in an easter egg hunt. Be back
[17:01:20] <jmkasunich> dang... he does that a lot... stirs the pot and then leaves
[17:01:28] <robin_sz> heh
[17:01:45] <SWPadnos> boil boil toil and trouble
[17:01:51] <paul_c> I'll bring a few ropes with me next month..
[17:01:59] <robin_sz> I originally thought the board would pilot the emc2 development
[17:02:01] <SWPadnos> checked baggage only
[17:02:13] <robin_sz> it seems not to have happened
[17:02:34] <robin_sz> so development effrot has been not as directed as it might have been
[17:03:20] <jmkasunich> some of the EMC2 lack of progress is my fault... I have been unable to motivate myself to do serious coding for several months... real life and all keep interfering, so EMC related tasks I set for myself are untouched
[17:03:33] <robin_sz> that I can understand
[17:03:44] <alex_joni> greetings
[17:03:49] <jmkasunich> hi alex
[17:03:55] <alex_joni> hey John
[17:04:09] <alex_joni> did I miss anything?
[17:04:21] <jmkasunich> yeah
[17:04:34] <alex_joni> darn ;)
[17:04:39] <robin_sz> unless a positive decision is made to set emc1 to bugfixes only and concentrate on emc2, its never going to get going
[17:04:43] <jmkasunich> lots of discussion about the Fest, and some about the board's role
[17:04:51] <alex_joni> ahhh
[17:04:57] <alex_joni> robin: I agree
[17:05:09] <alex_joni> but interp. changes could be part of emc1
[17:05:22] <alex_joni> what I think is necessary is take emc2 to the level of emc1
[17:05:34] <alex_joni> then you can focus on development from there
[17:05:50] <SWPadnos> Certain parts should be shared - can CVS/sf do that (ie, one copy of the interpreter, used by both projects)?
[17:05:56] <robin_sz> alex_joni: no, I disagree, if emc1 is always up to date, then there no incentive to move on
[17:06:03] <alex_joni> SWP: don't think so
[17:06:13] <SWPadnos> OK
[17:06:49] <stevestallings> do I hear candidates for the board? 8-)
[17:06:56] <jmkasunich> you do
[17:07:09] <jmkasunich> I've already warned alex that I intend to nominate him
[17:07:36] <SWPadnos> jmkasunichray, paul, matt, jon elson, me
[17:07:44] <SWPadnos> (me being you :) )
[17:07:51] <jmkasunich> that is the existing board
[17:07:58] <SWPadnos> heh - you noticed :)
[17:08:14] <jmkasunich> ??
[17:08:50] <robin_sz> so, election papers go out to all the developer and user lists?
[17:08:55] <jmkasunich> yes
[17:09:11] <jmkasunich> nominations are open to all members of both lists, as is voting
[17:09:30] <jmkasunich> nominees can decline before the ballots go out
[17:09:32] <robin_sz> perhaps there should be a minimum return
[17:10:05] <robin_sz> like 20% ...
[17:10:15] <jmkasunich> last year, 369 ballots were sent, 22 bounced, 58 valid ones returned
[17:10:23] <alex_joni> * alex_joni thinks last years voting was ok
[17:10:36] <jmkasunich> ~16%
[17:10:39] <robin_sz> that was the first vote right?
[17:10:41] <jmkasunich> not very impressive
[17:10:43] <jmkasunich> yes
[17:10:45] <alex_joni> I expect more returns than last year
[17:10:52] <robin_sz> I expect less
[17:11:13] <SWPadnos> There will be one more from me :)
[17:11:29] <jmkasunich> if the board did more (good or bad) that was visible to the EMC community at large, it might be more... as it is, I'm afraid robin might be right
[17:12:22] <robin_sz> I think last year, people voted because, well, it was someting new
[17:12:39] <jmkasunich> probably the best way to increase turnout would be for the board to do something very public that pisses a lot of people off ;-)
[17:12:45] <robin_sz> this year, I suspect they will consider it an irrelevance. sorry.
[17:13:10] <SWPadnos> heh - you could close off access to EMC1 ;)
[17:13:34] <robin_sz> no
[17:13:39] <robin_sz> as a money making venture
[17:13:48] <robin_sz> publish a emc board naked calendar ;)
[17:13:49] <SWPadnos> well - it *would* piss off a lot of people :)
[17:13:50] <jmkasunich> maybe next year ;-) EMC2 needs a few more drivers
[17:13:55] <SWPadnos> eeewwww
[17:14:02] <jmkasunich> eeewwwww^2
[17:14:04] <SWPadnos> I know - I need one of them
[17:14:39] <jmkasunich> which one?
[17:14:47] <robin_sz> the calendar, silly.
[17:14:50] <SWPadnos> Pico-systems USC
[17:15:08] <SWPadnos> I'm working on it, but it takes a while to understand everything around it
[17:15:17] <robin_sz> coo.
[17:15:22] <rayh> I'm hiding my eyes while they hide the eggs. I think the board did some serious work be existing.
[17:15:23] <jmkasunich> your coming to fest, right? we'll write it there (I have a USC board too)
[17:15:38] <SWPadnos> Yep - I'll be there
[17:15:49] <SWPadnos> Do you also have a GSI (Gecko Servo Interface)?
[17:15:53] <jmkasunich> I thought grandpa was supposed to hide the eggs and the grandkids search
[17:16:04] <robin_sz> really?
[17:16:05] <jmkasunich> no, just the USC
[17:16:07] <alex_joni> SWP: what's a GSI ?
[17:16:13] <robin_sz> I thought you hid the kids and eat the eggs
[17:16:15] <SWPadnos> (Gecko Servo Interface)?
[17:16:19] <rayh> Modern role reversal. Happens more and more often.
[17:16:28] <alex_joni> yes..
[17:16:28] <alex_joni> what does it look like?
[17:16:29] <SWPadnos> It buffers encoder signals and manages gecko faults
[17:16:35] <robin_sz> mmmm .
[17:16:39] <alex_joni> mmmm .
[17:16:40] <SWPadnos> it's on http://www.pico-systems.com
[17:16:48] <robin_sz> so a but liek a G200X then ;)
[17:16:54] <jmkasunich> it's a Pico systems thing, goes between geckos and the USC board
[17:16:56] <SWPadnos> you get full DRO, even when the geckos are de-powered
[17:17:12] <rayh> I built one machine with gecko servo drives and won't build another.
[17:17:18] <SWPadnos> (so a fulat can shut off the geckos, but any motion will still be tracked)
[17:17:22] <SWPadnos> fault
[17:17:27] <jmkasunich> not really robin... the USC is kinda like the G200x, the GSI is just an encoder power supply and signal splitter
[17:17:35] <SWPadnos> rayh: what didn't you like?
[17:17:43] <alex_joni> rayh: why not?
[17:17:54] <rayh> The second I built with rutex.
[17:18:13] <jmkasunich> what didn't you like about the Gecko?
[17:18:16] <rayh> Don't get me wrong. I like gecko and mariss
[17:18:30] <robin_sz> price and facilities, GPL
[17:18:36] <rayh> A fault and you start over.
[17:18:42] <SWPadnos> it is too bad that he doesn't make a higher voltage / current drive
[17:18:51] <rayh> Absolutely.
[17:18:55] <SWPadnos> that's what the GSI fixes :)
[17:19:15] <robin_sz> the G200X will do all that
[17:19:16] <alex_joni> rayh: I used a gecko G340 with a DRO board to emc
[17:19:21] <rayh> I was using 600 watt motors and had a bitch of a time making the system happy.
[17:19:26] <SWPadnos> There's a problem with e-stop anyway
[17:19:34] <alex_joni> a LS7166 counter board (emc2-driver available)
[17:19:42] <alex_joni> and the encoder feedback went to both
[17:19:51] <rayh> With the rutex drive I had exactly the opposite problem.
[17:20:11] <rayh> I left 24 volt to the rutex and killed motor supply.
[17:20:12] <robin_sz> thats what the G200X will do, seperate encoder inputs, should allow recovery with wteppers too
[17:20:30] <rayh> The first time I estopped and ran an axis a way by hand.
[17:20:54] <rayh> Turned the power back on and mega motion back to the place before estop.
[17:21:22] <robin_sz> rayh: luck the tool hadnt moved down
[17:21:23] <jmkasunich> that's the problem with having one PID loop in the software and another in the drive... they don't play nice together
[17:21:49] <alex_joni> jmk: I fully agree
[17:21:54] <rayh> The rutex advantage of remembering all the pulses is a real one.
[17:22:08] <alex_joni> but you can make the SW PID less stiff
[17:22:11] <rayh> You don't have to keep homing.
[17:22:35] <robin_sz> Im pretty hopeful the G200X will drive the PID loop directly, it has encoders and D->A channels, so its do-able already
[17:22:36] <jmkasunich> one way to address that - when the drives are off and you move the axis by hand, make EMC update it's position command to match the feedback
[17:23:03] <rayh> But with step and direction, emc does not see the pulses.
[17:23:14] <rayh> Vlad is working on that with the SPI stuff.
[17:23:21] <SWPadnos> it does see the encoder motion
[17:23:21] <jmkasunich> you need to split the encoder signals and send them back to emc as well as to the drive
[17:23:26] <rayh> But I don't think the update is fast enough.
[17:23:45] <SWPadnos> you need hardware to track it - that's what the USC does
[17:23:52] <SWPadnos> (or the G200x or the rutex...)
[17:24:16] <rayh> Or just use full servo with EMC
[17:24:37] <jmkasunich> right - that would be my choice
[17:24:46] <rayh> Mine also.
[17:25:12] <rayh> How about that -- jmk and rayh agreeing on something.
[17:25:19] <alex_joni> * alex_joni disagrees
[17:25:23] <jmkasunich> lol
[17:25:24] <rayh> Note the time and date.<g>
[17:25:30] <alex_joni> my choice would be full servo with EMC2 :D
[17:25:44] <jmkasunich> well mine too... that goes without saying
[17:25:46] <rayh> Yes to alex as well.
[17:25:55] <alex_joni> right...
[17:25:56] <alex_joni> now
[17:26:06] <alex_joni> I have a question I can't really answer
[17:26:19] <alex_joni> wft is missing from emc2 to have it production ready?
[17:26:26] <jmkasunich> drivers
[17:26:27] <SWPadnos> USC driver :)
[17:26:28] <rayh> That is why I favor some board action to collapse some of the layers in the venn diagrams that I see with the current branch and module situation.
[17:26:30] <alex_joni> or at least emc1 compliant
[17:26:35] <alex_joni> besides drivers
[17:26:51] <robin_sz> docs ;)
[17:26:59] <jmkasunich> yes
[17:27:07] <rayh> I see the aunt tillie as a straw man.
[17:27:07] <rayh> Here.
[17:27:55] <rayh> EMC-2 is much harder to configure but with options comes complexity.
[17:27:55] <alex_joni> there are a lot of nice features that can (and probably will) get implemented
[17:27:55] <rayh> We just need to develop the tillie configurator.
[17:27:55] <jmkasunich> HAL config is different, more flexible
[17:27:55] <alex_joni> like configurator, kbuild & such
[17:27:55] <SWPadnos> the infrastructure should support both superprogrammers and aunt tillies
[17:28:07] <alex_joni> SWP: did I get the chance to talk to you about kbuild?
[17:28:24] <SWPadnos> not really - I looked at your mods though - they look good
[17:28:34] <alex_joni> I think a 'make xxxxconfig' would do the trick
[17:28:39] <SWPadnos> (not ideal, since kbuild ins't meant for this, but still good)
[17:28:43] <alex_joni> the kbuild file will eventually get nasty
[17:28:44] <rayh> Absolutely. The kbuild screen does not look like your average point-n-click wizard
[17:28:51] <alex_joni> rayh: but it could
[17:28:59] <alex_joni> I thought about the following
[17:29:02] <jmkasunich> my opinion: "make foo" should not be used for Aunt tillie configuration
[17:29:08] <rayh> But it should let the most of us have access to the essential info and variables.
[17:29:11] <jmkasunich> make is for programmers, not spinster Aunts
[17:29:20] <alex_joni> use a switch: CONFIG_FOR_AUNT_TILLIE
[17:29:24] <alex_joni> if it's enabled
[17:29:28] <SWPadnos> there are two configuration problems - one for compiling, and one for configuring the machine connections
[17:29:36] <alex_joni> the user is presented with defaults, and with minimal options
[17:29:41] <rayh> kbuild hids the make. And in the case of ini should be completely hidden.
[17:29:56] <SWPadnos> kbuild is part of the make - it doesn't hide it
[17:30:07] <alex_joni> if not.. then the more advanced user (definately not a programmer) can access more options
[17:30:39] <SWPadnos> Since the config files will still be text (probably), a superprogrammer can always change things, given sufficient documentation
[17:30:56] <alex_joni> sure
[17:31:15] <jmkasunich> I'm afraid I've fallen way behind in this discussion
[17:31:16] <alex_joni> SWP: if right commented, you can have an average programmer to do that
[17:31:20] <robin_sz> gah
[17:31:25] <alex_joni> jmk: try the kbuild stuff
[17:31:28] <SWPadnos> sure - a "tech-savvy person"
[17:31:30] <alex_joni> and let us know what you think
[17:31:39] <jmkasunich> how do I do that?
[17:31:44] <paul_c> If only an uberprogrammer can manage configs (with the aid of a manual) something is seriously wrong.
[17:31:45] <SWPadnos> branch from emc2: auto_configure_0_2
[17:31:45] <alex_joni> it's in a emc2-branch somewhere
[17:31:47] <alex_joni> :D
[17:31:59] <robin_sz> why did jon elson do his servo drives as pwm input? +-10 would have quadrupled his market
[17:32:14] <SWPadnos> not that it's necessary - only that a savvy person can manage text file editing
[17:32:17] <rayh> * rayh phone
[17:32:18] <alex_joni> jmk: check out the branch, and follow instructions in the kbuild file
[17:32:35] <jmkasunich> cause he's not selling amps on the general market... his other products don't have DACs, they have PWM outputs
[17:32:42] <alex_joni> robin: how about both?
[17:32:46] <SWPadnos> it's best if you have the ability to do 'make xconfig' for the kernel
[17:32:46] <jmkasunich> (handy cause they only need 5V supply, no analog)
[17:34:02] <jmkasunich> * jmkasunich flails around with CVS
[17:34:30] <SWPadnos> try cervisia if you hate CVS command line
[17:34:43] <alex_joni> yeah.. or turtoise *grin*
[17:34:49] <robin_sz> ;)
[17:34:52] <jmkasunich> I prefer command line... just don't recall the command to check out a branch
[17:34:58] <alex_joni> -r
[17:35:05] <jmkasunich> cd emc
[17:35:06] <jmkasunich> oops
[17:35:08] <robin_sz> alex_joni: do you like tortoise then?
[17:35:09] <SWPadnos> checkout -r auto_configure_2 emc2
[17:35:17] <alex_joni> co -r auto_configure_0_2 emc2
[17:35:18] <A-L-P-H-A> turtoise again? :)
[17:35:20] <SWPadnos> checkout -r auto_configure_0_2 emc2
[17:35:26] <A-L-P-H-A> yumminess in a halfshell. :)
[17:35:32] <robin_sz> :)
[17:35:36] <alex_joni> robin: I gotta like it.. it's the one that does :ext:
[17:35:48] <robin_sz> yeah
[17:35:53] <robin_sz> its pretty flexible
[17:37:09] <jmkasunich> ls
[17:37:20] <alex_joni> ll
[17:37:22] <SWPadnos> nothing to ls here :)
[17:37:47] <alex_joni> try /ls
[17:37:54] <alex_joni> should work on IRC
[17:37:55] <alex_joni> ;)
[17:38:10] <jmkasunich> typing it in the right window works even better
[17:38:17] <SWPadnos> I've noticed that :)
[17:38:18] <alex_joni> usually
[17:38:31] <jmkasunich> ok, checkout done
[17:38:50] <SWPadnos> have you run make xconfig for the kernel on this box (ever)?
[17:39:18] <jmkasunich> no - this box is a BDI-TNG install... Aunt Tillie should never have to mess with kernel config tools
[17:39:35] <SWPadnos> that's true - but this is a Work In Progress :)
[17:39:36] <jmkasunich> (when it comes to building kernels, I _am_ Aunt Tillie)
[17:39:56] <SWPadnos> What kernel version ?
[17:40:15] <jmkasunich> 2.4.18-rtai
[17:40:34] <SWPadnos> OK - you won't have kbuid then.
[17:40:39] <SWPadnos> kbuild, that is
[17:40:49] <alex_joni> SWP: why not?
[17:40:54] <jmkasunich> strike one
[17:40:59] <SWPadnos> It was intorduces in the 2.5 series
[17:41:02] <SWPadnos> introduced
[17:41:12] <alex_joni> hmmm
[17:41:17] <SWPadnos> the new BDI is 2.6 based, so it has the 2.6 kernel
[17:41:19] <alex_joni> worked for me
[17:41:24] <alex_joni> on 2.4.21
[17:41:28] <SWPadnos> and the build tools, but not the qt libs
[17:41:30] <alex_joni> the kbuild stuff
[17:41:36] <alex_joni> without qt
[17:41:41] <alex_joni> I did the make menuconfig stuff
[17:41:46] <SWPadnos> hmmm - I thought it was introduced around 2.5.20 or so
[17:42:10] <robin_sz> jon's boards look neat
[17:42:28] <robin_sz> http://www.pico-systems.com/smallpwm.html
[17:42:33] <rayh> Kbuild will not work on tng.
[17:42:35] <robin_sz> but what a lot of hand wiring ...
[17:42:43] <rayh> They use a tk front end there.
[17:43:39] <jmkasunich> these kind of dependencies and incompatibilities are why I can't get excited about GUI config tools and would rather stick with text
[17:44:01] <alex_joni> mconf Kconfig
[17:44:24] <SWPadnos> OK - maybe it was just the qt front end that was from 2.5
[17:44:31] <jmkasunich> bash: mconf: command not found
[17:44:42] <alex_joni> you need to copy that from the kernel source dir
[17:44:45] <SWPadnos> jmkasunich: the idea is that you can use text or graphical tools, and we only write one configuration "master file"
[17:44:55] <alex_joni> read the beginning of Kconfig
[17:45:03] <alex_joni> SWP explained it thouroughly there
[17:45:12] <jmkasunich> where is Kconfig?
[17:45:19] <SWPadnos> /usr/src/<kernel version>/scripts/kbuild/mconf and libkconfig.so
[17:45:29] <alex_joni> Kconfig is in the root dir
[17:45:36] <alex_joni> of the branch you just checked out
[17:45:41] <jmkasunich> never mind, I was being dense
[17:46:00] <jmkasunich> less Kconfig
[17:46:03] <jmkasunich> dammit
[17:46:14] <SWPadnos> heh
[17:46:28] <SWPadnos> try it with 2 or 3 keyboards too :)
[17:47:22] <alex_joni> * alex_joni has 2 keyboards
[17:47:36] <SWPadnos> mconf probably has a dependency that libkconfig.so needs to be in the directory ../../scripts/kconfig (relative to where mconf is run)
[17:47:41] <jmkasunich> only one here (most of the time) but I have a KVM switch
[17:48:33] <Jymmm> * Jymmm has half a kybd --> http://web.mit.edu/atic/www/images/keyboards/halfkeyboard.JPG
[17:48:40] <SWPadnos> I was running with 2 or 3 sets of kb/mouse, with 3 monitors on one machine, one of which was switched for another machine, and then the EMC machine with its 800x600 LCD - it definitely got confusing at times
[17:48:58] <alex_joni> lol
[17:49:13] <SWPadnos> now I have cygwin/X, and all is good
[17:49:17] <SWPadnos> (except for Windows)
[17:49:19] <rayh> I've also fought this dependencies issue and favored tk but I'm leaning hard toward qt.
[17:49:26] <alex_joni> ssh -X :)
[17:49:51] <alex_joni> I had no problem with libkconfig.so :-?
[17:49:58] <SWPadnos> ssh -Y
[17:50:17] <Jymmm> ssh -Z
[17:50:27] <SWPadnos> ot: how can I get a graphical login using a remote X server?
[17:50:36] <SWPadnos> (to log into a KDE session, for example)
[17:50:40] <Jymmm> SWPadnos: since when On topic?
[17:50:49] <SWPadnos> Know anyone using EMC?
[17:50:52] <rayh> I tried taking the executable qconfig and moving it to live and that didn't work.
[17:51:09] <Jymmm> * Jymmm uses E=mc2 all the time
[17:51:23] <alex_joni> Jymmm uses emc2 .. nice
[17:51:24] <SWPadnos> no - qconf, mconf, conf, and gconf all use libkconfig.so - and the text mode tools expect it to be in a very specific location
[17:51:58] <SWPadnos> hence the PITA instructions in the Kconfig file
[17:51:59] <rayh> Right. It is a tool for the 2.6 kernel.
[17:52:36] <SWPadnos> well - mconf and conf just want it in ../../scripts/kconfig
[17:55:04] <Jymmm> Just curious, any of you use/have an EDM machine?
[17:55:19] <robin_sz> yes, used one
[17:55:25] <alex_joni> * alex_joni plans to build a control for one
[17:55:37] <Jymmm> robin_sz: does it cut clean?
[17:55:42] <robin_sz> perfectly
[17:55:50] <Jymmm> robin_sz no finidhing work needed?
[17:55:53] <Jymmm> finishing
[17:55:58] <robin_sz> nope
[17:56:07] <robin_sz> not for most things
[17:56:17] <Jymmm> robin_sz: how thick can you go?
[17:56:28] <robin_sz> on the machine I used, say 200mm
[17:56:32] <alex_joni> pretty thick.. but slooooow
[17:56:41] <jmkasunich> SWP, alex: I just redid the CVS checkout (I think I fscked it up the first time)
[17:56:43] <Jymmm> 1 IPM ?
[17:56:50] <robin_sz> hell no
[17:56:52] <alex_joni> heh
[17:56:54] <rayh> * rayh lunch with fam. Nice time guys.
[17:56:58] <alex_joni> 1 week / job
[17:57:08] <jmkasunich> the instructions say make new dirs in emc2/src/scripts
[17:57:11] <SWPadnos> happens to me all the time (the CVS thing)
[17:57:14] <alex_joni> bye ray
[17:57:17] <jmkasunich> there is no emc2/src/scripts
[17:57:19] <jmkasunich> bye ray
[17:57:21] <robin_sz> 1"/hour or less in thick stuff
[17:57:25] <alex_joni> emc2/scripts
[17:57:46] <jmkasunich> consider that a bug report ;-)
[17:57:49] <Jymmm> robin_sz: how is it on SS ?
[17:57:54] <robin_sz> perfect
[17:58:55] <Jymmm> robin_sz: do you have to contact the electric company before setting one up?
[17:59:01] <robin_sz> no
[17:59:05] <robin_sz> uses little power
[17:59:15] <robin_sz> like 500w or less
[17:59:21] <robin_sz> I tink
[17:59:33] <alex_joni_> it uses pulses
[17:59:44] <alex_joni_> but low avg power
[17:59:52] <robin_sz> couple of kw avg ??
[17:59:55] <robin_sz> at most?
[18:00:30] <robin_sz> and buy plenty of de-ioniser ;)
[18:00:40] <Jymmm> robin_sz but only works on conductive material, correct?
[18:00:41] <jmkasunich> ok, my box has no /usr/src/linux/scripts/kbuild directory
[18:00:45] <robin_sz> correct
[18:00:57] <alex_joni_> jmk: bummer... no linux kernel source?
[18:01:09] <SWPadnos> It's kconfig
[18:01:12] <jmkasunich> dunno... it's a BDI, it has what it has
[18:01:15] <alex_joni_> or is it not configured?
[18:01:15] <alex_joni_> if you have the kernel source
[18:01:20] <jmkasunich> another bug in the doc then ;-)
[18:01:24] <alex_joni_> go to /usr/src/linux
[18:01:26] <alex_joni_> and run make menuconfig
[18:01:38] <alex_joni_> that should build the executables
[18:02:00] <SWPadnos> I have it open - I'll commit a change once you get it running ;)
[18:02:07] <jmkasunich> anyway I don't have kbuild or kconfig in /usr/src/linux/scripts
[18:02:19] <jmkasunich> so trying alex's recommendation
[18:02:26] <alex_joni_> did you run 'make menuconfig' in /usr/src/linux ?
[18:02:32] <jmkasunich> not yet
[18:02:39] <SWPadnos> yes - you do need to have run a kernel make (something)config
[18:02:42] <jmkasunich> it isn't gonna affect my kernel config is it?
[18:02:53] <SWPadnos> just don't save
[18:02:57] <alex_joni_> nah
[18:03:02] <alex_joni_> you run that command
[18:03:10] <alex_joni_> and the kernel config will come up
[18:03:12] <jmkasunich> ok, in /usr/src/linux
[18:03:16] <alex_joni_> you can kill it with Ctrl-C
[18:03:21] <alex_joni_> to be absolutely sure
[18:03:27] <alex_joni_> or exit with don't save changes
[18:03:28] <SWPadnos> well - be careful - the configurators create output as ./.config
[18:03:40] <jmkasunich> failed
[18:03:45] <SWPadnos> so wherever you run it, you could screw something up
[18:03:59] <jmkasunich> it tried to "rm -r include/asm" and got permission denied
[18:04:05] <alex_joni_> what failed?
[18:04:06] <SWPadnos> kernel make menuconfig failed?
[18:04:21] <jmkasunich> make menuconfig in /usr/src/linux
[18:04:34] <alex_joni_> hmmm.. make menuconfig should NOT fail
[18:04:36] <SWPadnos> you may have the kernel tree read-only
[18:04:46] <alex_joni_> make modules_install is the only one you might need to run sudo
[18:04:46] <jmkasunich> very first thing it tried to do was "rm -f include/asm"
[18:04:52] <robin_sz> I suspec there might be some element of being root involved
[18:04:53] <alex_joni_> the others not...
[18:05:03] <alex_joni_> yeah
[18:05:03] <alex_joni_> try running it in sudo
[18:05:03] <jmkasunich> I'm not root right now
[18:05:16] <robin_sz> coo
[18:05:16] <alex_joni_> sudo make menuconfig
[18:05:16] <Jymmm> robin_sz: I find it ironic that a laser is like .003" and a spark is more like .001" AND can be controlled better than a laser.
[18:05:17] <jmkasunich> I don't like the fact that the first thing it tried to do was delete a directory tree
[18:05:44] <robin_sz> Jymmm: incorrect analysys
[18:05:57] <alex_joni_> jmk: hang on a moment
[18:06:08] <SWPadnos> include/asm is a symlink to the correct arch asm directory
[18:06:15] <SWPadnos> so it removes and recreates it first
[18:06:17] <alex_joni_> * alex_joni_ is looking at the kernel Makefile
[18:06:22] <Jymmm> robin_sz: The lasers I've seen using a 2" lens give a .003" beam
[18:06:32] <robin_sz> yes
[18:06:51] <alex_joni_> jmk: yes to SWP
[18:06:57] <alex_joni_> should be safe ;)
[18:07:07] <alex_joni_> it's under the symlinks rule in the Makefile
[18:07:14] <Jymmm> robin_sz: http://www.engineersedge.com/edm.shtml
[18:08:00] <robin_sz> where did you get "spark 0.001" from??
[18:08:04] <jmkasunich> ok, trying again with "su -c"
[18:08:19] <robin_sz> the wire is around .020 thick
[18:08:20] <SWPadnos> try sudo
[18:08:49] <jmkasunich> too late (I have sudo configed to allow only certain things, make menuconfig isn't one of them)
[18:08:52] <Jymmm> robin_sz: then how are they getting .0005 ?
[18:08:58] <robin_sz> the laser and the edm canboth be controlled to the same level of accuracy
[18:09:08] <SWPadnos> OK - you know better than I :)
[18:09:12] <alex_joni_> jmk: only make needs to be configured
[18:09:16] <robin_sz> you are confusing accuracy with tool size
[18:09:24] <jmkasunich> I have a menu, now I exit without saving?
[18:09:40] <Jymmm> robin_sz: ah, maybe I am.
[18:09:43] <alex_joni_> bottom option
[18:09:54] <SWPadnos> Jymmm: that was .0005 inches per inch - so a 30" part is .0005*30 = .015
[18:10:03] <alex_joni_> jmk: go to exit
[18:10:03] <robin_sz> edm has the advantage of no HAZ
[18:10:11] <alex_joni_> it will ask if you want to save
[18:10:14] <robin_sz> but, its slow
[18:10:15] <alex_joni_> or not
[18:10:20] <jmkasunich> bottom option is "save config to an alternate file"
[18:10:22] <alex_joni_> alex_joni_ is now known as alex_joni
[18:10:33] <SWPadnos> just exit, and answer no to the save changes prompt
[18:10:41] <Jymmm> robin_sz: Heh, faster than be cutting by hand =)
[18:10:49] <Jymmm> s/be/me/
[18:10:51] <robin_sz> but not as accurate :)
[18:10:56] <jmkasunich> ok, done
[18:11:03] <Jymmm> robin_sz wanna bet? lol
[18:11:14] <SWPadnos> OK - now go back to the (buggy) directions in Kconfig
[18:11:22] <robin_sz> edm has its uses, but they are fairly special
[18:11:37] <robin_sz> its not mass production, thats for sure
[18:11:41] <Jymmm> sound great for SS sheet
[18:11:46] <robin_sz> mmm
[18:11:47] <jmkasunich> one of them is confusing me while I try to follow SWP and alex's directions
[18:11:49] <robin_sz> no
[18:11:59] <SWPadnos> jmkasunich: which?
[18:12:08] <robin_sz> typically the maximum area is 200mmx200mm .. or less
[18:12:10] <jmkasunich> the EDM thread is confusing me
[18:12:24] <SWPadnos> yes. robin_sz and Jymmm quiet, please :)
[18:12:36] <jmkasunich> the instructions say to copy the kbuild (or kconfig) stuff from /usr/src/linux/scripts
[18:12:40] <SWPadnos> yes
[18:12:45] <jmkasunich> but there is still nothing like that in that dir
[18:12:53] <alex_joni> wanna go to another channel?
[18:13:17] <jmkasunich> I was gonna msg, but don't know how to have three people
[18:13:17] <SWPadnos> what subdirs do you have in scripts/ ?
[18:13:37] <jmkasunich> cramfs, ksymoops, lxdialog
[18:13:45] <alex_joni> use /join #emc-install-kconfig
[18:13:52] <SWPadnos> well - lxdialog is the one, I'd bet
[18:14:20] <SWPadnos> hmmm - I didn't mean to get rid of robin...
[18:23:04] <alex_joni> and Jymmm
[18:23:12] <SWPadnos> yeah
[18:23:20] <SWPadnos> oh well - I guess I'm the asshole today
[18:23:58] <alex_joni> well.. don't think it was you ;)
[18:24:14] <SWPadnos> heh
[18:38:06] <alex_joni> ok...
[18:38:08] <alex_joni> back here
[18:38:19] <jmkasunich> damn... I thought I did a /part before you could kick me
[18:38:35] <SWPadnos> Maybe a nice configurator would be an impetus for people to use EMC2?
[18:38:43] <alex_joni> I have my logger started (pretty much all the time)
[18:38:43] <alex_joni> lol
[18:38:43] <alex_joni> I even kicked me
[18:38:43] <alex_joni> that was amusing
[18:38:44] <alex_joni> SWP: my thoughts too
[18:38:53] <jmkasunich> there is that
[18:39:22] <jmkasunich> but we _must_ decide what systems we are going to support (kernels, etc) and then make something that works on _ALL_ those systems
[18:39:22] <SWPadnos> There were discussions about how far back EMC2 should work (like kernel 2.2 / 2.4)
[18:39:26] <SWPadnos> yes
[18:39:37] <jmkasunich> if we decide to abandon 2.2, so be it, but we need to decide that as a group
[18:40:12] <SWPadnos> There are a lot of changes between 2.2 and 2.4 (also 2.4 and 2.6) - it may be difficult to support all three
[18:40:44] <SWPadnos> at least, in a non-confusing way (I hate code that's full of #if VERSION<2.2, fo this #else do that)
[18:40:52] <jmkasunich> I still think that any computer capable of handling the realtime load of running a machine shouldn't be ruled out because it can't handle the config tools or GUI
[18:41:17] <SWPadnos> true - an upgrade path is important, and the most difficult part (I think)
[18:41:32] <jmkasunich> remember that someone might have a machine controller PC buried inside the machine somewhere, and use a remote GUI - the controller doesn't have to even run X
[18:41:46] <jmkasunich> text mode .ini files give you that ability
[18:41:47] <stevestallings> It seems 2.6 was a major break for compiles, and tool support like Kbuild, it looks like a natural baseline. Time moves faster than we do so dedicating resources to older systems is wasteful.
[18:42:01] <SWPadnos> They would then run the configurator on their workstation, and download the .ini to the machine
[18:42:32] <SWPadnos> the controller still uses a text file for configuration - it doesn't care how it was generated
[18:42:35] <jmkasunich> will that work, even if the controller is running a differnet kernel?
[18:42:48] <alex_joni> the ini is kernel independent
[18:42:54] <SWPadnos> The machine configuration is independent of the kernel, isn't it?
[18:42:55] <alex_joni> it's plain text
[18:42:57] <SWPadnos> right :)
[18:43:04] <jmkasunich> we must be carefull to keep it that way then
[18:43:07] <alex_joni> the only param would be PERIOD
[18:43:10] <alex_joni> the
[18:43:21] <SWPadnos> yes - the only discussion about that was making it more "xml-ish"
[18:43:22] <alex_joni> that might generate troubles on different machines
[18:43:40] <SWPadnos> but even PERIOD isn't kernel-specific - it's CPU dependent
[18:43:48] <jmkasunich> and document the file format, so that 1) a skilled human can generate or edit the file without the config tool, and 2) the config tool can be developed completely independent of the controller
[18:44:26] <jmkasunich> I don't see PERIOD as a problem, unless the config tool tries to set it base on the bogomips of the CPU it's running on
[18:44:38] <SWPadnos> The case for using something like XML is that the build (of emc) can generate a "configuration master", which can then be read by a configurator to generate an ini file for that machine
[18:44:49] <jmkasunich> huh
[18:45:17] <jmkasunich> the build of EMC will almost certainly need to take place on the machine that is gonna be the controller, _not_ the desktop workstation
[18:45:23] <SWPadnos> when you "make" emc, the make generates a file that has a list of the modules compiled, and theit possible configurations
[18:45:28] <jmkasunich> because the EMC build _is_ kernel sensitive
[18:46:07] <SWPadnos> right - then you copy this file (or nfs mount it) with the configurator, run in Timbuktu, and have the options available on that machine
[18:46:15] <jmkasunich> oh, OK... so you make on the controller machine, then copy some file that it generates to the config workstation, run the config, and copy the generated .ini(s) back
[18:46:15] <SWPadnos> (on the EMC machine)
[18:46:21] <SWPadnos> right
[18:46:46] <jmkasunich> and of course if the config workstation _is_ the controller, you just skip the copy part
[18:46:56] <SWPadnos> then, when a new driver is added, you might get extra options from running the same configurator, with a different input file
[18:47:01] <SWPadnos> right
[18:47:12] <jmkasunich> I still don't like the need for a 2.6 machine
[18:47:35] <SWPadnos> well - the configurator can be distributed as a binary as well, it wouldn't be kernel dependent
[18:47:59] <SWPadnos> also, look again at RTAI 3.1 - it includes kbuild in the distribition
[18:48:05] <jmkasunich> (maybe because I have about 7 computers here, none of which are running 2.6, and many of which probably can't
[18:48:29] <SWPadnos> it's kernel independent - I can probably email you the files, and you should be able to run them (do you want that?)
[18:48:37] <jmkasunich> sure
[18:48:52] <alex_joni> not sure about the .so file
[18:48:57] <alex_joni> is that kernel independent too?
[18:49:01] <jmkasunich> so the configurator dependencies are all statically linked?
[18:49:04] <alex_joni> how about libc-independent?
[18:49:10] <SWPadnos> it should only link with qconf/mconf etc.
[18:49:15] <jmkasunich> see... always another dependency
[18:49:16] <SWPadnos> well - there is that
[18:49:43] <jmkasunich> this is the kind of stuff that turned me off of programming when winblows took over from DOS
[18:49:53] <SWPadnos> yes.
[18:49:55] <jmkasunich> now it's happening again in Linux
[18:50:26] <jmkasunich> .so = .dll
[18:51:21] <alan__> anyone awake?
[18:51:24] <jmkasunich> sure
[18:51:33] <stevestallings> just dizzy
[18:51:42] <alan__> im wondering if anyone has managed to get axis slaving to work with emc
[18:52:14] <alex_joni> pseudo awake
[18:52:23] <alex_joni> Imperator_: you around?
[18:52:27] <jmkasunich> not really - we're too busy trying to figure out configuration tools to work on real motion controll stuff
[18:52:36] <alex_joni> lol
[18:52:46] <jmkasunich> (sorry, wise-ass remarks not really helpfull)
[18:52:48] <alex_joni> jmk's beeing sarcastic ...
[18:53:18] <alan__> if i specify xyyz as recommended in the manual
[18:53:33] <alan__> i get x, and 3 y axes
[18:54:13] <SWPadnos> jmkasunich: I have a 124k bz2 file - where do you want it?
[18:54:30] <alan__> i've tried tens of combinations, but they all give the same result. a unique axis for each letter, until one is repeated, then each axis is grouped under the same
[18:55:15] <alex_joni> alan__: what do you want to accomplish?
[18:55:31] <alex_joni> do you have 2 Y axes (as in 2 motors running the same axis?)
[18:55:43] <alan__> circular interpolation for xy and za at in the same g2 statement
[18:55:45] <alex_joni> or as in 2 Y-axes (e.g. in the same direction?)
[18:56:12] <alan__> the only way i can think of is rewriting the code the make a g4 statement, that does this
[18:56:18] <alan__> or to slave 2 axes together
[18:56:28] <alan__> right now i just have 2 xy towers working on a foam machine
[18:56:46] <alan__> but my circles come out as rounded squares, because i cant interpolate in 2 planes at the same time
[18:56:55] <alan__> 4 planes rather
[18:57:39] <alan__> any thoughts?
[18:59:37] <alex_joni> not really.. don't really get it
[18:59:53] <alex_joni> I'm deep in lxdialog & mconf right now :(
[18:59:58] <alan__> yeah
[19:00:15] <SWPadnos> are you trying to tilt the plane of a circle?
[19:00:35] <SWPadnos> (off one of the 3 cartesian planes)
[19:01:00] <alan__> let me explain further. i have 2 xy towers, with a hot wire attached, im not doing any tapers, so each x and each y should read the same at all times
[19:01:24] <alan__> but i only have g17 g18 and g19 to choose from for circular interpolation
[19:01:53] <alan__> so i get half a circle on my left x, half on my left y, and so on for right x, right y
[19:01:59] <alan__> it just comes out as a rounded sqaure
[19:02:28] <alan__> if i could just tell emc, to send the same signal for lx and rx. i could be alright.
[19:02:29] <SWPadnos> you may need to generate G-code that splits the circles into line segments
[19:02:38] <jmkasunich> you running steppers or servos or what?
[19:02:44] <alan__> steppers
[19:03:22] <jmkasunich> can you just tell EMC you only have 2 axis, then split the step and dir signals out to both motors?
[19:03:32] <jmkasunich> (won't be able to do tapers and such, but...)
[19:03:54] <alan__> hmm, i guess that would be something my controller is responsible for?
[19:04:26] <jmkasunich> your controller?
[19:04:52] <alan__> my stepper driver
[19:05:26] <alan__> do you mean connect 2 motors to 1 motor connector?
[19:05:34] <jmkasunich> no
[19:06:03] <jmkasunich> you have 4 motor drives, right... each one has it's output connected to one motor, and it's input connected to pins on the computer parallel port
[19:06:07] <jmkasunich> right?
[19:06:24] <alan__> i have 1 driver, with a parallel port in. and 4 outs
[19:06:36] <alan__> hobbycnc.com driver
[19:06:47] <jmkasunich> well, inside the box it is four drivers.. but you may not have access to the step and direction signals
[19:06:50] <jmkasunich> that's unfortinate
[19:06:57] <jmkasunich> as is my spelling
[19:07:00] <alan__> hehe
[19:07:10] <SWPadnos> it's contagious today :)
[19:07:56] <alan__> i'm using less than half out the rated output for each driver chip, so maybe i can do as you say
[19:08:06] <alan__> but i will have to ask the maker of the driver
[19:08:17] <alan__> thanks for the idea though.
[19:08:38] <SWPadnos> I wouldn't parallel the motors
[19:08:38] <jmkasunich> if you could tell EMC it has only X and Y, then send the X step and dir signals to both the X and Z drivers, likewise send the Y step and dir signals to both the Y and A drivers
[19:08:38] <SWPadnos> it just sounds like a Bad Idea
[19:09:10] <jmkasunich> you _don't_ want to connect two motors to the output of one driver
[19:09:10] <alan__> is this a somewhat common practice?
[19:09:10] <jmkasunich> if you're gonna send the same stuff to two motors, you must split _before_ the driver
[19:10:14] <alan__> ok
[19:10:14] <jmkasunich> how are your soldering skills?
[19:11:18] <alan__> pretty good
[19:11:18] <jmkasunich> you could get one male and one female 25 pin D-shell connnector, and make a short cable that splits the signals - insert between your parallel port and your drive box
[19:11:18] <alan__> that reminds me, i have seen pics of a hardware axis slaver that is exactly what your talking about
[19:11:18] <alan__> just some wires looped in a db25 connector
[19:11:18] <SWPadnos> or get one of the Radio Shack db-25 breakout connectors, and cross-connect as needed
[19:11:18] <jmkasunich> in the long run, that isn't much of a solution... I expect you'd eventually like to do tapers, right?
[19:11:18] <SWPadnos> (if they still sell them)
[19:11:18] <alan__> i dont have much interest in tapers
[19:11:25] <alan__> not really into cutting wings or model airplanes, like most foam cutting people
[19:11:38] <jmkasunich> then I think it would work... the main complication might be homing it
[19:11:45] <jmkasunich> do you have home switches?
[19:11:51] <alan__> nope :)
[19:11:58] <jmkasunich> how do you home?
[19:12:04] <alan__> a laser level
[19:12:15] <alan__> this isnt a critical application
[19:12:20] <alan__> its just steadier than my hand is
[19:12:44] <jmkasunich> but if you slave the two sides, they'll always move together, even when you're trying to match them up
[19:13:04] <jmkasunich> (unless you simply match them up manually with the power off)
[19:13:09] <alan__> yeah
[19:13:22] <alan__> this is a small dinky machine, it should be no problem
[19:13:34] <alan__> thanks for the help, i have to go now
[19:13:34] <jmkasunich> then I'd recommend the hardware splitter.
[19:13:41] <jmkasunich> your welcome
[19:13:51] <alex_joni> jmk: got the mail from SWP?
[19:14:12] <SWPadnos> you can connect a couple of DPDT switches to the step/dir pins on the parallel port side, and switch between independent (for homing) and synchronized operation
[19:14:16] <jmkasunich> yeah, gonna try it now (alan's problems are more my style, wanted to do that first)
[19:14:20] <SWPadnos> too late
[19:14:25] <SWPadnos> he
[19:14:27] <SWPadnos> heh
[19:14:43] <SWPadnos> I can't even type a 3-letter word (with only 2 unique letters) :(
[19:14:49] <alex_joni> I know.. that's why I asked only now
[19:15:02] <alex_joni> SWP: it's a virus
[19:15:06] <alex_joni> had it earlier myself
[19:15:14] <jmkasunich> any particular place I should untar that file?
[19:15:28] <alex_joni> had to try 4 times before getting 2 words out
[19:15:36] <SWPadnos> int o emc/src/scripts/kconfig
[19:15:46] <SWPadnos> see - into, into, into
[19:15:54] <jmkasunich> lol
[19:16:09] <SWPadnos> (I actually misspelled into the second time, but corrected it)
[19:16:41] <jmkasunich> there you go again.. there is no emc2/src/scripts... there is emc2/src, and emc2/scripts
[19:17:10] <SWPadnos> sorry - emc2/scripts/kconfig
[19:17:13] <jmkasunich> which one
[19:17:21] <SWPadnos> of course, I forgot to send you lxdialog - nold on a sec
[19:17:36] <jmkasunich> I think I have that
[19:18:26] <SWPadnos> hold - hold - hold aarrrggghhh
[19:18:33] <alex_joni> nol
[19:18:36] <alex_joni> or non
[19:18:38] <SWPadnos> "the castle aaahhh"
[19:18:49] <alex_joni> or even lol
[19:19:17] <SWPadnos> you should have it in a sec - compiled with the same compiler as the other stuff...
[19:19:45] <jmkasunich> ok
[19:20:36] <jmkasunich> brain fart here - how do you unzip a .bz2
[19:20:50] <SWPadnos> tar -jxvf
[19:21:14] <SWPadnos> (j is bzip2, like z for gzip)
[19:21:14] <jmkasunich> tanks
[19:21:42] <SWPadnos> ls -l
[19:21:47] <SWPadnos> oops
[19:22:53] <alex_joni> SWP: use ll
[19:22:56] <alex_joni> ls -al ;)
[19:23:20] <SWPadnos> not an alias for me (yet)
[19:23:53] <alex_joni> was the first thing I did on a new debian
[19:23:57] <jmkasunich> ok, everything unpacked in the right place
[19:24:16] <alex_joni> now run scripts/kconfig/mconf Kconfig
[19:24:18] <alex_joni> from emc2/
[19:24:46] <SWPadnos> or scripts/kconfig/qconf Kconfig for a graphical one
[19:24:49] <jmkasunich> scripts/kconfig/mconf: /lib/i686/libc.so.6: version `GLIBC_2.3' not found (required by scripts/kconfig/mconf)
[19:25:10] <SWPadnos> well - then I guess you'll have to wait :)
[19:25:11] <alex_joni> darn
[19:25:18] <alex_joni> that's what I was afraid
[19:25:29] <alex_joni> go to scripts/kconfig/
[19:25:29] <alex_joni> and run make
[19:25:36] <alex_joni> or make clean, make
[19:25:48] <jmkasunich> no makefile in there
[19:25:51] <SWPadnos> in the kernel tree?
[19:26:08] <SWPadnos> the sources aren't there - I sent the binaries
[19:26:10] <jmkasunich> emc2/scripts/kconfig
[19:27:58] <alex_joni> well.. send the sources ;)
[19:28:07] <alex_joni> but.. I don't like this ...
[19:28:57] <SWPadnos> no - it's just a test of the concept - the best bet would be to include the kbui;d source into the emc2 tree, if we want to go that route
[19:29:08] <SWPadnos> like they did with RTAI
[19:29:29] <jmkasunich> how big is the kbuild source again?
[19:29:42] <SWPadnos> rouhgly 200k unzipped
[19:30:18] <jmkasunich> btw.... Jon E's latest email to the list illustrates another problem with where Linux is going
[19:30:51] <SWPadnos> sort of
[19:30:52] <jmkasunich> the default install uses X... he has a problem with X, so it won't install... now why the hell don't default installs use plain ol TTY
[19:31:06] <SWPadnos> I've found installs to be way less painful lately than years before
[19:31:07] <jmkasunich> then you can run startx if you want to
[19:31:17] <SWPadnos> it can - see my response to him
[19:32:04] <SWPadnos> I had a similar problem - but it turned out to be the CD. I burned another copy (from the same ISO file), and it worked perfectly
[19:32:23] <jmkasunich> ahhh... but why is the _default_ the more fragile X startup, instead of the more robust TTY mode?
[19:32:48] <SWPadnos> because it usually works, and it's much easier for most users to use
[19:33:07] <alex_joni> remember aunt tillie
[19:33:11] <alex_joni> click and drool
[19:33:15] <jmkasunich> I guess I favor robust over easy
[19:33:27] <alex_joni> well .. that's just you ;)
[19:33:29] <SWPadnos> I've installed (using the X installer) on a laptop, a kiosk machine with integrated video, and a desktop - all worked flawlessly (except for the CD burning issue)
[19:33:38] <jmkasunich> IMHO, fewer lines of code = fewer bugs = better
[19:34:09] <SWPadnos> true, but "technically better" doesn't necessarily mean "better for the average user"
[19:34:28] <SWPadnos> (re: Windows)
[19:35:24] <jmkasunich> right.. windows, the OS that conditioned people to expect code that is complex, bloated, and full of mysterious intermittent bugs.... but it's user friendly, so it must be good...
[19:35:46] <SWPadnos> Not good, but better for a lot of average users
[19:35:52] <jmkasunich> (ray isn't here to stir the pot, so I'm substituting for him ;-)
[19:36:00] <SWPadnos> no trouble :)
[19:36:39] <alex_joni> heh
[19:36:42] <SWPadnos> It also conditioned people to expect graphical interfaces to their software
[19:36:44] <alex_joni> anyways
[19:36:46] <jmkasunich> for industrial control, I'd rather have simple, clean, and reliable, even if that means it's harder to iuse
[19:37:12] <SWPadnos> True, but you won't get any "market penetration" with that kind of software
[19:37:34] <paul_c> First, look at the target audience for the BDI...
[19:38:04] <SWPadnos> And, you're complaining (dort of :) ) right now about not being able to run new software on an old system
[19:38:07] <SWPadnos> sort of
[19:38:48] <SWPadnos> nano -w is a good configuration tool
[19:38:55] <SWPadnos> (for text mode)
[19:40:23] <jmkasunich> SWPadnos: what's the connection between my complaints about new sw/old system and my more recent statements
[19:41:11] <SWPadnos> well - a click/drool user wouldn't be trying to get something to work on an existing system, they would probably do a clean install, and want it to be pretty to look at
[19:42:05] <jmkasunich> paul once got in trouble when he said "fsck the users" and was quoted out of context, so I'll probably regret this...
[19:42:12] <SWPadnos> it's not that using the software is hard, it's that the installation and configuration of this software has many dependencies on things that are newer than your system - that's an artificial complexity
[19:42:34] <jmkasunich> but to the extent that the click-drool user thinks looks are more important the robustness, they deserve what they get - they're idiots
[19:42:44] <SWPadnos> true enough :)
[19:43:30] <SWPadnos> but - the 2.4 and 2.6 kernels are at least as stable as 2.2 (IMO - you may disagree)
[19:43:38] <SWPadnos> the tools that come along with newer kernels are nice
[19:44:01] <SWPadnos> the drivers are nice (and in many ways easier to fit into the scheme, once you learn it)
[19:44:10] <jmkasunich> it's not really the kernels... although they are certainly getting more complex
[19:44:17] <jmkasunich> it's all the other stuff that comes along with it
[19:44:17] <SWPadnos> the new window managers are nice etc
[19:44:38] <SWPadnos> you could use windowmaker on the BDI - it's a lot smaller than KDE
[19:44:50] <SWPadnos> The thing you get with KDE is that the system looks like a modern machine
[19:45:11] <SWPadnos> also, you have built in tools for other things, like internet access (in a form that people are used to)
[19:45:23] <jmkasunich> if you ignore the GUI and use servos instead of steppers, you can run a CNC control on a Pentium 100MHz with 32M ram and 300M of disk, with room to spare
[19:45:35] <SWPadnos> you could force people to use wget to update the machine, but that wouldn't appeal to too many potential users
[19:45:58] <jmkasunich> you've hit it on the head - what appeals to me doesn't appeal to the mainstream
[19:46:01] <SWPadnos> (good - then the little 300MHz geode machine I found should work well :) )
[19:46:12] <SWPadnos> well - get with the program ;)
[19:46:35] <alex_joni> GX1 ?
[19:46:37] <jmkasunich> I like embedded...
[19:46:50] <Imperator_> * Imperator_ is back. Somebody was asking for me, but i don't know how ist was (my logger is not deep enough)
[19:47:03] <alex_joni> * alex_joni was asking for Imp.
[19:47:07] <SWPadnos> yes - gx1 @ 300MHz
[19:47:10] <jmkasunich> gantry style axis slaving
[19:47:17] <Imperator_> Ah, hi Alex
[19:47:22] <alex_joni> there was a guy around that wanted gantry style axis slaving
[19:47:24] <alex_joni> hey martin
[19:47:26] <alex_joni> he left
[19:47:39] <alex_joni> SWP: I have one exactly like that
[19:47:46] <alex_joni> running emc & emc2
[19:47:51] <jmkasunich> guy named Alan was looking for help... he is doing a hot wire foam cutter, and wants axis 3 to track 1, 2 to track 4
[19:48:01] <alex_joni> I had problems installing any BDI on it
[19:48:25] <Imperator_> gantry axis support is comming soon, i hope. That was the reason that is was not on my box. A friend was here, we have spoken about the planning of our gantry machine
[19:48:27] <alex_joni> so I installed a SuSE (pretty new compared to BDI-TNG and 2.18 )
[19:48:27] <SWPadnos> look at it here: http://www.evalue-tech.com/products/EES-3412.cfm
[19:48:56] <alex_joni> GX1 has some problems with text consoles
[19:49:00] <alex_joni> so I used FB
[19:49:03] <jmkasunich> * jmkasunich wants one
[19:49:08] <SWPadnos> $316
[19:49:10] <jmkasunich> * jmkasunich wants more than one
[19:49:25] <SWPadnos> well - maybe we can do a quantity buy together :)
[19:49:34] <alex_joni> mine was 500$+
[19:49:39] <alex_joni> but a few years ago ;)
[19:49:42] <SWPadnos> these are really cool - it's a complete system
[19:49:42] <jmkasunich> ooo, dual NICs, looks like a router
[19:49:49] <SWPadnos> power supply included
[19:49:50] <alex_joni> http://www.inside.dk/products/sbc/gx1/GX1LCD-S.asp
[19:49:55] <alex_joni> that's mine
[19:49:56] <jmkasunich> no parport tho
[19:49:59] <Imperator_> nice little Box. Thats also what I want. on the top side is enough place for IO
[19:50:03] <alex_joni> has parport :D
[19:50:09] <SWPadnos> yes - there's a parport and 2 serial
[19:50:16] <alex_joni> mine has 4 :P
[19:50:16] <jmkasunich> I see "2 COM, 2USB 1.0"
[19:50:24] <alex_joni> 1 RS485 configurable
[19:50:28] <SWPadnos> look at the pink connector :)
[19:50:35] <anonimasu> nice
[19:50:57] <SWPadnos> I looked at around 50 different embedded boards at EC - this looked like the best bet
[19:50:58] <anonimasu> http://www.inside.dk/products/sbc/gx1/GX1LCD-S.asp how much was that?
[19:51:06] <jmkasunich> yeah, the also mention it in the green specs block... I was just reading the header at the too
[19:51:08] <jmkasunich> top
[19:51:12] <SWPadnos> it has the case and power supply, which is close to $300 for a PC/104 system
[19:51:15] <alex_joni> was about 500$ an0n
[19:51:18] <anonimasu> ah ok..
[19:51:20] <alex_joni> but 2 or 3 years ago
[19:51:25] <alex_joni> should be half now
[19:51:28] <anonimasu> hm, the speed is too low to do the pulse generation..
[19:51:36] <SWPadnos> it's a nice little box - almost fits in the palm of my hand
[19:51:38] <alex_joni> for 3-400 you get a VIA @ 600 MHz
[19:51:39] <anonimasu> with a G200x and 2 boards like that..
[19:51:51] <jmkasunich> I can do 10KHz with a Pentium 233MHz
[19:51:53] <SWPadnos> there's a slightly larger one that has a 1GHz Via Eden
[19:52:01] <SWPadnos> (for $350 or so)
[19:52:07] <anonimasu> jmkasunich: with emc?
[19:52:12] <jmkasunich> emc2
[19:52:20] <jmkasunich> HAL stepgen module
[19:52:35] <SWPadnos> http://www.evalue-tech.com/products/EES-3610.cfm
[19:52:36] <anonimasu> hm, is that faster then steppersegmod?
[19:52:43] <jmkasunich> I have no idea
[19:53:04] <anonimasu> well, I get joint following errors when I crank up the speed enough..
[19:53:25] <SWPadnos> PERIOD = 0.0000000000001 :D
[19:53:52] <jmkasunich> 50uS for 10KHz
[19:54:07] <alex_joni> SWP: shall we work on Kconfig ?
[19:54:09] <SWPadnos> I like the 3610 because it's basically sealed - no vents or fans.
[19:54:15] <SWPadnos> sure
[19:54:36] <alex_joni> is the Configuration skills in CVS ?
[19:54:36] <jmkasunich> work on removing dependencies ;-)
[19:54:43] <alex_joni> jmk: right
[19:54:49] <alex_joni> jmk: got it to run?
[19:54:54] <SWPadnos> dependency one: jmk's approval :)
[19:55:01] <alex_joni> SWP: I agree
[19:55:08] <alex_joni> * alex_joni prods paul_c
[19:55:09] <SWPadnos> removed
[19:55:36] <jmkasunich> alex_joni: won't run, wrong library here... would need to compile from source I think
[19:55:51] <alex_joni> bugger that
[19:55:54] <SWPadnos> jmkasunich: download RTAI 3.1 and do make menuconfig
[19:56:06] <jmkasunich> how big is that
[19:56:10] <SWPadnos> then copy the binaries from there to the emc2 dir
[19:56:14] <anonimasu> hm, jmkasunich is that 0,05
[19:56:18] <alex_joni> 3 MB
[19:56:27] <jmkasunich> url?
[19:56:35] <SWPadnos> www.rtai.org
[19:56:43] <anonimasu> or PERIOD = 0,???
[19:56:48] <jmkasunich> alex_joni: "bugger that"... you been hanging around paul too long
[19:56:55] <anonimasu> I'll be back in a bit going to go to the kiosk,
[19:57:09] <alex_joni> jmk: http://www.rtai.org/modules.php?name=Downloads&d_op=getit&lid=22
[19:57:22] <SWPadnos> direct to the tar: http://download.gna.org/rtai/stable/v3/rtai-3.1.tar.bz2
[19:57:22] <alex_joni> * alex_joni needs a munchie
[19:57:51] <jmkasunich> anonimasu: 50uS = 50 microseconds = 0.000050
[19:58:56] <jmkasunich> where should I save that tarball... don't want to overwrite any of my existing stuff
[19:59:11] <alex_joni> do it in your home dir
[19:59:14] <SWPadnos> just put it into ~/, then untar
[19:59:23] <SWPadnos> it'll be in ~/rtai-3.1
[19:59:54] <SWPadnos> you don't need to install this RTAI - it just includes the config programs, without the kernel dependencies
[20:01:19] <jmkasunich> ok, so I go into rtai-3.1 and run "make menuconfig"?
[20:01:23] <alex_joni> yup
[20:01:31] <SWPadnos> or make xconfig
[20:01:33] <alex_joni> you should see that it compiles some stuff
[20:01:41] <alex_joni> and when you have the menu.. you exit
[20:01:53] <jmkasunich> compiled, then got the menu
[20:02:05] <jmkasunich> and exited
[20:02:05] <SWPadnos> this will then go on to do more things, but you should be able to stop them harmlessly
[20:02:12] <SWPadnos> (or let them finish)
[20:02:25] <jmkasunich> actually, since I didn't save a config, it bailed out
[20:02:28] <alex_joni> and copy the scripts (from rtai-core/config/ )
[20:02:43] <alex_joni> there's kconfig and lxdialog there
[20:02:45] <alex_joni> or should be
[20:02:56] <SWPadnos> actually, it'll be ~/rtai-3.1/rtai-core/config/kconfig
[20:03:11] <jmkasunich> autoconf, kconfig, and modules, all directoreis
[20:03:12] <alex_joni> yeah
[20:03:24] <jmkasunich> cd kconfig
[20:03:25] <alex_joni> you only need kconfig
[20:03:27] <jmkasunich> dammit
[20:03:33] <alex_joni> copy the whole dir
[20:03:43] <alex_joni> with subdirs (lxdialog is a subdir)
[20:03:44] <SWPadnos> no - you also need libkconfig.so
[20:04:14] <alex_joni> that's there too
[20:04:39] <SWPadnos> just go to the directory and type mconf /path/to/emc2/Kconfig
[20:04:46] <SWPadnos> (the rtai kconfig directory)
[20:04:59] <alex_joni> how about running: ~/rtai-3.1/rtai-core/config/kconfig/mconf /path/to/emc2/Kconfig
[20:05:07] <alex_joni> SWP: same thought ;)
[20:05:10] <SWPadnos> that sounds like a great idea :)
[20:05:51] <jmkasunich> it worked!!
[20:06:05] <SWPadnos> do you have qconf in that dir?
[20:06:10] <SWPadnos> (cool, btw)
[20:07:11] <jmkasunich> hmmm... it says press "?" for help about this option, probably _should_ bring up the help text from the emc2 Kconfig file... but doesn't
[20:07:32] <alex_joni> for what option?
[20:07:36] <jmkasunich> says "there is no help available for this RTAI option"
[20:07:39] <SWPadnos> the help doesn't exist for submenus
[20:07:48] <jmkasunich> any option - I was doing it for TkEMC
[20:08:53] <alex_joni> works here...
[20:08:58] <SWPadnos> The help works on some of the options - like the EMC system configuration ones
[20:09:04] <SWPadnos> not on others though
[20:09:25] <jmkasunich> tell me one it works on for you
[20:09:26] <SWPadnos> I get all the help using qconf (hint hint)
[20:09:38] <alex_joni> get to Display program
[20:09:44] <alex_joni> push select
[20:09:46] <SWPadnos> go to EMC System Configuration submenu
[20:09:52] <SWPadnos> all of those seem to work
[20:10:00] <alex_joni> and it should work for any of (tkemc, mini, axis, Keystick)
[20:10:12] <SWPadnos> it doesn't here, using mconf
[20:10:24] <jmkasunich> debug works
[20:10:27] <jmkasunich> the GUIs don;t
[20:10:30] <alex_joni> it does here with mconf
[20:11:10] <jmkasunich> did make menuconf make all of them, or only mconf?
[20:11:23] <jmkasunich> * jmkasunich wants to try qconf
[20:11:26] <SWPadnos> don't know - is there a qconf executable in that dir?
[20:11:43] <SWPadnos> if not, use make xconfig in ~/rtai-3.1
[20:11:56] <jmkasunich> nope - the make command is what I was looking for
[20:12:54] <jmkasunich> ooohhhh, pretty....
[20:13:05] <jmkasunich> * jmkasunich clicks and drools
[20:13:08] <alex_joni> does it work?
[20:13:11] <SWPadnos> see - start drooling
[20:13:13] <SWPadnos> :)
[20:13:18] <SWPadnos> (click click)
[20:15:45] <jmkasunich> but it is really nothing more than another way to edit the ini file
[20:15:56] <SWPadnos> exactly the idea :)
[20:16:09] <alex_joni> jmk: might get a bit more
[20:16:22] <alex_joni> I plan to remove some of the options
[20:16:29] <jmkasunich> <SWPadnos> dependency one: jmk's approval :)
[20:16:30] <SWPadnos> the final program wouldhave questions like "encoder resolution" and "drive ratio" - then calculate INPUT_SCALE appropriately
[20:16:34] <jmkasunich> absolutely NOT true
[20:16:43] <alex_joni> If you have Configuration Skills set to SIMPLE
[20:17:05] <alex_joni> you'll see only a few, basic, options
[20:17:16] <jmkasunich> my "not true" was in response to me being dependency 1
[20:17:18] <alex_joni> if you set to ADVANCED you get to see more features
[20:17:35] <alex_joni> jmk: doesn't matter what number ;)
[20:17:43] <SWPadnos> dep 1 satisfied or removed, I can't decide which ;)
[20:17:45] <alex_joni> but.. I think that you like it is a big step ahead
[20:17:59] <alex_joni> bc you are famous for not liking stuff like this
[20:18:01] <alex_joni> :D
[20:18:08] <jmkasunich> I'm the last person who should be considered a dependency for a config tool, since I don't like them in general
[20:18:51] <jmkasunich> I don't particularly like this one either... not because of anything specific about it, but because it hides things... I don't like unneccessary (to me) layers
[20:19:44] <jmkasunich> this tool can be only as good as the documentation and tool author's understanding of the different fields
[20:20:05] <jmkasunich> if the meaning of INPUT_SCALE is poorly understood, then this tool won't fix that
[20:20:38] <SWPadnos> no, but it can hide the meaning from somebody who only wants to drive their motors.
[20:20:45] <jmkasunich> I'd rather have INPUT_SCALE documented well enough that a moderately smart person can figure it out
[20:20:59] <SWPadnos> also, the meaning can change down the line, and the user doesn't have to know if they don't want to
[20:21:15] <jmkasunich> I agree that with this tool, if ONE person figures it out, and embedds that knowledge in the tool, then others have an easier time...
[20:21:27] <jmkasunich> but the knowledge winds up hidden in the tool
[20:21:42] <SWPadnos> and in the documentation, for those who don't like tools :)
[20:21:58] <alex_joni> jmk: my thoughts are that after Kconfig is done
[20:22:07] <jmkasunich> I'm afraid the docs won't get updated
[20:22:10] <alex_joni> you have a config file (just like for a kernel)
[20:22:20] <alex_joni> you need to parse that (with a script or whatever)
[20:22:30] <alex_joni> and produce the .ini and other needed files
[20:22:36] <jmkasunich> "oh, the tool handles input scale just fine, no need to actually explain what it does"
[20:22:45] <alex_joni> maybe even Makefiles at some point
[20:22:59] <jmkasunich> makefiles?
[20:23:07] <alex_joni> why not?
[20:23:10] <jmkasunich> compiling and configuring are two completely different beasts
[20:23:18] <robin_sz> eh oh
[20:23:30] <alex_joni> if the user configures only ppmc, no need for other bins
[20:23:37] <alex_joni> emc1-ish thinking
[20:23:57] <alex_joni> but that's far-fetched right now
[20:24:10] <alex_joni> let's stay focused on basic task configure
[20:24:42] <alex_joni> hey robin
[20:24:53] <alex_joni> robin_sz: what happened to your meep ?
[20:24:59] <SWPadnos> and in HAL-land, it would be nice to include drivers for only the hardware you have
[20:25:03] <SWPadnos> Hi, robin_sz
[20:25:19] <SWPadnos> similar to building an optimized kernel for your hardware
[20:25:24] <alex_joni> SWP: in HAL land we kinda need some graphical interconection tool
[20:25:46] <SWPadnos> yes - your idea of a schematic-editor-like tool is interesting
[20:25:54] <alex_joni> wasn't my ideea
[20:25:59] <alex_joni> jmk came up with it first
[20:26:07] <jmkasunich> ideally, you place the component on the sheet, then click on it to config it's parameters
[20:26:09] <robin_sz> my meep is all meeped out
[20:26:14] <SWPadnos> I was referring to the build, not the machine config, but I'll stop now :)
[20:26:27] <SWPadnos> OK - jmk's idea is great then :)
[20:26:43] <alex_joni> * alex_joni meeps robin some meeps
[20:26:46] <ottos> greetings gents..
[20:26:53] <jmkasunich> unfortunately right now it's just an idea
[20:26:54] <alex_joni> greetings ottos
[20:26:56] <jmkasunich> hi otto
[20:26:59] <robin_z> bah
[20:27:22] <SWPadnos> (like kconfig :) )
[20:27:30] <SWPadnos> - just an idea at this point
[20:28:15] <SWPadnos> is there a HAL modules for manual spindle control (or something similar)?
[20:28:28] <alex_joni> how do you mean that`
[20:28:29] <jmkasunich> I guess I have no real issues with config tools, as long as they are considered accessories - IOW, you _must_ be able to do the config with a text editor and the provided documentation...
[20:28:30] <alex_joni> ?
[20:28:45] <alex_joni> jmk: right
[20:28:52] <alex_joni> the "old" way stays ;)
[20:28:57] <SWPadnos> well - a G-code program says "turn the spindle on, at 500RPM", and you have no machine control of the spindle
[20:29:12] <SWPadnos> you need to prompt the user to turn the spindle on and set the speed, then resume the program
[20:29:25] <SWPadnos> but that shouldn't have to be coded in the source G-code file
[20:29:40] <alex_joni> don't think emc2 does handle spindle speed
[20:29:42] <SWPadnos> jmkasunich: no argument there
[20:29:44] <alex_joni> I might be wrong
[20:29:46] <jmkasunich> my approach would be that the motion controller would have several output pins
[20:29:54] <alex_joni> but I don't remember that
[20:30:05] <jmkasunich> spindle on/off (bit), spindle speed (float)
[20:30:16] <jmkasunich> and one input pin: spindle OK
[20:30:42] <jmkasunich> then you'd have hal modules that connect to those pins
[20:30:52] <SWPadnos> and then a "spindle_manual" module that prompts the user, and returns "spindle_ok" when the "finished" button is pressed by the user
[20:30:55] <alex_joni> jmk: that's what I did ;)
[20:31:08] <jmkasunich> right
[20:31:08] <alex_joni> SWP: not really
[20:31:15] <alex_joni> you can connect the spindle_speed to smthg
[20:31:15] <jmkasunich> HAL modules can be kernel modules or user space, even GUI programs
[20:31:23] <SWPadnos> OK - that's good
[20:31:27] <alex_joni> and that smthg is a gui program (say a halmeter)
[20:31:43] <alex_joni> and the halmeter tells the user how much speed the spindle should have
[20:32:07] <alex_joni> but what I don't remember is the GCode for spindle speed
[20:32:11] <SWPadnos> OK - you can use a halemter / halscope / halbutton (?) to do it
[20:32:15] <jmkasunich> so you could have a user space prog that reads the speed pin, displays the desired speed on the screen, sets OK false whenever the desired speed changes, and true when the operator clicks to say he set the speed correctly
[20:32:52] <SWPadnos> I was justthinking at a high level about machine functions, and what to do if the machine doesn't have automatic control of some things
[20:33:13] <robin_z> I do similar on my plasmas
[20:33:24] <robin_z> with manual current control
[20:33:28] <jmkasunich> the trick is to choose the right pins on the motion controller... perhaps spindle OK isn't the right choice, for example
[20:33:41] <robin_z> the user gets a "please set plasma to 40 amps" message when changing processes
[20:33:51] <SWPadnos> robin_z: it's a matter of making it transparent to the program
[20:33:54] <alex_joni> I did code a few pins for spindle
[20:33:54] <robin_z> (only if it wasnt on 40A )
[20:33:56] <alex_joni> to make it generic
[20:33:58] <SWPadnos> (the g-code, that is)
[20:34:03] <robin_z> SWPadnos: absolutley
[20:34:17] <alex_joni> // simplest way of spindle control (output start/stop)
[20:34:18] <alex_joni> hal_bit_t *spindle_on;/* spindle spin output */
[20:34:18] <alex_joni>
[20:34:18] <alex_joni> // same thing for 2 directions
[20:34:18] <alex_joni> hal_bit_t *spindle_forward;/* spindle spin-forward output */
[20:34:18] <alex_joni> hal_bit_t *spindle_reverse;/* spindle spin-reverse output */
[20:34:18] <jmkasunich> robin_z: so the code can tell what it is set on, but can't change the setting?
[20:34:23] <SWPadnos> OK - so if there 's a plasma height controller, it just does it automatically and goes on its way
[20:34:27] <alex_joni> // simple velocity control (as long as the output is active the spindle
[20:34:27] <alex_joni> //should accelerate/decelerate
[20:34:27] <alex_joni> hal_bit_t *spindle_incr_speed;/* spindle spin-increase output */
[20:34:27] <alex_joni> hal_bit_t *spindle_decr_speed;/* spindle spin-decrease output */
[20:34:27] <alex_joni>
[20:34:29] <alex_joni> // simple output for brake
[20:34:31] <SWPadnos> current - sorry
[20:34:31] <alex_joni> hal_bit_t *spindle_break;/* spindle break output */
[20:34:35] <alex_joni> // output of a prescribed speed (to hook-up to a velocity controller)
[20:34:35] <alex_joni> hal_float_t *spindle_speed_out;/* spindle speed output */
[20:34:38] <alex_joni> hal_float_t *spindle_speed_in; /* spindle speed measured */
[20:34:42] <robin_z> jmkasunich: it just stores whatever it asked the user to set it to last time
[20:35:02] <alex_joni> you could connect speed_out and speed_in to the GUI program
[20:35:09] <alex_joni> and the user sets the speed he has set
[20:35:22] <alex_joni> and if the two are different emc sees that
[20:35:43] <jmkasunich> alex_joni: I'd probably make the first level interface to emc even simpler... just commanded speed, start/stop, and OK or something like that
[20:35:53] <SWPadnos> direction as well
[20:36:01] <robin_z> SWPadnos: same on the plasmas I just use M3 and it does whatever it needs to do ... turns on the torch, lowers Z, messes about with height sensing etc etc, pierce delay .. etc
[20:36:08] <jmkasunich> direction is sign of speed
[20:36:10] <alex_joni> the first level is start/stop
[20:36:15] <alex_joni> just one pin (bit)
[20:36:24] <robin_z> SWPadnos: I dont agree with putting extra, machine-speciffic crap in the gcode
[20:36:31] <alex_joni> the second is start/stop on two pins (depending on direction)
[20:36:37] <SWPadnos> that's what I want to avoid
[20:36:45] <alex_joni> the third is a pin for increase/decrease speed
[20:36:47] <robin_z> * robin_z nods
[20:36:52] <alex_joni> then a pin for break
[20:36:53] <SWPadnos> by having a machine module that says "This is a manual operation"
[20:36:57] <alex_joni> and the floats for speed
[20:36:57] <SWPadnos> like toolchangers
[20:37:03] <jmkasunich> no, no, no
[20:37:11] <robin_z> SWPadnos: the key to that is a flexible and configurabel user macro system ;)
[20:37:13] <jmkasunich> the controller is _always_ the same....
[20:37:34] <jmkasunich> it _always_ outputs an on/off, and a signed speed, and expects an acknowledgment
[20:37:45] <jmkasunich> the HAL module then implements whatever is needed
[20:37:45] <robin_z> mmmm
[20:37:49] <alex_joni> SWP: the main ideea is to be able to connect HAL-pins
[20:37:58] <jmkasunich> maybe it displays the desired speed and tells the user to set it and click OK
[20:38:02] <alex_joni> SWP: without touching the HAL-module itself
[20:38:07] <SWPadnos> right - the BridgeportSpindle module then takes that and converts to a fwd/rev output bit, and a speed analog drive (for example)
[20:38:10] <jmkasunich> maybe it drives increment and decrement outputs
[20:38:15] <robin_z> it always takes command for an on/off and a signed speed ...
[20:38:26] <robin_z> thats not the same as outputs a ...
[20:38:26] <jmkasunich> maybe it simply writes the speed to a DAC that drives a VFD
[20:38:49] <alex_joni> or writes the speed to a step-gen that drives another type of VFD
[20:39:14] <robin_z> so ... the input API is the same ...
[20:39:21] <SWPadnos> exactly - the hardware -dependent modules give the same interface to the controller, but "no hardware - prompt the user" is also a viable option. That's the only thing I was thinking about
[20:39:27] <robin_z> but anything after that is variable
[20:39:31] <jmkasunich> the EMC core <-> HAL module API is fixed - 3 pins or so
[20:39:41] <alex_joni> actually NML ;)
[20:39:50] <SWPadnos> Not My Language ;)
[20:40:04] <alex_joni> I started to speak it a bit
[20:40:37] <alex_joni> NMFL
[20:40:38] <alex_joni> ;)
[20:40:45] <alex_joni> Not My Favorite Language
[20:40:48] <SWPadnos> heh
[20:40:56] <robin_z> so, this spindle I have ... with on/off, speed, vibro on/off, pre-mist on/off and potato level [float] ...
[20:41:08] <SWPadnos> yes...
[20:41:19] <alex_joni> robin: the way I see it...
[20:41:28] <robin_z> how does that fit into 3 pins?
[20:41:28] <SWPadnos> A floating potato level is the only way to go
[20:41:30] <alex_joni> there's a module called IOcontrol
[20:41:41] <alex_joni> that should have all possible pins
[20:41:50] <alex_joni> and the user connects only what he needs
[20:42:00] <jmkasunich> what G-code is supposed to control vibro-on/off?
[20:42:01] <alex_joni> one user connects start/stop (one pin)
[20:42:08] <alex_joni> V20
[20:42:11] <alex_joni> :P
[20:42:18] <robin_z> jmkasunich: non
[20:42:19] <jmkasunich> I want robin's answer
[20:42:31] <robin_z> mayeb an M code
[20:42:45] <jmkasunich> ok then, why should vibro-on/off come from the motion controller that is concerned with G-code
[20:42:46] <alex_joni> another user connects start/stop, brake, speed (to a VFD)
[20:42:48] <SWPadnos> actually, it can be done with two pins (Paul had suggested soemthing like this) - speed_setting and speed_feedback
[20:43:00] <robin_z> or M3 S1000 V34
[20:43:16] <SWPadnos> V == parallel axis to Y
[20:43:21] <robin_z> alex_joni: what do you mean "all possible pins" on the IO module?
[20:43:23] <alex_joni> SWP: that's what I have done
[20:43:25] <jmkasunich> well make up your mind - is it g-code driven or not?
[20:43:38] <alex_joni> robin: possible types of commands to hardware
[20:43:40] <jmkasunich> damn we're going around in circles here
[20:43:46] <robin_z> tell me of M934 is a Gcode
[20:43:53] <SWPadnos> sorry -it seemed like a simple wuestion at the time :)
[20:43:56] <SWPadnos> question
[20:44:11] <robin_z> tell me if M934 is a Gcode
[20:44:13] <jmkasunich> does the interp know what M943 is?
[20:44:22] <jmkasunich> if not, then it's not a G code
[20:44:29] <SWPadnos> It runs scripts/M934
[20:44:40] <robin_z> sounds fine
[20:44:56] <jmkasunich> I thought we were talking about spindles here...
[20:46:02] <SWPadnos> It was just a question and idea for generic "stub functions" that prompt the user to do something
[20:46:46] <jmkasunich> SWPadnos: I understand where you were going, and I think I like it... robin is saying stuff and I'm trying to figure out what his point it
[20:47:05] <jmkasunich> too many conversations going on at once
[20:47:09] <SWPadnos> yes
[20:47:37] <jmkasunich> robin_z: where were you going with your vibro and potato level example?
[20:47:50] <jmkasunich> you were trying to make a point, but it got lost in the noise
[20:48:19] <alex_joni> jmk: think robin says we need stuff to be more generic
[20:48:26] <alex_joni> so he can connect his laser to emc
[20:48:28] <robin_z> well, I was pointing out that a fixed 3 pin system may not be the best answer in all cases
[20:48:29] <alex_joni> :P
[20:48:42] <alex_joni> or plasma
[20:48:48] <alex_joni> or waterjet cutter
[20:48:50] <alex_joni> or whatever
[20:48:54] <jmkasunich> well it's only three pins at the controller level, not at the I/O level
[20:48:57] <SWPadnos> for a spindle, it should be fine
[20:49:02] <robin_z> for a laser?
[20:49:12] <alex_joni> SWP: the main thing is .. it's not always a spindle
[20:49:25] <SWPadnos> if youhave a plasma or waterjet, it may take some thought to apply spindle commands to your cutter
[20:49:40] <SWPadnos> (or toolchanger commands, which might be more appropriate)
[20:49:40] <alex_joni> you "could" be able to define M3 --> laser on/off
[20:49:51] <jmkasunich> M3 is spindle on, right?
[20:49:52] <alex_joni> M4 --> coolant on/off
[20:49:57] <SWPadnos> spndle is fine - on/off and power (speed)
[20:49:59] <alex_joni> M5 --> whatever
[20:50:08] <alex_joni> SWP.. not always
[20:50:16] <alex_joni> some have 2 pins for direction
[20:50:26] <robin_z> then it becomes a mess, I want my macro to send laser_on, not spindle on, I dont even have a spindle. why should I be translating into that?
[20:50:27] <anonimasu> * anonimasu is here again
[20:50:30] <alex_joni> others only 1
[20:50:31] <anonimasu> * anonimasu lurks
[20:50:52] <alex_joni> robin: then you might wanna connect to classicladde
[20:50:53] <alex_joni> r
[20:50:56] <jmkasunich> alex_joni: let's ignore what I/O a spindle drive might have
[20:51:00] <jmkasunich> concentrate on the G-code side
[20:51:02] <alex_joni> there you have I0-I50
[20:51:12] <robin_z> ok ...
[20:51:12] <alex_joni> and nobody knows what either is
[20:51:12] <jmkasunich> robin_z: what G-code do you want to use to turn on your laser
[20:51:17] <SWPadnos> from a high level, the nimber of pins is immaterial to thefunctions of a generic "spindle"
[20:51:19] <robin_z> M someting
[20:51:29] <robin_z> (possibly with args)
[20:51:33] <alex_joni> user defineable ?
[20:51:39] <robin_z> M934 P100
[20:51:44] <robin_z> absolutley
[20:51:50] <alex_joni> when?
[20:51:58] <jmkasunich> specifically _NOT_ the normal spindle code?
[20:52:07] <robin_z> specifically not the spindle code
[20:52:09] <robin_z> say,
[20:52:39] <alex_joni> robin: you might get into troubles with your postprocessor
[20:52:47] <alex_joni> changing it accordingly
[20:52:53] <jmkasunich> so you are extending the g-code language
[20:53:12] <robin_z> adding useful macros
[20:53:20] <robin_z> liek on any modern control
[20:53:31] <robin_z> eg the Bosch on my trumpf laser
[20:53:34] <jmkasunich> you are _not_ using the spindle channel of the motion controller, and thus _not_ using the three pins we're talking about
[20:53:39] <robin_z> correct
[20:53:43] <robin_z> for instance
[20:54:06] <jmkasunich> I thought you started out by telling me that three pins wasn't enough
[20:54:24] <jmkasunich> now you admit you aren't even using that interface, and don't really care how many pins it has
[20:54:25] <robin_z> sorry .. I thought we had moved away from that
[20:54:29] <robin_z> we can go back
[20:55:14] <jmkasunich> I'm talking about spindle, and only spindle (or at least, only things controlled by the spindle G-code and spindle related cannonical motion commands)
[20:55:30] <CIA-7> 03paul_c * 10emc/src/emctask/emcsh.cc: Spotted an error in an error message...
[20:55:41] <alex_joni> jmk: and thus having a lot of controllers?
[20:55:47] <robin_z> sorry, I understood you to want to specifically talk about anyting but the spindle
[20:55:53] <jmkasunich> if you want to control a laser or waterjet or plasma as if it were a spindle, then we can talk... if you want to use other G-codes, then that is a differnet situation
[20:55:57] <alex_joni> 1 for spindle, 1 for laser, 1 for waterjet, 1 for plasma ?
[20:56:04] <CIA-7> 03paul_c 07bdi-4 * 10emc2/src/emc/task/emcsh.cc: Spotted an error in an error message...
[20:56:06] <anonimasu> hm..
[20:56:12] <jmkasunich> by controllers, you mean HAL modules?
[20:56:23] <alex_joni> paul_c: that's why it's called error message
[20:56:33] <alex_joni> jmk: probably
[20:56:42] <SWPadnos> erroneous error messages are evil
[20:56:45] <alex_joni> more correct entities ;) (part of an HAL module)
[20:56:47] <robin_z> in my opinion M3 should simply call a macro
[20:57:05] <robin_z> if you want that macro to work spindle hal pins fine
[20:57:06] <jmkasunich> what kind of macro, what language?
[20:57:19] <robin_z> right now? decision?
[20:57:21] <robin_z> Ok ...
[20:57:23] <jmkasunich> yeah
[20:57:24] <robin_z> LUA
[20:57:31] <CIA-7> 03paul_c 07pc_2_6_test * 10emc2/src/emc/usr_intf/ (emcsh.cc getinput.c): Spotted an error in an error message here too......
[20:57:33] <anonimasu> ARGH"#�
[20:57:41] <anonimasu> lua's cute :)
[20:57:53] <robin_z> http://www.lua.org/
[20:57:57] <paul_c> emc_lube() returns "emc_flood requires..."
[20:58:08] <jmkasunich> when somebody talks about a G-code calling a macro, I assume they mean a macro also in G-code (like a subroutine)
[20:58:11] <alex_joni> hey paul_c
[20:58:12] <SWPadnos> SWPadnos is now known as SWP_Away
[20:58:43] <robin_z> as standard, the M3 macro might simply be "emcSinpleOn();"
[20:58:54] <jmkasunich> you mean you actually want it to spawn a Linux process that runs some arbitrary code in some arbitrary language?
[20:58:54] <robin_z> except spelt spindle
[20:59:01] <anonimasu> you can do that today..
[20:59:15] <anonimasu> you can call LUA via your C code..
[20:59:51] <jmkasunich> what language is "emcSpindleOn();"?
[20:59:56] <robin_z> lua
[21:00:09] <jmkasunich> wtf is LUA?
[21:00:12] <robin_z> but it refers to C function
[21:00:18] <anonimasu> yeah but how do you get LUA to call somthing else..
[21:00:23] <anonimasu> external things and stuff?
[21:00:29] <robin_z> external?
[21:00:35] <anonimasu> oh, emcSpindleOn
[21:00:37] <robin_z> it can only call back into the emc code
[21:00:58] <anonimasu> hm, interpreter > LUA > HAL
[21:01:01] <anonimasu> somthing like that..
[21:01:01] <anonimasu> ?
[21:01:08] <alex_joni> forget LUA !!!!!!!
[21:01:11] <robin_z> jmkasunich: you asked me to name a suitable macro language, I chose one
[21:01:14] <alex_joni> stop talking crap ;)
[21:01:17] <anonimasu> lol
[21:01:24] <alex_joni> robin: why not make it M4?
[21:01:33] <anonimasu> but LUA is cute ^_^
[21:01:39] <alex_joni> so that no-one knows how to use it
[21:01:45] <jmkasunich> in any case, you guys are talking about stuff that happens at the interpreter level
[21:02:00] <alex_joni> outside the interp.
[21:02:09] <robin_z> * robin_z nods
[21:02:29] <jmkasunich> if you want the re-implemnent the entire interperter so no M code has a fixed meaning, they all simply call some macro, that's fine... it means nothing at the motion control level
[21:02:31] <alex_joni> extending hal-modules to an aching extent
[21:02:46] <alex_joni> have the interpreter export 999 pins
[21:02:49] <alex_joni> M1-M999
[21:02:51] <jmkasunich> retch
[21:02:59] <robin_z> no,
[21:03:01] <alex_joni> and link those to any hal-module you want
[21:03:02] <jmkasunich> even I don't think HAL should be used for that
[21:03:03] <robin_z> that would be bad
[21:03:07] <alex_joni> lol
[21:03:09] <anonimasu> hm..
[21:03:37] <alex_joni> maybe pass parameters too ;)
[21:03:43] <alex_joni> like M3S1000
[21:03:54] <robin_z> what I tink is important is that an integrator can change the behaviour of M codes without recompiling the entire shooting match
[21:04:01] <jmkasunich> as I understand it, M3 S1000 has a well known and accepted meaning
[21:04:01] <robin_z> alex_joni: absolutely
[21:04:13] <anonimasu> jmkasunich: why not?
[21:04:14] <robin_z> jmkasunich: yes, it turns the plasma on
[21:04:33] <jmkasunich> it sets a bit ON and a float to 1000
[21:05:04] <jmkasunich> if you want to hook the bit to the plasma and the float to the amp dial, go ahead
[21:05:20] <jmkasunich> now convince me that I need more bits or floats
[21:05:22] <alex_joni> right
[21:05:30] <alex_joni> jmk: only one problem
[21:05:34] <robin_z> where do I add the code to check that the compressor is on and up to pressure?
[21:05:34] <alex_joni> how do you call the bit?
[21:05:46] <jmkasunich> in the HAL module that runs the plasme
[21:05:46] <alex_joni> right now it's called spindle_on
[21:05:49] <alex_joni> robin: you do that in classicladder
[21:06:02] <alex_joni> jmk: I meant what name does it get
[21:06:07] <jmkasunich> M3 S1000 sets the bit and float
[21:06:20] <alex_joni> that bit is called... M3_on ?
[21:06:32] <jmkasunich> the HAL module sees the bit set, and reads/writes other bits that are connected to the compressor or what have you
[21:06:54] <jmkasunich> the HAL module could be custom written for the plasma, or you could do it with classic ladder, or...
[21:07:07] <anonimasu> isnt that the idea of classicladder..
[21:07:10] <anonimasu> to emulate a plc..
[21:07:14] <robin_z> ok,
[21:07:14] <anonimasu> to do stuff like that..
[21:07:19] <jmkasunich> alex_joni: I wasn't too worried about bit names right now
[21:07:39] <robin_z> let me give you another example, one I use in Mach2
[21:07:51] <robin_z> I implement this with a macro ... Mxxx
[21:08:01] <robin_z> its the "park" macro
[21:08:26] <robin_z> it takes fully retracts the torch
[21:08:37] <alex_joni> jmk: beside bit-names the rest is already done (at least in my point of view)
[21:08:45] <robin_z> moves to whichever edge of the sheet is nearest (left or right)
[21:08:51] <robin_z> and then to the back of the table
[21:09:09] <robin_z> (avoids going over possibly tipped up parts)
[21:09:21] <anonimasu> classicladder.. probably..
[21:09:23] <robin_z> easy to do as a macro
[21:09:29] <robin_z> and in classicladder?
[21:09:30] <jmkasunich> how?
[21:09:41] <anonimasu> hm, can you output motion back to emc via hal?
[21:09:45] <jmkasunich> I wasn't suggesting classicladder for that
[21:09:58] <jmkasunich> how do you do it in mach2?
[21:10:01] <robin_z> as a macro
[21:10:18] <jmkasunich> you said that already... how does the macro do it?
[21:10:30] <robin_z> just dump a bit of VB into the macros folder called M956.m1s
[21:10:35] <jmkasunich> does it emit g-code, does it hook into the motion controller,
[21:10:38] <robin_z> it reads the current X and Y
[21:10:57] <robin_z> calls back into the motion
[21:11:01] <alex_joni> and has a way to command movement
[21:11:04] <robin_z> exactly
[21:11:12] <jmkasunich> calls back into the motion?
[21:11:13] <robin_z> waits for motion to stop
[21:11:21] <robin_z> I forget the command
[21:11:40] <anonimasu> but well still we need macro functionality like in other machines in the interpreter..
[21:11:45] <robin_z> I try not to rememebr as I now loathe that program :)
[21:12:17] <robin_z> the GUI and the user macros were awesome. the motion sucked.
[21:12:48] <jmkasunich> I'm still trying to wrap my head around "calls back into the motion"
[21:13:10] <robin_z> something like goto(X,Y);
[21:13:23] <robin_z> whileIsMoving();
[21:14:13] <anonimasu> :)
[21:14:20] <jmkasunich> what is the main program doing while this VB thing runs?
[21:14:36] <robin_z> waiting for it to return
[21:14:49] <robin_z> lights and dials stillwork of course
[21:15:00] <jmkasunich> does the main program actually link to and call the VB, and the VB is linked in such a way that it can call C functs in the main program?
[21:15:03] <alex_joni> and if it never returns.. it's just another push the reset button m$ thingy
[21:15:35] <robin_z> yep, it calls c functions in the main prog
[21:15:50] <robin_z> and can read certain things
[21:15:55] <robin_z> like
[21:15:56] <jmkasunich> how does that work.... isn't the VB thing running in another process
[21:16:13] <robin_z> (x,y)=getCurrentPositon();
[21:16:24] <robin_z> no idea
[21:16:38] <jmkasunich> very helpfull
[21:16:39] <robin_z> it might be on another thread, I have no idea how 'doze does its thing
[21:16:53] <robin_z> its closed source, how could I know?
[21:17:25] <jmkasunich> perhaps RPC or some such rot (or the win version of it)
[21:17:35] <jmkasunich> in any case, all this happens in user space
[21:17:41] <robin_z> correct
[21:17:48] <jmkasunich> above the level of the motion controller
[21:17:55] <robin_z> correct
[21:18:10] <alex_joni> I think the motion controller exports some entrypoints to functions that it provides
[21:18:19] <alex_joni> and the VB part can access this functions
[21:18:39] <robin_z> yeah, you can do the same with LUA, export what it can call and how
[21:19:08] <alex_joni> robin: a lot of this stuff doesn't exist in emc
[21:19:14] <jmkasunich> in EMC, M101-199 or whatever actually forks a process that can execute anything it wants... bash script, compiled C program, whatever
[21:19:15] <robin_z> the LUA interp is then embedded in your application and when you call M3, it digs out the M3 script and works through it
[21:19:15] <alex_joni> export functions for motion
[21:19:24] <alex_joni> to be called by other folks
[21:19:44] <alex_joni> jmk: yes, but it can't communicate back with the interp.
[21:19:56] <robin_z> I dont get why you want to handle M3 through an entirely seperate mechanism to M101
[21:20:08] <robin_z> is having two mechanisms easier than one?
[21:20:30] <alex_joni> robin: could be the same for M1-199
[21:20:31] <jmkasunich> when you put it that way...
[21:21:20] <jmkasunich> but it seems to me that revising the effect of M3 (or M101) means changing the _language_ of the g-code, not just changing the machine
[21:21:57] <robin_z> Mx have been hijacked to hell and backalready
[21:22:20] <jmkasunich> so it's OK to do it some more?
[21:22:25] <robin_z> almsot every plasma on the planet uses M3 or M15 or M8 for "on"
[21:23:22] <robin_z> is it sensiblel to define M3 as "spindle on" on a machine with no spindle?
[21:23:46] <jmkasunich> is it sensible to use the spindle on M code on a machine with no spindle?
[21:24:01] <robin_z> is it the spindle on mcode?
[21:24:09] <robin_z> or "just an mcode"
[21:24:10] <jmkasunich> if M3 is defined in the language as spindle on, then don't fsck with the definition, use a different code
[21:24:33] <robin_z> ah well.
[21:24:37] <jmkasunich> you hit it on the head... is M3 spindle on, or just an M code
[21:24:57] <jmkasunich> if they are all "just an M code", seems to me you have chaos
[21:25:13] <robin_z> im sure there is a leather bound volume with it written in gold leaf
[21:25:19] <robin_z> but in reallity ....
[21:25:24] <robin_z> they get jijacked
[21:25:28] <robin_z> hijacked
[21:25:42] <jmkasunich> the language becomes whatever the machine builder wants it to be, and portability of part programs vanishes in a puff of smoke
[21:25:56] <anonimasu> yep
[21:26:02] <jmkasunich> of course that's good for commercial control makers
[21:26:07] <robin_z> well ...
[21:26:15] <robin_z> surely the opposite?
[21:26:34] <jmkasunich> huh>
[21:26:36] <jmkasunich> ?
[21:26:45] <robin_z> if M3 turns my plasam on (doing whatever funky crap is needed to do that, lowering heads, squirting in water etc) ...
[21:26:54] <robin_z> then I can use the same code on my laser
[21:27:02] <robin_z> with M3 turning on the laser
[21:27:22] <jmkasunich> and on your mill
[21:27:34] <jmkasunich> in all cases, M3 turns on the "cutter"
[21:27:46] <jmkasunich> tool diameter may be different, but they all cut
[21:27:54] <robin_z> true
[21:28:01] <jmkasunich> as long as cutter comp is set correctly, all is well
[21:28:09] <robin_z> but the process for turnig it on may be VASTLY different
[21:28:51] <robin_z> eg my Trumpf laser ...
[21:28:53] <jmkasunich> M code is the same, result is the same... ON command goes out to <something>, "I'm on and ready to cut" comes back
[21:29:16] <robin_z> or doesnt come on ...
[21:29:31] <robin_z> (eg failed to detect any material under the torch)
[21:29:44] <jmkasunich> in which case what should the machine do?
[21:29:48] <robin_z> retracts ... pauses the interp
[21:30:01] <jmkasunich> interp is already paused, waiting for OK
[21:30:09] <robin_z> waits for the door on the head to be opened (to inspect to see if there is any material)
[21:30:19] <robin_z> then you cna shut it and press start again
[21:30:23] <robin_z> it retries
[21:30:44] <robin_z> (thats real world btw)
[21:30:49] <robin_z> not made up
[21:31:19] <jmkasunich> I belive you.
[21:31:32] <jmkasunich> and it could easily be handled by ON and OK pins
[21:31:40] <robin_z> I know ...
[21:31:49] <robin_z> but where do you put the logic?
[21:31:55] <robin_z> the code to do that?
[21:32:08] <jmkasunich> in the module that is between the ON and OK pins and the actual hardware
[21:32:39] <jmkasunich> could be PLC
[21:32:43] <robin_z> * robin_z ponders
[21:32:43] <jmkasunich> could be C
[21:33:28] <robin_z> so, say for instance, the first part of my "M3" or "M103" call
[21:33:38] <robin_z> is to lower the torch .. using the Z axis ..
[21:33:56] <robin_z> thats a call back into the EMC motion right?
[21:33:56] <jmkasunich> hold it
[21:34:12] <robin_z> * robin_z holds it.
[21:34:29] <robin_z> can I let go yet?
[21:34:31] <jmkasunich> G0 Z0 tells the Z axis where to go
[21:35:08] <robin_z> in my Gcode part program?
[21:35:08] <jmkasunich> and 500 lines later, if there hasn't been a subseqent line that commands Z movement, the program has every right to expect that Z is still at 0
[21:35:25] <jmkasunich> having your macro move Z sounds like a disaster waiting to happen
[21:35:47] <robin_z> well, i have NO Z commands in my part programs
[21:35:50] <alex_joni_> jmk: I think robin was talking about 2.5 axes
[21:35:57] <alex_joni_> XY with G-Code
[21:36:00] <alex_joni_> Z with Mcodes
[21:36:17] <alex_joni_> not actually an axis, but one that can do up/down
[21:36:18] <jmkasunich> then your G-code doesn't include Z, and Z IS NOT a motion controller axis
[21:36:24] <alex_joni_> maybe a pneumatic axis
[21:36:30] <alex_joni_> jmk: right
[21:36:38] <robin_z> well, it moves up and down ...
[21:36:50] <jmkasunich> you have a two axis motion controller, and Z can be managed in HAL
[21:37:08] <robin_z> OK ...
[21:37:12] <robin_z> so
[21:37:42] <robin_z> I still dont see where I put this macro logic ...
[21:37:52] <robin_z> code and associated mess
[21:38:06] <jmkasunich> in your case, none of it needs to be realtime?
[21:38:26] <jmkasunich> so you favor user space macros, LUA, VB, whatever
[21:38:28] <robin_z> mmm ... not realtime realtime, no
[21:38:37] <robin_z> anything but VB ;)
[21:38:41] <robin_z> LUA, whatever
[21:38:44] <jmkasunich> what about torch height control
[21:38:51] <robin_z> thats realtime
[21:38:56] <anonimasu> I'd think about classicladder for that..
[21:39:25] <robin_z> after the pierce delay, i expect to call torchHeightOn(0.8); or whatever
[21:39:47] <robin_z> again, not from the part file gcode
[21:40:00] <jmkasunich> right
[21:40:14] <robin_z> a bit like stepnc really
[21:40:25] <robin_z> M3 .. start cutting ...
[21:40:26] <jmkasunich> so I _can_ but don't have to do startup in realtime
[21:40:29] <anonimasu> how do other controllers to this?
[21:40:35] <jmkasunich> I must do torch height in realtime
[21:40:39] <robin_z> anonimasu: using macros
[21:41:02] <robin_z> anonimasu: my Bosch control on the Trumpf laser has 999990xxx assigned to macros
[21:41:03] <jmkasunich> for the non-realtime parts
[21:41:10] <robin_z> thes manage everything for the machine
[21:41:20] <robin_z> like ... lube cycle for the bed ways
[21:41:26] <robin_z> piercing
[21:41:36] <robin_z> setting torch heights
[21:41:43] <robin_z> you name it.
[21:42:20] <robin_z> as it happens its M934 for start cutting on the trumpf ...
[21:42:27] <robin_z> that will call a bunch of the others
[21:42:40] <robin_z> closing the bed covers, turning on extraction
[21:42:42] <robin_z> blah
[21:42:57] <anonimasu> yeah but thoose are parts that are separate from the motion part..
[21:43:12] <robin_z> well, no
[21:43:17] <anonimasu> yes..
[21:43:19] <robin_z> some control the Z axis
[21:43:24] <robin_z> som control the U axis
[21:43:30] <jmkasunich> what is U
[21:43:37] <robin_z> (the crap catcher under the torch)
[21:43:47] <robin_z> a moving bucket
[21:43:55] <jmkasunich> U is parallel to Z?
[21:44:06] <robin_z> U is similar to X
[21:44:15] <jmkasunich> OK, so there is V too, then
[21:44:16] <robin_z> but 10" lower :)
[21:44:19] <robin_z> no
[21:44:23] <robin_z> just U
[21:44:32] <jmkasunich> full width bucket?
[21:44:33] <robin_z> its a Y width bucket
[21:44:54] <jmkasunich> oh, stationary gantry, moving X
[21:45:06] <robin_z> moving gantry in X and Y
[21:45:13] <jmkasunich> ignore last statement
[21:45:13] <robin_z> moving bucket in U
[21:45:23] <robin_z> sometimes U is closely linked to X
[21:45:27] <robin_z> soemtimes its not
[21:45:44] <robin_z> but anyway
[21:46:10] <robin_z> the specifics are not important ... its the priciple ... can Mcodes do stuff to the motion
[21:46:20] <anonimasu> not like they are now..
[21:46:24] <anonimasu> but they should be able to
[21:46:43] <robin_z> for instance ...
[21:46:54] <anonimasu> imo a M code should be like when you cann a sub inside a program..
[21:46:59] <anonimasu> call..
[21:47:05] <robin_z> hook a button on the GUI to "M909", label it "Park"
[21:47:20] <robin_z> when you pressit it runs the "park" macro
[21:47:27] <anonimasu> so you can pipe your code back into emc.. and output commands to HAL for example..
[21:47:37] <jmkasunich> what if you are in the middle of a G-code program when you press part
[21:47:40] <jmkasunich> park
[21:47:46] <anonimasu> then it launches the "sub"
[21:47:50] <robin_z> a big hammer comes out and hits you
[21:48:10] <jmkasunich> seriously...
[21:48:14] <robin_z> dunno
[21:48:18] <robin_z> never tried it :)
[21:48:27] <robin_z> probably Bad Things happen
[21:48:40] <anonimasu> that's not really a big issue, but with the current interpreter it's impossible..
[21:48:49] <jmkasunich> your saying the macro can be invoked from both G-code and the front panel, it's inevitable that sooner or later someone will do it
[21:49:00] <anonimasu> yes..
[21:49:09] <robin_z> * robin_z nods
[21:49:15] <jmkasunich> or maybe the answer is "in auto mode, the macros can only be invoked by the program, in MDI mode only from the panel"
[21:49:21] <robin_z> sounds fine
[21:49:22] <anonimasu> hm..
[21:49:22] <anonimasu> nah
[21:49:25] <anonimasu> wouldnt help all the time..
[21:49:26] <robin_z> sorta
[21:49:30] <anonimasu> you might have aux funtions..
[21:49:35] <robin_z> * robin_z nods
[21:49:38] <anonimasu> but that's another issue..
[21:49:42] <robin_z> when program is running ...
[21:49:52] <jmkasunich> after all, same applied to jog - you can't jog from the panel when your in auto
[21:49:58] <anonimasu> true.
[21:50:06] <anonimasu> maybe you shouldnt be able to call macros while running..
[21:50:15] <robin_z> * robin_z nods
[21:50:21] <anonimasu> how do commercial machines do it?
[21:50:35] <jmkasunich> well you need to call em while running - but you call em from the g-code program
[21:50:41] <anonimasu> exactly
[21:50:42] <robin_z> true
[21:51:13] <anonimasu> hold motion ( remember position keep executing code..
[21:51:14] <anonimasu> )
[21:51:22] <anonimasu> err execute other motion code..
[21:51:30] <anonimasu> like retract Z and stop spindle..
[21:51:46] <anonimasu> maybe the same way somone talked about EDM's and backing up..
[21:51:58] <anonimasu> jogging back a bit and pressing the button again to continue the motion..
[21:52:12] <jmkasunich> for laser and plasma, I really would have only a 2 axis motion controller, and control Z independently
[21:52:31] <robin_z> fine by me
[21:52:44] <jmkasunich> a G code commanding Z motion should result in an error
[21:52:44] <robin_z> and waterjet?
[21:52:52] <jmkasunich> likewise I think?
[21:53:07] <robin_z> hint: waterjet has A and B axes :)
[21:53:16] <jmkasunich> oh, for taper control
[21:53:20] <robin_z> uh huh
[21:53:23] <robin_z> but again ...
[21:53:25] <anonimasu> hm.. I wonder how commercial machines do it..
[21:53:34] <robin_z> maybe thats not an axis per-se
[21:53:38] <anonimasu> you cant enter things while the program is running or can you?
[21:53:40] <jmkasunich> are they usually "programmed" as part of the G-code, or computed on the fly by the controller
[21:53:47] <jmkasunich> I bet the part program is still 2D
[21:53:49] <robin_z> computed on the fly
[21:53:52] <robin_z> yeah
[21:54:02] <anonimasu> can you execute macros off the panel while the program is running?
[21:54:06] <anonimasu> I'd think not..
[21:54:15] <robin_z> probably not
[21:54:22] <robin_z> infact laets say "no"
[21:54:26] <anonimasu> in the case of a mill I think the only settings you should be able to do while running are send NML messages..
[21:54:31] <anonimasu> so alter feed and things like that
[21:54:38] <robin_z> yeah
[21:54:41] <anonimasu> that's about what you can do and pause the motion..
[21:55:09] <robin_z> my "pause" button linked to a macro
[21:55:21] <robin_z> all it did was set a bit though
[21:55:54] <robin_z> durning an "M5" it stopped the plasama, retracted and then checked if it was supposed to keep going
[21:55:57] <jmkasunich> my problem with allowing both the panel and the program to invoke macros is that you are essentially setting up two independent threads
[21:55:58] <robin_z> or just pause
[21:56:05] <anonimasu> yep..
[21:56:06] <jmkasunich> with all the contention and other issues that impllkes
[21:56:09] <robin_z> * robin_z nods
[21:56:49] <anonimasu> the question is if you need that functionality..
[21:56:54] <robin_z> whheeeee this has been fun
[21:56:59] <anonimasu> it adds loads to the complecity of the interpreter..
[21:57:04] <anonimasu> complexity..
[21:57:14] <jmkasunich> been? you leaving?
[21:57:17] <robin_z> not really
[21:57:36] <robin_z> just replace all the "M" codes with calls to macros
[21:58:09] <robin_z> or more to the ppint
[21:58:09] <anonimasu> robin_z: yeah but while you are running a prorgam..
[21:58:12] <anonimasu> program..
[21:58:19] <robin_z> calls to the macro handler
[21:58:27] <jmkasunich> the macros would then issue cannonical motion commands (among other things)?
[21:58:35] <anonimasu> yes
[21:58:49] <robin_z> yes
[21:58:50] <anonimasu> robin_z: but if you break the program from the panel in the middle of the motion
[21:58:55] <anonimasu> like "hold"
[21:58:59] <robin_z> uh huh
[21:59:03] <anonimasu> how would you do that?
[21:59:10] <anonimasu> or I might have gotten it wrong..
[21:59:39] <robin_z> hold sends an nml message to the interp/task I guess
[21:59:52] <anonimasu> yeah, but how do you go on about the motion..
[22:00:02] <anonimasu> in the middle of the running program..
[22:00:16] <anonimasu> unless you have a m314 in your program for checking if it should keep going..
[22:00:17] <robin_z> you mean like our pause button now?
[22:00:20] <anonimasu> yeah..
[22:00:27] <jmkasunich> the interp can't do anything about a message... it has passed control off to the macro handler
[22:00:29] <robin_z> well, that would be pause I guess
[22:00:31] <anonimasu> but with retract like you talked it about earlier..
[22:00:40] <robin_z> ah right
[22:00:42] <jmkasunich> which has issued a motion command and is waiting for it to complete
[22:01:03] <anonimasu> how does it go with the motion planner?
[22:01:09] <anonimasu> I can see how you can do it interpreter wise..
[22:01:28] <robin_z> can I say "I dont know"?
[22:01:32] <anonimasu> yeah :)
[22:01:34] <jmkasunich> no
[22:01:38] <anonimasu> somthing like grab the computed segments.. and save them to memory..
[22:01:44] <robin_z> damn.
[22:01:47] <anonimasu> and continue your own motion..
[22:02:12] <anonimasu> and then move back to the point and load the old segments again..
[22:02:17] <anonimasu> and continue the motion..
[22:02:23] <jmkasunich> pause, like feedrate override and some others, makes things complicated
[22:02:32] <robin_z> yeah
[22:02:40] <robin_z> its always the edge cases which are the hardest
[22:03:06] <jmkasunich> otherwise, I can actually see the appeal in the macro based system... everything is a macro, including all M codes _AND_ all GUI controls
[22:03:32] <robin_z> suits me
[22:03:43] <robin_z> makes a lot of tings a LOT simpler if you ask me
[22:03:50] <jmkasunich> but if it can't handle the edge cases, it doesn't work
[22:03:58] <jmkasunich> so how do you handle the edge cases?
[22:04:08] <anonimasu> the trouble is defining what edge cases is..
[22:04:09] <anonimasu> really :D
[22:04:14] <robin_z> well yeah
[22:04:25] <anonimasu> there's a point where it's not possible without major modification..
[22:04:29] <anonimasu> what are thoose cases..
[22:04:37] <jmkasunich> pause
[22:04:38] <robin_z> pause and stop I guess
[22:04:48] <jmkasunich> anything that needs to interrupt a motion in progress
[22:05:06] <robin_z> I guess my button that has "pause" written on it is not actually pause
[22:05:23] <robin_z> its "pause at end of part request"
[22:05:24] <jmkasunich> another issue is what happens when a macro has a bug and never returns
[22:05:28] <anonimasu> yep..
[22:05:32] <robin_z> well yeah
[22:05:36] <robin_z> thats an issue
[22:05:44] <anonimasu> jmkasunich: send a error message and break the execution..
[22:05:55] <anonimasu> jmkasunich: that can kill somone..
[22:06:57] <alex_joni> an0n: add even more error messages ;)
[22:06:59] <anonimasu> yeah..
[22:07:03] <alex_joni> :(
[22:07:07] <anonimasu> alex_joni: well users are stupid..
[22:07:12] <alex_joni> I know
[22:07:25] <alex_joni> I don't expect many users to be able to code macros
[22:07:27] <anonimasu> you cant make stuff that's impossible to break just minimize the damge when it breaks..
[22:08:15] <alex_joni> anyways...
[22:08:34] <alex_joni> jmk, robin: any conclusions on the macro stuff?
[22:08:59] <alex_joni> robin: I can't see how a macro is different from a .c file
[22:09:16] <robin_z> doesnt need compiling ?
[22:09:17] <alex_joni> you need almost the same programming skills to program it
[22:09:18] <anonimasu> alex_joni: you need to be able to send stuff back into emc..
[22:09:26] <jmkasunich> macros should be in a more "accessible" language
[22:09:26] <anonimasu> alex_joni: motion also..
[22:09:42] <robin_z> * robin_z nods at what jmkasunich said
[22:09:51] <alex_joni> jmk: agreed
[22:09:54] <alex_joni> but...
[22:10:02] <alex_joni> that would add yet another thing to emc
[22:10:10] <jmkasunich> actually, I like the existing M101 approach... it forks and executes somethign that can be any language you want
[22:10:20] <alex_joni> even a script
[22:10:22] <anonimasu> oh, but you need it..
[22:10:25] <alex_joni> or macro if you will
[22:10:33] <jmkasunich> since it forks, it can also have timeouts or other ways of responding to macros that never reutrn
[22:10:49] <alex_joni> only thing it can't talk back to emc
[22:10:50] <jmkasunich> what it needs is a way to hook back into emc tho
[22:10:54] <alex_joni> right
[22:10:54] <robin_z> does it fork?
[22:11:09] <robin_z> * robin_z isnt sure it forks
[22:11:12] <alex_joni> a new process is spawn
[22:11:16] <alex_joni> not forked
[22:11:16] <robin_z> sure?
[22:11:20] <robin_z> * robin_z isnt sure
[22:11:25] <alex_joni> exec_le?
[22:11:30] <alex_joni> * alex_joni looks
[22:11:36] <jmkasunich> it must - if it just did an exec, the existing process would be _replaced_ by the new one, no turning back from that
[22:11:59] <jmkasunich> alex_joni: fork _does_ spawn a new process
[22:12:00] <robin_z> what if I include luainterp.lib
[22:12:23] <alex_joni> jmk: right
[22:12:27] <jmkasunich> I like the idea of macros being in any language, including bash
[22:12:34] <robin_z> and just call luaProcFile("some_macro_name.lua")
[22:12:45] <alex_joni> confused fork
[22:13:52] <robin_z> my brief look at lua
[22:14:05] <jmkasunich> why is it always something new with you...
[22:14:06] <robin_z> was that it was generic enough to be doable by any programmer
[22:14:13] <jmkasunich> XML, lua, python, etc, etc
[22:14:15] <robin_z> shrug
[22:14:24] <robin_z> eek]I NEVER said python :)
[22:14:43] <robin_z> and XML isnt new
[22:14:43] <jmkasunich> maybe it was perl - one of those P words... I can't tell em apart
[22:14:54] <robin_z> ugh, no perl in here please
[22:16:48] <robin_z> anyway, LUA is what Sheetcam uses for its post processors
[22:17:00] <jmkasunich> * jmkasunich is reading about Lua
[22:17:09] <anonimasu> laters everyone
[22:17:15] <anonimasu> :)
[22:17:16] <robin_z> it was the first ting that came into my head when you asked for a macro language
[22:17:23] <anonimasu> I need to rest a bit
[22:17:48] <jmkasunich> "Lua is implemented as a library, written in clean C (that is, in the common subset of ANSI C and C++). "
[22:17:52] <jmkasunich> I like that
[22:20:14] <alex_joni> aaaargh
[22:20:22] <alex_joni> I hate this kind of naming
[22:22:48] <jmkasunich> something tells me LUA is _not_ fast
[22:22:59] <jmkasunich> associative arrays ;-)
[22:23:11] <robin_z> depends ...
[22:23:16] <robin_z> they can be fast
[22:23:22] <alex_joni> now who tf codes like this
[22:23:30] <alex_joni> if (USER_DEFINED_FUNCTION[index - 100] ISNT 0) {
[22:23:39] <jmkasunich> Fred?
[22:23:39] <robin_z> hmmm
[22:23:42] <alex_joni> CHK(1, NCE_UNKNOWN_M_CODE_USED);
[22:23:45] <alex_joni> darn
[22:23:48] <jmkasunich> Tom Kramer?
[22:24:11] <jmkasunich> those IS, ISNT, etc macros are an abomination
[22:24:19] <jmkasunich> thank god I don't work on the interpreter
[22:24:24] <alex_joni> I agree
[22:24:30] <jepler> jmkasunich: I think it was a rhetorical question
[22:24:35] <jmkasunich> robin_z: associative arrays are _not_ fast
[22:24:40] <robin_z> surely you mean FRED or TOM_KRAMER
[22:24:45] <alex_joni> I am still searching where the M-code gets run
[22:24:54] <alex_joni> robin: RIGHT
[22:25:15] <jepler> associative arrays can be fast _enough_.
[22:25:24] <jmkasunich> for certain values of "fast"
[22:25:27] <robin_z> jmkasunich: not as fast as direct variable access, but how fast do we need to be here?
[22:25:35] <alex_joni> I found where the executables are searched, and filled into an array, but didn't find the fork yet
[22:25:38] <jmkasunich> I know... just my biases showing
[22:25:42] <jepler> if this isn't realtime, it'll be "fast enough".
[22:25:57] <robin_z> assoc. arrays are programmer friendly
[22:25:57] <paul_c> alex_joni: emctask.cc
[22:26:05] <jmkasunich> * jmkasunich should be locked in a room labeled "realtime only:
[22:26:06] <robin_z> but slow as you say
[22:26:28] <jmkasunich> kinda hard to loop thru one too
[22:26:36] <robin_z> optimize for programmer time, let moore's law sort the rest out ;)
[22:26:44] <robin_z> nah
[22:26:53] <jmkasunich> I'm a hardware guy at heart
[22:27:15] <robin_z> foreach my $key ( keys %foo ) { ... } # in perl
[22:27:32] <robin_z> the order of keys os of course weird as hell
[22:27:45] <jmkasunich> well, if you have a foreach operator, then yes it's easy
[22:28:17] <robin_z> languages that hav assoc. arrays tend to have appropriate functions
[22:28:21] <alex_joni> jmk: I think this is the calling code: (*(USER_DEFINED_FUNCTION[index - 100]))(index - 100, block->p_number, block->q_number);
[22:28:39] <robin_z> ugh
[22:28:40] <jepler> fwiw Python's dict lookup is "0.332 usec per loop" on this 1.5GHz hardware.
[22:28:41] <jmkasunich> line number and file?
[22:29:02] <jmkasunich> about 500 instructions... I rest my case
[22:29:07] <robin_z> alex_joni: is this a find the ugliest line competition?
[22:29:16] <jmkasunich> find the fork competition
[22:29:17] <alex_joni> robin: nope
[22:29:24] <alex_joni> I think it's not a fork
[22:29:28] <alex_joni> it's a simple call
[22:29:32] <robin_z> it sure is ugly though
[22:29:45] <jmkasunich> how can a simple call execute a bash script?
[22:30:02] <jmkasunich> (and I know M101 can be used to invoke a bash script)
[22:30:07] <alex_joni> rs274ngc_pre.cc (convert_m function)
[22:30:44] <robin_z> * robin_z isnt sure
[22:32:36] <alex_joni> this is really tough to read
[22:32:42] <robin_z> no kidding
[22:32:47] <alex_joni> nope
[22:32:48] <alex_joni> :D
[22:33:00] <alex_joni> emctask.cc (int emcTaskInit() )
[22:33:04] <robin_z> jmkasunich: so did the Lua stuff look stat bad?
[22:33:48] <alex_joni> jmk: as far as I see it, the programs/M1XX get searched for executable files
[22:33:58] <alex_joni> and those get added as user_functions
[22:34:13] <jmkasunich> robin_z: not really...
[22:34:14] <alex_joni> and run later when M1XX is encountered
[22:35:44] <paul_c> emctaskmain.cc:431
[22:38:36] <jmkasunich> line 444 has the fork
[22:38:46] <alex_joni> right.. so when the M1XX is encountered actually the function called appends to the interp_list
[22:38:57] <alex_joni> and the interp then does the fork?
[22:39:11] <jmkasunich> dunno ;-)
[22:39:15] <paul_c> task handles the fork
[22:39:37] <alex_joni> right
[22:39:39] <paul_c> The interp does not do anything apart from tokenising an ngc file
[22:39:58] <alex_joni> once again it's very clear :D
[22:40:03] <jmkasunich> who calls int emcSystemCmd(char *s)
[22:40:35] <alex_joni> I was wondering who calls "user_defined_add_m_code"
[22:40:48] <alex_joni> that's the function that gets registered for custom M1XX codes
[22:41:00] <alex_joni> and that function appends to interp_list
[22:41:11] <alex_joni> if I interpret: interp_list.append(system_cmd);
[22:42:42] <alex_joni> actually it's not interpreter (interp is from interpl.cc)
[22:43:00] <alex_joni> interplist.cc
[22:43:24] <jmkasunich> looks like NML message EMC_SYSTEM_CMD_TYPE invokes it
[22:43:53] <alex_joni> if I got this straight...
[22:44:08] <alex_joni> 1. task searches for executable files in programs/M1xx
[22:44:50] <alex_joni> 2. task adds for found files a function called user_defined_add_m_code to USER_DEFINED_FUNCTION
[22:45:12] <alex_joni> 3. during run of a program interpreter encounters a M1XX code
[22:45:51] <alex_joni> 4. interpreter calls the defined function (user_defined_add_m_code with params number (XX) and P & Q)
[22:46:30] <alex_joni> 5. the function adds a message to interp_list (interp_list.append(system_cmd)), which is a EMC_SYSTEM_CMD_TYPE message for task
[22:46:50] <alex_joni> 6. task gets the message and runs the function (fork, spawn, whatever)
[22:47:30] <jepler> emctaskmain.cc: 19-Mar-2004 FMP changed 'system' to 'execvp' so we can abort SYSTEM commands
[22:48:49] <alex_joni> jepler: that's the exact run of the file
[22:49:01] <alex_joni> but first a child has be spawned with fork
[22:49:06] <alex_joni> and the child runs execvp
[22:49:10] <paul_c> alex_joni: Just where did you see EMC_SYSTEM_CMD_TYPE with interp append ?
[22:49:27] <alex_joni> in user_defined_add_m_code
[22:49:57] <paul_c> nope
[22:50:05] <alex_joni> emctask.cc
[22:50:17] <alex_joni> EMC_SYSTEM_CMD system_cmd;
[22:50:18] <alex_joni> strcpy(fmt, user_defined_fmt);
[22:50:18] <alex_joni> strcat(fmt, " %f %f");
[22:50:18] <alex_joni> sprintf(system_cmd.string, fmt, num, arg1, arg2);
[22:50:18] <alex_joni> interp_list.append(system_cmd);
[22:50:35] <paul_c> EMC_SYSTEM_CMD != EMC_SYSTEM_CMD_TYPE
[22:50:53] <alex_joni> well... EMC_SYSTEM_CMD
[22:51:06] <alex_joni> jmk confused me with _TYPE
[22:51:07] <alex_joni> ;)
[22:51:25] <jmkasunich> _TYPE is #defined to a number that identifies the message type
[22:51:38] <jmkasunich> without the _TYPE is the actual message (I think)
[22:51:51] <robin_z> eek, the madness is starting again ;)
[22:52:08] <alex_joni> jmk: right
[22:52:13] <jmkasunich> time for dinnner
[22:52:18] <alex_joni> without TYPE is the message
[22:52:22] <jmkasunich> jmkasunich is now known as jmk_dinner
[22:52:25] <robin_z> out to lunc more like ;)
[22:52:31] <alex_joni> message_TYPE is the type of the message
[22:52:31] <alex_joni> :D
[22:52:59] <alex_joni> anyways...
[22:53:09] <alex_joni> pretty "unpretty"
[22:54:12] <robin_z> remarkably
[22:54:15] <paul_c> inrerp_list is just a linked list that uses some of the rcslib classes.
[22:54:32] <alex_joni> interp_list is the list with commands that task parses
[22:54:34] <paul_c> It has nothing, repeat, nothing to do with NML messages.
[22:55:02] <alex_joni> paul_c: might only be local (not an actual NML-channel)
[22:55:19] <robin_z> paul_c: any comment on the macros thing?
[22:55:45] <paul_c> NO
[22:56:04] <alex_joni> interplist.cc
[22:56:05] <alex_joni> Mechanism for queueing NML messages, used by the interpreter and
[22:56:05] <alex_joni> canonical interface to report list of NML statements from program
[22:56:05] <alex_joni> files to HME.
[22:57:31] <alex_joni> emctaskmain.cc
[22:57:32] <alex_joni> In auto mode, the interpreter is called
[22:57:32] <alex_joni> and as a result the interp_list is appended with NML commands.
[22:57:45] <paul_c> I see an append, a get, a clear, and a len method
[22:57:58] <alex_joni> right
[22:58:07] <alex_joni> it's a linked-list derivative
[22:58:08] <paul_c> I do not see any NML inheritance.
[22:58:14] <alex_joni> not an actual NML-channel
[22:58:30] <alex_joni> but data that is appended can be NML-messages
[22:58:39] <paul_c> No NML channels, No NML messages
[22:58:51] <robin_z> sounds like heaven :)
[22:58:52] <alex_joni> int NML_INTERP_LIST::append(NMLmsg &nml_msg)
[22:59:33] <alex_joni> now if NMLmsg is not a NML message... then I must reconsider my thoughts on RCS&co.
[23:01:49] <alex_joni> on the other hand... who cares?
[23:02:00] <paul_c> would suggest looking at where NML_INTERP_LIST is used
[23:02:05] <alex_joni> * alex_joni doesn't really care if it's a NML message or not
[23:02:21] <alex_joni> NML_INTERP_LIST interp_list;
[23:02:39] <robin_z> * robin_z hits the sherry
[23:02:48] <robin_z> hic
[23:02:54] <alex_joni> which is the interp_list emctaskmain.cc talks about
[23:03:26] <alex_joni> robin: pass some sherry this way
[23:03:55] <robin_z> * robin_z passes alex_joni a glass
[23:03:57] <paul_c> emctask & emctaskmain is 'bout the only place it does get used.
[23:04:23] <alex_joni> I'd suspect so... hic
[23:05:03] <alex_joni> and emccannon
[23:05:22] <robin_z> canon?
[23:05:35] <alex_joni> canon
[23:05:36] <robin_z> * robin_z gets out his gunpowder
[23:08:15] <alex_joni> darn.. I'm really too tired to get phrases like: Move in a helical arc from the current location at the existing feed
[23:08:16] <alex_joni> rate. The axis of the helix is parallel to the x, y, or z axis,
[23:08:16] <alex_joni> according to which one is perpendicular to the selected plane. The
[23:08:16] <alex_joni> helical arc may degenerate to a circular arc if there is no motion
[23:08:16] <alex_joni> parallel to the axis of the helix.
[23:10:09] <robin_z> sounds about right
[23:10:22] <paul_c> makes perfect sense here.
[23:10:25] <robin_z> do a helix, unless it flat
[23:10:34] <robin_z> in which case, do a circle
[23:10:53] <alex_joni> well after reading it for the second time I got it too
[23:11:36] <alex_joni> robin: but I think the way you put it sounds easier to read ;)
[23:12:38] <alex_joni> hmmm.. seems there are nicer things out there than emc-style-coding
[23:12:39] <alex_joni> public boolean compareObjects(Object obj1 , Object obj2) {
[23:12:39] <alex_joni> if (obj1.equals(obj2) == true)
[23:12:39] <alex_joni> return true;
[23:12:39] <alex_joni> else
[23:12:39] <alex_joni> return false;
[23:12:40] <alex_joni> }
[23:14:31] <jepler> alex_joni: pyooque
[23:14:36] <robin_z> ugh
[23:14:58] <alex_joni> http://thedailywtf.com/
[23:15:14] <robin_z> thats a hanging offence is that
[23:15:39] <robin_z> I can only hope the compiler optimises it out of existance
[23:16:23] <alex_joni> http://www.99-bottles-of-beer.net/
[23:19:32] <alex_joni> robin: how about that for-break?
[23:24:52] <alex_joni> * alex_joni found the perfect language for macros
[23:24:58] <alex_joni> not LUA... but COW
[23:25:00] <alex_joni> http://www.bigzaphod.org/cow/
[23:26:21] <alex_joni> * alex_joni is going to sleep
[23:26:24] <alex_joni> night guys
[23:28:02] <LawrenceG> oops... I'm a wee bit late...
[23:28:29] <alex_joni> hello there
[23:28:44] <alex_joni> I was jsut leaving.. but there are others still lurking around
[23:29:05] <robin_z> good choic moOO
[23:29:13] <robin_z> moO sorry
[23:29:19] <alex_joni> right MMM
[23:29:21] <LawrenceG> hi there... I meant to make the developers meeting.... I got tied up in coding bdi 4.2 stuff
[23:29:34] <alex_joni> heh.. whatcha coding?
[23:30:03] <robin_z> alex_joni: you'll *love* the Perl module Acme::Pony
[23:30:04] <LawrenceG> putting quadrature and phase drive back into emcmot
[23:30:39] <alex_joni> pony?
[23:30:53] <alex_joni> moo is kinda debian related
[23:31:05] <robin_z> http://search.cpan.org/dist/Acme-Pony/lib/Acme/Pony.pm
[23:31:06] <alex_joni> because apt already has super cow powers
[23:31:06] <alex_joni> :D
[23:31:20] <LawrenceG> looks like it build ok and I can see the bits flashing... have to go to the shop to see if it will run the machine
[23:31:27] <robin_z> sadly I know the author.
[23:31:42] <alex_joni> LawrenceG: nice to hear that
[23:31:55] <alex_joni> bug paul_c to include that on the next BDI
[23:32:35] <LawrenceG> yep... been talking to him about it.... its a pretty simple add
[23:32:53] <alex_joni> robin: how about hanoi as a language?
[23:32:54] <alex_joni> http://lilly.csoft.net/~jeffryj/compilers/hl/hanoi.txt
[23:33:18] <LawrenceG> once I have verified it works, I'll send it to Paul to get put in the cvs
[23:33:32] <alex_joni> robin: looks like this:
[23:33:32] <alex_joni> ..,...'...,.;'...,.;'...,.;'...,.;'...,.;'...,.;'...,.;'...,.;'...,.;'......
[23:33:32] <alex_joni> '..,'...:.,.'..,.;'...,.;'...,.;'...,.;'...,.;'...,.;'...,.;'...,.;'...,.;'.
[23:33:32] <alex_joni> ..,.;'...,.;'.....,...'....,...`.'......,!...;..,.'.....'..,'...:..,...'....
[23:33:32] <alex_joni> ..'..,'...:.,...`.'......,!...;.
[23:34:02] <alex_joni> LawrenceG: you might request CVS access and do it yourself !?
[23:34:12] <paul_c> LawrenceG: You have CVS access....
[23:34:20] <LawrenceG> I know....
[23:34:25] <alex_joni> well then... do it yourself
[23:34:33] <LawrenceG> it hurts too much!
[23:34:41] <alex_joni> what?
[23:34:51] <alex_joni> cvs commit -m "message" file ?
[23:35:01] <alex_joni> that's something even I remember ;)
[23:36:41] <LawrenceG> ok... will have to do another checkout as non anonymous.... correct?
[23:36:53] <alex_joni> right
[23:37:09] <alex_joni> you could change CVS tags.. but it's safer like that
[23:37:23] <robin_z> * robin_z tries Acme::Pony just for fun
[23:37:54] <robin_z> * robin_z decides to tell alex_joni about Perl
[23:38:03] <robin_z> you have used debian?
[23:38:10] <robin_z> and apt-get?
[23:38:53] <alex_joni> a bit
[23:38:57] <robin_z> well ...
[23:39:03] <alex_joni> well?
[23:39:07] <robin_z> perl -MCPAN -e shell
[23:39:09] <alex_joni> apt-get moo
[23:39:15] <robin_z> is the same sort of thing for Perl modules
[23:39:17] <alex_joni> try that
[23:39:24] <alex_joni> I used -MCPAN
[23:39:30] <robin_z> ah right
[23:39:36] <alex_joni> try "apt-get moo"
[23:39:36] <robin_z> it rocks, like apt-get
[23:39:47] <robin_z> apt-get install moo
[23:39:57] <alex_joni> nah
[23:40:00] <alex_joni> apt-get moo
[23:40:08] <robin_z> 'k
[23:40:22] <robin_z> oops, debain box is offline
[23:40:31] <alex_joni> bugger ;)
[23:40:42] <alex_joni> well.. I found a polite programming language
[23:40:45] <alex_joni> LOLOLOLOL
[23:41:01] <alex_joni> it's called INTERCAL
[23:41:21] <alex_joni> DO (600) NEXT
[23:41:21] <alex_joni> DO (101) NEXT
[23:41:21] <alex_joni> (71) DO RESUME .7
[23:41:21] <alex_joni> (50) DO (51) NEXT
[23:41:21] <alex_joni> PLEASE DO FORGET #1
[23:44:45] <alex_joni> ok.. bye