Labview To A Thrill....

The basis of my latest project is the design of a real time data acquisition program using LabVIEW, this is a program which allows you to build programs visually without having to write code. My programming knowledge is based on Matlab but I have built several complex models using a program within Matlab known as Simulink, which is simply a graphical representation of Matlab coding. This is a very powerful way of implementing dynamic systems quickly, especially for engineers as we tend to see the world in a visual way, rather than trying to implement many lines of code. The picture below shows a Simulink model that governs fuel flow rate into a gas turbine. This model is one of many subsystems that make up the entire simulation, I wont go into details but it should be easy to see that building up a model this way has its advantages.

Now LabVIEW has very similar approach to Simulink, but that is were the similarity ends. I have only been using it for a week but I'm slowly getting to grips with it. Although it is designed to receive data through a a digital to analogue converter or DAQ, it seems like the good people at National Instruments have decided to make it really easy to use LabView their own brand of DAQ's. Use another brand of DAQ and you either have to rely on the DAQ manufacturers releasing some code, help from forums or just ploughing away and figuring it out yourself. Trust me, if you are new to this kind of thing, I would seriously consider paying a fortune for a National Instruments DAQ, it will save you hundreds of hours of work on a very steep learning curve.

I currently own several DAQ's, one is a kit from Maplins, I have two from DATAQ which are very good and come with some good free software, and the fourth is from Starting Point Systems. The latter is an excellent piece of kit called µChameleon and also comes with a piece of nice software with a really simple but interesting programming language. For my jet engine test bench I needed ten analogue and four digital inputs to measure the following:

• RPM
• Thrust
• Fuel Flow Rate
• Pressure Ratio (differential)
• Case Pressure (gauge)
• Freestream Temperature
• Intake Temperature
• Compressor Temperature
• Turbine Inlet Temperature
• Exhaust Gas Temperature
• Fuel/Gas Solenoid Operation (digital)
• Starter Motor Operation (digital)
• Glow Plug Operation (digital)

So this means I have to use two DAQ's, specifically the µChameleon, which has eight analogue input channels and the DATAQ 148 DAQ which has a further four analogue channels. They both also have several further digital I/O channels, counter channels, analogue outputs etc. But this also means I have to use LabVIEW to read two instruments simultaneously which may or may not work. I hope it works or I have to lose two measurements most likely the pressure measurements.

In between playing with LabVIEW I had to go back to address an old problem I had before in measuring the the RPM signal. The engine has an ECU that controls the fuel flow rate while also monitoring the RPM and exhaust temperatures. In a nutshell, should these deviate from limiting values the ECU will correct the fuel flow rate to bring them back into line or even shut the engine down. The RPM is measured by using a hall sensor and small magnet embedded within the nut that holds the compressor onto the shaft. This signal is a 0 to 4V pulsed signal and at the engines maximum speed of 160K RPM, this signal will have a frequency of around 2.7K Hz. This signal also has some noise embedded within it and is particularly noisy at very low speeds, the picture below shows the signal measured during five pseudo start attempts where the engine is spun from 0 to 5000 RPM over several seconds.

 I did play around with this signal in LabVIEW but even though I managed to get a reliable RPM reading using a generated signal mimicking the hall sensor, complete with random noise of a similar amplitude, I could not get it to work with the real signal. Although using the oscilloscope function within LabVIEW I did see that I had what appeared to be a valid signal. I also didn't like seeing the way the on screen gauge would behave at zero or very low RPMs. So I made the decision to convert the hall sensor output from a pulsed dc signal to an analogue voltage which I had already cracked with LabVIEW and was having great results with. See the short video below, this was literally two days after losing my LabVIEW virginity so excuse the simple layout, and I have since moved on and improved the response from the load cell to remove a lot of the noise that caused the gauge to 'bounce' between values. Also note that I took the video at 4:00am so there is no sound bar some rustling and the light is dark, but you get the idea.

Now before I get into details on how I plan to do this I think I should cover how I linked my DAQ's with LabVIEW.