Interlock SIG under Infra

DMS General
#1

Hello DMS !

We’ve had an ongoing problem with lack of good Interlocks and Tool controls. This is often discussed, and there is plenty of willing volunteers and expertise available, we just need to actually do it.

There’s a lot of conversation, and some interest to get them, and it’s coming from at least 3 committees (Machine Shop, Woodshop, and Laser… with additional interest from 3D and so forth)

There’s many options about how to move forward, and it’s a great opportunity to have an approach-ably sized project to which volunteers can contribute.

With that in mind, our new CTO, @jphelps is sponsoring a new Interlock SIG under Infrastructure. I’ll be helping with communication / documentation / project wrangling. You’ll see a discord channel set up, and maybe some talk posts, perhaps some github activity, etc.

I’m collecting input and feedback, ideas, requirements, project names, opinions, etc… Brainstorm what you’d love. (Fair warning, the first Proof of Concept probably won’t be the final results… but we want to capture and review all ideas)

Thanks,
Jack

7 Likes
#2

Interlock SIG Overview.pdf (111.2 KB)

Some Ideas attached.

Discord channel link: Discord

2 Likes
#3

At @TBJK 's request @njannati and I are working on building a few more hardware units for the machine shop.

What’s become apparent is that:

  • The API has some serious delays - most interlock authorizations are taking more than 30 seconds according to my infomal measurements. This is also true of lookups on the kiosk in the common room. I haven’t tried the QR links, yet.
  • Some parts for the current design are no longer available. Not insurmountable, but a recurring issue if we use commodity boards and “onesy-twosy” builds. Nothing wrong with small build quantities, but Chinese assembly suppliers seem to have a half-life of 23-13/16 days.We’ll need a design we own and can maintain.
  • I can probably pull a $100 out of the current design with a small custom board design that we open source.
  • There are a number of features that probably belong in a design that will support wider application (touchscreen support, etc.)
  • As more are deployed the current bespoke construction model will become unmaintainable and unsupportable.
  • Need to avoid the “creeping feature creature” If it does everything none will ever be built. I believe DMSs needs can be accommodated with intelligent modularization.
  • Documentation (not better, just some) documentation needs to be available and revision controlled to the point that no person or group is required to continue.

I can talk more about the hardware work I’m doing and assumptions so far in another thread. I’ll try and get a talk post later today.

I think we manage the creeping feature creature by listing using cases - including the wild ones. We can prioritize them and look at how we allocate and accomplish the required features.

And a plea: let’s pick ONE communications channel (Talk OR Discord, but please not both) so that we don’t’ spend a lot of time integrated data and discussions from many sources.

Also, I do not see an Interlock SIG on Discord or much recent in the way of interlock discussion there.

Oz (in DFW)

2 Likes
#4

The purple relay board in the shark lathe is open source made by DMS members, DMS should have a copy of the kicad design files and firmware if you guys don’t let me know. Also elab should have all the parts on hand for it because we were planning on teaching a soldering class using it.

#5

Are you on Team Infra in discord? You might need Team Infra permissions to see it. @TJSmith @jphelps

#6

No, and no green dot here yet, so can’t see the appropriate Talk groups if I’m not on campus.

1 Like
#7

Shark lathe now has a Piface2 board. I don’t know when that changed. Here’s a recent photo.

IMG_4469
IMG_44691920×2560 335 KB

