mross

It would depend entirely on how the data is formated in the file. If you could share that....

I never hurts to post code. It sounds like you are not yet on the dataflow bandwagon. Dataflow differs from sequential programming in that functions, structures and sub vis run when the get all their wired input data. And finish when all the wired outputs get data (default values can substitute if they are enabled). It is not only possible but desirable that these nodes may operate in different order depending on circumstance. In this way LabVIEW is inhenently parallel and having numerous loops running simultaneoulsy is common. Each frame of your sequence structure will run when the sequence before it completes AND when it gets all its input terminals filled. Then it only completes when the vis and functions within it complete and all the output terminals are filled. So the sequence is acting exactly rigth and it does not relase to the next frame until the VI is done itself. The borders of loops and structure are important. Terminlas on boreders represent buffers for data. If you wire a control that is outside a border to a border it creates an input buffer. If you wire any indicator outside a border to the border it creates an output buffer that must be filled for the structure to complete. If you wire a control inside a border to the border an output buffer is created. If you wire an indicator inside the border to the border an input buffer is created. This is tricky: if you don't wire something from the outside to the input terminlas they are uninitialized and under some conditions they may not be empty. Output terminals can have a defalut value if unwired. You should consider getting away from the use of multiple frames of a sequence. This sounds weird but we often use a single sequence frame to encapsulate functions that need to occur at the same time, but we avoid just what you are doing as it is too restrictive and can slow down program execution. If the VI can go ahead with some operations, it should and a set of sequence frames stops this from happening. The border between sequences is the same as wiring an output from an individual sequence to the input of another. With both stacked and flat sequences the wiring betwen sequences is implied and the output terminal is the input of the next. Hmm, I don't know if two buffers are created as would occur with two discreet structures. You said: " because i need to execute some things before it is called. " Execute those initialization things within a single sequence frame, but then wire something as an output to the subvi, but the subvi is outside the sequence. You can have additional sequence frames if you like and now the subvi can run independently of it. You can even run basically nonsense wires just to control data flow. Suppose you ssubvi has an input that is a boolean. Creat that input control on the subvi, drag it into the sequence frame and the wire it from the contro to the sequence border and then to the subvi. Now when the sequnce frame is done the data on the border is released, it passes to the subvi which will not run untill is gets that input. There is a highlight function to track dataflow on the block diagram. Click the light bulb and when you run the vi it will show you all the data as it flows through the vi. This is a great way to learn the implications of dataflow. It is very common to use the "Error" clusters which are built into functions and vis as dataflow controls. The error cluster starts with some early function in the block diagram and is passed through the various functions to which it is wired picking up errors along the way for dsiplay at the end or at different points during execution by placing indictaors. Becasue no function, or structure will run until it gets all its input data, it waits for the error from the eprovious VI and passes it to the next one when it finishes. Mike

I am sort of behind the times and don't mess with the express vi's so I may be offering archaic advise... There are two kinds of "canned" acquisition vi's that are shipped with LV. Continuous and buffered acquisitions. The continuous (which in theory could run for an infinite time interval) acquisitions are primarily used for visual display to an operator. The buffered acquisitions (operate for a finite time interval and produce an amount of data limited by the number of scans to be read) are more for data collection and analysis. You can access the "history" of a chart in a continous acquisition vi to get at the data acquired after the fact for storage or analysis. This is headed in the direction of what say you want to do. You should look into this. However, I never do this myself. All my acquisitions are done with storage and analysis in mind and I know exactly how to limit the of data I wish to acquire - I know the scan rate and number of scans. These are user settable before the acquisition is run, and you don't stop the aquisition in the middle. You wouldn't want to run a really long buffered acquisition and interuppt it before it is completed. My first question is, what do you gain by allowing the rough control of having the operator turn the acquisition on and off? If you can limit the acquisition size ahead of time, even if it is to some ridiculously large amount of data, then buffered acquisitions may be simpler to deal with. You let the vi do its buffered thing and look at a graph of the data after it has finished. In my work I mostly want to compare like data sets. By having them all the same length and time scale it is very simple top make visual and numerical comparisons - after the fact not on the fly as more data is taken If you have no need for comparing data sets after acquisition then the continuous approach is indeed useful. I find that many people start using the continuous acquisitions becasue they are the cool demos that are first seen, but in reality they want finite chunks of data that need further massaging to be useful, bufferd is better in this situation. For "real" work, the not very real time "continuous" display of data on the screen is just a comfort and it is not very useful. Taking data for a prescribed period of time, at a particular rate, and finally post processing the information is more useful. Can you tell me why exactly you want on the fly determination of the data record length rather than setting up a finite test period? Can you say something about why you are acquiring the data, from what signal sources, and what decisions you need to make based on that record? These answers can help me/us provide more useful advise for you in the long run. Your query is very general and the software provides so many ways to gather and process data... Mike

