Gate Valve Drive Electronics

[Penri]

Terry

Would you like me to re-drill the base board to accommodate the revised module arrangement? if you are happy to do it I've measure the positions later to change the 3D model of the "box".

These DC-DC converters are rogues or at least their designers are! Do you want to accommodate the caps on a piece of Vero board?

Hwyl

Penri

[TerryJC]

I think I'm OK to re-lay out the base board and manufacture a Veroboard for the Converter and the Caps. I can't do much until that is done and I plan to do it this afternoon. Once I've got the thing together, then you can use it as a template for the new model.

I should know how long the stand-offs need to be then too.

[TerryJC]

Now the bad news:

1. The DC-DC converters that I had selected seem to suffer from the same poor regulation issue as the ones that you bought at the beginning: see viewtopic.php?f=15&t=18&start=10. I applied 12 V to the input and set the O/P to 5 V (off load) and when I applied a 10 Ohm Load, the voltage dropped by over half a volt. I thought about whether we could set the voltage on the basis that we knew what the load was to be but dismissed that because any fault could result in an over-voltage to the Pi. I still have 4 of the other type of converter that I used for Sump and Butts Pis, so I'm going to make up a filtering circuits with capacitors as I did for the existing Pis:

Penri,

I've just discovered that I made a boo-boo when I posted the above message (and with the earlier posting regarding your original adaptors). I built a small veroboard 'carrier' for an eBoot Mini converter to accommodate the capacitors. During setup yesterday afternoon, I noticed a half volt difference between the on-load and off-load output voltage; just like the other type. Once started, the voltage was rock solid. It was getting late, so I left further investigation until today.

I just confirmed that the problem is still occurring and have now found that if the device is powered up with a load on, and then the load is removed, the voltage stays at the loaded voltage. I had been powering up with the load off, then powering down and powering up again with the load on. It seems that the device regulates to whatever voltage it settles at when it powers up, so as long as the load is applied at power up it will deliver the correct voltage, even if the Pi is subsequently unplugged during maintenance.

I've also confirmed the same behaviour with the new converters, so presumably your original ones would be the same. However, in your case, the output is via a USB Type A socket, so it's much more likely that the converter would be powered with the nothing connected, which might be risky to any equipment you might plug in.

The ripple is fairly high on the new type of converter, but nothing like as bad as the eBoot ones are when unfiltered. Hopefully this shouldn't be a problem, but if it is, I may have to filter the output anyway. Anyway, I think it's worth reverting to the original type, unless that becomes a problem.

Back to laying out the baseboard!

[TerryJC]

I've rebuilt the electronics using the layout shown below:

Plan View:

Gate_Valve_Baseboard_Plan_View.jpg (156.67 KiB) Viewed 1242 times

Side View:

Gate_Valve_Baseboard_Side_View.jpg (166.53 KiB) Viewed 1242 times

As you can see, the Pi has been put onto long standoffs. This was still necessary to provide enough room for the HDMI and USB cabling. At present, all of the other boards are on the shortest size standoff, although I might end up raising the Motor Drive Board slightly, to give more room for the Power connections, which are a bit close to the A/D Board. (I may be able to get away with simply bending the terminations on the wiring.)

The final version could be 'fine-tuned' to make slightly better use of the space; I'll know more when I've made up the cable harness.

[Penri]

Good job, high rise electronics!

When you have it working we can fine tune the mechanics and think about box design.

[TerryJC]

Penri,

Some progress, since I last posted. I've put the Gate Valve Assy together and it works (using my standalone program). This assembly process is quite labour intensive and I had a few problems to debug before I got it working. See:

Gate_Valve_Assy_2018-12-03.jpg (131.47 KiB) Viewed 1241 times

I've also attached the latest drawing for the Assy, which now includes details of the wiring and the layout of the Veroboard. See:

Actuator_Motor_Drive_Circuit_(LM298D_Board)_V04.odg

(485.34 KiB) Downloaded 87 times

One thing that I've found is that the Pi Zero is too slow to keep up with the movement of the gate when I run the program in the debugger, but it works OK when I run it from the shell. This is OK, because that's how we will be running it in the system, but it makes debugging a bit difficult!

