[labnetwork] Fwd: Interlock Boxes

Wed Oct 1 20:25:34 EDT 2014

The Berkeley Marvell Nanolab has multiple Cat5e drops in each service
chase for network connections. Also the lab was wired with a 25  pair
cable to each chase. The twisted pairs are used for sensors and a
centralized relay control system, an Agilent 34980A, for the entire
lab that activate magnetic latching relays in Walker Interlock Boxes
for each piece of equipment.  There should be a diagram of the system
in the Mercury report that Katalin recently sent to the list.

The centralized system, called Hydra, based on the 34980A reduced the
per equipment interlock cost because the individual interlock boxes
were brought over from the Berkeley Microlab when the equipment moved.
The 34980A is not only able to turn on the interlock boxes but also
read the relay coil resistance. That allows the connection to be
tested when a piece of equipment is enabled. The 34980A also allows
full manual control of all the interlock boxes (an override). The
loopback  wiring check was also a feature of the Walker Interlock
Controller system we used in the Microlab.

Some of the Nanolab's equipment is in the building next door, Cory
Hall. To interlock these systems, we use the ControlbyWeb 4 channel
WebRelays and the Walker Interlock System. The Mercury software knows
which system to contact for each piece of equipment.

The other tricky problem is making sure all of the interlocks are
synchronized to the state of the Mercury database. I've attached a
diagram the explains the procedure that the Nanolab uses.

I think setting up your facility with Cat5e/6 would be preferable to
only wireless routers, but I don't have any experience with going
wireless for equipment control. I know the Microlab had wireless
access points that apparently didn't cause any problems with the
equipment.

