Showing results for 
Search instead for 
Did you mean: 

Order of Transmission - Multiple CAN Signals from Different Frames

I am trying to confirm what I see on a CAN bus using 1 transceiver in listening mode. 


Condition - creating a CAN session (using a customer database) using 2 signals from 1 frame, 4 signals from 2nd frame, 4 signals from a 3rd frame and finally, 1 signal from a 4th frame. I combine them all for a 1D array of signals a single session.


It appears that it transmits those signals (plus data) in this order - sort by the arbitration ID (Frame - lowest first) of the signal then further sort the signals alphabetically for each arbitration ID.


Example - IDx00 Signal A, IDx00 Signal B, IDx01 Signal C, IDx01 Signal D, etc....  In other words it will sort, it will NOT use the order of the signals in the 1D array, it will sort according to the rules, then transmit.


I hope I got that clear 🤔 - I have a bigger issue with just having a pile of parts (no brand new units available) of questionable parts. I don't know whether to blame a part for not work or I am screwing up the data because to signals are being sorted differently than what I am doing.


Thanks, Robert      Oh, I have searched, I know that frames alone are always done with lower IDs have higher priority. If working with signals, does the same apply? Signals that have lower frame IDs also have higher priority?

0 Kudos
Message 1 of 2

I think I may have found my answer. It would appear that the signals in the session are passed in the approximate timing for each Frame noted in the database. I have found the order of ID that are transmitted depends on transmit time from a relative start point. An ID that is x52 with transmit time of 0.02 seconds will be sent before ID x01 with a transmit time of 0.2 seconds. So Frame IDs have no effect on what get sent first and I believe "signal data" is actually sent as Frame information, so the the sort order of signal names within the same frame shouldn't have any effect either. Signal data in reality just makes it more friendly for the LabVIEW developer. You can avoid working with the frame if you only need to deal with a small portion of it.


Note I am working with 1 CAN transceiver and 1 unit under test, so Frame priorities from other devices aren't a factor in my case. A slow learning process when some of my parts don't actually work.......



0 Kudos
Message 2 of 2