2D Array 1 element a double int and the other Date and time for output to file

[rr1024]

Yes it is empy, but I've seen other applications that save files and they don't require the user to select a file upon launch

[RTSLVU]

---

@rr1024 wrote:

Yes it is empy, but I've seen other applications that save files and they don't require the user to select a file upon launch

---

You have to think about data flow, as soon as the program starts the contents of that (empty) control is sent to the write to file vi.

If you want it to wait then you have to put that control somewhere where it waits before sending its data to the write to file vi.

[rr1024]

would that be like puting it in db verses a text file?

also why do I get that memory error, I could probably live with the file issue or at least fix that when it's convienent but it's saying the 34401a is out of memory when all I'm doing it putting the data coming from it into an array and attempting to dump it to a file.

[RavensFan]

The error is not coming from LabVIEW.  It is coming from the Agilent instrument.  Check your parameters for the capture you are calling.  My guess is you are telling it to capture more samples than the instrument has space for.

[RTSLVU]

Something as simple as this would fix your file dialg timing.

Dont worry about the broken wires, that's just because I made a snippet from only part of the block diagram. But you get the idea, right?

[rr1024]

I see, kind of strange I tested this sample VI out with those parameters before I started modifying the VI yesterday but I guess I must of mistakenly increased the samples.

The stop button doesn't seem to work either and when I get my output it's not the data from the DMM and the date stamp is totally wrong....LOL

<19031231 160000>T	<19031231 160000>T	<19031231 160000>T	<19031231 160000>T	<19031231 160000>T	<19031231 160000>T	<19031231 160000>T	<19031231 160000>T	<19031231 160000>T	<19031231 160000>T
2	2	2	2	2	2	2	2	2	2

It should be 

2016Jun29 8:45:32:001,1.599

2016Jun29 8:45:32:002,1.599

2016Jun29 8:45:32:003,1.599

[rr1024]

I get the idea but not why that would work

[RTSLVU]

---

@rr1024 wrote:

I get the idea but not why that would work

---

Because the value of the path control will not be sent to the write to file vi until the case is exited.

Data flow.

Turn on the trace (the little light bulb) on your block diagram and hit run, then watch what happens.

[rr1024]

Oh that's kinda cool and using that witht he probe is very useful

[James.M]

---

@rr1024 wrote:

I see, kind of strange I tested this sample VI out with those parameters before I started modifying the VI yesterday but I guess I must of mistakenly increased the samples.

The stop button doesn't seem to work either and when I get my output it's not the data from the DMM and the date stamp is totally wrong....LOL

<19031231 160000>T	<19031231 160000>T	<19031231 160000>T	<19031231 160000>T	<19031231 160000>T	<19031231 160000>T	<19031231 160000>T	<19031231 160000>T	<19031231 160000>T	<19031231 160000>T
2	2	2	2	2	2	2	2	2	2

It should be 

2016Jun29 8:45:32:001,1.599

2016Jun29 8:45:32:002,1.599

2016Jun29 8:45:32:003,1.599

---

You still have the value of zero wired to your timestamp conversion... so you should expect to get the value that LabVIEW understands as zero time, which is way back in 1903. Use the Get Date/Time in Seconds node to get the current time. Now, to get it in the exact format you want, look at the Help window for the Format/Date Time String to see all the formatting options.

I did make a mistake with my format string because I generated it for a different function. Remove the brackets and T and shoud should actually have something like this: