Automotive and Embedded Networks
XNET behavior when arbitration loss occurs: CAN
I think reading the signal back on a trigger certainly is an option. But correct me if I'm wrong, it sounds like you set a single point value, and then basically don't want to stop, until that signal's new value has been written at least once. So what I think would be a good technique is to create a Signal Single Point Read session, on all the values you want to perform this check on. Then read these values before stopping. If the read values are the same as the last written values, then that means the new data has gone out and you are good to stop. Otherwise the new values haven't been written and are either waiting for a valid ACK from another device on the bus, or maybe there is retransmit due to data loss.
You can use property nodes to read things like the queue of data waiting to be written, but that will just return the number of items in the queue. It won't return the actual values of those signals.
Hi all,
On this similar query asked, there is XNET Wait (Transmit Complete).vi
in the XNET--> Notify pallette. I tried to use it in one of sample example, but didn't really get the significance of it. Definitely its a important check to make sure the Transmitted frame is successfully received by DUT. Anyone used this wait function before? or throw some light on any useful implementation.
I'd have to do some testing to see if that function is appropriate for what OP was asking for. I believe the intention of this function, is to be used somewhere that you have a queued write, and want to know when the queue is empty and all frames have been written. I'd have to do some tests to see the behavior of the function on things like a Single Point write. I'm unsure how this function would behave. It is possible you perform the write with the new payload values, and then this function will wait until that new data has been written at least once. Or it is possible it will return immediately on a Single Point write. The help isn't clear to me how it will behave in these session types, and I don't currently have a setup to test with.
However I will add that in my environment it doesn't really matter. If I ask an ECU to perform some operation with a CAN write, even if I waited until that CAN message was received, I still need to wait some amount of time for the ECU to act on it. Say I asked it to turn on an output to some PWM value. I can't just expect the PWM to be running at the same microsecond that the CAN message went out. So what I'm saying is, when I've used the Singe Point write, I typically just have to have some kind of wait before I expect the action I asked the ECU to do, to actually be measurable. For this reason I've never used this function. Even on the queued sessions where I expect a response I'll just perform the write, then sit in a loop waiting for the response from the ECU. Waiting for the transmit to be complete isn't helpful if I just need to keep waiting anyway.
@Voyager7277 wrote:
like you said, this could mean if am using Frame output queued session VI and I have 5 frames to be transmitted to DUT and after Frame Write.vi, if the session queue internal memory gets "empty" (maybe after all frames transmitted from XNET device), means "guarantee"? but still i dont believe this means you have transferred all frames to DUT unless you get some ACK from DUT that all 5 frames received with correct CRC check n all.
That's how I interpret the help for the Queued session types. I write 5 frames with XNet Write, each goes out one at a time waiting for the ACK from any node on the bus, and only after all 5 have been ACK'ed will the Transmit Complete return. Again for single point I can guess how it will function, but I would need to test it first.
