My initial attempts at getting Labview to communicate with a DAQ were based on two methods. The first was an old pdf document from DATAQ and the second was from ultimaserial.com, without these two informative guides I would have been lost. Once I had a working virtual instrument in Labview, vi, I resort to what I did when I was learning to model in Matlab Simulink by playing with various things to see what effect they have. This is my most efficient way to learn new software like this, because by discovering for myself what something does means I can better understand how to use the tools to my advantage. There are of course hundreds of examples available in Labview for you to play with, so it looks like my summer is going to be busy playing with them too....
Here is a screenshot of my block diagram for the DATAQ 148 DAQ in case anybody ever needs that extra bit of help with their models, if anybody needs the entire vi for this DAQ then get in touch. This vi has an extra bit tacked in to it so I could see how well it was working when using a load cell which I use to measure thrust.
The next picture shows the vi I used to import data from the µChameleon, this is still in the development phase and requires some tweaking. This time there is a signal generator and an RPM measurement block to investigate how to build a reliable tachometer. More on this later. This time the vi was assembled from scratch based on trawling through many, many forums and help topics.
The front panel, the bit that will be the user interface once complete looks like this, the calibration dial is used to set the thrust gauge to zero before use, as strain gauges are very sensitive to small changes in temperature and even switching the power supply on and off can result in a small deviation from the previously zeroed condition. A careful look at the block diagrams will show that the output from the DAQ is multiplied by a small value to convert the signal to Newtons, the dial then subtracts a small value from this signal, which is then passed through a block which ensures that the output is always positive. Therefore by moving the dial, the needle will approach zero, and if the dial exceeds the zero value, the needle will bounce back up, preventing false calibrations.
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.
It's been a long while since I last posted and many things have happened. Don't worry I promise not to bore you to death. Well that's a blatant lie, I will try my hardest to bore you.... Lately it seems my favourite topics of conversation revolve around jet engines, no pun intended.
Anyway I have managed to winkle some spare time into my incredibly busy life that the fourth year of an aerospace engineering degree demands. So what did I do with the few days I had off over Easter break? Did I watch TV? Go flying? Run about in the garden, splashing a water from a hose in slow motion like those sentimental flashbacks to childhood? Nope. I spent the time working on something. It is a philosophy that Aerospace Girlfriend doesn't understand, but I don't see it as work. In fact over the looooong summer months between each year at uni I start to go mad with the shear boredom. Usually by the end of the summer I have no money left to carry on with my projects, the weather is usually terrible and I resort to spending the evenings moaning about the lack of Dr Alice Roberts on television these days. Ah Dr Alice Roberts, now she does make me want to run around the garden with a hose.
So what have I been doing, well I have been building a jet engine data acquisition program which would let me control a jet engine through a computer and see the performance of the engine in real time. The problem is I have to couple many, many, many different sensors to the computer. This is the easy bit and I have been doing this for years using a DAQ, but now I want to build a neat virtual dashboard and have the on screen instruments display the data from the sensors using Labview. Sounds easy, but trying to use Labview is very much like trying to herd badgers into a laundry basket with a plastic spoon. I'm getting there though and will post details soon.
In other news I won the NorthWest Aeropace Alliance 'Sir Frank Whittle Award' in February with my work on the steady state and transient performance of micro-gas turbine engines. I have a problem accepting praise for my work, especially the project that won me the award and this annoys Aerospace Girlfriend. The project wasn't done to win awards, simply as a way of me getting to spend vast amounts of time working on something that I enjoy doing while getting some much needed uni credits out of it. Sir Frank Whittle is a personal hero of mine, and it was due to a documentary about his achievements, that sparked my interest in jet engines when I was a child. So winning an award set up in his honour, in the field of gas turbines was very cool.
I also won a £1000 as part of the award and it was only right to invest a small amount into buying a bunch of pressure transducers, thermocouples and other assorted goodies towards the jet engine testing bench. Here is the obligatory picture, I had drunk many glasses of champagne and wine by this point, combined with my unphotogenic 'bulb head', I have no idea how the photographer managed to get a half decent picture. My dad took some pictures, but the less said about those the better....
I will be graduating in a few short weeks and the thought of being released into the world as a real live boy engineer is quite scary. I will still be building mad contraptions in the garden shed, except this time I am a certified rocket scientist. Let's hope this means less failures and more success? Turbines spewing flames, running pulsejets late at night and small explosions as a rocket motor decides to commit suicide, these don't go down too well with the general public. I need to win the lottery then I can become a mad scientist, free to tinker at leisure, although that's as far as the dream goes. I haven't yet decided if I want to be a Doc Brown kind of mad scientist or a Professor Frink. Time will tell, but I think my future lies with Doc Brown, (again no pun intended)...
Now that I have mentioned Doc Brown, I think I should also mention his closest living parallel, Clifford Stoll. Watch this because if every child had the experience of having a teacher like him the world would be a far better place. I remember my science classes at school being dull and boring, well most of school for me was dull and boring. I remember having the fun of mathematics beaten out of me quite early on. and of course I couldn't be bothered to do any homework preferring to spend time reading books on geology, rockets and whatever else I could get my hands on.
