I am having an issue trying to plot a signal on the stripchart. I will explain it... I am communicating a LabWindows/CVI application with an FPGA from Altera through an FTDI. I communicate with the FTDI through a COM port. The goal is to obtain some values from the FPGA and plot them in a real time stripchart graph through a timer with an interval of 1ms. I can read the data quite well without any problem but I am having issues ploting it on the stripchart, the problem is that acording to the x-label of the stripchart (time) the ploting does not occur every 1 ms. For example, for make things easier I obtain 2 values from the FPGA (170 and 240) that would be a triangular signal and in the stripchart the period of the signal is very far from 1kHz (I acquire a different value every 1ms).
What is the problem here? Any help will be appreciated. Thanks.
P.S. Here is a picture of what is happening
The answer is quite easy in my opinion: according to the screenshot you are opening the serial port on every timer tick, which is a huge time-wasting task (at least if you want to monitor a 1 kHz transmission!).
Open the com port at program start and do only com I/O in the timer callback: CVI can happily live with the serial port open for long time (hours, days... months!)
I did what you said and I works!!! But, there is now another problem and that is with the stripchart x-axis, there is not a synchronization between the x-axis and the plotting curve. I mean, if the sample period is 1ms it should be 1000 periods of the signal in 1 second. Evidently I could not see on the chart 1000 periods, so I changed the sample period to 100ms in the timer and that is where I see the problem. I am using in the x-label the Relative time and there is no match between the plot and the x-axis. So, what should I do if I want to work with the x-axis as a time axis?
Hi, first of all: does the external object respond immediately or does it take some time to respond? Since you are using a polling schema, total throughput of your system sums up all times including the external device response time.
You can reduce the time on the CVI side with a few precautions, but if you have delays inside the external device you will need to work there if you can.
Second: which communications speed are you using? Consider as a rough approximation that the serial channel takes 1 msec/byte at 9600 baud! You have one byte transmitted and one received on every loop... (*)
Having said this, 1 msec is very short so your callback must be the shortest possible to keep up with the expected acquisition rate. Just as an example, in my opinion the SetCtrlVal is dangerous and useless: nobody can't even note 1000 updates/sec on a numeric! Flush instructions too should be excluded.
You will probably also have a benefit by raising CVI sleep policy to Do not sleep in Options >> Environment... settings panel.
Next, using an asynchronous timer may also have a beneficial effect on the final app.
Finally, check the throughput in the compiled release executable, since probably the debug executable can't keep this timing as it includes several facilities that impact on program responsiveness.
Even after that, you may find that 1 msec timing can be hard to obtain and sustain for a long time without loosing events.
(*) (1 byte + 1 start bit + 1 stop bit) * 2 (query + answer) at 115200 baud means roughly 20 / 115200 = 173 µsec: this means you are spending almost 20% of your time just to transfer the information from the PC to the FPGA and vice versa; add execution time on 2 sides and you can understand how that 1 khz pace is difficult to achieve!