Anfang der weitergeleiteten E-Mail:
> Von: robert <[email protected]> > Datum: 28. Dezember 2010 21:22:50 MEZ > An: [email protected] > Betreff: Re: [Emc-developers] Revising the toolchanger protocol - requirements > > Hi > first a big thanks for working and looking hard into this, for awhile now a > tool change abourt has always been something that would been handy so many > times, where right now it takes a tool chagne complete and abour/stop program > to get out of a change which can be a right pain. > > first maybe a insight to how some of my CNC toolchangers work might help abit > > on the mill here > http://www.youtube.com/watch?v=UlW1s2BNixo > > this works with Air operated cylinders for carousel in and down, 3phase motor > for direction control > when the carousel is in and down, and i hit Estop the carousel takes avery > odd way home, a 45deg angel and any tools under spindle will get wiped out in > the path, so an Estop in a tool change problem i would say is a big nono, > > on our random machine that has hydrolic arm and hydrolic counterbalance on Z > axis. > the Z has been known to drop 1 or 2mm on a Estop or power out as hydrolics > are turned off, and the Z brake in the motor (direct drive on motor to screw) > delay is enuth to give a noticed axis drop. so again a Estop on this machine > could see the twin arm getting jammed or something worse. a machine off state > would be safe as it would leave the hydrolics on etc and let the operator > machine back on mode, and MDI some tool change moves (as i like to keep my > tool change having coustom Mcodes for each change move, Pocket down, Arm > move,arm down, etc > > the 3 hardinge lathes (CHNC, superslants) > Hydrolic left, with Air Spin. they have a earth ring on there 8 station > turrets so they can in effect lock down any where out of station postion. > if u hit Estop this again turns of Hydrolics, so turret drops, air motor > relay is turned off so it free wheels to a stop, so again is a uncrontroller > condition. > what i did here is left the Lift on, but turned the air motor off after a > timeout of finding a station or other error condition with in the PLC, then > issue a abourt from program (along with a tool changed) so operator can then > index to next station manualy (from Mcode or switch) and lock turret down in > asafe known postion. > > 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. > > 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. > 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 collecting requirements. This is my ideas only, so if folks have >> different requirements please throw them in. In particular, I have no >> experience with random toolchangers. >> >> Problems: >> >> - Jeff noted that the current protocol suffers from a potential race >> condition when tool-change or tool-prepare operations are aborted by EMC. >> The consequence could be that the external toolchanger, and the iocontrol >> component have different 'views' about the state of affairs, namely wether >> the tool was changed, or the change aborted or completed. >> >> - while it is now possible to abort change/prepare operations immediately >> and reliably from the EMC side, there is no obvious way how that should be >> done from the toolchangers/machine side. A candidate would be E-Stop - I >> think its unsuited because an aborted toolchange is not the same as an >> Estop, and it limits the usefulness of the abort: if the abort only can be >> caused by an Estop through the external toolchanger, this Estop might cause >> the axes to move, meaning that the program cannot safely be restarted, or >> run-from-line. Programmatically it is possible to have a toolchanger script >> to cause an abort by executing emc.command.abort(), but the suitability of >> the halui.abort pin is a bit questionable (signal goes into a different >> process, which might cause more synchronization problems downstream). >> >> - IMV it is clearly desirable to have a way to cause such abort from the >> toolchanger, both as a protection measure or as a feature to be able to >> safely restart-from-line, which I see as a big plus >> >> That said, I think requirements include: >> >> my must-haves: >> 1. at any time, the toolchanger and the iocontrol component must have a >> reliably synchronized view of the the other party's state. >> 2. The semantics of both EMC-caused and Toolchanger-caused aborts must be >> clearly defined (pin protocol, effect on EMC, requirements for TC). >> 3. there needs to be a means for the toolchanger to abort a prepare or >> change process reliably through HAL pins, and have details conveyed to EMC. >> 4. an aborted toolchange operation must be idempotent in terms of internal >> state and restartable without skipping a program line, that is: EMC has not >> changed tools, and the toolchanger either issued the abort, or got it >> reliably signaled. A restart of the M6 operation will cause exactly the same >> sequence of events as a previous run. >> >> >> usability: >> - reliable state synchronization which also works with external hardware >> will involve more pins and possibly more internal states. it should be >> possible to just 'jumper out' unused parts of these synchronization >> processes, similar to the prepare-loopback mechanism. (this btw rules out >> bidirectional notify/acknowledge handshake pins because they cannot be >> jumpered to cause the same effect) >> >> so, what's missing or wrong here? >> >> -Michael >> >> >> ------------------------------------------------------------------------------ >> 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 >> >> >> ----- >> No virus found in this message. >> Checked by AVG - www.avg.com >> Version: 10.0.1191 / Virus Database: 1435/3344 - Release Date: 12/28/10 >> >> > ------------------------------------------------------------------------------ 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
