High School Test Stand for Hybrid Rockets, labview and sensors integration

[elfenix7]

Hello everyone, I am representing a high school rocketry program which is in the process of redesigning and updating our test stand. We run the test stand to validate specific fuel/oxidizer/nozzle combinations before flight of our 100k ft class rockets. Unfortunately, the teststand labview programs were designed years ago by students who neglected to pass on their knowledge, and then edited last year by a class with minimal training. During their edits, they broke the labview program. Therefore, this year we are starting over at either a blank slate, or a former stable version. Unfortunately (again) upon exit last year, the test stand wiring was unplugged. Therefore, it is currently inoperable. We are in need of help to determine how to reassemble the sensor/solenoids, and on tips for refining the labview program in use. This class has so far studied the Labview Core Module 1, and is willing to progress. Attatched is the currently in use program.

Hardware in use
3 Omega Pressure Transducer to measure chamber pressure during combustion (PX309-2KGV)
1 Omega Pressure Transducer to measure Head Pressure (PX309-1KGV)
1 Load Cell to measure thrust (details forthcoming)
1 "MOOG" valve (details forthcoming)
1+solenoids for N2, C02, 02, N20
1Load cell to measure tank fill (details forthcoming)
Possible other sensors, to be determined tomorrow.

Connected to a cDAQ-9174, with modules 2 x 9125, and 2 x 9481

So far all labview code has been edited in labview 2013 on a single sony laptop that is used for the teststand.

Due to school schedules, replies may be delayed somewhat, we will strive to reply as promptly as possible to this thread, more info will be added tomorrow when we have acces to the teststand once more. Thank you for any help, and for your time.

[Gregory]

Hi elfenix7,

It definitely sounds like you've been dealt a bad hand from the previous students. I cannot see your code, but to me it sounds like a very hard task to try to wire up a system with only seeing the software. Generally, the compact DAQ modules will interact with LabVIEW using either the DAQmx drivers or some kind of network variable. You may be able to deduce from these functions what hardware it is interacting with.

For instance, if data is coming in from some location "dev2/ai4", you will be getting data from device 2, analog input channel 4. Your device 2 will depend on how the modules are situated in the cDAQ chassis. I believe it would be the module in the 3rd slot (dev0,1,2,3...).

When you talk about your test stand, is that just what you are calling your setup, or are you using the NI test management software "TestStand"? If you are using TestStand, you can find tutorials for that online as well which should help quite a bit. 

All this being said, it sounds like you have a lot of components to your system. I personally would not have felt comfortable working with a system like that until taking the Core 3 classes in LabVIEW (and had at least a couple smaller projects dealing with 1-2 instruments!).

Try working with 1 component at a time, and then integrate it at the end. If you try to put calls to several different instruments on the same block diagram, it will be very hard to debug and take much longer.  

[Ben]

That code is actually better than I expected after reading your write-up.

Your analog I/O is;

Load Cell

Pressure 1

etc.

The horn is connected to mod 4 and all of the other DO are on mod 3.

Use MAX to test each module and input to make sure you  have things connected right and ensure the device name in MAX matches the I/O used in the code.

Ben

[udka]

-I didn't see Stop button implementation, I believe you are using Abort button which is not advised.
-Use one of the methods for Stopping Parallel While Loops in LabVIEW with One Stop Button:http://digital.ni.com/public.nsf/allkb/267704CDE91156D186256F6D00711AAE

[elfenix7]

Thanks for your help, we are not using the software teststand, it is simply a stand that we test rockets in. I will try to upload some pictures tonight to clarify. For the last few days the students have begun tracing wires, and isolating components to test with. Unfortunately the wire labeling had also been messed up over the last years, and as it is all conduited this may take a while to recitfy.

[elfenix7]

Here are a few pics of the setup.

Also, loadcells are Omega Lc101-1K and 500
Ignition exciter is pictured.

[elfenix7]

UPDATE- As of last month, we have successfully restored the teststand to a basic level of functionality. Pressure and thrust sensors work, and two dead transducers have been replaced. All solenoids function, and the students have completely rewired every input and output in a much easier to follow format. They also labeled the wires this time.

As per our NASA grant, we are implementing an additional DAQ (MC USB-TC) and a set of three K type thermocouples connected to it to monitor the temperature of our test cell, and to provide an automated shut off function in the event of another burn through event. This addition also prompted the move to a more modern Dell desktop in place of the 6 year old sony laptop our teststand had run off of. After a significant amount of difficulty due to the IT department updating to 2016 labview, and our files being only partially compatible coming from 2013, the students have updated the program to run in labview 2014, albeit with some error messages. I will attatch the error list tomorrow, when it has been compiled fully. Two main problems occur.  

1-Formerly our measurements were taken every 1/100th of a second, now they frequently vary between 1/150th and 1/30th of a second. This poses problems with our analysis of the combustion, as some of our hybrid fuels have unstable combustion, and the highly precise measurements are necessary.

2- At the end of the run, the program will consistently display an error message stating that error -200279 has occured, that the application is not able to keep up with the hardware. We have attempted to increase the buffer size, and to decrease the temperature sample rate (hardware is only capable of 2Hz, so this should not be that much of an increase?), but with no luck. Our vi has a queue counter on the front page, which flickers rapidly between single digits and zero, but never seems to show a backlog. Labview is only using ~150 MB of ram out of ~6gb unused at any time, so if the program could be told to access more this would not be a problem.

I have attatched the most recent version of our code.

[Kodester]

Hi elfenix7,

It sounds like you are having two entirely new problems. Issue 1 is a problem with your LabVIEW architecture, and issue 2 is a problem with dequeueing buffer size. I would make two new forum posts so you can get more attention, and possibly some new opinions to help out. As for my own 2 cents, for issue 2 you are having I would reduce your code to only the task throwing the error and establish what is happening. You might not be reading samples fast enough for the LabVIEW buffer (which you are not able to alter).