You guessed it. I don't follow you at all. I think you are processing sensor data from your ECM to make a control map for your vette. But I don't get it.

What can you do with this data if it is out of chronological order? Once you get it out of Excel the filesize will no longer bog down the production and viewing of graphs... I don't get it.

What you want is a database function that has been shoe-horned into Excel. It might be easier to use a database. I definitely don't have the LV method in my head. To all: Does Open G do that? Rearrange the rows based on a sort of a single coulmn? To JD: I coiuld help you with what I thought was a newbie question about how to work with a 2D array. I am interested to do the record sort, but I know I don't have time right now. Sorry about that. See what I mean about code samples and a good description to start off a discussion? I am glad I didn't make a totally unsuitable example to show you something you don't want to know about.

So you want to duplicate an 'auto filter data sort' where all the columns are sorted according to the sort of a particular column...you don't just want to pull out one column and sort it alone and reasssemble?

Samples of the data and vi's are aways good for getting a quality answer and making sure the answering person doesn't spin their wheels trying to fill in the blanks. The LAVA forums make that easy. Since I don't want to spin, I will make a general answer: index out the column and sort it, put it back together. Mike

There is always good old fashioned hardware... That is better than wrting your own software filters. It is easy to make a running average vi. I can give you one for post processing acquired data (v 7.1). Let me know. mike

Your vi won't open for me so I have to talk generally about the task. You have to ask yourself, "How would I evaluate two traces and compare them, if I did it without the help of a computer?" You will have to get LV to do roughly the same things. You will have to identify the maxima and minima - by what criteria will you decide a maxima or minima has occured? (How would you decide what is noise or a real signal? How much noise that could cause faulty analysis can really occur?) Then you know what data to compare from the two waveforms - The first rise of one signal gets compared to the first rise of the other signal, and so on. The time measure measurements are taken at some amplitude. What is the amplitude criteria? Is it some absolute value or a percentage of the total rise or fall of the wave that must be calculated? I have never used Write Waveform. Typically, I will acquire a triggered acquisition into a circular buffer. The example vis of this sort are usually titled "Acquire N Scans ..." The result is an array of the voltage readings that can be analyzed in whatever way you wish. If you want a record saved as a file the you can use Write to Spreadsheet File to produce a comma or tab delimited file. You can find examples (included with the LV software or found at ni.con, OpenG, or LAVA) of how to locate the maxima and minima (and get the array index of that data). Once you know the index of the maxima and minima then you can parse out the data between them and see where the threshold of your choice occured. You would do this to the various segments of the signal and make your comparisons. Mike

Yes, that sounds interesting....I seem to recall the nested events are not supported however. Like mashe quotes from Heinlein, and paraphrased by moi, after listening to the experts say why not, do it anyway. Mike

Yes, that is correct. 2 consumers requires a lot more planning. You can also have a third loop that services both queues... It can get very ugly.

It is a data flow process. A consumer loop runs and completes when all the output tunnels are filled and continues if the conditional says so. All the while loop inputs must fill, then data flows to the dequeue Element function. If there is an element in the queue, then that is dequeued and it feeds the case structure. The case corresponding with the dequeued element runs. etc. If there is no element in the queue, then the consumer loop waits unitl one arrives, then it is processed. Elements can stack up in the queue and they get processed when the consumer gets time, in FIFO order. OR if nothing is queued up by some other consumer loop or the event loop, then it waits. This gets very useful AND messy when you have more than one queue and corresponding consumer loops. A user evernt could queue up multiple operations in one consumer loop that are processed sequentially, or it could queue up several elements in differnent queues and corresponding consumer loops would run in parallel. I hope you don't have to do all that the first go around, but it does work. If that is still not clear then ask again. Mike

