Improving performance by eliminate sequence structures and global/local variables

[JohnnyF]

Hi all,

I am working with an existing VI that we use for fatigue testing. I am trying to refine it to eliminate some of the local and global variables and came across the information on here that sequence structures should also be avoided. I am confused as to how I might impliment a state machine or similar structure within my VI and was hoping that some of the more experienced users could help me out. The VI works fine though it is slow to obtain the initial readings from the DAQ board. I am just trying to do all I can to optimize it since it will need to run for days at a time on a Pentium II with a whopping 128 megs of ram. I'd really like to blow it up and start over but I lack the knowledge and the time to do extensive trial and error work. If any of you can just point me in the right direction and offer some suggestions for altering the data flow, I would greatly appreciate it. I'm pretty new at this so please be gentle.

Also, I am trying to impliment something to save the data to a file every x number of times a peak has been detected but haven't been able to successfully impliment that. I'd appreciate any suggestions on how to accomplish that as well.

Thanks in advance for any help you can provide, and sorry for the length of the questions!

The first VI is the intial startup, which allows the user to get to the setup VI, which then allows the user to use the main fatigue tester VI.

[JohnnyF]

For some reason, it won't let me edit my previous post.

I wanted to mention that I have experiemtned with the various peak VI included in LabView and have checked the examples, but still can't quite seem to get it right. Also, is eliminating the sequence structures simply a matter of replacing them with while loops and incorporating a bunch of shift registers, or would there be a better way to go?

Thanks again!

[Andy F.]

Hey JohnnyF!

Basically if you want a good example of a state machine you could check out the LabVIEW template.  If you select New and then select VI From Template»Frameworks»Design Patterns»Standard State Machine you will get a good starting point for a state machine.  The instructions on the Block Diagram should be helpful when modifying the application.  Another design pattern that you could look at would be User Interface Event Handler since it looks like you want things to happen depending on the button you push on the front panel.  You can configure events for the buttons and then only perform the tasks necessary when the button is pressed. 

Regarding your question about dataflow and removing sequence structures, I would check out some of the DAQ examples (Help » Find Examples), which will show you how the error cluster is used to control the flow of data in the VIs.  Many VIs use the error cluster to pass error information, so to get VIs to execute in order all you really need to do is wire the error clusters together.  Try running an example with Highlight Execution on (light bulb button on the toolbar of the Block Diagram) to see this flow. 

To help with the last issue you mention what are you trying to do with the peak VI (find a peak obviously) but what is the desired functionality and what is happening.  Any information about LabVIEW version and anything else you think would be helpful.

Thanks!
Andy F.

[JohnnyF]

Andy,
Thanks for the reply. I'll poke around some more with some of the examples. The tip on the error clusters is just what I need-it was getting a bit out of control otherwise.
Basically, the data I am getting is somewhat like a sawtooth wave, though the system returns to its equilibrium position very briefly in between cycles. What I would like to do is save the sensor data values (and calculated values from the sub VI, if it doesn't complicate things too much) every x number of detected peaks. Currently, it is saving the data on either side of the true peak value so the Excel file doesn' relfect some of the more severe loading conditions. I can attach a data file/Excel file if that would help. I'm sure it's relatively simple to do but I'm having trouble with the logic. As I'm sure you noticed, I'm a bit new to these things.
Thanks again for the help!

[Andy F.]

Johnny,

It would be very helpful if I had some data.  Either an Excel file or, even better, a graph with the data saved in it would be very helpful.  You can save the data in the graph by running the VI, then stopping it when it has appropriate data, then selecting Edit » Make Current Values Default and saving that VI.  This will save the data in the VI so next time you open it, the data will be there. 

In any case, I am a little confused about what you are trying to do... It sounds like to me you are counting peaks and every x peaks you would like to write that information to file, is that correct?  Please let me know if my understanding is not correct.  Thanks!

Andy F.

[JohnnyF]

Andy,
Unfortunately, one of our valves broke so it will be a bit before I can get it up and running to collect fresh data. What I have attached is the Excel file generated for a sample run. The shape of the plots is what is observed directly in LabView, the issue is that the peak values are as large in magnitude as what was shown on the waveform charts.
Sorry I wasn't more clear, that is a gift of mine. What I would like to do is save a set of data every x number of times a peak is detected. Each time it saves the data I would like to record the parameters corresponding to a peak in LC1 and subsequently the parameters corresponding to a valley in LC2. The issues I have are that the frequency does not seem to be 100% constant and we expect that the peak values will decline somewhat as the part fatigues. Thanks again for your help, and let me know if what I'm trying to do is still not clear.

[JohnnyF]

Andy,
I also have a question on how best to eliminate some of the local variables in the VI. Within the pseudo state machine I have, there are several nested sequence structures. There are a few parameters I need to increment that are within these sequence structures in the inner while loop (e.g., cycle count, save count, jump duration counter). This is currently being done via local variables, which I would like to remove if at all possible (that is, if you think it is truly of concern in this case). Of course, since that while loop that contains these parameters runs continuously, this hampers my ability to do so. I've experimented with several variations on building arrays and so forth using the shift registers, but nothing has quite worked right. I've attached the before and after VIs; the latter does increment but it resets the values every so often (a buffer is cleared? I'm not sure why or how...). I've searched on here quite a bit and can't seem to come up with a solution to this one.
It turns out that we weren't able to get that valve today so I will not be able to get new data until tomorrow at the earliest. Thanks again for the help!

[jasonhill]

It is safest to wire something to the shift register for each case of the case structure.  Relying on the defaults is dangerous.  For example, if you have five cases and only one of them increments your shift register, then you should have a plain wire connecting the input and output terminals in the other four cases as well.  If the output is unwired, it resets it to the default.  Which for I32 is 0.

On a stylistic note: I try to reserve a space at the top or bottom of the while/for loop for shift registers.  Running them through the middle can be very confusing, especially if there are several cases that do not touch the registers.

[JohnnyF]

Thanks, I had it wired for each case previously but it still did not work. Maybe I messed it up somewhere, though; I'll try it again.
Good call on the location of the shift registers-the block diagram is ugly enough as it is.

[JohnnyF]

Well, today when I wired the tunnels for each step of the sequence and went back to building and summing array elements, all worked well. Go figure...guess I'm worse at this than I thought.