As I say, my standalone program works, but I still haven't quite cracked running the software when the code is part of Hamish's framework. He's going to the LUG Meeting tomorrow evening, so I'll buttonhole him there.

I'll be calling into WMT tomorrow morning, but won't be staying too long because I need to prepare what i need when I see Hamish. Clive says he may pop in to give me some hardware for his Underground Railway, but that's fairly low on the totem pole for the moment.

See you tomorrow.

[TerryJC]

Sitrep6:

First the good news... I got some useful guidance at the LUG Meeting on Tuesday and I was able to refine my Gate Valve Class. As a result, I can control the motor to go smoothly to any value of open between 1 and 99% and it holds very quietly within tolerance of the demanded position. I haven't seen any problems with it having to correct the position once it has got there and I've been running the code for a considerable time.

Now the bad news (part 1). Hamish was unable to attend the LUG meeting, so the guidance I received was mainly about improving my existing code. I also received some clues on how to investigate the framework, but I'm going to have to write to Hamish with a few more questions soon.

Then the bad news (part2). I haven't quite got to the bottom of it yet, but the heat sink on the Motor Drive Board got very hot after I started the software in the debugger (you will recall that I mentioned that it hunts when the code is slugged by the GUI) I measured the temperature with my probe and it reached nearly 60 deg C!. However, when I run it in the shell, as it will in situ, the problem is not nearly as bad and the heat sink temperature seems to have stabilised as around 36 deg C. I want to monitor this for a while to see what the long term effect is. Once I am happy that the stable condition is acceptable, I'll run it in a loop to see what the worst case situation is.

One factor in the above is that I have to keep the clutch engaged at all times, because as soon as I disengage it the valve open fully under spring control.

If repeated changes to the valve position makes the driver very hot, then we will have to take this into consideration during full integration, to ensure that position changes do not occur too often. However, I think it should be OK.

[Penri]

Terry

Good progress, well done.

Interesting news about the motor drive temperature. i know you'll want to make sure the valve can reach every position but the chances of us needing to maintain fully open for any length of time is slim, in my estimation.


Hwyl

Penri

[TerryJC]

I've being experimenting since my last post and I've noticed that disengaging the clutch when the program shuts down doesn't cause the motor to retract, so more investigation is needed I think. It may be that turning the motor off doesn't need two lows on the Motor Drive Board input pins, as I am currently doing. I'll have a think about what's happening.

[TerryJC]

Sitrep7:

I've been running the Valve in parallel with investigating the software framework and so far it has run for many hours and retained it's set position perfectly, except when I disable the clutch. I reluctantly come to the conclusion that we have to keep the clutch engaged for the whole time that the valve is powered, even when it is holding its position.

I think the reason for the problem that I've encountered is that the spring in the Actuator is allowed free-reign when the clutch is disengaged. Sometimes this will result in the valve moving and sometimes it will retain it's position. I further think that the uncertainty here is down to the amount of stiction that the valve itself contributes, its precise position and the amount of vibration in the assembly. Since this has been observed on a sample of one, I feel that we couldn't possibly rely on the valve staying put across the whole population of valves/actuators. We could probably put in a second spring to oppose the tendency of the actuator to fully open the valve, but that may be counter productive because if we did that, we might find that different valves/actuator combinations needed different strength springs and we still don't know what affect the water will have in the pipe (it will certainly add vibration, especially for the valves that are part of the pump matrix).

With that in mind, I've done some power supply measurements. I have two 12 V PSU bricks, one rated 1 A and the other rated 1.5 A. Their actual terminal voltages are quite different however, being 14.22 and 12.03 V respectively. Here is what I found:

Gate_Valve_PSU_Performance.png (54.23 KiB) Viewed 1233 times

What you can see from the above results is:

• The voltage to the Pi, generated by the DC-DC Converter is constant withing the range of I/P voltages that I have.
• The I/P current is higher during booting with the lower voltage brick, but this is offset by the lower current drawn by the motor and clutch.
• The volt-drop over the motor drive chip is fairly constant as you would expect.
• We would need a 1 A PSU Brick to adequately provide for a single Gate Valve and a 3 A brick for the Pump Matrix.

The temperature measured at the chip heat-sink today is about 33 deg C, but the room is a bit colder.