VISA Serial Bytes at Port update rate

[Mads]

Using VISA serial bytes at port on a cFP-2220 device I noticed that the reported number of bytes did not update sufficiently often during a continuous transfer. It updates, but only when a rather large chunk of data has been received (which is more noticeable to us now because of a low baud rate):

Here is an example:
Bytes at port is only updated when a certain chunk size has been received

In this case there is a continuous stream of bytes (well, I am really just assuming that as it is sent as one write operation...) coming in on the port at 1200 baud (so about 2 characters per 20 ms), and as soon as the reported number of bytes exceeds 0, the value is rechecked once every 20 ms and plotted.

I have been expecting the number of bytes to increase quite gradually in such cases (approx. 2 bytes/sample), but it stays stable until a sizable chunk of new data has been transferred. This erroneous assumption has not created any problems earlier simply because we have been using much higher baud rates

Does anyone know if this is always the case (does the chunk size vary depending on the hardware for example, are there any settings that affect it etc.), and if this behavior and the logic behind it is documented anywhere?

[YusufD_UK]

Hi Mads,

Thank you for your post.

I have some questions for you:

1. Please could you upload your code and a screenshot of your setup?
2. You are using a baud rate of 1200bps, what were you using previously?
3. What version of LabVIEW are you using?
4. Have you tested the device in NI-MAX?
5. How are you connecting your cFP-2220 to your PC?
6. Please can you upload your MAX technical support report here?

Creating a MAX Technical Report to Document Configuration Information - National Instruments

Cheers,

YD

[ikaiser]

Hello Mads!

YD is asking very good question to start this.

I want to add a bit of information on:

Using VISA serial bytes at port on a cFP-2220 device

[...]
Does anyone know if this is always the case (does the chunk size vary depending on the hardware for example, are there any settings that affect it etc.)

---

How does your setup exactly look like? Are you using the RS-232 or an RS-485 port? Are you transferring data from another device (what kind of device?) to the cFP-2220, or from a PC to the cFP-2220?

The data transmission depends on three factors: The way the sending device sends it, the way the cFP's hardware handles the reception, and the driver/software part on your cFP.

1. In case your other device sends the data in chunks, then the cFP cannot do anything about it. Have you checked this? You could "sniff" on the connection itself with e.g. a laptop in the middle that shows you live what is happening on the wire. In case the data is actually flowing steadily, it's not an issue with the connection itself.
2. The receiving hardware. Serial chips feature a hardware buffer (see Serial Communications Hardware Concepts and Hardware Overrun Errors). Sometimes it can be configured a bit.
3. Another question is, if "Number of Bytes at Port" is just updated in a low interval rate, or if there is actually no more data available. This leads to one important message: Only use "Number of Bytes at Port" when you have to! Normally you do NOT have a reason to use this function. There are a few exceptions, see e.g. Bytes at Port Property Node. When to use it and when not? What does the data look like you receive?

[Mads]

It seems to be caused by a USB to RS485 converter (Advantech)...(should have eliminated that at once...) at least it goes away if I use the RS232 port on the cFP-2220 and on my own Dell desktop instead (then the byte count grows gradually as expected). I'll test the RS485 on the cFP-2220 alone soon to see if it indeed follows the USB converter.

This is with LabVIEW 2018 on the desktop and 2015 on the cFP...The code in this test case is just a simple write on the desktop and a read byte count in a loop with a 20 ms wait. The serial IO handling needs to be protocol agnostic (there are various binary protocols in use, many of which do not have a fixed length indicator), that's why we are using silence time as the end of message marker (this is a generic serial handler that we have used for years, but then on other hardware and at baud rates between 9600 and 115200).

[Mads]

Correction - the behavior seems to be linked to the RS485 port of the cFP-2220....not the USB converters. (I routed the data through the same USB to RS485 converter and back to RS232 through another such converter and then into the RS232 port on the same cFP-2220 - and the stops in the communication disappeared.)

This is with the RS485 port in 2-wire mode, I have not checked yet if using 4 would change anything).

[ikaiser]

Hello Mads, I am a bit lost on what your setup looks like.

Is this how your connections are?

1. PC's USB connected to USB-RS485 converter connected to the RS485 port of your cFP-2220 has the unexpected latency.
2. PC's USB connected to USB-RS485 converter connected to RS485-RS323 converter connected to the RS232 port of your cFP-2220 works as expected.
3. PC's USB connected to USB-RS485 converter connected to RS485-RS323 converter connected to the RS232 port of your laptop works as expected.

2-wire vs. 4-wire should not make a difference in your case, as your data rate is low (1 symbol per 10ms), and the turnaround time (switching between "send" and "listen") should be around 1 symbol's time. Which is less below than the 200ms I see in the diagram in your first posting. Still, I don't know your exact setup, so feel free to give it a try.