Array channel as app-out function

No, the APPOUT channel is sending one 32-bit channel value per CAN frame, so the array does not fit in it.

For now, using a J1939 bus is still the best way to have an efficient transfer of channel values between master modules.

It is a bit more tricky to implement than using the APPOUT, but have a look at the solution library file "Multi master JFOUT.ids4" to see an example of how it can be done:

Is there any way of broadcasting J1939 messages on the master bus as well as APP IN/OUT? We have a project with large quantities of data but only one CAN bus between the modules. To prevent overload can I use a mixture of J1939 messages as shown above but also APP IN/OUT on the single master bus?

Hi Kevin, does all the information have to be real time? in other words could you index and carousel info that can live with latency? its a good way of taking down CAN load.

For our application we have a lot of app-outs and I prioritized them and gave them different transmit rates, next to putting them "on change". This dramatically downsized the can load, but I still get the warning in IQANdesign.

Nick, We can have latency within the functions, real time information is not critical. The safety related trasmissions need to be live but non critical are OK to be delayed. How can I configure this within IQAN Design using APPIN/ APPOUT?

Jan, Even if you prioritise them you still get all the APPOUTs transmit on boot of the system, causing a burst of information on the can at startup. This has previously caused a module to crash when I was testing the limits of an MC3 module.

Ok, I would use 2 APPIN/APPOUT

1 APPIN/OUT is the index value.

1 APPIN/OUT is the data value.

Create a mirrored carousel both ends of the APPIN/OUT.

Send all your non time critical data over these two channels.

I think it is worth thinking about the risk with this method, of using a pair of APPOUT:s, with this suggestion, the identification of the data is in one, and the data is in the other. This causes a risk of getting a mismatch if only one of the CAN frames gets throuh. There are lots of diagnostic features built into the APPOUT, that is the very reason it takes up so much bandwith, with one full CAN fram for each channel value. But by splitting the data and the identification (the index) over several APPOUT:s, that introduces a new risk. Your idea could be used, but it would be safer to do so if you use JFOUT/JFIN, that way you can put index and channel value in the same CAN frame. That also makes it possible to use the page protocol feature for reception of the JFIN:s.

I think the main advantage of sending with just one JFOUT instead of multiple JFOUT:s with different CAN identifiers, is that it gets a bit easier to implement the transmission trigger so that one avoids sending all data at the same time.

Nick,

Would that effectively be J1939 signals being transmitted over APPIN/APPOUT? If so how would that be arranged in the system layout? Would have to have J1939 but on the master ICP bus?

Jan, Even if you prioritise them you still get all the APPOUTs transmit on boot of the system, causing a burst of information on the can at startup. This has previously caused a module to crash when I was testing the limits of an MC3 module.

I handled this by grouping a lot of appouts in a single function group that has a delay during startup (function group was enabled by an IDC that had a delay on of 3 seconds).