Workshop blast gate automation

@DaveE

Posted by: @davee

↑

On the other hand, a couple of 'bargain packs' of different capacitors (and maybe the same for resistors)  for your 'spares' drawer, would be useful.

I had already looked on Amazon and picked out virtually the same assortment boxes. AliExpress is a much better idea as they are half the price an not holding me up at the moment. Caps on order, resistors already in 'stock'.

Posted by: @davee

↑

The ESP32 data sheet at https://www.espressif.com/sites/default/files/documentation/esp32_datasheet_en.pdf includes a table with this snip:

-- attachment is not available --

All this introducing me to datasheets and has given me more insight and makes them a little less intimidating. 👍

Posted by: @davee

↑

Commonly, splitting a circuit into two parts will markedly change it, as other components and current flows can all contribute to the resulting voltage at a point. This is why it so helpful to have a copy of the schematic in front of you, when you begin to test a circuit.

My gut told me it could, but I wasn't sure. I have another question along a similar vein but will ask it on another post.

@andydowns I downloaded the app, but I don't see the boards I use other than strip, which is of limited use. I have to leave to take my new car in for first (10,000km) service, ordered a year ago and on the road since Sep. When I get back, I will look for some more to see if I can find a helpful board.

@andydowns

Thats really nice and well thought out.   Its very promising. 👍 

I looked at all the boards. Most I had never seen before, and nothing appealed to me. The ONLY boards I might use are standard breadboards and very few veroboards for buses. The search continues.

@zander Which do you use?

@andydowns There are A few different boards; I don't know what they are called. If I want to splurge, I have a collection of permanent breadboard types in various sizes. The majority that I bought before I knew what works and what doesn't are just holes with no connections, so NOT breadboard style. I just checked again, and the Perf board w/pads is like what I have a lot of, but I may need to resize the board if that is doable. The breadboard is like my new favourite, the 'permanent' breadboard.

I will play with those a bit when the opportunity comes up.

Prototype 2 is up and running.

Prototype 2 came about by a friend of mine suggesting a different approach when I showed him the early stages of prototype 1. We explored the idea for a few minutes and set about making it.

As you can see it is based on the motor being mounted over the gate shutter. It came about because the first prototype juddered because the shutter is a very loose fit and occasionally pitched and tried to jam. With the motor being in line with the center of the shutter, the pitching wouldn't occur even with a poor fitting shutter. There are other ways of solving the pitching issue with prototype 1, but his idea seemed worth exploring.

Whilst looking at the awful fit of the shutter, I decided to make a new, better fitting one. The original is ~1mm thick and the opening is ~3mm, hence it rattles, and the width is also 3mm narrower, hence the pitching.
The new one, shown in the photos, is a whisker under 3mm and made of PVC. 3mm is too thick and I'm sure would start to jam with dust ingress, so it would need to be probably 2mm. PVC is also completely wrong as a material because it is prone to static, but It's what I had to hand and serves the purpose for experimentation. I'll explore this more later.

The shutter on prototype 1 was also modified by adding some UHMW (Ultra high molecular weight) tape. It is specifically design for lining sliding surfaces and works well on the gate shutters. However, I am unsure of the static potential of Polyethylene and need to look into it further. If you are considering using it for the same purpose, do your due diligence regarding static.

I considered using optical limit switches on prototype 1, but the requirement for disconnecting the gate arm to allow manual operation made it difficult to come up with a sensible solution. Hence I went for mechanical limit switches.
Since manually operating the gate has now been solved, it allowed optical limit switches, so prototype has them instead.

The drive to keep the prototype 2 module the same width as the gate gave reduced space and meant that the EP32 Dev kit wouldn't fit across the plate. Lots of shifting around produced a Veroboard layout that worked, albeit a bit packed. You may also have noticed that there is an empty position for an another IC. This is for one of the next steps to do something a bit more flashy with individually addressable LEDs. I've added the circuit without trying anything out, so it may well not work. Time will tell.

Prototype 1 and 2 side by side operation. You will notice there is some difference in speed; this is a part of the experimentation to come.
Each have slightly different software; different ports are used, the limit switches are different and there are no LEDs on prototype 2.

Now I have two functioning modules, it's time get them talking to the MQTT broker and interacting with each other.

Once complete functionality is achieved I will install both and see how they perform. There will no doubt be several tweaks to the software and then I can decide which design to go with. I suspect it be a combination of the two.

