Am 10.06.2013 um 18:23 schrieb Jon Elson <[email protected]>: > Dave wrote: >> >> How about a top ten list of things that need to be fixed/redone, etc?? I >> think that Michael has attempted to throw a few things out there but ... >> > OK, one big thing that comes up again and again is high speed > contouring, and > the single-block lookahead. I think Michael Haberler has a handle on this, > and plans something major to make it work better.
Note that I'm working the stack bottom up. Dont expect major wisdoms from me on say a motion-ng any day, its not my area of expertise. My office address is still machine room - boiler #2, next to coal bunker ;) But to get "what if" process going: there is a HAL extensions already in place which was primarily intended to cover networking aspects needed to get rid of NML and its legacy interface into HAL (basically non-blocking, operating system and environment independent (kernel vs userland) queues). Those are now named HAL citizens, like comps, pins, signals etc. Conceptually they are very similar to Unix named pipes. They support user process to RT comp message exchange, and vice versa, but also RT comp to RT comp. This means any HAL component can now pass compound objects (C structs if you will) as messages around and and any other component will be able to receive and act upon them (in fact even end-to-end across architectures because protobuf serialisation and deserialisation takes care of that). This is different from what we had so far - the only object which can currently be passed atomically between components being a scalar value (pin/signal). It turns out that this vehicle is also suitable for splitting huge blobs like motion into smaller ones which can be more easily replaced. For instance, I would think it is entirely possible to spin out homing into a component, and have it hook into motion with HAL queues. While in theory you could do that with HAL pins passing structs of any meaningful size and member count is so unwieldy and error prone (atomicity property needs attention) nobody has ever tried to. Also, transparent exchange across user/rt boundaries in any combination becoming possible (user->rt, rt->user, rt->rt) suggests that in the future we will be much more free in assigning parts of functionality to either type of component. This might get us out of the corner motion is in (I mean a ton of code in a single rt comp. and only a small part actually being rt-critical), and get us more flexibility. -m > I hope we can talk to > him at the Fest and get details of how he plans to make it work better. > So far, I have not really understood what he has in mind, and may completely > misunderstand what he is doing. I even have some tests that show the > shortfall of the current scheme without any high speed moves (although > programming a 2" circle with 10,000 linear vectors is, admittedly, a > torture test, and not real code I'd want to machine with.) > > Another thing that comes up often is proper handling of a dual-motor gantry. > There are apparently 3 ways to do this now, mostly related to homing. > gantrykins was supposed to solve it, but you shouldn't be able to get it > into joint mode after homing, but it apparently can. (This problem > may also have a perfect solution, and maybe at the Fest somebody > can show me how to do it!) > > These are the two areas I have run into a number of times, and I think > solving them would make LinuxCNC useful in some more applications. > > Jon > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > Emc-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-developers ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
