Morning John, congrats on getting kinematics linked in. only half way there... Yes, but if I understand EMC structure, it is enough to run a mill. forward kins are the ones used to convert joint feedback to cartesean coordinates I still need to get the inverse kins (and the cartesean trajectory planner) working Oops, guess that tells how much I understand.... (I wonder who came up with forward and inverse for the kins - it seems backwards, inverse is used for the output, and forward for the feedback... ) that usage predates emc though - I've seen it in robotics texts, etc * robin_sz looks forward to the fun jmkasunich will have getting segmotqueue linked in ;) ;-) John: I'm going to split posemath.c in to smaller chunks at some point in the near future ok by me I haven't touched (and don't intend to for the forseeable future) the interface (API) for either kins or posemath I've changed where it is called, but not how It will have the end effect of producing a smaller bin at the linking stage most of posemath isn't used anyway what about for non-cartesean machines - it's used by genhexkins.c, isn't it? Some of it is used by parallel kins speaking of which... it's getting to be time to move the other kins files over from emc1 I'd rather see that stuff left until emc2 is actually working and debugged kinematics are interesting ... "working and debugged" includes the cases where kinType is other than KINEMATICS_IDENTITY fair point Let's not clog up the source tree with stuff that few will use for the time being 99.5 % of machines are cartesian. so long as the kinematics class/thing/whatever has a nice API, it can be plugged as a different sort of thing later I guess yes and no... it does indeed have a fairly clean api but there are non-trivial things inside the core of the motion controller that change depending on kinType for instance, with KINEMATICS_IDENTITY, you can change from free mode to coord mode and back at will KINEMATICS_BOTH can only change if all joints have been homed and KINEMATICS_INVERSE_ONLY has even more strict restrictions on when you can change to coord mode hmmm cartesean machines are the "worst" case for developing and testing, simply because they are so simple - you can have a cartesean machine working perfectly while failing to address many issues that show up on other machines on the other hand, without a machine to test on, testing non-cartesean stuff is hard assuming of course that anyone actually uses the 'other' machines true, but being able to do hexapods and the like is one of the things that makes emc special - don't want to lose that theres a good argument for allowing for it to be added at some point in the future, but just worrying about cartesian now. the hexapod guys can always use emc1 at the moment anyway * jmkasunich wants to build a cable hexapod someday (just cause it's cool) handy for flying camera over football stadia I see your point tho... for now, the rest of the kins files can stay in emc1 but I intend to code it to handle non-trivial kins I'm not changing that much, mostly re-organizing things (well, homing and free mode planning were completely redone, but kins and the cartesean TP will see little change) Matt, did you get the proposed election announcement? yes, what should I do with it? Well FC (fearless crusader) wanted it posted. if you agree, post it (in your role as leader) if you disagree, work with ray and others to make it agreeable, then post it wait, let me look at it... this is election of? election of a "board" for emc uh huh ... leadership can be a good thing discussed (at length) at Fest most projects like this have a pumpkin i'll have to change the jul 3 date, how much time should be allowed? couple weeks at least http://www.comedia.com/hot/jargon-4.2.3/html/entry/patch-pumpkin.html I expect a flurry of discussion when it's posted robin_sz: this isn't a patch pumpkin - the board would be making non-technical decisions mostly general direction, that kind of stuff I suspect having much development going on in lots of little branches, but only the pumkin holder approving patches to the main tree is the way it might go right so we elect a board, lock em in a room with boxing gloves .. and see what comes out? more to the point, see who listens to their decisions afterwards haha. i'll post it with the date changed to jul 24 then, OK? Good, and away we go.... date sounds OK... more to the point, do you think it addresses the issues for myself, i'm sceptical, but lately I've been sceptical of nearly everything let me read this thru again... I was originally against, but Ray can be very convincing, especially in person I'm now "skeptically in favor" IOW, lets try it and see what happens A prominent list of contacts for various aspects of emc would go a long way in helping our acceptance true given that development effort is a rare resource, it needs to be used wisely. I guess that means trying to steer active development towards a common goal. where a significant chunk of developer effort is heading in a particular direction, the goal may have to move to meet it I guess. one real issue that Ray had was commercial users folks like Sherline might approach him about using emc, but don't want to tip their hands to their competitiors quite so Ray can't just ask the mailing list what he should do but he doesn't want to be seen as acting too independently and committing emc to things without consulting anyone hence the board, which can discuss these things privately and endorse them I guess it's ok, I'm sort of with Linus Torvalds, "Show me the code...". this is where a more modular EMC should help I have also had a couple of commercial users aproach me... with respect to a number of core changes anything you can discuss here? with a good, solid, modular approach, it should be easier to have a generic framework into which commercial users can plug the special needs in theory, that should reduce significantly the number of commercial requests because they can do it without changing the core code ...I have some aspirations of commercially using emc as well likewise btw Matt, you do realize that you are already on the board, right? ;-) board is president and four other members Oops, better go, wife wants me ready for church in 20 min, will stay connected, bye. maybe I shouldn't have said that ;-) one thing that I pesonally would find very useful is a 'monthly roundup' .. I try and keep up to date with EMC, but sometimes I miss stuff that has gone on. that could be a lot of work a once a month 'state of the onion' sort of roundup would be handy. just a paragraph or two ... summary for the hard of understanding and who's gonna write it? you volunteering? part of the problem is that different folks are up-to-date on different parts exactly ... maybe with a 'board' sorta co-ordinating stuff, that might get easier? Ray knows what's cooking with Sherline, Smithy, etc, I know what I'm doing on emc2, etc, etc right ... but an overview is hard to get unless you read and distill an awful ot of posts, irc logs and more one thing that might be doable without too much pain: take the message line only from each commit message, append it to a webpage somewhere possibly ... so folk can see cradek's additions to the backplotter, etc the short summaries you put on the last two Sunday IRC logs are a step in the right direction too SteveStallings: would it make sense to host the IRC logs at linuxcnc? I'm talking about these: http://www.quacky.co.uk/~robin/emc/ Sorry, was away for a moment. Hosting on LinuxCNC if files are a couple hundred Kbytes each is reasonable. If they are really large, then summary form would be better. We get a lot of folks who download every large file in some sort of collecting frenzy. The ones currently on quacky are fine. Have they been cleansed of e-mail addresses? the files are about 20-100K per week yes, I edit each one before sending it on to robin remove emails, remove trivia like "jmkasunich has joined #emc", remove stuff that isn't of general interest, etc OK, I will grab them assuming it is fine with Robin. Then copy me on future versions. if they're on your machine, I can just upload the new ones, instead of mailing them (but perhaps there should be a subdir for them) One moment while I check settings on server.....