Question : acces variable to an other master unit

Glad to hear that you find composing display pages a smooth operation. Super!

However, the data transferred for GUI use isn't really considered real time per se.

Exchanging information for use between applications is another matter.

Other considerations must be taken into account, the main limiting factor being bandwidth, but perhaps also transmit rate or the update frequency of the value on either end.

It would be great if all data, was available, everywhere, all the time. Bandwidth prevents that!

With a ""super public" variable cross master" (equivalent to GUI data transfer) you would probably very quickly and easily consume all available bandwidth, probably also unknowingly, until you could not transfer any more data, leaving you wondering why doesn't it work and, what do I do now.

So this boils down to making a decision for each place an external value is used.

Enter APPIN/APPOUT; They force the user to take these things into consideration.

Admittedly, the concept could probably be simplified/streamlined to some extent, but that's what we have today.

And even though it's easy to get values onto a display page, you can break the bank there too...

Cheers!

Also APPin and APPout consumes bandwith. Because for every signal an own CAN-message is created. APPIN/APPOUT are being used, when it comes to safety related messages.

It is better to use J1939 communication for this, please take a look in this thread:

http://forum.iqan.se/topics/740-multi-master-j1939/

I understand the issue with the bandwich, but maybe it is possible to do an "super public not real time" variable (latence max : 2000 ms).

Like that when it is very important use APPIN/APPOUT, if not use "super public not real time".

What do you think ?

@Arno I know that, it is an improvment to simplify the coding (it is not easly to use J1939).

We have acknowledged ourselves that the APPIN/APPOUT isn't the most efficient way, in terms of usability and bandwidth, for transferring data between applications. But as Arno states, it was put forth as a solution for safety related messages.

Currently there isn't any work scheduled in the short term on improving the workflow in this area, but I see what you're getting at.

This is a great idea. Actually, we've thought about adding this for a while now, but, as Marcus points out, it is not a simple task. Your feedback has been added to the feature request. As of now it is planned for 6.0.

In relation to this (we have a combination of MD3 + MC2 multi-master):

I can select channels programmed in the MC2 to show on the display of the MD3, without J1939 or appin/-out constructions.

I imagine this is sent over the master bus as well, but does it take up as much memory as the appin-out channels? (To rephrase, should I be wary in using that?) I read above that it is not realtime, but it is working fine for me so far.

Only showing channels on the display of a different master is automatic . This CAN traffic is sent over the diagnostics bus and is done, when the procesor has time to send messages.

Appin/out is sent on the masterbus. Every app.out is translated into one CAN message, even if ghe channel is only a digital value.

Have there been any updates on this feature? It was planned for 6.0, but I don't believe it has been added yet, even in 7.0.

That is right, in current version (7.00) there isn't any new feature for sharing channel values between applications.

The bandwith consuming APPOUT or the method of manually mapping channels to JPOUT/JFOUT is what works. 

But it is still a very interesting feature enhancement, and we have had several feature requests along this line. 

Changing this topic type to feature request also.