I have an issue with the data formatting from my output array and I cannot figure out a simple solution. I have created a complex API to operate our measurement setup over GPIB. The API collects the data in a 2D array in the format:
Data 1 Data 2 Data 3 Line 0
Data 1 Data 2 Data 3 Line 1
If you attach a bunch of VIs, please tell us the name of the toplevel VI.
Please do a basic cleanup on your code first. Nobody want to troubleshoot code that contains piles of overlapping elements and hidden wires. Tha'ts just disrepectful.
Your shift register probably belong in the outer loop. Are the 2D arrays all of the same size?
One of the requirements of an Array is that all of the elements are of the same type. For a 1D array, this is simple -- everything must be an Integer, or a Dbl, or a String, or a Something Else. For a 2D array, all of the 1D "components" of the array have to be of the same type, which here means that they also have to be the same size. For 3D, all of the underlying 2D components need to be the same size, as well.
It is not clear to me that your basic requirement fits this picture. If that is true, then a simple extension from 2D to 3D will not work.
Are you intending to keep all of these data in memory, and never write them to an external device? If you do write to a file, then you can consider a format where an entry would be a cluster consisting of identification (name of instrument being measured, for example) and the 2D measurement for that instrument. Now you have the situation where you have a 1D array of clusters, with the cluster element containing the (now variable-sized) 2D array of measurments for each instrument.
Forgive me, I didnt believe my code was that untidy, but I will try improve that in the future. I am also very new to labview and when I am unable to accumllish a task I try various approaches, which probably made the code look a bit messy. To answer your questions, the top level VI is 4142_Control.Vi. This will open up the subVi (Template.VI) within the 4142 VI to simulate the measurement setup and output the data. The shift register is there to show all the data captured. However, I would prefer to output each measurement (in a 2D array) and use the third dimension to index it. The array size may not be the same and this is adding to the complexity. Do you have any suggestions on how to accumplish this taks or is it impossible?
Thankyou for the reply. I will be writing the files eventually to an external device, so I belive your method will work for this application since the 2D arrays can vary in size. I am quite new to Labview, so can become stumped from time to time and only ask a question when I cannot see a solution. Can you provide some assistance with adding the identification? Will this method allow for over-writing the data if needed before exporting or will the file have to be called and over-written?
Forgive me, I didnt believe my code was that untidy, but I will try improve that in the future.
Note that LabVIEW allows you to cleanly "make room" by "ctrl-drag" a rectangular area. Try it! 😄
If you just enlarge structures over existing code, it quickly becomes unmaintainable. Here's a small collection of some serious cosmetic code problem.
Thanks for your helpful suggestion. I do usually tidy my files up, but on this occasion I didnt expect anyone to look at the hastly prepared tempate.Vi in that much detail. This file simply simulates the test kit, but is highly simplified from the original which contains about 50 Vi's. It does however work perfectly despite the way it looks, but again sorry for not tidying the file. The problem is not with this file, but the 4142 control.Vi, or more specifically how to manipuate the data produced from Template.Vi. I thought this would be a simple task, but will require some more thought. I will attempt the to use the cluster solution as suggested by Bob, so researching it now.
Can you provide some assistance with adding the identification? Will this method allow for over-writing the data if needed before exporting or will the file have to be called and over-written?
Your data are a 2D array where the Rows are what you seem to identify as "Line 1, Line 2", while the columns are (mostly) Data Values (Data 1, Data 2, etc.). Suppose you decide that you have multiple instruments, each with a name, each having a set number of Data Values to be saved, and an unspecified number of data points to go into the file.
Here's one Idea. Create a 1D array, called "Data Reading", that will contain a single reading in the form Data 1, Data 2, Data 3, ... (no "Line X" entry). Note that for each Instrument, the size of this Data Reading array will be set by the Instrument, i.e. Instrument A requires 3 readings (Current, Voltage, and Temperature), while Instrument B requires only 2 (Voltage and Speed). Take a series of Readings for Instrument X, generating a M x N array, where M, the number of rows, corresponds to the number of Readings you took, and N, the number of columns, is 3 if Instrument A, 2 if Instrument B, etc.
Create a Cluster of two elements -- Instrument, a String naming the Instrument (or, more elegant, perhaps, a Enum that takes on the values of the allowable Instruments, which makes it easier to ensure you don't have "spelling mistakes" in naming your Instruments in your code) and a Data Array, the 2D array of Readings.
Now do your Testing. As you do each Test, you need to specify what Instrument you are testing, and then just run the test, taking as many Readings as the Test or your measurement requirements dictate. Each Test generates a Cluster -- save all of the Clusters in an Array. If you need to repeat a Test, go ahead -- you can decide whether to keep the Original and the Repeat Test or simply replace the Original Test (in the Output Array) with the Repeat Test.
Finally, you need to think about how to write this big array to a file. There are multiple pros and cons, some of which depend on whether you need it to be "human-readable", capable of being integrated into other applications, whether it needs to be index and/or searched, etc. A whole other topic.
Bob, thats a very good suggestion and not one I had considered. I will give it a go and see what I can come up with.