Feb 15 15:49:06 I was contacted by a guy who is wanting/starting to integrate EMC to a commercial machine. Feb 15 15:49:32 He was wondering if there would be an integration group at Fest? Feb 15 15:51:01 Monday would be the best day for that wouldn't it ? Feb 15 15:51:21 Not if we want any hands on stuff. Feb 15 15:52:34 something tells me emcfest is going to go by very fast Feb 15 15:52:35 most of the "hands on" stuff will be running at NAMES Feb 15 15:52:56 lots to do, very limited time to do it Feb 15 15:54:18 Do we all need to be doing the same thing during Fest? Feb 15 15:54:24 nope Feb 15 15:54:45 everybody will be doing their own thing to an extent Feb 15 15:54:58 Being the Devil's advocate here. Feb 15 15:55:05 good Feb 15 15:55:22 Not certain that I wanted to be bothered with int stuff either. Feb 15 15:55:32 But he had a good point. Feb 15 15:55:35 I talked to matt on the phone Fri, (he called with some hal questions), and we discussed the fest a little Feb 15 15:55:53 I'm all ears! Feb 15 15:56:20 two days isn't really much when you think about coding... but if we use it to define APIs, and do _design_, it can be very productive Feb 15 15:56:42 then we go back home and get into the time consuming details Feb 15 15:57:10 another priority for the fest is documentation - that will benefit from discussion Feb 15 15:58:38 I'm with you so far. Feb 15 15:58:41 documentation & discussions about the inner workings Feb 15 15:58:46 right Feb 15 15:59:16 But all of this sounds more like the Monday and evening formats. Feb 15 15:59:53 for instance... threading: we could sit down and figure out _how_ we want to attack it, and leave with block diagrams, flow charts, whatever... our chances of actually coding threading in two days are nil, but our chances of working out how to do it are good Feb 15 16:00:37 I can see that. Feb 15 16:00:56 last year we talked about threading, but not in enough detail that anyone could go off and write code Feb 15 16:01:30 Ilooking at the code base and examining areas that are potentially bugs Feb 15 16:01:38 (the other thing we didn't do last year is take notes) Feb 15 16:02:07 * paul_c proposes Matt brings his tape recorder Feb 15 16:02:09 Except Steve and that was a overview of the meeting. Feb 15 16:03:00 It still sounds to me like we are extending Monday into the Fest and expecting to focus on a topic at a time. Feb 15 16:03:34 tape is better than nothing, but audio is not a random access storage method Feb 15 16:03:44 rayh: perhaps.. Feb 15 16:03:48 I have a couple of topics I would like to discuss with Fred Feb 15 16:04:03 rather than as a group thing Feb 15 16:05:06 I can see that. I'd be willing to bet that several would like to listen. Feb 15 16:07:35 rayh: what are specific things you would like to see us actually working on Feb 15 16:07:47 (as opposed to discussing) Feb 15 16:07:59 Wow! I sure got a ton of warnings from the adeos kernel and modules compile. Feb 15 16:09:00 Oh! These meetings seem like a really good place to clarify that very question. It's not what I thing that we should be working on. Feb 15 16:09:11 It's what we think we should be working on. Feb 15 16:09:26 What I've attempted to do is make a place. Feb 15 16:09:36 sorry, I wasn't clear Feb 15 16:10:11 Sure you were and we needed me to say that. Feb 15 16:10:32 I was talking about using the fest to plan future work, you seemed concerned that that was just an extension of monday Feb 15 16:10:55 There are autocratic open source projects but this is not one of them. And if it were, I would not be a good autocrat for it. Feb 15 16:10:56 so I'm trying to figure out what you had in mind instead. Feb 15 16:11:10 * paul_c doesn't want to spend all three days talking integration issues.... Feb 15 16:11:26 I guess I was wondering what we would do with the compile farm, router, and all the cnc machines that we've listed. Feb 15 16:11:43 well of course we can (and will) do some hands on work Feb 15 16:12:05 the hardware can be used for testing and demonstrating bugs Feb 15 16:12:24 but I for one have been known to lose an hour or more fighting with some library function, or other silly little thing... not a good use of time when we are all together, better I do that at home Feb 15 16:12:58 I particularly want to do hands on work on docs - drawings, etc Feb 15 16:13:14 Maybe we need to change the arrangements for Fest so that they come more into line with what we are thinking. Feb 15 16:13:24 * paul_c wants to document some of the core source files. Feb 15 16:14:01 but for code, I'd rather write a detailed and commented .h file that defines what functs we intend to write, and what they do, etc., then go home to write the actual code Feb 15 16:14:27 Still need to settle the GPL question. Feb 15 16:14:37 what GPL question? Feb 15 16:14:45 No problems with that approach. Still don't need compile farm or cnc's. Feb 15 16:14:53 Charting my own progress so far in writing code, I'd have to say that I would probably be better using the fest time to gain a better understanding of the code, rather than actually doing a lot of coding. That said, I can't imagine that I will be able to do the _learning_ part without doing some coding at the same time. Feb 15 16:15:05 right, we need a mix Feb 15 16:15:06 re: NIST derived code - Can it be GPL'd Feb 15 16:15:12 yes it can Feb 15 16:15:23 we can do anything we want with it, including release it under GPL Feb 15 16:15:26 ditto (yes it can) Feb 15 16:15:45 if others want the pub domain stuff, they can get it from other places Feb 15 16:16:08 So I can go through the libnml adding GPL headers ? Feb 15 16:16:27 the one under emc2? Feb 15 16:16:29 BTW -- Got a big pile of probe and g-code conversion stuff from Dean just this morning. Feb 15 16:16:29 sure Feb 15 16:16:45 He was wondering where we ought to put it in the cvs? Feb 15 16:17:11 rayh: I think I know where the disconnect in our thinking is coming from.... Feb 15 16:17:27 The changes we're making will make emc2 code rather incompatible (compilation wise) with emc1, so we'll gpl it. People who want the public domain stuff will have to carefully extract it from emc1... Feb 15 16:18:01 talking of emc2.... Feb 15 16:18:04 I am thinking only of emc2 - I know very little about emc1, and am not inclined to learn more, so I'm thinking about what is needed to get emc2 running (hence design and coding) Feb 15 16:18:22 you are thinking of both, perhaps with more emphasis on emc1, so you are thinking debugging and testing Feb 15 16:19:00 under src/emc/ we have nml_intf & hal_intf - Should we have usr_intf for stuff like usrmot ? Feb 15 16:19:25 Perhaps. Not certain what I'm thinking. Wondering more. Feb 15 16:19:26 so far, I've tried to back port & forward port any bug fix stuff I do (emc1 <-> emc2), but it's tedious... Feb 15 16:20:07 There are some serious bugs, like the 25.4*degrees. Feb 15 16:20:15 paul_c: that's a sensible idea Feb 15 16:20:47 There are some serious features like accurate feedrate for angular. Feb 15 16:21:00 mshaver: OK - I'll probably move the emcsh & iosh stuff across too... Feb 15 16:21:05 rayh: those things should be worked on, but I'm not qualified to do so, nor should I comment on how to plan that work Feb 15 16:21:13 There is a serious need for spindle control using feedback. Feb 15 16:21:22 rayh: I'm hoping to put an end (once and for all) to all the units issues in emc2. Feb 15 16:21:32 paul_c: okie dokie Feb 15 16:22:31 matt brings up another point... some bugs can and should be fixed in both emc1 and emc2 - for instance, if there is a bug in the g-code interp, it can be fixed once and both places win. Feb 15 16:23:10 but other bugs will be fixed _only_ by the redesign/refactoring that is taking place in emc2 (unless you want to fix it separately in emc1) Feb 15 16:23:40 rayh: did the emcsh patch I sent over help with the linear/angular units in tkemc ? Feb 15 16:23:53 I've got no problem with moving to 2 and letting 1 stagnate. Feb 15 16:24:14 * paul_c would rather concentrate on emc2 Feb 15 16:24:18 paul_c: Yes but it broke rapid motion for angular. Feb 15 16:24:27 rayh: I just searched - I don't have twofish.* in my tree... Feb 15 16:26:04 * jmkasunich will be working almost exclusively on emc2, but that doesn't mean everyone at emcfest should do the same... bugfixes for emc1 are important too Feb 15 16:26:05 Re: John's comments on the portability of bug fixes - I'm "going to school" on emc2, and some things done there just can't be back ported easily (units stuff comes to mind). Feb 15 16:28:27 What I'm hearing about Fest is that it will focus on emc2. Feb 15 16:28:52 That we will study the overall structure and write headers. Feb 15 16:29:25 and write some code to try out ideas... Feb 15 16:29:43 and it would be cool to try out some of the motion stuff on real hardware Feb 15 16:29:58 If so, I propose that we leave the farm home, the cnc's in the trunk of the car, and get a xga projector. Feb 15 16:31:29 I disagree Feb 15 16:31:43 there are as many agendas for emcfest as there are participants Feb 15 16:33:38 believe me, I want to write code there... I'm just afraid I'll start doing that, and look up at 6pm on wednesday, and say "what happened, I didn't accomplish near what I intended to" Feb 15 16:33:55 we have to weigh the utility of having the farm & cnc machines against the time it will take to lug 'em in & hook 'em up & make 'em work... Feb 15 16:34:19 I know both of those feelings. Feb 15 16:35:00 anyway, I was just raising that concern, not trying to re-direct the goal of the fest Feb 15 16:35:20 and I'm bringing the farm whether anyone else wants it or not ;-) Feb 15 16:36:32 everyone OK with a usr_intf dir under emc/ ? Feb 15 16:36:33 what coding I do will probably be hal device drivers - for Jons boards, or STG, or whatever... and I'll want to test those so I'm bringing my motors too Feb 15 16:36:45 paul_c: sure Feb 15 16:37:31 Re: John's comment on time - we should probably start with a review of the code hierarchy at the corsest resolution and then run through it again (& again) @ increasing levels of detail. Feb 15 16:38:21 and as we get more detailed, maybe we will break into groups with each group taking notes... Feb 15 16:38:27 I got a note from Abdul that he's sending one of his new pci cards. Feb 15 16:38:30 paul_c: I'm down for that ;) (usr_intf) Feb 15 16:38:38 that's another one I want a hal driver for Feb 15 16:51:22 The conclusions of our Fest discussion then is that we want to leave what we've got in place. Feb 15 16:51:57 But at the same time try to limit other than code and documentation discussion and writing? Feb 15 16:52:25 yup - Concentrate on code & docs Feb 15 16:52:55 So we are saying no to integrators. Feb 15 16:53:27 hate to say no to anybody... Feb 15 16:54:04 what exactly do the integrators want? Feb 15 16:54:23 lay out the plans & goals for each day, and let the integrator(s) decide. Feb 15 16:54:24 if they want developers to give them hands on emc lessons, that would kill the fest Feb 15 16:54:45 (but they can get that during NAMES) Feb 15 16:54:57 training and demos would be better served @ NAMES Feb 15 16:55:23 if they want to help us document things by evaulating docs and pointing out inportant stuff that we left out, then they would be welcome Feb 15 16:55:50 proof readers Feb 15 16:55:54 right Feb 15 16:56:11 I don't think that there is any time during NAMES for serious integration. Feb 15 16:56:52 I've found that I run completely empty just answering the first questions from the curious. Feb 15 16:56:59 perhaps, but there isn't time in the fest for a training seminar Feb 15 16:57:09 still have Mon/Tue/Wed evenings to fill.... Feb 15 17:02:07 I guess I was wondering, if there was someone who wanted to head up integration, if it would be appropriate to have an integration seminar during Fest? Feb 15 17:03:34 If that didn't take to much away from code and documentation. Feb 15 17:03:36 * paul_c thinks Monday would be best for such a thing - Or an informal evening discussion. Feb 15 17:04:20 He wasn't thinking of talk about integration. He was thinking of doing integration. Feb 15 17:04:43 as in, he brings a machine, and we help him hook emc to it? Feb 15 17:04:54 Someone does. Feb 15 17:05:43 well obviously I wouldn't be able to help him, emc2 isn't ready, and I don't know emc1... but if someone wanted to do that, I have no objections Feb 15 17:06:44 that does mean that "someone" will get pulled away from the rest of the fest discussions/work... "someone" needs to decide whether that is worth it to them Feb 15 17:07:51 next year I'd be willing to to that w/emc2 Feb 15 17:08:54 Okay -- got you penciled in and me as your first student. Feb 15 17:09:41 uh oh ;-) Feb 15 17:10:42 Pain in the a%$ aren't I. Feb 15 17:11:46 I am in agreement that we don't want to draw talent away from code. That's first. I'm also in agreement that we don't want to draw talent away from the handbooks. That's second. Feb 15 17:12:38 But if we can find someone competent to handle integration and a project to integrate, that might be oday???? Feb 15 17:12:49 definitely! (IMHO) Feb 15 17:13:40 We will have the manual mills and lathes needed to accomplish a project. Feb 15 17:16:56 Would it be prudent to post a note to the lists asking if there is interest in the integration of a machine at FEST and if so is there someone who would be willing to head that activity? Feb 15 17:19:34 rayh: about posting a note - why not... sounds like a good idea Feb 15 17:26:03 Okay. In conclusion on the Fest, I'll post a note with were we are on planning and ask if someone would head up an integration project. Feb 15 19:14:33 Darnit - We should have broached the subject of Gnu's autoconf Feb 15 19:15:17 * jmkasunich doesn't like autoconf Feb 15 19:15:33 that'll do me Feb 15 19:15:52 * paul_c has been reading up on the ato-tools Feb 15 19:16:48 nasty stuff to get in to.