Am 20.10.2011 um 20:20 schrieb Kirk Wallace: > On Wed, 2011-10-19 at 21:24 +0200, Michael Haberler wrote: >> Am 19.10.2011 um 19:38 schrieb Kirk Wallace: >> >>> On Wed, 2011-10-19 at 18:08 +0200, Michael Haberler wrote: >>> ... snip
>> ok, so what does iocontrol do? wiggle some pins, and 'manage' the tool >> table. >> >> Does it do any meaningful action which does warrant a separate process (eg. >> so things can run in parallel)? No, it doesnt. Does it make the tooltable >> handling better if it is in a separate process? No, to the contrary it is >> one of the major boat anchors wrt tool handling in EMC. > >> From my limited view, EMCIO or iocontrol is just a place to put > non-realtime functions. You hint that, for instance the tool table, > functions have been moved from a more natural container. Which would > that be? I dont know wether they've been moved. What I meant to say: the current tool table is limited in several ways. First, it has a fixed layout and the whole table needs to fit into an NML message, or emcStatus. Second, laying out the table differently depending on the toolchanger type is really bad. Third, using a private property of a given toolchanger mechanism (a 'pocket') as an index into that - changing - table is a really bad idea. Last, swapping entries in the table around is a bad idea. The whole arrangement violates every rule in Data Modeling 101. And all those assumptions are littered throughout the code. Iocontrol is just the ice block about which one stumbles first when looking at the problem. Just think through a random single idea, like for instance tool wear management, and think through what would be impacted. It is truly repelling. Some of this is bad design, and some of it comes from NML limitations, which in turn origin from its realtime properties. However, much off the stuff which righfully would belong to a world model, and would not fit the limited, compile-time defined space of emcStatus, not necessarily has to be hard realtime (like in the stepgen sense), and hence no need for early binding as in C/NML. Look at tool interactions. Very slow. User interface parameters - detto. 'Relaxed realtime' at most. Look at HAL - a stunning success IMO. It uses late binding (via HAL) - components glued together with an interpreted language. How many folks would use EMC if the hardware layer were 'C adaptable'? So its safe to say much, if not most of EMC's success stems from its HAL layer configurability. The underlying theme is a constant - look outside EMC: Find a single successful software product which does NOT have any user extensibility/scripting/plugin mechanism. I can't think of one. It's a funny mixture. Some parts of EMC are incredibly well done, and the whole thing sits on a foundation which is severly botched in some respects. > >> That trivial functionality is bought with gobs of inflexible and size-limited >> NML messages and a separate process with its own set of synchronization >> problems. >> (e.g hang on abort). All it really is is a HAL I/O device with tooltable >> hardship thrown in. > > Are you saying you want to git rid of NML? No, there's no reason for that. Plus, I have just one life;-). What I'm proposing is an effort to fix the world model, and at the same time deploy a mechanism which is late binding and not size limited for all the stuff which does not rightfully belong into a hard realtime straightjacket. I'm currently looking into redis, which looks promising. But see below. > > environments or even on a network. It seems EMC2 might benefit greatly > by optimizing it for a single computer/user hobby shop context. You're posing a very valid question, which I've raised as well but was unable to get an answer or opinion which would be reliable enough to base a design decision on. Depending wether the answer on this is yes or no, the effort to remove some of EMC's limitations is VERY different, so it is an important question and one which we should have consensus going forward, also looking at support impact. That said, I'm currently thinking along the - more complex - distributed solution. A shared memory approach with a late binding world model would have much less code impact. > A few years back, I made a comment on how it seemed impossible to get > more than one person to collaborate on a shared goal. After prodding a > bit, I seem to recall the response I got was that each developer > preferred to work pretty much alone. I'd prefer to see more structure to > the project, but then I suppose that might take many people out of their > comfort zone and that is what a day job is for. It's a bit unnerving to > think that if a relatively few people decided that EMC2 wasn't fun > anymore, I could find myself with a shop full of CNC machines that won't > work, but it is what it is. This reflects my perception 1:1. But this is too important a point to discuss on the subject 'spindle orient support'. - Michael ------------------------------------------------------------------------------ The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
