01-14-2016 06:35 AM
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.
Solved! Go to Solution.
01-14-2016 07:51 AM
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?
01-14-2016 07:59 AM
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.
01-14-2016 08:07 AM
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.
01-14-2016 08:18 AM
@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.
01-14-2016 12:20 PM
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.
01-14-2016 12:33 PM
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.