07-15-2019 11:38 AM
Folks,
I am using LabVIEW 14 with XNET, and a USB-8502 for now (will transfer to PXI in due course).
I am attempting to configure some code to process CAN frames on receipt. I would expect to be able to use the NumPend property for the session to determine if there are frames waiting to be read. However, the NumPend value is always 1, regardless of the relative rates of writing & reading loops. I am writing the frames from Vector CANoe on different hardware. The frames appear fine, but my LV code is not currently indicating when a frame actually appears. Any ideas?
Regards, Ian
Solved! Go to Solution.
07-15-2019 12:30 PM
What kind of XNet session type are you using? If you are reading a single point read I'd expect that reading to always return a 1. If you are performing a Queued, or Stream read it should return the number of values in the buffer not read yet. There are several XNet session modes and my CAN Blog 6 post covers how they work. I've definitely used this property for reading and writing raw frames.
Unofficial Forum Rules and Guidelines
Get going with G! - LabVIEW Wiki.
17 Part Blog on Automotive CAN bus. - Hooovahh - LabVIEW Overlord
07-16-2019 03:03 AM
Hooovahh, you are absolutely right, I am using signal single-point read. I will experiment with the other types to get the behaviour I need.
Thanks for your help!
07-16-2019 09:01 AM - edited 07-16-2019 09:03 AM
So, using Signal XY mode, I can now get the timestamp for all received values, and the NumPend parameter seems to work...except if I connect it to the selector terminal in a case structure. When I connect NumPend to the selector, either directly, or through a [ >1 > comparison block, it no longer shows any value except 0. I am monitoring NumPend in two VIs, and connecting the output to the selector in the subvi stops the value appearing in the higher VI as well.
After some experimentation it seems that NumPend might be corrupt if it is used from the start of the VI, but if engaged while the VI is already running it works fine. I attach an example which shows this. Running this with the 'Always NumPend' option does not work. Likewise, with 'Always True' there are misreads. The 'FirstCall > NumPend' option ignores NumPend for the first read, then it will use NumPend. This option works as I intended.
Is there an issue with the NumPend property, or with something else in my code?