In my view, there are three different roles that we consider: 1 -- the system integrator 2 -- the supervisor (or owner) 3 -- the operator
Changing .ini files is the part of the integrator role. Fixing problems when a limit switch is hit is an owner role. Running the machine is an operator role. A well placed key switch is a reasonable way to differentiate things that may be done by an operator from things that should be done by a supervisor. It is then up to management to determine who has access to the key. I could imagine a system that enables some menu items when the key switch is turned on. The purchaser of the system might specify which ones that should be so that the integrator can put the proper items in the .ini file. Of course, one could build the system to require a password, instead. That would add a bunch of unnecessary complexity though. Everyone knows how to use a key. Management know how to copy a key, secure a key, or change a lock. Regards, Ken On 4/27/2012 11:11 AM, Jan de Kruyf wrote: >> Either by pressing button (Jan would like that) > Bitter experience with the human race, and more particularly the subspecies > that habitually operates machines: > > The are very good at confusing computers. > > And at the same time a properly implemented switch needs the supervisor to > attend the correction of the overtravel, so there are 4 eyes watching. . . . > > j. > > > On Fri, Apr 27, 2012 at 3:56 PM, Viesturs > Lācis<viesturs.la...@gmail.com>wrote: > >> 2012/4/27 EBo<e...@sandien.com>: >>> but I can see joint mode >>> being useful for setting up and calibrating. >> Just like You mentioned - for setting up, calibration. I would add >> also troubleshooting and debugging. >> IMHO all of these things are outside "normal everyday use" realm. >> >>> Actually, this makes sense. How about this for safety then -- disable >>> joint mode in the normal interface and have a separate interface/program >>> for setup that can do joint mode? >> I think that this would over-complicate the implementation. >> I think that all is needed is a special INI file setting and, if that >> is "true", then make GUI or whatever place switch to teleop mode as >> soon as all joints are homed. There are HAL pins for that >> (halui.joint.n.is-homed), I tried to do this in HAL, but did not get >> it right. The idea was to take these "is-homed" pins and feed them >> through "and" gate (I had 5 joints in that machine, so I created and5 >> module). >> If "and" gate output is linked directly to halui.mode.teleop, then it >> will request that all the time. Also when there is attempt to execute >> g-code file. >> Basically it is needed to do this only once after the machine is >> homed, so I tried to do this on rising edges of "is-homed" pins, but >> this approach failed as I could not predict, how long time would be >> between first and last joint to get homed. So then I created homing >> sequence and added this only to last joint in sequence, but it still >> was not good. I could not figure out, what was wrong, so in the end I >> gave up on that idea. >> >> Is there a HAL module that would work as "set-reset trigger"? Rising >> edge on "set" input would set output true until there is rising edge >> on "reset" pin. I tried to find something like that, then I tried to >> create something like that, but also failed... >> I think that this could work - if the output of such trigger is passed >> through oneshot component to create a short signal (to >> halui.mode.teleop) on rising edge, then it would not repeat such a >> request until user specifically created a signal on "reset" pin. >> Either by pressing button (Jan would like that) or by some linking it >> to some M65 command to be activated in MDI or whatever. >> >> Viesturs >> >> >> ------------------------------------------------------------------------------ >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ >> Emc-developers mailing list >> Emc-developers@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/emc-developers >> > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