The two best things that have happened to me over the last couple years were User Events and learning the Producer/Consumer architecture. In your programs I have the impression that there is lots of user interaction. Obviously, you have a wide variety of tasks going on. I think you should conside a producer/consumer form with queues. I find that the P/C is very akin to a flow chart. If you have a good flow chart you are on the way. In a nutshell you will have an event loop that responds to user input. Each user event will fire off a series of actions by loading the queue - enqueueing. A second loop or third or more, depending on how many parallel functions you need, dequeues and the case structure responds with the desired action. The case can enqueue further actions or just finish and wait (I usually enqueue a "Wait for user instructions" case to do the waiting.) Within the cases or the event loop you can make decisions based on states of the system and enqueue appropriate responses. I could go on, but you should just try it. MIke

Not to be argumentative, and you are correct about strings working slower, but getting to know the string conversion business is very useful. It seems like cheating, but the string conversion method offers more ways to tweak the numbers and the method is less obscure. As in how wide do you want the result to be? Rather than multiplying, or whatever, truncating, and de-whatevering. Speed is rarely going to be a problem when doing silly thinks like displaying or exporting with a particualr digits of precision. As I mentioned earlier, typically we would just do the operation as single or double precision, at speed, then change the display whenever that is needed - without ever reducing the number in its actual precision. Reducing the sig figs does nothing to reduce computation ,if the representation is not changed.

You should try the string method too. It is more of a useful "package;" more ability to truncate with the offset function and you can feed a "prototype" into the default terminal. It is worth knowing about. Mike

You should learn about the help that is provided with labview. If you go to Help/Vi, Function, and How to help you get a search engine. Enter "rounding" and click List Topics. There you will discover that rounding is a normal function with several options contained in the Numeric Tools of the Block Diagram (BD) tool pallette. If you place your screen cursor over any of the function icons you see that each has a useful name such as "round to -infinity." If you multiply by 1000, round the way you find most appropriate or convert to integer form, and then divide by 1000 you will get a number truncated to 3 decimal points. Or you could convert the number to a string, formating as desired, and then convert back to a number. These are normal function found in the BD tools pallette. I have no idea why you do not find the usual methods appropriate such as converting to single precision. Normally most people just use single or double precision and adjust the indicators to show what is necessary - as you noted. Nothing much is gained computationally by truncating a double or single precision number...the computer still has to treat it like double or single precision no matter how many zeros are trailing. Mike

And gosh, aren't these projects hard? What were their profs thinking? It is a wonder these poor folks have time to get a brew before they send us an email.

If you look at the image I posted you can see it does the same calculation properly using a formula just like yours. The only way yours could not do it right is if the wires are wrong. Check them and be neater next time. You will save everyone a lot of trouble if you pick that habit.

Sorry, I can't see that anything is wrong. Your vi is hard to read with lines on top of lines. Maybe we both just can't tell what is wired where.

Yes. What causes the switching?

You haven't stated what your project needs are. That could be helpful. The VI was helpful. You said LEDs and I thought you meant actual LEDs attached digital outputs of a DAQ card, not boolean indicators on the front panel as you have. You are missing the concept of dataflow and the use of wires for sequencing. Try to stop using sequence structures they are bad form the way you are using them. Dataflow progamming is not like sequential text programing. No gotos. A function or subvi runs when all its inputs are filled with data. I sympathize, you must be trying to make sense of this with no mentors around. Been there. You should turn on the highlighting (light bulb symbol at top of block Diagram in menu) to watch how the data moves about the VI. There are about a million ways to do this. I am not saying you want to copy what I did. It is more to demonstrate dataflow for you. Play with the vi a bit. You will need to extract both the top level vi and the subvi to the same folder. Download File:post-48-1146803160.zip

What do you know how to do? (Real question, not rhetorical) Have you ever written a VI? To do what? Are even able to wire up LEDs to the digital outputs and get that to work? What you are asking is incredibly simple and all of us had to get at least that far on our own. Furthermore everytime we do something new it is the same for us as for you. We go look at the examples that ship with the software (there are very pertinent example for you to use). We try and figure out how the examples work and mess around with them some. We read forum archives, look at tutorials, etc. Once we have the basics in hand and at leatst a rough understanding of the basics - then, then we start asking people to show us the VI. Mike

Sorry, I won't do your school work for you. But, you may want to look at how to read and write to digital ports and lines. Mike