If you carefully look at your program/vi you will see that you program the machine to perform one measurement and then do the measurement.
all the stuff relted to scanning is not what you need, because you don't scan but just need to repeat the measurement.
So put in a while at that point and an wait for 5 seconds and repeat the measurement as long as you want.
I don't have that dmm but the idea is:
setup measurement, while not finished measure each five seconds, save data.
If you send me the vi instead of a 2017 snippet, I can modify the program to show what I mean
I tried a bit to do few things with those advises.
The VI is a bit simpler and I managed to get a "continuous acquisition" (one sample each 200ms).
It seems to work as I can see the graph of defbuffer1 being filled bit by bit.
I'm still stuck with how to save the acquisition on my computer,
I get scolded by LabVIEW :
So I'm trying to find what should be the problem (I wonder if it's a wrong name or string I put in the "save buffer.vi". Or if it's even possible to put the acquisition on my computer rather than on a USB key.
I'm also trying to put the real VI if Mr Albert.Geven manage to find something 🙂
Kudo to him one more time by the way !
I downloaded the driver and your vi and it is nicely done.
How long did you measure?
I also now display the value of the loop counter to see something like that.
But you should not use the save buffer vi because you already read the data from the buffer in the while loop.
The best way is to start a second while loop parallel to the reading one and transfer the data via a buffer to that while where it can be saved.
I'll try to find a vi that will do that for you, but cannot finish that before wednesday evening.
The idea is to read in one while loop, put the data in a queue that is read by the other while loop and by that loop written to disk in parallel with the data reading so that both while loops don't influence each other timing. This is doable when no wires originate from a while are read by the other while.
Because LabVIEW schedules an operation to wait until all inputs are available, and a wire from one while to another makes the other wait until the originating wire has data.
There was an example for this parallelism but I don't remeber the name. Sorry.
I must admit that I didn't try for too long, because I thought that if it worked a bit it should work a lot 🙂
I'll do it longer to try !
Good idea with the loop counter, I'll try.
I thought that at the end of my measure (with the stop button it was supposed to be done like this to get the buffer which was filled during the while loop). And I was thinking about a solution to just save the read values in LabVIEW without passing by the buffer. But I thought it was too bad because the buffer has all the needed info...
Yes I read the data, but I can see on the front panel of the DMM that the graph exist already so I thought the good way would be to get back this buffer in a csv file or something along to put it on excel.
(Naively I was imagining something along this :
Start experiment -> clear buffer -> start measurement -> stop measurement by clicking on the stop button -> save buffer in my computer)
But it seems I'll have to do something along this parallelism you talked about.
"Start a second while loop parallel to the reading one and transfer the data via a buffer to that while where it can be saved"...
I think I get a bit what you are hinting, but I never tried till now.
I'll try a bit, but if you have a bit of time I can largely wait until wednesday 🙂
I'll try to do my homeworks until wednesday 🙂
Again, lots of thanks for your time and motivation.
I was asking also to the Tektronix staff their thoughts on this,
And the (nice) guy who answered me told me that he doesn't have LabVIEW,
But to him two solutions :
- "The CSV must be saved in the USB stick connected to DMM6500"
(It's not what I want)
- "If the intention is to trace the buffer to Labview, TRACE:SAVE is not the function to use, you need to save the buffer into a Labview array and then save it to PC hard disk".
So I think that Mr Albert.Geven was definitly right. I should try this solution of parallelism. 😱 😉
I found what I was looking for, but could not remember the name correctly.
In fact it is the producer/consumer design pattern.
It is an old pattern and in LV2018 and probably also in versions before it can be found in:
File/new and you will see something like this.
The idea is that the loop above the data is read from the instrument as you do already and queued into the opened queue and that data is read and when a number of points is gathered saved in a file on disk.
probably 100..200 measurements together.
Saving to disk takes some time and saving chunks of data is much more efficient than saving single points.
In a next message, I will send an example of how data can be saved to disk (appended to a file).
You have to make sure that the folder exists in which the file needs to be saved.
attached is a LV17 vi that saves a 2D array to file.
Probably you want to save time since start of measurement and measurement as two elements in a row
And create a 2D array that will be saved as text.
This can be done in the consumer loop by calling this vi with enough data.
Hi Albert.Geven !
Sorry to bother again, I know I'm really close to the end with all the tools in my hands.
But as it's the first time using those concepts in LabVIEW I think I made 2-3 errors.
I'm putting my VI in case you've got time to look at it a bit.
I still manage to read the resistance. But I cannot manage to save values to the file.
- The file path can be written like this ?
And you told me that it's better (maybe even necessary) if the file already exist.
- For this array,
Am I supposed to fill it or can I just hide it from the controls ?
- Is it a good thing to "merge errors" just before releasing the queue, or not in this case ?
- Lastly (I think) how should I deal/link those parameters 🤔 ?
Sorry for all those silly questions, but I'm really not used to those kind of VI in LabVIEW.
A beautiful weekend to all !
So, back again to bother the community 🙂
I'm trying really hard to save my resistance data from the dmm6500 in an 2d array (time vs resistance) into my laptop.
Thanks to Albert.Geven I know that the most probable solution should be the producer/consumer design pattern (data) but I'm having a hard time understanding the array problem and how to save them at the end.
I'm putting the full VI in case of it.
I tried like this :
- The element data type in the queue is a 1D array of double.
- In the producer loop, where we are supposed to generate the data : I use a "buid array.vi" to
* get the measure of the dmm
* multiply the iteration by the time delay (to get a time base)
Like this I have a 1D array of two elements (resistance time)
- Those two elements are put in the queue with "enqueue element.vi"
-Then is the consumer loop, I use "dequeue element.vi" to get back this resistance/time data (1D array).
with this data I use "insert into array.vi" to add the dequeued data in a 2D array at index "i" (iteration of the consumer loop to put the last resistance/time data at the end)
Should it be something like this to get a proper 2D array of resistance vs time ?
Then I use "array to spreadsheet string.vi" with "%f" for the format string because I had an array of numbers and "tab" should be good enough for now for the delimiter parameter.
- If I test my VI with nothing for the file path, I have nothing else than just on data couple in the text in the front panel. So I think I should try differently to add my 1D array in the 2D array that I want to save
- And if I put a file path like "C:\Users\basti\OneDrive\Desktop\test" with the file test already existing. Then I have nothing in the text tab. And nothing in the test file in my desktop.
.... A long way to go it seems
If somebody who has done something along can tell me if it should be done in this manner or if I forgot (a lot of) things ?
Thanks for your reading time in any cases !