Building a prototype and what went wrong?
Exactly two years ago, I was approached by a friend of mine and also a former supplier, who happens to be an excellent machinist and a mechanical technician with theoretical knowledge that of an engineer, to help him build a machine for hydrostatic testing of gas cylinders. He was going to design, develop and produce the mechanical portion, while my responsibility was to design, develop and produce the electrical portion of the machine. In other words, his job were the extremities and the hearth of the machine, while mine was the brains!
So I went along with it.
It took us one year and a half to build and test everything. Sadly at the end though, when we were supposed to cash in the check for the prototype, we had to disassemble the ‘damn thing’ because of a bad business decision. I will keep my decency here and skip the details. They are history anyhow, as we are currently in the process of re-assembling it and ‘wrapping it up’ worthy of a trade show display.
The type of machine is nothing new, and certainly no rocket science. Still, I would like to present some of the very – very – unprofessional photos, taken during the process, the technical decisions we took and some of the steps I personally took to overcome few of the obstacles.
Oh! Did I mention the machine is capable of creating (and withstanding) a pressure of an excess of 1000 bar!? That’s 14500+ psi for some of you out there!
We stopped at 800+ bar in order to prevent the only cylinder we had available to us at the time from bursting out!
There were few requirements given! Very few of them. Some (related to the actual testing of the cylinders) were to test the cylinders in three different modes: two non-destructive and one destructive mode, where in the first two, the test pressure to be reached (and maintained!) was not greater than 300 bar, while in the 3rd mode, all we knew was to expect that the gas cylinder would burst at a pressure greater than 500 bar. How much greater (or lower?), we didn’t know. Hence, the first decision made was to go with two different pistons: the 1st one (with a larger cross-sectional diameter) would be utilized for reaching test pressures of up to 400 bar, while the 2nd piston (with a smaller cross-sectional diameter) would be utilized for reaching test pressures in excess of 400 bar. Obviously, the 1st piston would be utilized exclusively in the first two and partially in the third mode, while the 2nd piston would automatically take over in the third mode, after the 1st piston would reach it’s target. This approach was chosen, in order to spare the 1st piston (which would be used most frequently) from the wear and tear caused at very high pressures. Mode 3 was anyhow going to be executed every once in a while.
One of the other few requirements, was to measure the volumetric displacement of the test cylinders. That is, measure the change in volume of the cylinder as it inflates during pressurization, and express that change in % of its original volume. The way we did this, was very interesting.
We would fill up the reservoir up to a certain level (until the water spills over in the outer metal tube), then we would drain this trapped water, giving us a ‘zero start’. Then, during the testing process, as the cylinder expands, water would spill over in the tube. The amount of water (at least according to Archimedes) exactly equals the change in volume. For more precise measurements, a LVDT (a linear displacement transducer) would’ve been ideal – but also a more expensive option – as it would’ve given us the height of the water column directly. Instead, we opted for a pressure transmitter, calibrated for measuring watter pressure in mbar. And also cheaper! From there, it was easy to convert from the pressure to the height of the water column as:
hydrostatic_pressure = specific_density_of_water * earth’s_gravitational_acceleration * height_of_the_water_column
and from there, to the volumetric displacement in %!
Some of the other requirements given, were to store the results of the test “on the cylinder” (!?) and to make an image/photo of the entire test, before it actually commences.
The way we accomplished the first of the two above mentioned requirements, was to utilize a water-proof RFID tag, which would be pre-printed with a 2D/Datamatrix code of the test cylinder’s serial number (from a pre-defined list of serials). The tag’s EPC would contain the pre-printed serial number. This way, we would guarantee we target a uniquely defined RFID tag upon writing to it – and we would write all of the test related data, into the user defined portion of the RFID tag’s ‘memory’.
The way we accomplished the second of the above mentioned requirements, was to utilize a regular USB webcam with a higher resolution which would be connected to a Raspberry Pi and it would make a snap automatically after the gas cylinder serial number has been read with a hand held reader. Yes, you read correctly – a Raspberry Pi!
A few words on the RPi setup… Apart from taking photos, the RPi was also serving as a monitor for the 24VDC power supply i.e. the entire electrical cabinet was utilizing a power supply with a UPS-like function. That is, each time the mains voltage would ‘drop’ for what ever reason, the cabinet would continue running the +24VDC rail on batteries. If this status continues for more than 30 minutes, the RPi would gracefully shut down. As you might be familiar already, the RPi is not so keen on sudden ‘poweroffs’ – to many of them, and what you get as a consequence is a corrupted file system on the SD card! Try it if you don’t believe me.
All that was/is RPi related, I plan to publish in a separate article as a ‘how to’! Fingers crossed. 🙂
What you see on the bottom of the electrical cabinet is a result of bad planning and it’s purpose is/was to hide the wire mess! What I should have done instead, was to raise everything up and leave enough space to place a channel for the wiring – right bellow the wire connectors. But… Maybe in another revision.
What you don’t see on the image above, is the PLC and the actual RFID reader/writer, which were mounted on the front door/cover of the electrical cabinet:
What else… Well, for one – I also developed a PC program that acts as a SCADA application (C#), collects all the relevant data for each test and writes them down (along with the photo of the test) in a small database (SQLite), offers basic reporting functionality and e-mailing – and it also handles all of the RFID ‘stuff’. The programming on the RPi was simple shell scripting, but mostly Python programming.
While I was waiting for the mechanical part of the machine to be finished, I wanted to debug everything before hand – so that I spent least amount of time debugging and troubleshooting on-site. So I developed a ‘simulator’ consisting of one part mimicking the discrete logic going to the PLC and a second one – mimicking the analog 4-20mA transmitters (the two pressure transmitters).
Regarding the 4-20mA simulator, I also plan to publish the details as a separate post, really soon I hope!
So what went wrong? Why we had to disassemble the entire machine? Like I said, it was a bad business decision altogether! A really bad one. Point in case: choose wisely who you go in business with is how I plan to end this story. That’s all I can say!