Hi Robert, thanks for your realistic description!
Please help me understand what you're suggesting here: > so i think i would lean to bring up a tool change error message, let the > intergrator decide what makes a toolchange error/abourt and how best to > handle is to the machien with in the PLC, and if so have Mcodes to get out of > it just like any commercial machine control on the market does. same way a > join following error does a machine off state. its safe and controllable > condition. So lets assume the tool change process resulted in an error, or a TC abort button was pressed. What would you expect to happen in EMC? Could you describe in a bit more detail how commercial machines deal with this? I happen to own a homebrew only, so no experience here. Does it fall back into the G-code interpreter, you type in some M-code, then restart somewhere, somehow? How do these M-codes interact with the toolchanger? I think there arent many other options than to abort the running program, and then do something. This 'then' could be M-codes typed into the MDI window, or buttons or some other logic in a Pyvcp or gladevcp panel dealing with the hardware through HAL, all while the program is stopped and Axis is in manual mode. If everything goes well, the program might be restarted by run-from line (assuming not too much global state has been changed to make this dangerous). What I can imagine is passing through more information to the EMC level, namely wether it was a tool-prepare or a change, what the tool/pocket number was, and how it was aborted (user, machine). That could be passed to say an Axis message describing what happened. But other than that, the tools at hand at this point are really what I described in the previous paragraph. > what todo with a changed or not changed tool number state is tricky > some controls i'v seen asume it has change the tool from pocket to the > spindle, i think you have to say, what does someone do in a power cut while > in a tool change right now?! answer is problem same for here... > other dont and still think the old tool is there. Ok, that sounds exotic, but I could imagine that EMC dealt with powerfail in a more configurable way beyond just restarting in e-stop mode; for instance, trying to save essential machine state if a powerdown is pending, and deal with it in a controllable way if power comes back up. Linux has fairly basic support for dealing with powerfail and recovery in a controlled way provided there's some power backup to at least permit a controlled shutdown, and that mechanism could be built upon. I dont see how an EMC distro could provide a 'bring back machine XYZ back after a powerfail into a clean state whatever shape it was in when that happened'. But I can imagine some hooks so an integrator could build a recovery mechanics on that. This might be worth looking into. Is that what you're suggesting? regards, -Michael > i find a quick tool reorder in table is needed but its a small problem for a > unknown or known reason for a tool abour to have happend which is very rare > or if there is power cut. > > ii hope above is of some help and insight to some different machine setups > and types. > > robert > > On 28/12/2010 19:52, Michael Haberler wrote: >> There was a discussion on #emc-devel today on how the current toolchanger >> protocol behaves, and how it could be developed. Let me write up my view to >> start ------------------------------------------------------------------------------ Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
