Am 02.01.2011 um 00:31 schrieb andy pugh:

> On 1 January 2011 08:58, Michael Haberler <[email protected]> wrote:
> 
>> - if one were to extend O<M6> to check an hypothetical tool-change-abort 
>> pin, the sub would need to self-abort.
> 
> Wouldn't the toolchange-abort normally be set by the operator pressing
> the "Stop" button? In that case the G-code will just stop anyway.
> I imagined toolchange-abort as an output triggered by machine-stop?

this mockup tries to emulate iocontrol as of today, the  toolchange-abort pin 
was loud thinking only

as for a future revision, in fact I think it needs to be bidirectional; an 
EMC-initiated abort as well as a Toolchange-process originated abort or fault

http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?ToolchangerProtocolProposal

the EMC-initiated abort is needed when the Operator hits Escape, Stop etc
the Toolchanger-originated fault (eg. changer mechanism jam) should fail the 
next M6
the Toolchanger-originated abort is needed for toolchangers which rely on 
run-from-line to restart until we have something better 

-m

> -- 
> atp
> "Torque wrenches are for the obedience of fools and the guidance of wise men"
> 
> ------------------------------------------------------------------------------
> 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


------------------------------------------------------------------------------
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

Reply via email to