08-04-2025 07:38 AM
I'm adding XNET functionality to an existing NI-CAN app. Eventually the NI-CAN functionality will be dropped, but not for a while. I want to modify the existing code as little as possible. The NI-CAN code uses the Channel API, so I decided that for reading, "XNET Read Signal (XY)" with "number to read" set to 1 was the closest fit to the existing NI-CAN function ("CAN Read, 2D Time & Dbl NChan NSamp" with "number of samples to read" set to 1). This makes it easier to initialize the XNET session in a similar way to how the NI-CAN task is initialized, so I can keep the code structure of the existing app.
My problem is that it seems that "XNET Read Signal (XY)" reads all the pending values regardless of what I set "number to read" to, returns only the most recent data, and drops the older values, so I lose them.
My question is, is there some way to make "XNET Read Signal (XY)" return every value, one-at-a-time?
Thanks.
08-04-2025 09:44 AM
According to Signal Input XY Mode,
The received frames for this mode are stored in queues to avoid signal data loss.
Could it be possible that your XNET device actually didn't receive any new frames before you called the XNET Read VI again? Can you try to Log Bus Traffic with NI-XNET Bus Monitor?
08-05-2025 08:23 AM
XNET Bus Monitor was very helpful. It looks like my problem is that I was transmitting using XNET Write (Signal Single-Point). This is not queued, so most of the messages weren't even being transmitted.
I'm updating an existing NI-CAN application to XNET. The NI-CAN code uses the Channel API. I want to pick XNET modes that let me retain the basic structure of the existing application. It looks like I should write using XNET Write (Signal XY), which is queued.