LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Measurement reading previous value

Solved!
Go to solution

Hi Folks.

 

I have an issue here wherby the program seems to be implementing the second frame before the first frame in the sequence. The measured signal is the previous value that was generated. The labview reading is one sample behind what I see on my actual oscilloscope when I press the 'Amplitude Up' button. Why is this the case???

 

Thanks,

 

Mark.

0 Kudos
Message 1 of 7
(3,736 Views)

Hi Mark,

 

The labview reading is one sample behind what I see on my actual oscilloscope when I press the 'Amplitude Up' button. Why is this the case???

You seem to use a serial communication, so there surely is a buffer in the serial driver. Are you sure you have an empty buffer after you read a measurement value? Are you sure you are trying to read the latest received value?

 

the program seems to be implementing the second frame before the first frame in the sequence

No. I guess you're not reading the whole serial receive buffer…

 

Why is there a timeout event when nothing happens inside that event case?

Why are there unwired output tunnels in the event structure?

Why do you need a sequence when you could use the error wire to enforce dataflow?

Why don't you use FormatIntoString instead of NumberToFractionalString followed by ConcatString?

Why are there two different error cluster outputs for the same device in your event structure?

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 2 of 7
(3,701 Views)
Solution
Accepted by MarkGreally

Your vi is quite hard to read because (a) I don't have that scope driver installed so those blocks are blank and (b) the front panel is spread out over an area larger than my monitor!!

 

That aside, the default setting for the VISA write you use to sent the AMPL command is 'asynchronous' - that means that program flow will not wait until the string has been sent before moving on to the next frame. The scope read probably begins execution before the first character has been sent. It will take a finite time to send the string depending on the chosen baud rated (or not chosen), and the FG will take a finite amount of time to implement the command and change the output.

 

The scope read, meanwhile... does reading the scope trigger a new acquisition or just read back the latest existing waveform from the buffer? I suspect you want it to trigger a new acquisition AFTER the FG has had time to process its command, and I suspect it is probably just sending back the waveform it last acquired before the FG was changed. This is supposition as I don't have the manual.

Message 3 of 7
(3,694 Views)

Stuart you are correct in your assumptions. I previously did add a short delay between sending command and reading the scope but that did not solve the problem. Is there a way to change the visa settings so the program waits until the string is sent.

0 Kudos
Message 4 of 7
(3,681 Views)

@MarkGreally wrote:

I previously did add a short delay between sending command and reading the scope but that did not solve the problem.


How much of a delay?  For a Tektronix scope, I had to add 500ms waits between certain commands to allow the scope time to process and make the desired measurements.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 5 of 7
(3,669 Views)

Oddly enough when I changed scopes It worked but the aquisition was a bit slow. It seems that it is just down to waiting the appropriate time.

 

Crossrulz isn't 500mS quiet long. If you have a load of samples being fed in the measurements will take forever.

0 Kudos
Message 6 of 7
(3,630 Views)

MarkGreally wrote:

Crossrulz isn't 500mS quiet long. If you have a load of samples being fed in the measurements will take forever.


The 500ms was usually for a measurement channel.  And you could see on the screen the scope taking "forever" to get the measurement.  The 500ms was the smallest time I found that consistantly worked.

 

Again, that was for a different scope than what you are using and your mileage may vary.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 7 of 7
(3,620 Views)