Now that I’ve got the new board working, I’ve been programming all of the pertinant functions back into the chip. This time I’ve redesigned them to be a little more modular and useful in the long term. As was mentioned in the post a while back, I made a new board and I’ve come to realise that the RS-485 Port is wrong. It has 2 connectors when it requires 3. A-B-Ground. Sigh!
Anyways, I’ve been running tests with the viscometer and everything is working great so far. I’ve got the temperature sensors working and the conditioning of them with OP-amps has worked like a charm. Though I find that the read value from the ADC is pretty jumpy.
Anyways, as reference, here some photos.
Also, the linearity test went well. Better than I initially expected.
One can notice that there are some burps along the graph but for the most part, it’s fairly linear as far as I’m concerned.
Well, For the last week or so I’ve been developing a new viscometer board. Sloppy as it is, it’s a jump ahead from the last board in terms of overall inputs allowed. I used the 68PLCC package PIC18F6680 in this one because it had a sufficient number of IO and because it looks cool in it’s socket. 🙂
Anyways, this one has the following features:
Several analog channels for temperature measurement.
Several analog channels for use in a torque sensor set-up.
Some analog channels.
built in RS-232 Output.
built in RS-485 Output.
Provisions for PICKit2 hookup.
TVS’s on all input lines
Separate PIC12F683 for PWM output
Debug Serial Output.
All in all, it’s gone smoothly, I’ve double checked a number of the traces, let’s hope all of them are well when they come back from AP Circuits later on. 🙂
Yet another iteration of the stormer viscometer board
What’s an abraser you ask? Well, it’s a device that has two abrasive wheels that are pressed against a plate with paint on it. The idea is to determine the wear a certain coating or paint will get with a number of revolutions on this device.
Anyways, it was acting up the other day and the guys at work asked me to fix it since the numbers were jumping into the thousands quite quickly. Since this device counted revolutions via an interrupted beam of light, I simply stated that it was dirty. I was right, it was just a bit dirty and after blowing the head out and looking at the signal, it was fine. What surprised me though was it’s electronic construction.
Surprisingly it was nothing more than a PIC-based protoboard with a transformer and a gearmotor, I was surprised that it was so sloppily put together. Here are some images of it in case anyone is interested or in case I wish to refer to them later.
As is evident, they used a PIC16C71 for their little project and soldered it together on a protoboard, very strange for company that’s been in business for so many years. They even used cables that didn’t have the correct number of wires in them, they simply trimmed the excess wire, sloppy!
Well, I took the plunge and built an RS232 output device so that I can track the values over a longer term than whatever my memory can hold. I’ve started with a series of tests designed to test the speed control or the encoder. So far my results have been poor. I’m not exactly sure why, perhaps the motor is hooped, maybe the encoder or perhaps even my logic with timing the pulses, I don’t know as yet. I’m going to purchase some different motors to try out.
Click on the pictures to enlarge them, there is a good description of each. There is also a zip file of the analysis data and the program so far.
So, I’ve been playing with simulating the output of the viscometer at a specified power output. When the real unit runs it seems to output noisy but patterned values. I’ve found that the output has a sinusoidal output with anomalies at the upper and lower value ranges. So, I’ve made a simulation of the outputs so I can find the best way to smooth out the sample sets.
In my simulation I generate 2000 samples and divide the samples into 10 sets. These sets are each 200 samples, the amount that’s being generated on the laboratory viscometer. The idea behind this is to make all of the value sets almost exactly the same, so far, I’m close with the average, but not close enough. Here’s a screenshot of the output
I’ll include a link to the file for shits and giggles (It’s freebasic BTW)
Well, as far as viscometers go, I could be considered an expert by now (no, not really). Today my new board arrived and I assembled it, I’m kind of proud of it, it works real slick just like the last one. This one has the following changes
ICSP provisions so that I can program it in place.
a PIC18F2620. Has 10 times the program memory and RAM.
diode protection in case the power is hooked up wrong.
Fast recovery diode for motor induction absorption.
Larger traces for the motor.
Fixed resistor array.
Anyways, here is a comparison shot. Old on the left, new on the right.
After a couple of weeks of solid work, the laboratory viscometer is almost ready for extensive testing. Since this is a redesign and simplification of the older design, it has a few more features and a couple of drawbacks in relation to a brand name Stormer Viscometer. I’ll detail some of the features and drawbacks.
Viscometer can produce results in both KU and MPa*s.
Viscometer can be used as a gel timer.
Viscometer can derive a trend plot of viscosity over time.
Current design is highly simplified, requiring only a 2.25″x1.875″ circuit board and an appropriate power supply, this allows it to fit in smaller, potentially hand-held units.
Has an easy to use menu system to allow lab techs to calibrate the unit themselves and operate it easily.
Has a keypad for data entry, used for time lapses and calibration (Oil values)
Relatively cheap to produce.
No spring to break, unlike the Stormer viscometer.
Unit does not do live sampling, thus, any kind of watch-and-wait testing has to be done by the computer. This is due to the fact that the motor has inherent changes along the time line and therefore a fix sample time is necessary.
Unit is a single CPU unit, unlike the larger in-process version, thus requiring a great deal more finesse in programming.
May still be difficult to detect low-viscosity fluids like water and alcohol. Different motor may make the difference.
Things to do so far:
Finish motor mount – almost done anyways, need encoder though, hence why I’m using the in-process viscometer device for now.
Test and program – of course, who know how long this will take, though, the majority of the difficult work is already done.
Since the last report done on the viscometer, a great many things have changed in regards to the mechanical and electrical design of the unit. It is now a rotary viscometer instead of a paddle based unit. It operates in a similar fashion to the typical Stormer viscometers in that it measures the energy required to push a paddle at 200 (or other specified) RPM; the greater the force required, the larger the KU value.
Summary of what’s been done so far
So far, the majority of the unit is in a functional state. Recent modifications have allowed the unit to function in a more reliable fashion. The unit works on the following principle:
There is a gear motor that is specified to run at 275RPM at full power.
If the motor is running too fast (>200RPM) , the duty cycle is dropped.
If the motor is running too slow (<200RPM) , the duty cycle is increased.
From the duty cycle values sampled over a period of time is derived a viscosity value, preferably translated into Krebs units.
So far, things that are done/workable are:
Main CPU w/o calibration and safety routines
High ESD Input controller
Auxillary controller (not implemented yet)
Main Viscometer Unit
Here is an image detailing some of the items on electronic side of the viscometer:
Click to enlarge
Whats going on now?
Currently, I’m working on a few items related to the viscometer, namely:
Viscosity testing with mostly a flour-water mix since the resulting mixture is similar to the shear thinning fluids of paints and coatings.
Explosion proof case acquisition. While there are a great many NEMA-7 Enclosures available, I’m trying to find one that isn’t $800+ per case.
Algorithm changes. Since the samples that come into the unit are not as clean as they appear on the screen, the sampling algorithm has to be tested in order to produce accurate and useful data to the automation system.
RS-232 Output device. I’m currently working on the output portion of the device, that way the automation system can read what’s being measured.
This board integrates everything that you see in the picture above and allows it to take on the same footprint as the 5×3 power supply. This allows one to purchase smaller enclosures and it’ll be a lot more reliable with fewer interconnects.
While there aren’t any showstopping problems, there are a couple of kinks to work out.
With the increased friction from the new top and bottom bushings, the sensitivity to the lower end of the scale (around water’s viscosity) is almost Nil. I’m going to play around with the sizes and try a couple of tricks in the way of selectively modifing the outgoing voltage. The bushings are a double-edged sword, they help remove the reliance on the alignment of the shaft and the unit in general but, of course the aforementioned friction is now a problem.
Long warm up times. In order to reach a stable set of samples with any fluid, the unit must be on for at least 5 minutes. This has been exacerbated by the bronze bushings to about 7 minutes. I suspect this isn’t the fault of the motor but of the seals and lubricant needing a warm up time in order to drop their friction levels. I am looking at different lubricants and at adding a start up routine that runs the motor at full speed for 40 seconds or so, this seems to mitigate the issue.
Still some measurement differences based on vertical or horizontal alignment….
Well I hope this was informative, if you have anything you want to ask, feel free to do so.