Additional:

Just in case it's not clear, prototype 1 will be positioned (See topic introduction for photos) as the gates currently are mounted, so button facing forward. Prototype 2 would be facing sideways to how it is currently mounted because it would stick out too far. So again, buttons facing forward.

All gate positions have space for sideways mounting except the bandsaw which would be a little tight.

Another small step…

After a bit of a battle with the Shelly relay, and some help from @byron, it finally works.
Each gate/module is talking to the rpi mosquitto broker and responds as intended. When one gate is opened, the other one closes. When the opening gate is half way open the extractor starts.
The extractor can then be stopped by pressing the red button on any of the modules.

Shelly relay:
For any others falling down the same hole I did. There is a lot of information on the Shelly relays available of both the Shelly site and many others.
The relay I bought is a Shelly Plus 1, which I assumed to be an slightly newer improved version of the version 1 relay.

Shelly relays have a fixed mqtt topic that you need to write to, to operate the relay. The topic is given as

'shellies/shellyplus1-c4d8d55ec6a4/relay/0/command' (shellyplus1-c4d8d55ec6a4 is the topic for my relay)

and the payload is a simple 'on' or 'off'.

After much buggering around I eventually found that this is the topic for a version 1 relay, and I have a version 2. So, Shelly Pus 1 is a version 2 relay.

For a version 2 relays, the topic is
'shellyplus1-c4d8d55ec6a4/command/switch:0'.

What also threw me further was an odd behaviour with MQTT explorer. When I stumbled upon the right topic my elation was short lived as it only worked once.

'shellyplus1-c4d8d55ec6a4/command/switch:0' with 'on' worked
'shellyplus1-c4d8d55ec6a4/command/switch:0' with 'off' didn't work
and then 'shellyplus1-c4d8d55ec6a4/command/switch:0' with 'on' also didn't work.

I haven't managed to get to the bottom of this and haven't returned to it again since.

I went back to the command line approach in a putty terminal and low and behold it worked reliably. Adding the publish command to the code now works.

This is the definition in my header file
// ****************************************************************************
// Shelly relay topic - is different for each relay
// ****************************************************************************
const char* extractorRelay = "shellyplus1-c4d8d55ec6a4/command/switch:0";

These are excerpts from the main code to turn the extractor on via the Shelly relay:


// When the gate is half open, start the extractor
if ((motorStepsCounter == (motorStepsPerMm * gateRangeMm) / 2)
&& (direction == openGate) && !extractorInhibit) {
client.publish(extractorRelay, "on");
}


// Check if red extractor off button has been pressed
if (extractorOffButtonState == LOW) {
client.publish(extractorRelay, "off");
}

Next step:

I was going to use an RGB led to indicate gate/module status, but have fancied having a play around with an addressable led strip, so that is next on the plan along with pinning down the mechanical design.

@andydowns

Hi Andy, progressing well I see. 

As I mentioned I use MQTT,fx as my goto mqtt helper, but as you mentioned mqtt explorer I had a look to see what I had on my mac.  I see I have an old version of mqtt explorer but when I went to update it I see that all the later offerings are labeled as beta.  If yours is a beta version then as it cant do what you have proven to work with both the command line and you C program it seems to be rather wobbly and not worth using at the moment.

