Lags on data rappresentation in real time serial communication

[FatBoyMonchi]

Hi Thoraz,

the USB converters are not so good, especially at the rates you need...Maybe that's the main reason of this odd behaviour.

Is it possible for you to try with a serial port?

Hope it helps.

Have a nice day

FBM

[thoraz]

I'm sure that the USB converter works very well. I've tryed to create a new firmware on my board with ONLY the serial communication that after, a start command received, sends 30 byte packets every two milliseconds to simulate the behavior of the original board.
I found that with the two millisecond delay between two packets, the vi's charts and indicators continue to display in steps of a lot of data and not continuously; but if I remove the delay, the things seem to work fine since the charts display continuously, fast, but continuously. Now my doubt is on the presence of the delay. Why 2 milliseconds between the packets imply this behaviour?

[Kevin_Price]

Please post your latest LabVIEW-side reading code so people have something concrete to examine and comment on.

If your firmware is sending packets that include termination characters every 2 msec, you do *NOT* need to add any 2 msec delays in the LabVIEW code.  You just need to configure VISA for the correct line termination character, then call VISA Read while requesting *more* than the needed # bytes.  This may seem unintuitive, but this is the normal way to do VISA serial reads.  The Read terminates on whatever happens first -- the specified # bytes, the arrival of a termination character, a timeout.

Unsure what leads to your jittery timing, but if you post your code there's a much better chance someone will spot something relevant.

-Kevin P

[thoraz]

You're right Kevin.
My firmware, written ad hoc, starts to send the packets when it recives the 0x08 byte. The packets are in this form (hexadecimal):
'0102 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FF03'
The first two bytes, '0x01' and '0x02', are start markers and the last, '0x03', is the termination character. After every packet the system performs a delay of 2 milliseconds.
In the LabView vi I set the termination character '0x03' and all seems to works fine: the packet received is complete.
About the timing, I checked the serial communication (before the serial-USB conversion) with an oscilloscope and the data are sent actually every 2 milliseconds.
My vi is attached to the present post.

[Kevin_Price]

Nothing in the recently posted code jumps out at me to explain the jittery timing.  In my mind, the leading suspect would be the USB-to-serial device or driver or settings or...

I've definitely encountered analogous jittery streaming behavior with USB-to-serial converters.  The jittery timing disappeared when using a hard serial port instead.

-Kevin P

[thoraz]

Thanks for your reply Kevin. If I would to communicate without the serial-USB converter, how can I connect the board with the pc and then with the LabView?

Anyway I repeat that If I remove the delay in the board firmware, the vi displays the data continuously and fine, very fast. So I think that the problem is not in the serial-USB converter.

[Kevin_Price]

Oh, didn't realize that your latest code represented success, thought you were still troubleshooting.

Direct serial ports aren't really standard-issue these days though if you look, you can still find desktops and laptops that provide 1 serial port.  If you anticipate needing more ports you're probably best off with a desktop add-on card that provides 2 or 4 ports.

We've standardized on NI's offerings primarily due to support.  The intial purchase may seem expensive, but I know we've gotten indispensable NI support finding the root cause of a very subtle issue that more than made up for the cost of the serial adapters we bought.

Other adapters will be pretty likely to work fine too, you just need to consider whether your application is experimental or mission-critical.

-Kevin P