Your comments

Yes, in the example, I used the same Identity number (738100) that we use for IQAN master modules when making address claim for the multi-master addresses, I think this should be fine to use also for this purpose.
Yes. It will appear a bit confusing in the system layout, but that would be the way to be able to read if the address claim would come from another module trying to claim the same address. Which should of course not happen.
If the requirement is only to send out the address claim and not check for conflicts, you could just use this application:
Send J1939 NAME.ids3
This is sent on trigger on startup. If the requirement is to respond to a J1939 diagnstic tool, then you may want to change the send method to on-request, or duplicate it to do both.

The Parker ECD manufacturer code is 71, so that is what I put in this example.

To read J1939 NAME, you can use this application:
Read J1939 NAME.ids3

The upper limit for the storage is the 2 GB flash on the MD4 (where some space is of course needed for other parts like application, fonts and logs).

Yes, it will be possible to add e.g. the machine manuals to the project file. Here is a picture of the work in progress, with the MD4 instruction book as an example. The navigation will look a bit different in the released version.

That is an interesting question, it has actually been very few times that we have had requests for an automatic address claim message. I guess one reason is that when designing the J1939 network for the application, all the nodes will be know at design-time and have fixed source addresses. But a built-in address claim message could perhaps further minimize the risk of an address conflict having some unintended effect on the system.

One idea for building this up manually using JFIN and JFOUT would be to add a J1939 module with the same address as the IQAN master, and add a JFIN listening to PGN 60928. If it is received, it could be used to block an IDC that enables all other J1939 modules in the system.
To also send out an address claim, a JFOUT channel broadcasting that PGN could be added to this module too. If one wants to send a J1939 NAME that is following J1939-81, then that could take some time to figure out though.

For the J1939 traffic that you set up in the application to interface with other non-IQAN modules, use the property J1939 source address on the master module.

The other property J1939 start address is on the Diagnostics bus. For Master-Master communication, IQAN uses a J1939 based protocol, with addresses starting in the proprietary source address range. Setting this property to anything other than default is is only relevant to use if you have an IQAN system with more than one master on the Diagnostics bus, and also share this physical bus with other J1939 modules.

For the J1939 source address you set on the master module, there is no automatic address claim. To make an address claim for e.g. address 23, you need to build it with a JFOUT channel.
Next IQAN Creative Studio training in Mölnlycke moved to 6-8 of October.
I think that a function like this could be useful. There is a similar idea about a quick way of modifying channels that in a discussion here:

Hello Raúl,

Are you using an MD4 build during 2014?
The first IQAN-MD4:s had a quite short RTC backup time, about 4 hours.
I am not sure if you saw this, but on MD4:s built 2015 the RTC backup time has been increased to 14 days.

There is still no battery inside, but a RTC with lower current consumption than the first MD4:s. This is supplied with a capacitor inside the MD4. It gets charged either if you connect +BAT or +RTC.
Hi Zach,

The XT2 is not in phase-out yet, but it is getting old so it is a very relevant question.

The way I see it, the XT2 has got three unique features:

-E-gas servo output (H-bridge).
The E-gas servo output is still being used in some applications with smaller engines where there is no J1939 interface.
You can build this using a pair of PWM outputs on e.g. an MC2, but it is easier to use an XT2.
-High frequency based COUT with sinusoidal ripple
The XT2 COUT has traditionally been used on hydtrostatic transmissions where there needs to be a very smooth ripple. But nowdays most of the applications I see just use a regular COUT:s on MC2 or XA2 with an increased PWM frequency for driving the hydrostatic pumps.
-J1939 gateway
In the days of the MDM and the IQANdevelop system, the XT2 had to be used as J1939 gateway.
Now on the IQANdesign platform where all master modules have two to four CAN buses, this gateway function on the XT2 is very rarely being used.
Also, you can mix J1939 traffic and IQAN expansion bus traffic on the same physical bus, so even if you are running low on CAN buses on your master, you don't need to use the XT2.
Compared to mixing IQAN expansion modules and J1939, and using an XT2, the bus utilization on the IQAN expansion bus would be almost the same, since all J1939 data that passes through the XT2 must run on that bus also.
A drawback of using the XT2 as J1939 gateway is that there are fixed limits on number of PGN:s it can handle, and it does not support all features, e.g. DM2 viewing.

In general, I would not recommend designing a new system with the XT2 as J1939 gateway, it is almost always better to connect the J1939 bus on the master module(s)