Apart from having a nice gui to enter your topics and payload in these mqtt helpers, of course its easy enough to knock up your own one that connects to your broker and auto subscribes to all topics (#),  prompts for a topic and payload string, publishes them, and then prints them out when received as a subscription.   With just a bit more effort It also easy enough to code in a GUI with the likes of qt6 I would think.  Its certainly a breeze with the python wrapper pyqt6 if doing this sort of thing in python (though I would probably just use the tkinter gui that comes as standard in python).

Musing about using some electronic blast gates in my workshop I pondered on what would happen if a blast gate failed to close.  

The one on my planner/thicknesser would be a prime example in my workshop where the dust/chip collector rapidly fills when machining down planks, and often gets full up unnoticed by the poor old operator, now getting quite tired of repeatedly sending the planks through.  

After a while a cuppa would be called for and on return I may command the blast gate to close on the thicknesser whilst the dust bag and pipe is clogged up with chips, and open the gate on the chop saw to trim those planks to the desired length.  

No doubt the thicknesser blast gate would indicate an error if it failed to close being clogged with chips in the pipe, but my attention would be on the blast gate of the chop saw which will probably indicate a successful open.   Come to think of it, some sort of sensor that indicates the dust collector is getting full is called for to complement the blast gate automation.

Well you've probably thought of all these scenarios but I thought I would mention it as it occurred to me that whenever there is a fault condition anywhere all blast gates should indicate this. (say a red light for an error at the gate with the error and all other blast gates get a flashing red light to indicate an error somewhere.  

That addressable led strip is going to be mightily useful. 😎 

@byron 

i would like something better to monitor Mqtt messages and will give this some thought.

i like the idea that the gate with the problem is the one that flashes red. If they all flash the red it would be harder to tell which one has the problem. Of course the gate with the problem could flash with a different sequence. 🤔

I do completely get what you say though, and could definitely see it happening.

I had been thinking of a sounder of some sort for when there is an error, but considered it would be an overkill. With what you’ve pointed out, though, it could be back on the table.

I’ll think about this some more, but all modules flashing red with the faulty one flashing differently sounds good.

Thanks for the thought. It’s asy to miss things when in the nuts and bolts.

@byron Back when I had my shop, the only clogging problem I ever encountered was when I decided to make pine blanket boxes for my girls. OMG, those fluffy shavings clogged up the planer within a few minutes. Keep in mind this was a professionally designed materials mover (what they call a dust collector) with a 6 ft tall cyclone and the good pipe with wide sweeps etc.

That was the last time pine was in my shop, maple and cherry are so much easier to work with.

Posted by: @zander

↑

@byron Back when I had my shop, the only clogging problem I ever encountered was when I decided to make pine blanket boxes for my girls. OMG, those fluffy shavings clogged up the planer within a few minutes. Keep in mind this was a professionally designed materials mover (what they call a dust collector) with a 6 ft tall cyclone and the good pipe with wide sweeps etc.

That was the last time pine was in my shop, maple and cherry are so much easier to work with.

Funnily enough I had this problem for the first time only a couple of weeks ago. The planner was fine, but the inlet to the extractor kept blocking. A right pain!

It's been a while since I gave an update on the Blastgate automation project. Partly due to doing some workshop improvements (I do pick my moments 🙄) and partly because I'm pretty slow at using Fusion 360.

The workshop improvements have been very worthwhile. A new metalworking area with new bench and new pillar drill, and a bench for electronic stuff. This was all done in the same area before and they don't go well together, especially with woodwork.

After prototype 1 and 2, it was time to use the best parts of each and do a Fusion 360 design for prototype 3. I have a real love/hate relationship with Fusion, but we'll leave that for another day.
Prototype 3 is based on prototype 1 but the electronics and mechanics have been swapped around.

Top cover is made transparent for clarity (pun intended 😁)

The electronics on top makes more sense from a keyboard connection point of view, and components will vibrate into the board rather than out of it. The combination of vibration and gravity over a long period can shake loose the most firmly fixed components.
Mechanics on the bottom just look neater as you can't see them as they are housed under the gate shutter. A lower cover will be added to reduce dust ingress, but I haven't tackled that one yet.
Many of the parts are now plastic and 3D printed, such as:
Keyboard bracket
Power socket bracket
Motor mount
Shutter arm
Shutter arm spacer
Limit switch arm
Limit switch adjusting blocks
Pillow block spacer

The new, better fitting shutter is made from aluminium sheet. It glides much easier with the UHMW Polyethylene Tape and has less play.

(Some parts are in blue because I was using up that filament 😊)

It's not very clear from the photos, but in the first photo you can see a 3D printed lens in clear PLA. The idea is that the LED strip will slot behind it and the LEDs shine through. It's my first time printing with this material; it is a bit challenging but I think it will work okay.

That’s it for now. More experience gained with prototype 3 an now back to Fusion to correct some ill-fitting parts and make further design improvements.

Quite a few additional design features have occurred to me throughout this process and they will be added once the first release is complete.

@andydowns - I see its a well thought out and engineered project, and thanks for the progress report, its very interesting to see it evolving over time. 

Love or hate Fusion 360 I can see from your fusion model pics you are an advanced user.   The blue supporting arm that twists and turns in multiple directions is testament to that.  That looks a bit of a mind boggler to design. Way beyond my F360 abilities 😮