Am 19.10.2011 um 19:38 schrieb Kirk Wallace: > On Wed, 2011-10-19 at 18:08 +0200, Michael Haberler wrote: > ... snip >> Because it modifies spindle state, and interacts with spindle motion >> commands, all of which are in motion. The contortions to do the same >> semantics in, say, iocontrol would have been substantial, for no >> benefit I could see. > > Thinking aloud some more. My guess is, motion should be were realtime > and coordinated movement functions should live, basically axis stuff. > iocontrol should hold non-realtime user functions. On the surface, a > spindle seems to be a user function, Speed, On, Off, Brake, except for > the fancier features like CSS, threading, tapping, etcetera, so I can > better see having it in motion.
I understand your structural argument, but personally I dont see the upside - resource use of spindle related commands is likely a non-issue. I do see some potential for new synchronization issues. >> as far as iocontrol is concerned, I do not want to prolong its life >> more than necessary - there is no good reason left nowadays to have >> that prolonged by adding new functions to it. > > I'm not seeing this point. What should replace iocontrol for user > functions? I'm all for it, (Slight rant) if it makes EMC2 leaner, easier > to understand, and more predictable. 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. 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. I understand iocontrol had different functionality over time, so I'm sure it was warranted at some point, so I'm not blaming anybody here. Note that I'm not alone with my view - micges took a viable stab at the same issue: (see http://git.linuxcnc.org/gitweb?p=emc2.git;a=shortlog;h=refs/heads/iotask_remove). My angle on this is that removing iocontrol necessary, but not sufficient in itself to really improve tool handling in EMC. The other part is work on the world model, where 'world' translates into 'shared by all processes, even if remote', and 'not limited by the NML funnel'. The upside is not limited to tool handling btw. UI's would benefit a lot. Consistency between task and UI G-code interpreter instances would benefit a lot. To give an idea how EMC without iocontrol would work: I've experimentally removed it and replaced its methods (basically the task/iocontrol NML interactions) by Python methods with same functionality. All that's left of iocontrol is a Python class running in task, of some 400 lines which look remotely like so: http://git.mah.priv.at/gitweb/emc2-dev.git/blob/refs/heads/remapping-preview-1:/configs/sim/remap/iocontrol-removed/python/customtask.py No separate process, no NML, no sync issues, no deadlocks, hence easier debugging and IMO a lot more flexible than what we have now. See my point? -- wrt the second issue - work on the world model: I have a plan on how to do this, but have nothing to show yet, and this is the reason why my remapping branch still has the existing NML-based tooltable mechanism, despite the experiment in removing iocontrol. It's just that I havent seen that work item on the EMC road map (ha!). Personally I'd prefer to work on something which there is consensus on that it's desirable to do, and get accepted provided its not broken. But at that point I'm in the dark here. - 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@Ciosco 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
