Feedback wanted: Equipment risk categories

[originalfoo]

Inspired by a message on the main page of the DoES wiki:

Surf over to the Cambridge Make space equipment page to find information that maybe we ought to link to or bring back here. After all, we're all using much the same things the the same reasons.

And inspired by their tool classes:

http://wiki.makespace.org/Equipment/ToolClasses

I decided to import that concept to the DoES wiki:

https://github.com/DoESLiverpool/wiki/wiki/Workshop-Safety

I've started adding safety precautions section to various equipment pages, for example:

https://github.com/DoESLiverpool/wiki/wiki/Bandsaw

Any feedback greatly appreciated.

[JackiePease]

Really good idea to categorise the tools. Should the machines have coloured stickers? One query, I’m hoping the information on acrylic is a typo – it’s generally considered safe for laser cutting and we use it all the time. I know there have been discussions about fumes from polycarbonate though.

[originalfoo]

Good catch - it looks like acrylic is safe. I just found this useful list of materials for use on laser cutters: http://atxhackerspace.org/wiki/Laser_Cutter_Materials

I will edit the page some more later today and correct that typo.

[cheapjack]

That's a great bit of material knowledge. Just in time @amcewen Plastazote is a cuttable packing foam that can be cut and contains no chlorine (the ultimate dangerous do not cut material). Awesome work as usual @aubergine10

[DefProc]

@cheapjack Agree on Plastazote, Polyethylene is one of our laser cut-able materials, and EVA foam is also good too (someone brought the MSDS before cutting).

I've added some of the laser cutter material info that I've been carrying round in my head. My collected knowledge disagrees in places from the atx hackerspace wiki page (eg. they list materials that absorb IR are bad for laser cutting — but you have to absorb the IR from the laser to heat up the cut area) but it's a good starting point.

[DefProc]

---

Scratch that, I saw the:
> higher risk of damage to equipment from untrained use

from the class red definition eventually

---

Do we have any suggestions of a good process for collecting induction sign-offs for users if we're introducing this as a system?

Is it worth making clear the two parts of the risk equation (as in HSA-style Risk Assesments) of `chance of injury occuring` and `severity of injury` which get multiplied to form the overall risk level? And should we make the decision for this classification open too?

[originalfoo]

I'm a complete newbie on all this stuff so if you see anything wrong, please don't hesitate to edit the page. I've also been marking - based mostly on guesswork and limited knowledge - the various equipment pages with the red/orange/green classifications. I know the laser cutters are class red, and I've been marking anything with a drill, mill or saw as class red also. I've been marking anything that heats as class orange, and most of the other stuff (3d printers, etc) as class green.

I'm not sure whether it's best to have a central materials list or to have each machine define its own "no go" materials? Maybe a central list for general knowledge, and on equipment pages just list the major no-no's?

This all ties in with #488.

[originalfoo]

Do we have any suggestions of a good process for collecting induction sign-offs for users if we're introducing this as a system?

I've been thinking it could possibly be tied to the RFID doorbot system. I assume there's a database somewhere for each RFID tag, and who owns it and what they can access. We could store induction status for the various machines alongside that data. At later date we could then potentially use the RFID tag to enable the plug socket for a machine or something like that. In any case, we'd at least have a database showing who is trained on what machine.

