VeriStand

cancel
Showing results for 
Search instead for 
Did you mean: 

XNET's Frame Information -> 'Receive Time' is not updating and remains zero

I deleted the rogue channel and now it deploys.

Right after Deployment I have "Error Active" Communication state, the other fields are zero.

After sending the offending Frame whose Timestamp does not update, the Interface's Status channels remain unchanged:

MaWei_0-1638451574002.png

 

Note: There's absolutely no other traffic on the CAN. I just send this one CAN frame to avoid any overflowing buffer or whatever else could happen from the CAN Port up to VeriStand itself.

 

Actually, I tried the above after lowering the Baudrate to 250kbaud/s ...still the same result.

 

0 Kudos
Message 11 of 13
(836 Views)

Can you confirm that the workaround found by SKTheLimit to use the raw frame access does cause the Receive time to work correctly?

If that workaround works, then this implies to me that the issue from 2019 described by the OP still exists in the XNET driver or VeriStand support for the XNET driver. In which case, it would really help us out if you direct message me a small reproducing case, with all sensitive info removed from your end -- such a small XNET database file that has just the one offending frame -- and then we could get a Bug filed on the NI R&D side and finally address this.

If it only shows up with your physical hardware setup, it will be more challenging to move the ball forward here. There are these general XNET debugging steps, that may yield some clues? Some of these approaches won't apply as you're not using the LV XNET API directly.   https://knowledge.ni.com/KnowledgeArticleDetails?id=kA03q000001DkYeCAK&l=en-US

Darin Gillis
NI - Chief Product Owner - VeriStand
0 Kudos
Message 12 of 13
(828 Views)

Dear Darin_G,

I have heard from MaWei, that the workaround found by SKTheLimit to use the raw frame did not work correctly in this case.

 

Regards,

Hrag

0 Kudos
Message 13 of 13
(764 Views)