Looking for clarity around CAN timing settings in VeriStand

[croohcifer]

Hello all!

I'm trying to understand how the various timing parameters in the CAN Port Settings interact.  I've read the help and tested various combinations, but I'm running into some conflicts and misunderstandings.  I'm using VeriStand 2018.  Here are some of my findings and questions:

1. I have an XNET database with a 1 kHz cyclic frame, and my ECU is broadcasting a sine on a signal in this frame at 1 kHz (verified with the bus monitor).  In VeriStand, I have added a CAN port with a single point input.  My PCL is at 100 Hz.  My CAN Port Settings have inlining unchecked and an "Incoming frames processing rate" (IFPR from hereon) of 100 Hz.  When I acquire this CAN channel using the embedded data logger, I see a new value for my CAN signal every sample.  When I switch the processing rate to 10 Hz, I see a new value every 10 samples.  This makes sense.  However, when I then check the box to inline incoming frames, the help states that the IFPR is used as a decimation factor (I assume with respect to the PCL).  What I actually observe is that no matter what I set IFPR to (I tried 1, 10, 100, and 1000), I always get a new value on every sample.  Am I missing something here?  If I set the processing rate to 100 Hz with a 100 Hz PCL, I'd expect a new value every 100 samples.  If 10 Hz and 100 Hz, I'd expect a new value every 10 samples.  Etc.  Instead, I always see new values at the rate of my PCL.
2. I don't understand the use case for the "Input stream read time" (ISRT from hereon) setting.  Nor do I see how it affects data.  The help states that it "Specifies how quickly, in seconds, to read from the port into memory."  In a single point framework like VeriStand, I don't understand why this setting would exist or how it would behave differently than the "Incoming frames processing rate" (IFPR).  If I take the help at face value and assume that VeriStand only reads new samples off the XNET port and into memory at the ISRT rate, I'd expect to see at least that amount of latency in my data log when comparing my output signal to my input, but I do not.  I did a CAN loopback test with one port connected to the other.  My output port was set to inline outgoing frames at my PCL rate of 100 Hz.  My input was set to an incoming frames processing rate of 100 Hz.  I tried a variety of ISRT values in combination with/without inlining incoming frames, and I always saw only a single tick of latency between what the embedded datalogger logged as the frame on the output CAN port and the input CAN port.  This makes no sense to me.  As far as I know, the embedded data logger logs the channel value as seen in the PCL on that PCL tick.  How can reading samples off of the bus in an async XNET loop with lower frequency than the PCL still result in one tick of latency and a new value on every sample in my data log?  I could understand a new value on every sample if there were latency equal to at least the read time interval, but there is none.  My guess is that VeriStand is completely ignoring this setting (at least in my test case), but I have no way to confirm.

I'd really appreciate if NI could weigh in here.  In the case of the first problem, there appears to be a huge gap between the help and my observations in a very simple-to-reproduce case.  In the case of the second problem, I'd mostly like to know the theory of operation of the setting.  The help does little to clarify the actual impact of this setting and how/why/when you'd set it.  Some documentation like the "Parallel" vs "Low Latency" execution settings would go a long way to help out.

Thanks!

David

[croohcifer · Accepted solution]

I escalated this to NI and got some clarification.

1. The IFPR field is not used as a decimation factor like the help states. It is used to calculate the decimation factor (DF) with this equation:

   
   DF = PCL_Rate/IFPR

   
   The IFPR used in that equation is the highest IFPR configured for all inlined incoming/outgoing CAN, LIN, and Flexray ports configured in the entire system definition. So, if you had a PCL of 1 kHz with one CAN port with inlined incoming frames of 100 Hz and another CAN port with inlined outgoing frames of 10 Hz, the decimation factor used for all inlined frames for both ports would be (1kHz)/(100 Hz) = 10. So all inlined CAN traffic would operate at (1 kHz)/10 = 100 Hz.
   
   CAR 745144 was filed to clarify the help.
   
   

2. This setting only applies to raw frame data logging (configured in the "Incoming" node of a CAN port in the sys def), which is why I didn't see this setting make a difference in my experiment using single point frames.
   
   CAR 745234 was filed to clarify the help.