NI-XNET nxPropFrm_CANTimingType and nxPropFrm_CANTxTime differences with different versions

[D1Spartan]

I'm trying to figure out if this was a bug that was introduced some time after version 17.0.1 or if it is working by design.

I have been reading frame properties from a DBC using NI-XNET for a while now with no issues.  All of the past scenarios of reading the nxPropFrm_CANTimingType and nxPropFrm_CANTxTime properties have been using standard CAN dbc or arxml files.  The results have been consistent between NI-XNET Database-Editor, Vector CANdb++ Editor, analyzing the raw dbc, and what NI-XNET returns at runtime.

We have recently switched to a dbc using CAN-FD BRS, and I started to see discrepancies between the NI database tool and Vector's database tool.  For example, NI's tool would show a frame as being "Event Data" and Vector's would say "Cyclic" (or whatever the ENUM was set to in the dbc).  Also, the "Transmit Time" in NI would not match the "Cycle Time" from Vector.  I read the difference between cyclic and event data timing types and realized that what I was seeing for the "Transmit Time" was the "GenMsgDelayTime" attribute, which made sense given the context for event driven messages.

All of the above was observed using version 19.6 on my test station.  As I was showing a colleague the issue, I happened to load the dbc on my laptop which had version 17.0.1.  In NI-XNET Database-Editor for this version, all of the fields now matched what Vector was showing.  I downgraded the software on my test station to 17.0.1 and tried out my code and these frames that were originally tagged as "Event Data" was now being reported as "Cyclic Data", which I believe to be correct (It didn't surprise me that it matched the editor, since I'm pretty sure it's using the same driver).

I updated NI-XNET once more to version 20.5, and I am seeing the same issue once again.

I really don't want to have to downgrade my version that far (I'm not sure when the changepoint happens yet), but I REALLY don't want to have to parse the dbc for the relevant information on top of using NI-XNET for other functions.

Does anyone have any thoughts on this, or have any experience with these differences I'm seeing?  Am I just doing something wrong?  Is this working as intended?

If it is necessary, I may be able to generate a dbc to show the same issue and attach it, I won't be able to include the original dbc.

Thanks for any advice

[D1Spartan]

Attached is an example dbc showing the differences between versions 17.0.1 and 19.6.  The forum wouldn't let me attach a dbc, so the extension needs to be changed.

[MichalWo]

I know that is a 1,5-year-old subject but I had the same issue and I struggled to find some information about it. So I want to share what I found. Maybe it will be useful to someone. 

I use Labview 2017 SP1 with XNET 20.5 and I operate with the DBC databases from another department of my organization. Some of them were read with the wrong properties of Timing Type and Transmit Time. I figured out that the DBC exported from XNET Editor has a lot fewer attributes than the original DBC and was read correctly. And others databases, which were loaded properly, do not have the "GenMsgCycleTimeFast" attribute.

After deleting this attribute Frame from the DBC file was with proper values. After changing this property to a nonzero value, Frame was loaded with Cyclic Data and Transmit Time from this attribute.

So XNET reads "GenMsgCycleTimeFast" instead of "GenMsgCycleTime" and when it is 0 changes the Timing Type to Event Data. This change is proper behavior because Cyclic Data cannot go with 0s Transmit Time.

The issue not happened on XNET 18.5 (I have it on setups) and XNET 21.8 (after the upgrade). I found that is the bug repaired in the XNET 21.0.

https://www.ni.com/en/support/documentation/bugs/21/ni-xnet-21-0-bug-fixes.html Bug Number: 1499506.

So you can upgrade/downgrade your XNET driver to versions above 20.5 or below 19.0 or modify your database.

PS. I work with XNET 21.8 and for now, it works despite it hasn't official support for Labview 2017 😁.