I’ve seen the DMS relay board but haven’t found the source files. It wouldn’t be that hard to replicate in their absence, but I think a little more is needed. What I’m working on is a design for a connectorized board that

  • supports a wider range of I/O and power options (right now one 250 VAC relay, four open drain FET outputs of at least 500 ma/30 V, four inputs that will accept 3.3 to 12 V in, and on-board power supply.
  • eliminate the separate relay board
  • eliminate the small ($40) Meanwell supply
  • get rid of as many of the screwdriver connections as practical and move to crimped connectors

Oz (in DFW)

1 Like
#8

I planned to put this in a separate thread. This is long, It’s mostly my raw project notes. I don’t see a good way to make it usefully shorter…

This applies to the RFID lockout controller hardware and software running on it.

=======
System

Needs to be supportable and maintainable in the long term

  • common parts across deployment
  • ability to stock small quantity of spares
  • good documentation to limit need for personal corporate knowledge.

=======
Software

The authorization API seems to have some serious delays - most interlock authorizations are taking more than 30 seconds according to my informal measurements. This is also true of lookups on the kiosk in the common room. I haven’t tried the QR links, yet.

If API delay is insurmountable add code to cache x most recent auths, 
expire after time (2 hours, 12, 24, configurable?) 
Reaquire auth before timeout to prep for next request?

Current Python code is version 2, Convert code to python 3. Should not be a big job, don’t see too many feature collsions in the code.

Keep config on USB Mem or I2C/SPI flash and read that (to include)

location
io assignments
timeout period
lookup base URL
lookup backup URL? 
use Sandisk Cruzer or Ultrafit on cord tied to chassis 
     or 2-4K byte SPI/I2C on config board.

Add version info to code and use it and config info in serial log

Use remote logserver? Does DMS already have one?

Add remote machine disable.

=======
Electronic Hardware

Piface and Piface2 board are no longer available and closed source. We don’t really need the unique features and specialized software driver this board requires. It looks like the base Pi GPIO is more than adequate for most use cases.

There are a number of features that probably belong in a design that will support wider application (touchscreen support, etc.) support with common interface connector SPI/HDMI Display Support (Active user, clock, job time remaining, elapsed time, timeout, authorization warnings.

Breakout connector with I2C, SPI, a few GPIO and 5V supply to support touch when paired with display.

Green indicator to 24 VAC Contactor drive Mallory FL1P-22NA-1-G24V (or whatever control relay drive) and a direct indication of state.

Maybe sonalert beep as well? - if so use existing I/O with OTS module.

Status light on box; red, yellow or RGB? Needs to readable in bright light and facing user - do we remote mount or bespoke location on box?

Add serial port connector (Cisco RJ45 pinout) from Pi serial port (connector and buffer cost should be minimal. Is this needed, will it be used? Would special serial cable based on OTS 3.3V USB serial IF be a better choice?

Have separate config board that holds all hardware configuration jumpers and a SPI/I2C flash ROM for local unit configuration. Allows main board swap without reconfig of SW or HW.

Use bulkhead connectors - Ethernet and dual USB - USB will need some retention mechanism - something to tywrap to. Might need USB on top and bottom of box.

Wifi only - Pi Zero W on top of box in 3D printed housing/radome

Should HV section be interlocked? Power to box would not be effected, so it this even useful?

Door interlock as anti-tamper? any history to indicate this is a valid need?

PoE - probably not. Why is it needed if we are already switching power? On board supply will accommodate 12 - 24 VDC in, so extra wire PoE already an option. If it’s a corner use case add a seperate 802.3af POE interface.

=======
Mechanical Hardware

Use Bud box and 8.5 " Square 0.125" AL base plate. Everything mounts to plate and removable as a unit
Seperate HV section as now with cover/door.

=======
Use Cases

Common questions WiFi or Wired Ethernet?
Touch display - if so why? Show username, queue, runtime, bill, time remaining

heavy machine - 220V 3 phase 40A contactor, or single phase as needed.

light machine - 110V single phase less than 10 A

display only? Why?

=======
Issues

Wire to HV section is rated at 300V - should really be 600V for 220V AC
now using CONSOLIDATED ELECT WIRE &CABLE 820-3 ORANGE: HOOK UP WIRE, 20AWG STR 10 X 30, 300V, PVC, Stranded and Topcoat Tinned Copper conductor per ASTB-33, TEMP -40C TO 105C

Piface relay ouputs underated for applicaiton. Being used at 24 VAC (so ~38 V Peak) Limited to 20V at 2 A DC. Relays are rated at 5A/250 VAC, board design limits rating. Not a crisis, but should be corrected.

Existing project Wiki Page: https://dallasmakerspace.org/wiki/RFID_Interlock

I’ll shut up for now.

#9

I believe the wiki page you linked is actually for a prior version of the interlock that’s only used on the Haas. Not the slightly more recent box that’s used on the shark and the auto lift.

Could you elaborate on why you think the piface relays are underrated? It sounded like they were rated to 250Vac and being used at 24Vac, which seems fine.

#10

The relays are fine.

The board design is specified for 20 VDC.

#11

This is also an issue the SMS board may share. I have not looked at it for that detail yet.

#12

Not to belabor this. Well, maybe a little…

The basic issue is that the traces on the PCB are not spaced far enough apart for the voltages involved. The guidelines for trace spacing are very conservative. That conservatism is justified when you are working mains power.

From the PiFace 2 data sheet (also attached)

PifaceRatingExcept
PifaceRatingExcept713×217 21.8 KB

We should spool up a separate thread to avoid causing comas among the others in this topic. Where should that be?

PiFace-PIFACE_DIGITAL_2-datasheet.pdf (813.8 KB)

#13

There is actually some merit in keeping mains voltage out of the same enclosure as the logic, and using 24V or lower switched by the logic to power an appropriate, listed contractor in a separate enclosure.

#14

It’s not just good, it’s essential. The issue I’m talking about if that he PiFace board is not even rated to handle 24 VAC.

Another issue is that the wiring for the 24VAC contractor coil doesn’t have good enough insulation to be in the HV compartment. Likewise the 5VDC supply from the Meanwell supply.

It’s OK if these low voltage wires are in the high voltage compartment, but their insulation ratings need to be good enough to be there. This means 600V for 220VAC or 1200V for 480 VAC. The reason is that the AC voltages are RMS values (a sort of average, but not exactly) and the peak nominal voltage is 312 volts. By the time you add tolerances and margins, 600V is the standard.

That said the stuff is working and there are no fires (yet.) If we’re building new stuff, we ought to build as safely as we can even if we aren’t getting a UL cert.

1 Like
#15

I’ve captured the input… and yes, insulation rating and creepage&clearance distances should be appropriate.
I’ll be on site tomorrow at 7pm to gather more info and type up what we’ve captured so far.
Jack

#16

What I have is here:

https://ozindfw.net/DMS_Stuff/RFID_Lockout/

Until we establish a DMS repository.

Do we have a git server? If not, can we establish one externally accessible?

#17

There is an extremely deep pool of talent and experience involved with this. I’m more comfortable now, then anytime in the past, that an internal project can actually be completed while conforming to industry norms.

Enjoy code review, some good, some ugly.