Your comments

For reading information from the device (the status message in this case), the JFIN will be associated with the module it is located on in the system layout. After adding the instance of the external function, just drag the JFIN to the module matching the source address. 

For sending to the device (the command message in this case), the default setting on the JFOUT is to use the IQAN master  source address as the source address. 

If the sending of commands to the device was done with a J1939 PDU1 messages (the type that is designed to have destination address) it would have been easy, then you'd just drop the JFOUT of the module in the system layout. 

But in this case, when the cooling pump controller command has been designed as a broadcast PDU2 message from different source addresses, you need to set this as a constant or constant channel on the JFOUT. 

As Ed mentioned, constant channels are only available in the main project, not in externals. So you will need to duplicate the JFOUT

To change the scaled value range on the Voltage input channel, an IQANdesign user with access to the project file needs to make the modification. 

With IQANdesign it is possible to get the project file from the system, but for this you need the full access password that the file is protected with. 

My recommendation is to contact the company who created the project file. 

It is hard to tell, it could be an unusual bug that comes with a combination of firmware and application. 

If you have a 5.x version of the application it could be a good idea to start the MD3 by bypassing the application and trying if that solve the problem. (specifically thinking about one case fixed in 5.01)

It could also be related to hardware, in which case the module should be replaced. Had a similar case some years ago on MDL2:

Still investigating, but to give a small update, we've managed to reproduce one situation situation when the MD4 gets stuck at calculating checksum for the updated pdf:s. 

So far, it has only been when making a local update via the app that it has been possible to reproduce. (copying the file to the phone and using the send to machine function). 

Interestingly, when instead trying the exact same update as a remote update via IQANrun-IQANconnect-IQANgo-G11, it has not been possible to reproduce. 

Attached is an example script for this solution (based on the wheel loader example file).

Get logs and settings.issx

You can do this with IQANrun for PC, by using a script prepared in IQANscript.

You need the project file to build the script. 

In IQANscript, add one get log record script action for each log in the system. You can include the PIN code for the log in the script. 

If viewing is protected by an access level, you can include a login script action in the beginning of the script. 

As this is done with a script, the solution requires the technician who runs the script to have a PC with IQANrun. 

The functionality for running scripts isn't included in the IQANgo app. 

The error message on the screen looks like the MD4 wasn't able to keep up with the amount of messages it had to process. 

Possibly due to an overcrowded CAN bus. 

Very interesting observation that the MD4 that stops had logged No contact with modules on both CAN-A (where the multi-master traffic is)and CAN-B (where its expansions are). 

My first reaction would be to look at the shared diagnostics bus and see if there could be a burst of traffic there. But I can't really figure out how it could be related to the bus with the expansions. 

Are you running 6.02.7 ? 

It sounds like one of the bugs with copying we had in that version, the original 6.02 release

That problem was fixed in 6.02.10