LabVIEW
Using comport data to start a sequence
Solved!
ssmith490D wrote:Altenbach--
I most certainly can. The VI is in LV 7.1 Any tips you give are appreciated. Why is using "string to path" and path to string" and issue.
Which do you think is easier to code:
Hard-coding paths using strings makes it non-portable across platforms. As it is, your code will only run under Windows.
Also,
The parallel while loop is gone but I still need a way to get the clock to update once per second rather than once per read, which is currently once per minute. I believe I fixed the opening of the file each read. I now do it before the main loop. Thanks in advance for the help.
You started another thread asking about how to sum up elements over the past 4 hours, which is clearly related to this. You are assuming it's once per minute. You cannot guarantee this. You loop is software-timed, and as such it will be a slave to the operating system's whims and fancies, like deciding to do a Windows update check, or an anti-virus check, or...
ssmith490D wrote:I don't see how summing the last "n" elements in an array is similar to updating a clock once per second. What am I not seeing here?? I had the clock in a separate while loop running parallel to the main loop and it worked, but I had 2 stop buttons, one for each loop. Didn't like that. I tried using one switch and changing the switching mechanism and it never seemed to worked correctly. As for the timing thing. Data arrives at the com port once per minute when the Campbell data logger sends it. The read is triggered by the arrival of data. Since the clock is in the read case the clock updates at the same time. That is how it works, right?? I understand that there might be a small delay if the anti virus or updater is running. If it takes a couple of seconds longer to update the clock it should still update with the correct time, right??Thanks for the help.
So, if data arrives once per minute, small timing differences are probably irrelevant. You should take the (orange) time after the data has arrives. This way you can combine it with all the data as a row in your 2D shift register. Please get rid of all these hidden arrays!
If the times are approximately regular, maybe you can use charts. It would really simplify things.
Do you have a typical raw sample string as it arrives from the serial port?
More glaring mistakes:
- You need to initialize the shift register in the inner loop
- You need to wire the VISA resource across ALL cases of the case structure. RIght now, if you stop the VI while it is in another case, you'll get an error closing the resource, because it is invalid.
- ...
I am not a hardware guy, but your visa stuff looks odd. You are waiting for long times, during which the clock on the FP does not update.
About the summing of the last N points. It also makes little sense. Do you want a running average? Do you want to decimate the data in some way? It is difficult to see what the sum of N windspeeds or direction angles would mean to the observer. 😉
ssmith490D wrote:I need the arrays so I can plot them against time. If, for some reason, data stops for a period of time the plots will show that break in the data. I don't think you can do that with a chart.
I don't have time to look at your VI at the moment, but you can have gaps in charts. Just feed it NaN instead of data for the missing points.
For the summing of points, all you need is a single scalar in a shift register where you add the incoming values with each iteration.
