RFID Interlock - Pull Requests Welcome

DMS General
1

I’ve got a very basic version of the RFID Interlock system working, you can see my (horrible) code on GitHub:

Right now it does the following:

  1. Reads an RFID tag from a Wiegand26 reader.
  2. Check with a server (example.php script) to see if the RFID tag is authorized.
  3. Turns on an LED (pin 9) if authorized, turns it off if unauthorized.
  4. Turns off the LED when the “stop” button is pressed (pin 8) and notifies the server of the shutdown event.

The plan is to use an Arduino Ethernet with PoE, so the devices can be easily setup (all our network drops are PoE). If would like to help out with code or hardware please let me know. Code contributions are best handled via pull requests.

2 Likes
2

So is there a plan to start interlocking some of the more dangerous equipment? I’d be willing to help out, as I’ve been working on a similar system for my university’s hackerspace.

3

If doing an interlock I’d recommend adding a piezo element to beep once. Also, mod it to do flashing of the LED and beeping of the piezo element multiple times if someone tries to operate the interlock with an invalid tag.

4

I’ve added a buzzer with simple allow and deny tones. The LED now flashes on deny as well.

5

Wooo! :smile: I’ve been itching to propose something like this for both access control and usage logging. I’m really interested in helping with the hardware. In another week or two I might have had a prototype cobbled together as well. I don’t know how many of these are going to be installed but we might would I think save considerable cost by spinning a custom board instead of using full arduinos and ethernet shields. In any case it would add to the fun of the project and get more members involved.

Are the ethernet drops already in place? Would we save much trouble if we use 802.11 or 802.15.4 instead?

6

I’m all for making more cost effective versions, wireless, etc. Consider this the reference design.

For anyone designing a nicer/better version, here are some additional features that would be nice to have:

  1. HTTPS support, the Atmega328 can’t handle the crypto, so we currently just use HTTP.
  2. Wireless, for flexibility of implementation.
7

I can help you get this working with a Raspberry Pi that could easily handle the crypto if you want. The hardware isn’t that hard, just different.

If it catches your interest for this project, I recently used one of these for a production test station with an RPi:
http://www.amazon.com/gp/product/B009NQFD6S/ref=oh_aui_detailpage_o04_s01?ie=UTF8&psc=1

8

An implementation with a rPi would be useful, and likely cheaper. You could probably use a serial-based RFID reader, instead of Wiegand 26.

9

Do it like a commercial door access system. Readers/solenoids at the local area, with bell wire back to a control box. A dedicated micro-controller for each device is wasteful. Could run several devices off of one PI.

10

Am I understanding that if you hit stop on the machine, that it logs you out? That could get tedious for some of the woodworking stuff. We have a sign-in system on our copy machines here at my office, and I’m very glad that it has a time-out function, where you aren’t immediately logged out.

If I am understanding the system plan right, it would be very helpful to add maybe a 60 or 90 second delay before you are locked out again (with a blinking LED) on some machines. That would give someone time to, say, kill the table saw, set the blade to a new height, and then start it back up without having to dig out an RFID dongle again.

Laser cutters and CNC routers, where you usually leave it on until you are done with your cuts? Log out as soon as you hit stop. Table saw type stuff? It’s going to get old fast (or even worse, encourage unsafe practices as people leave the saw running so that they don’t have to re-beep it.)

2 Likes
11

I respectfully disagree. When a centralized system like this fails, all work comes to a halt. A rPI or Beaglebone black is (<$50), and we have perhaps 10 devices which need this sort of interlock. Cheap, distributed access control.

[Edit: Just thought about this point…]
Additionally, running wires all over the place is a pain, and is asking for someone to snag/cut one.

— Zach

2 Likes
12

I too will respectfully debate the merits of a centralized controller, and I am offering my opinion from my armchair as I most likely won’t be the one building, programming, maintaining, or installing this system. (I do offer my assistance whenever I am available though.)

The centralized design is cheaper because there would only be 2 MCs. (One in use and one as a redundant spare in case the first fails).

The proposed POE solution would also involve “running wires all over”.

One Cat5 cable (4 pair) emanating from a central control box to a machine, would have enough wires for a reader (2 power 2 data), and a lockout solenoid, still leaving wires left for some other function.

