Steve's Things

Well, since funding for the viscometer has fallen through for various, understandable reasons, I have decided to take one last kick at the can before I shift my focus on to other ventures. The last kick at the can? Two similar viscometer heads, two very different purposes.

This is the rough mockup of the new head, it is the same for both designs

The hand-held stormer
 
  This device is designed to work in the field and provide readings in KU, Grams and perhaps Centipoise. The device itself doesn’t feature any communications of any kind. Also, there is no LCD display, instead a 7 Segment x 4 LED display is used since it’s a bit cheaper and more visible in various lighting conditions. Also, since it will be use tables of values rather than calculating it on the fly, I can use some slimmer hardware such as the PIC18F2620 Microcontroller or an ATMEGA8.
 
  Also of note is the fact that everything is fairly cheap to build, these low-cost viscometers could be used in paint shops in any size container. I am building one to go to Cold Lake where they’re going to try one out since they’ve been having trouble getting decent consistency using only a mixing stick to test viscosity. 🙂
 
  Here’s a rough mockup of what it will look like. Of course none of the boards or covers are shown, also the display isn’t visible, I haven’t decided the best location for it yet. I may actually put it inside of a separate enclosure to make the unit lighter since it requires 12 volts.
 

Mockup of the handheld viscometer

 
  This is probably the most marketable device thus far.
 
The Super-Visc
 
  Over the last 9 months or so I have developed a number of interesting methods for determining error and correcting for it, I have also develop methods for calibration and symbolic parsing. Since I would hate to come away empty handed and waste all the of knowledge accumulated over the course of 2+ years, this is the coup de grace of rotational viscometers.
 
  To my knowledge, most other rotational viscometers use a beryllium copper torsion spring to provide a fixed, known spring rate, or torque on the sensing shaft. The cheap ones like the stormer viscometer base it on time and run a fixed speed AC synchronous motor, whereas the more expensive ones use a variable drive and encoders on the top and bottom to determine the difference from top to bottom. My viscometer uses the cheaper method of determining difference and RPM by using the timing via ether opto-interrupters or hall effect sensors. By using a a very high sampling rate, I can get very precise measurements of the rotation, though some differences may occur during rotation. Accuracy is achieved through error correction in the form of running averages, temperature and friction compensation and angular displacement compensation. While this is places a heavy burden on the software side of things, it is extremely effective.
 
  This viscometer works on three key concepts: Variables, Equations and Test Programs.
 

• Variables – These are variables that are calculated dynamically before any other calculations have taken place. These include ambient temperature, fluid temperature, angular displacement, spring length, time from test start, time from last sample and other mathematical constants such as PI and E.
• Equations – These are the equations that determine the units. You may (and for basic units, must) include variables in order to calibrate the device. These equations are completely configurable by the user and includes every standard mathematical function such as Cos(), Sin(), Cosh(), Powers, Square Roots and many others, perhaps even logical equivalents say to multiply by 1 or 0, could be useful. While developing this I had a choice, either computationally expensive or memory intensive, I chose memory intensive symbolic storage in order to improve performance. This also allows one to develop any unit with any paddle one wishes!
• Test Patterns – These are the patterns that develop the test. For example, let’s say you want to test for KU. You place the appropriate spindle in the machine and select the KU test run. KU test runs would appear as follows (200 RPM Fixed, Equation KUPU, Out->FLTP, Out->KU) or for Centipoise vs RPM (50-220 RPM variable, Equation CNTP, Out->CNTP, Out->RPM, Out->FLTP). These are a boon for the experimentor.

 
  One key disadvantage of this device is the initial difficulty of calibration. However, if done en masse in the factory, it wouldn’t be an issue. One of the major advantages of this device is for the experimenter. You could put a hotdog on a stick, put it in a fluid, create a relationship via an equation and call it whatever you want. The device is very configurable and would probably be well suited to materials engineers and chemists who need either standard or non standard tests with a large amount of automation in terms of data collection.
 
Here’s a mockup of the finished laboratory device.
 

Potential mockup of finished device

 
The device will feature an RS485/232 output along with perhaps a touch screen or simply a keypad and 20×4 LCD display. The processor will either be a DSPIC33F or PIC32, I may stray towards Atmel since they have great throughput. My current prototype board however has a PIC18F4680, it’s enough to test on but its limits on RAM are starting to bother me.
 
Well, this was a long post… Whew 🙂
 
As always, anyone who has any questions can leave a comment or E-mail me.