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 > >> 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.
In trying to understand more, I looked up the diagram of EMC2's basic parts: http://wiki.linuxcnc.org/emcinfo.pl?EMC_Components http://wiki.linuxcnc.org/uploads/EMC_Control_LG.gif I don't see iocontrol or io on the diagram, but I assume that it is or they are EMCIO or contained within it. Until recently all of the spindle features where non-realtime and uncoordinated like flood, but that seems to have changed. Maybe spindle could be a new joint type in EMCMOT, as well as leave the dumb spindle in EMCIO. ... 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? > 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? > 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. I thought this was why NIST created NML, to allow for integration of manufacturing functions of all kinds. > 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? Not yet, but that is my fault. To take a more anti-NML approach, it might be argued that extremely few EMC2 machines are in production environments or even on a network. It seems EMC2 might benefit greatly by optimizing it for a single computer/user hobby shop context. > > -- > > 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 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. -- Kirk Wallace http://www.wallacecompany.com/machine_shop/ http://www.wallacecompany.com/E45/index.html California, USA ------------------------------------------------------------------------------ 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
