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:
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.
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
I have heard from MaWei, that the workaround found by SKTheLimit to use the raw frame did not work correctly in this case.