Both designs are ultimately centralized with the authorization/logging being accomplished elsewhere, regardless of the count/location of the MC(MicroController).

For every machine you tie back to a central controller, you save the cost of a MicroController. You also cut down on repair time because if the one central MC fails, you just go to the box and swap it out with a preprogrammed spare. You could store the preprogrammed spare in the box so it would be a matter of minutes required to swap cables and power it up, no skills needed, and the person doing the swap wouldn’t need to program anything.

In the case of having a MicroController at each machine, you wouldn’t want to have a preprogrammed spare for each machine(high cost), so you would have to program a replacement MC with the specific software/settings needed to work with that specific machine. This would require a software repository that is accessible to the person doing the swap as well as the skill set required to accomplish the software installation.

10 machines at $40 a piece is $400 worth of extra hardware, not counting the spares you would want to have on hand.

You could have key bypass on all the machines so that in the event of a lockout system failure, someone could temporarily enable all the machines until the system is repaired, like they are now.

One of the reasons I am inclined towards the centralized MC design is because that is how it is done in the commercial world and it would seem to me that they have spent considerable resources designing, testing, and evaluating the merits of each design and have settled on the centralized design.

Paul

13

I think you are misunderstanding the interlock’s operation. The interlock has no knowledge of the tool’s state, it’s more like a light switch. Stopping the saw/laser/router/etc won’t log you out of the interlock, so the tool can be turned on and off as needed. It’ll be up to the user to remember to hit the “logout” button when they are completely done using the tool, at which point the “light switch” is turned off.

14

I did misunderstand, I thought that the interlock would go safe when the equipment was turned off. That kind of begs the opposite question – what do we do about people who forget to relock the equipment? Do we look for a procedural solution or a technical one?

15

One thought that comes to mind is that we could monitor the current going into the equipment and log the user out after a few minutes of inactivity. We’d have to calibrate for the idle current of each machine of course. This should pretty much work for all equipment.

16

This one is simple, we can use the login/logouts to show if a machine is in use. If someone forgets to logout, people who use the status page will notice and bug them about it. Peer pressure can work better than code sometimes.

3 Likes
17

I expect we’d be using a $2-3 microcontroller, so cost seems like not as much of an issue there. That would enable us to use an IP wireless solution which we can’t do without a micro. There will probably prove to be multiple benefits of having each machine IP-addressable from the existing LAN. I can definitely see myself running a bash script in the background on my laptop in the common area pinging some machine in the shop to let me know when it’s available for use.

Admittedly the wireless adds some cost but for 802.15.4 it’s on the order of what ethernet costs. As for 802.11 I’m not really sure but if any of those cheap serial wifi modules are good enough (none may be; I’ve tried a couple) then that’s not so bad either.

Ideally all devices should run the same firmware. They would be told which machine they’re hooked up to during installation, probably through a web interface.

18

Consider my vote an emphatic “NO” for wireless. Whenever I see wireless deployed in a static endpoints situation, I just shake my head. And yea, basically all those wireless->serial devices are horrible to set up, impossible to secure, and break without any indication as to why.

As for the centralized vs. decentralized debate, I think there are merits to both. In the end, it comes down to maintenance and expandability issues. Namely, whatever system we set up needs to be able to be maintained by our successors. I’d say simplicity is the #1 requirement there. For simplicity’s sake, having one central GPIO unit would seem to me to be the best solution. I’m assuning the RFID readers are serial, so there would have to be some microcontrollers to handle them as inputs, a board computer (rPi, BBB, etc.) to resolve the database accessess and pass the data back to the micros, and a bunch of relays to control the contactors.

For the sign-out issue, I would suggest putting a long (30-minute?) tineout on it, and having a large, visible light on the machine. If the machine is signed-in, the light is on / blinking. It will be easy to spot machines that have been left on, and the access log will tell you who the culprit was.

It seems that there is enough interest in this that maybe a wiki page should be started for it. I think the discussion here is going to get hard to follow.

19

Something like this wiki page?

https://dallasmakerspace.org/wiki/RFID_Interlock

1 Like
20

Why yes, just like that. Seems like it could use some cleanup, though. Maybe I’ll try and make a hardware layout for a controller unit.