Another thing to consider is network security and administration. The
Nanolab has network connections that are connected to the department
public network and private network connections for cameras and stuff
that cannot be exposed to the outside world. We also use a plug
computer, sheevaPlug (http://en.wikipedia.org/wiki/SheevaPlug) to
isolate the Hydra system from the public network.

Agilent (previously HP) is now Keysight Technologies.
http://www.keysight.com/en/pc-1000003024%3Aepsg%3Apgr/34980a-multifunction-switch-measure-mainframe-and-modules?nid=-33260.0.00&cc=US&lc=eng

I had worked for HP/Agilent writing software for manufacturing network
analyzers. I have a feeling that is why I was comfortable using the
34980A as an interlock system for the Nanolab.

Todd
(formally of the Marvell Nanolab).
Oh, I should mention that my daughter is a doctoral candidate in
English at the University of Chicago.

On Wed, Oct 1, 2014 at 11:06 AM, Shivakumar Bhaskaran
<sbhas at uchicago.edu> wrote:
> Todd,
>
> Thanks for the interlock system, It was really helpful. I guess each equipment in the cleanroom is equipped with interlock, so you run network cable to unit, Do you ever thought of using the wireless router to do this. Will the Wireless router signal might interfere your sensitive equipment.
> Is there any specific network cable you use or regular CAT5 / CAT6 cable is sufficient. Our cleanroom is built without any network port, if I want to do this I have to physically run cable on the ceiling in the chase and drop it next to the equipment.
>
> --Thanks
> --Shiva
>
>
> Shivakumar Bhaskaran
> Searle CleanRoom Manager
> University of Chicago
> 5735 S.Ellis, Room 032
> Chicago-60637
> Ph:773-795-2297
>
>
>
> -----Original Message-----
> From: labnetwork-bounces at mtl.mit.edu [mailto:labnetwork-bounces at mtl.mit.edu] On Behalf Of Todd Merport
> Sent: Wednesday, October 01, 2014 11:36 AM
> To: Fab Network
> Subject: [labnetwork] Fwd: Interlock Boxes
>
> I hope this is useful.
>
>
> ---------- Forwarded message ----------
> From: Todd Merport <merport at gmail.com>
> Date: Tue, Sep 30, 2014 at 5:00 PM
> Subject: Re: [labnetwork] Interlock Boxes
> To: Shivakumar Bhaskaran <sbhas at uchicago.edu>
>
>
> Here are some user account issues that we had in the Berkeley Microlab ( I'm not sure if they are still relevant to the Marvel Nanolab in 2014).
>
> The Marvell Nanolab maintains it's own user database for the following
> reasons:  Note, the Nanolab network is administered by the EECS department.
>
> a) The EECS departmental database does not allow account creation of users from other departments without a monthly fee (so members would be billed for two departments in that case).
>
> b) The EECS department doesn't want non paying customers using their network.
>
> c) The campus database does not allow outside industry members to acquire an account without legalese that industry members find unacceptable.
>
> d) Guest users require limited access to layout conversion software ( for mask making) or view only privileges of equipment maintenance, process monitoring, and other database tables. So paying a network access fee is out of the question.
>
> Todd Merport
> (formerly of the Microlab/Nanolab)
>
> P.S. A web based interlock system used in some rooms by the Microlab was from WebRelay http://www.controlbyweb.com/webrelay/
>
> On Fri, Jul 11, 2014 at 12:09 PM, Shivakumar Bhaskaran <sbhas at uchicago.edu> wrote:
>> Hello All,
>>
>>
>>
>> I am trying to set a interlock system for our cleanroom. In the
>> process I was able to get the phpscheduler up running. Before I design
>> or buy the interlock I need your inputs regarding how to set up.
>>
>>
>>
>> Do the user log in to computer that is attached to the unit and
>> validate the credentials and then use the equipment. Inorder to do
>> that user data should be validated by the scheduler system, in that
>> case does user have separate id created or it will be same associated with the campus ID.
>>
>>
>>
>> Do the user use separate swipe card in the interlock to access the system.
>>
>>
>>
>> Apart from the user access, currently the users access the cleanroom
>> with swipe in card and when they leave they swipe out. But not all the
>> users swipe in or swipe out. Our door system is designed in such a way
>> that it will be opened for atleast for 10-20sec , but with this there
>> is possibility of other users following the previous user without
>> swiping the card. Does any one have system that detect the user based
>> on proximity that automatically gets the user information based on RF
>> ID card without swipe in.
>>
>>
>>
>> --Thanks
>>
>> --Shiva
>>
>>
>>
>>
>>
>> Shivakumar Bhaskaran, Ph.D.
>>
>> Searle CleanRoom Manager
>>
>> Uinversity of Chicago
>>
>> 5735 S.Ellis, Room 032
>>
>> Chicago-60637
>>
>> Ph:773-795-2297
>>
>>
>>
>>
>>
>>
>>
>> From: labnetwork-bounces at mtl.mit.edu
>> [mailto:labnetwork-bounces at mtl.mit.edu]
>> On Behalf Of Michael Rooks
>> Sent: Friday, July 11, 2014 9:11 AM
>> To: labnetwork at mtl.mit.edu
>> Subject: Re: [labnetwork] Interlock Boxes
>>
>>
>>
>> We use ethernet relay boards from National Control Devices, controlled
>> by Badger (the new version of Coral). NCD also makes wifi connected relays.
>> Having two relays on a board makes it easy to keep isolated grounds
>> isolated. Each board requires its own static IPv4 address. The boards
>> can be easily mounted in a 6"x6" electrical box, or in the
>> custom-fitted plastic case from Badgerlms. I suggest you keep these
>> boards behind a firewall, since they run a tiny operating system and
>> web page, but with only minimal security.
>>
>>
>> ---------------------
>>
>> Michael Rooks
>>
>> Yale Institute for Nanoscience & Quantum Engineering
>>
>> nano.yale.edu
>>
>>
>>
>>
>>
>> On 07/11/2014 06:14 AM, Flückiger Philippe wrote:
>>
>> Hi All,
>>
>>
>>
>> EPFL is using Ether IO24 R from http://www.elexol.com/IO_Modules/
>>
>>
>>
>> Our software is homemade but we have a call for tenders running in
>> order to “couple our homemade software” with a commercial package.
>>
>>
>>
>> We will keep you posted on this important move on which we are
>> investing a lot of effort.
>>
>>
>>
>> With my very best regards,
>>
>> Philippe
>>
>>
>>
>> Dr Philippe Flückiger
>>
>> Director of Operations
>>
>> http://cmi.epfl.ch/
>>
>> Phone +41 21 693 6695
>>
>>
>>
>> From: labnetwork-bounces at mtl.mit.edu
>> [mailto:labnetwork-bounces at mtl.mit.edu]
>> On Behalf Of John Shott
>> Sent: jeudi 10 juillet 2014 20:55
>> To: Kolin Brown; labnetwork at mtl.mit.edu
>> Subject: Re: [labnetwork] Interlock Boxes
>>
>>
>>
>> Kolin:
>>
>> I believe that most folks are using the Advantech ADAM-6060 or
>> ADAM-6066 6-channel IP-addressable relay modules for interlocking.
>> Others use modules that come from National Control Devices that have
>> 1-, 2-, 4-, and 8-relay devices with current ratings from 5 to 30
>> amps.  Most folks are currently using hard-wired ethernet connections,
>> but some wireless options are also available.
>>
>> I believe that most of these IP-addressable relays are functionally
>> equivalent but would certainly have minor differences in the default
>> port that is used and the exact command sent to turn on, turn off, or
>> check the status of a given relay channel.
>>
>> I don't have experience with either Cores or iLab software to know
>> what, if any, interlocking hardware has been interfaced with their systems.
>>
>> Good luck,
>>
>> John
>>
>> On 7/10/2014 6:08 AM, Kolin Brown wrote:
>>
>> Hi!  Here at WVU, we are going to interlock our tools to our
>> reservation software.  Everyone at the UGIM was talking about the
>> “blue boxes” from Advantech.  Can anyone provide me with a model
>> number?  Also, has anyone interfaced these boxes with Cores or iLabs software?
>>
>>
>>
>> Kolin Brown
>>
>>
>>
>>
>>
>> _______________________________________________
>>
>> labnetwork mailing list
>>
>> labnetwork at mtl.mit.edu
>>
>> https://www-mtl.mit.edu/mailman/listinfo.cgi/labnetwork
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>>
>> labnetwork mailing list
>>
>> labnetwork at mtl.mit.edu
>>
>> https://www-mtl.mit.edu/mailman/listinfo.cgi/labnetwork
>>
>>
>>
>>
>> _______________________________________________
>> labnetwork mailing list
>> labnetwork at mtl.mit.edu
>> https://www-mtl.mit.edu/mailman/listinfo.cgi/labnetwork
>>
>
> _______________________________________________
> labnetwork mailing list
> labnetwork at mtl.mit.edu
> https://www-mtl.mit.edu/mailman/listinfo.cgi/labnetwork
-------------- next part --------------
A non-text attachment was scrubbed...
Name: overides.pdf
Type: application/pdf
Size: 201396 bytes
Desc: not available
URL: <https://mtl.mit.edu/pipermail/labnetwork/attachments/20141001/dbaf0566/attachment.pdf>