Automotive and Embedded Networks

cancel
Showing results for 
Search instead for 
Did you mean: 

NumPend property for XNET and USB-8502/2

Solved!
Go to solution

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

0 Kudos
Message 1 of 4
(2,629 Views)
Solution
Accepted by topic author IanDeaville(ZF)

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.

Message 2 of 4
(2,617 Views)

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!

0 Kudos
Message 3 of 4
(2,601 Views)

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?

 

0 Kudos
Message 4 of 4
(2,595 Views)