Side note: I think we should also start defining who the 'go-to' people are for each piece of equipment, similar to how the Cambridge hackspace does it. They have this notion of "owners" of a machine - people responsible for maintaining it and providing training. If someone could provide me some infos (probably in separate issue ticket so it's easier to track) I could add that in to wiki pages with applicable formatting to make it look nice.

Is it worth making clear the two parts of the risk equation (as in HSA-style Risk Assesments) of chance of injury occuring and severity of injury which get multiplied to form the overall risk level? And should we make the decision for this classification open too?

We could provide that infos in the "Safety precautions" section on the equipment pages.

[originalfoo]

FYI, this is the trajectory that's fermenting in my mind (where nickname refers to the pet name for a piece of equipment):

Obviously that view is equipment-centric, but there would be other boxes and linkage in there for DoES members, desks, rooms, etc. - I've just not got round to fleshing out the diagram yet.

[DefProc]

I assume there's a database somewhere for each RFID tag, and who owns it and what they can access.

This is stored in a YAML file that defines the doorbot access allowances. Currently this is updated by hand (@DoESsean has a fancy RFID key reader), pushed to the remote repo, and then pulled by the doorbots so they all have a local copy to check against. The part-automated deployment details are in the doorbots-config #11

It's entirely possible that the YAML could be generated from a user database and then updated on the doorbots via the git repo. That way it wouldn't require any breaking changes to the current doorbot process and could tangibly improve the RFID registration process. Although to note: where possible, DoES should own it's own infrastructure #18

There was some movement on better integrating the access logging (currently going to a google spreadsheet as a pre-database "working is better than perfect" approach in addition to local logging) in #45 but this has been stalled for some time.

Side note: I think we should also start defining who the 'go-to' people are for each piece of equipment, similar to how the Cambridge hackspace does it.

Yes, and agreed in an organisers meeting: #244

And the safety info also ties in with issue #243 for adding the appropriate signage by the piece of equipment. It would of course be perfect if the wiki info could be parsed directly into a printable sign so it can be easily updated if anything changes…. 😁 🤞

[originalfoo]

This is stored in a YAML file that defines the doorbot access allowances. Currently this is updated by hand

Would it be possible to just add a few extra fields to the YAML, by hand, when someone does induction - for example, a key TRAINING with a string value, the string containing a comma separated list of machine names the user has been trained on? Not perfect, but at least it will keep the training infos associated with user infos, and at later date can be machine read if we want to do more with it.

For now, my main desire is to shift things towards a format that will facilitate future automation and integration. Which is why I'm making all the equipment pages follow similar format, and trying to get nicknames for all machines, and ensuring there's an issue tracker label for each machine, and those labels in consistent format. It's creating some headaches, but I think it will help greatly facilitate future development and refinements.

It would of course be perfect if the wiki info could be parsed directly into a printable sign so it can be easily updated if anything changes…

Yes, I've been thinking this too. A two or three colour e-ink display next to machines that could list current issue tickets, safety classification, booking infos, etc. And RFID reader somewhere near the machine for user to check in and out (verifying training requirements as part of that process). Oh, and also a transparent-background PNG image for each machine :) That will be useful for website also.

[DefProc]

Would it be possible to just add a few extra fields to the YAML, by hand, when someone does induction - for example, a key TRAINING with a string value, the string containing a comma separated list of machine names the user has been trained on?

Not that it can't, but that access to the YAML is limited to organisers (as it controls out-of-hours access), and is git only — so it's probably not the best solution. Currently the canonical list of formal inductions is the laser cutter calendar, but we'll need something more robust (and be able to record things like: equipment, inductee, inductor, date) if you're proposing an increased induction process. Although this is starting to feel like a break out somebody-should item…

[originalfoo]

Although this is starting to feel like a break out somebody-should item…

Agreed - I've been wondering if it's worth having a repo for brainstorming ideas separately from somebody-should. What do you think?

[originalfoo]

I'm pondering whether it would be a good idea to split the materials out of the equipment and safety pages - there seems to be lots of duplication, especially for laser cutters.

For example, there is materials info on the main Sophia page, the laser cutter materials list, the workshop safety page, etc. And then additional duplication on the Gerald page. And probably a few other places I've not found yet. If using a laser cutter, it would be nice if I could see a page of materials specific to laser cutters (which is why I'm moving away from the idea of a big list on the workshop safety page - although that page could link to the other materials pages?)

Specifically, four pages:

• Laser Cutter Materials - this page already exists, but could use some cleanup and formatting
  • Also, London hackspace materials list might be worth reviewing, their banned list is likely applicable to our laser cutters too.
  • The cut and etch settings would remain on separate page
• Drilling and Milling Materials - a new page to cover materials for drills / mills / CNC routers
• Bandsaw Materials - new page specific to bandsaws
• 3D Printer Materials - new page specific to 3D printers, with extra section about filament widths for the different printers

We could possibly create materials pages for other equipment too, such as vinyl cutter, vac former, etc., although that might be overkill?

I like the London Hackspace approach of having two clear lists:

• Specifically allowed
• Specifically banned

A third section on each page would list suppliers for the specifically allowed materials.

What do you think?

[DefProc]

Agreed - I've been wondering if it's worth having a repo for brainstorming ideas separately from somebody-should. What do you think?

If only we had a discussion forum of some kind… 😁

[amcewen]

Indeed. The google group would seem the obvious place to be spitballing/brainstorming, with things getting raised as an issue here once there's enough understanding of it. Plus that'd have the benefit of introducing people more gradually to the online systems - tell people about the mailing list, then when they're on there they'll find out about here, and actually join in when they're ready to (or there's an issue that prompts them to)

[originalfoo]

@DefProc awesome edits on the wiki pages btw, thank you!

@amcewen Agree - would be good to drive people to community (I much prefer Discourse style over google group) first, it's the perfect place to brainstorm - and it would also reduce the number (or complexity) of issue tickets here on github as all the finer details could be dealt with on the community site.

[DoESsean]

From my (incredibly) limited understanding of all that ^^^^^^^^ it seems like a lot of really good work happened on this issue.

Does anyone know if it was enough for it to be closed, whether it was a start that can be finished, or if it's something that we no longer want/need?

[amcewen]

I think most of the stuff listed above has been implemented (apart from RFID access to control any category-red equipment, but that should be spun out as its own issue if/when we can implement that)

We need to make sure each bit of equipment has an up-to-date page on the wiki, but the work in #243 will flush out that.