XNET Frame TimingType and TransmitTime properties

Issue Details

When opening in NI X-NET Database Editor a .dbc file containing event frames with the attribute GenMsgCycleTime set to 0 (default), the NI X-NET Database Editor displays a different value  in the field "Transmit Time". The same observation applies when reading frame properties in LabVIEW.  If the value is changed from 0 to something else (using for example an external editor like Vector CAN db++), it is then displayed properly. Why is this happening ?

Solution

When discussing CAN frames, it is important to differentiate between Event and Cyclic frames and understand how the XNET driver loads their properties. The type of the frame is defined by the GenMsgSendType property in the .dbc file. As the names suggest, "Event" frames will be sent upon request while "Cyclic" frames are sent periodically. Thus, they will have specific and separate fields in the database defining these properties.

For the "Event" frames, the "GenMsgDelayTime" field determines the minimum time between messages, and XNET will use that value as the "Transmit Time".  In case of an "Cyclic" frame, " GenMsgCycleTime " is used. Also, one thing to keep in mind is that if the type of a frame is undefined, or defined improperly, the frame will be loaded by default as an "Event" frame. This is important since if a frame had the GenMsgSendType attribute set to cyclic, but the "GenMsgCycleTime" would be equal to zero, XNET would still import the frame as an event frame. Cyclic messages cannot have a transmit time of zero (messages cannot be sent at an infinitely high frequency). Similar to a "divide by zero", the XNET firmware would generate an error if a transmit time of zero is used. Instead, XNET automatically converts the frame to an event frame.