01-24-2019 07:40 AM
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?
01-25-2019 05:50 AM
Hi Mads,
Thank you for your post.
I have some questions for you:
Creating a MAX Technical Report to Document Configuration Information - National Instruments
Cheers,
YD
01-25-2019 06:27 AM
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.
01-25-2019 11:33 AM - edited 01-25-2019 11:47 AM
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).
01-28-2019 04:28 AM
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).
02-01-2019 08:21 AM
Hello Mads, I am a bit lost on what your setup looks like.
Is this how your connections are?
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.