- Software
-
Ideas
TSC1 CAN message queue
Hi,
I am trying to implement on iQAN a "TSC handler" and a "TSC1 CAN message queue". Both items are defined in the J1939 standard. This question is open-ended and might not have a simple answer.
Essentially, it is assumed TSC1 CAN messages will sometimes be read by our MD4 at a faster rate than we can process them in our 10 ms cycle time. When this happens (if it does happen), a queue is needed to ensure TSC1 CAN messages that could not be processed during a cycle time are stored and accessible by our TSC handler for processing during the subsequent cycle time. Our queue is expected not to overflow since TSC1 messages have a timeout value within the queue.
Here are my questions:
1. Does iQAN design already have the tool needed to queue CAN message at the software level
2. If not, I am thinking of using the following method:
A. read every input CAN frame and identify new messages (i.e. those that were updated since the last cycle time)
B. copy every new message's data-frame content into an array that is large enough to prevent overflow
C. process as many TSC1 message on the array during the remaining time of the current cycle time period.
then go back to step A when a new cycle time begins.
Customer support service by UserEcho
There is no function for queuing up incoming messages. The concept is to process everything in one cycle, to avoid having queues.
The slots for an incoming CAN frame are the channels. Each JFIN channel and its associated JPIN channels hold the values from the last incoming CAN frame matching the JFIN.
The channel values are updated with the value from the latest matching CAN frame, when the application gets to calculation of the JFIN.
If you for example have 50 ms cycle time, and read a CAN frame that is sent at 10 ms repetition rate, there will be four frames that are never used in the application, and one that is used.
The JFIN will have the value True in the cycle when it is updated. So in an example with a 50 ms application cycle and 10 ms repetition rate, the JFIN value will be true all the time.
Looking at the standard, it seems as if what you are looking at doing is implementing something like the flow chart described for Engine override control mode (SPN 695) ?
I have never looked much at that, and all applications I have worked on have been limited to sending TSC1. To me it seems as if the purpose of the flowchart is to select the winner when there are multiple devices requesting override?
You can have multiple JFIN channels for the same PGN, if they have properties to keep them apart. You always have this for the property source address. What you can also do is to set a fixed priority, that way you can duplicate the JFIN:s so that there are multiple channels reading JFIN from the same source. With this it might be possible to pick the command with the higher message priority.
After this it should be possible to continue looking at the override control modes and so forth. But it could be hard to make it match the flow chart exactly with this apporach.