Your comments

The APPIN:s will get the status Timeout when there is a No contact issue.

You would most probably also see in the log of the MC3 that has APPIN timouts that it is having No contact with at least the master module that is sending the APPOUT:s.

I would also expect that you see the 3:1 blink code (3 red, one yellow) on the MC3 that has the APPIN timouts.


Normally, a local error on one master will get shown on the MD4 in the system, but in case of a No contact, this is of course impossible to send the message to the MD4.


A CAN bus wiring issue is the most probable cause.

For an automotive type relay controlled by an XC21/22/23, it should not be necessary to use diode suppression in order to protect the DOUT.

We have not stated a maximum inductance in the XC21 instructions, only the max current. But the maximum would be around 150-180 mH or higher.


You may still want to use diode supression to reduce EMI that could influence other parts of the system, but it should not be needed for protecting the XC21 DOUT.

I am aware of a possible bluescreen that could occur in 3.19.7 and earlier when there were CAN bus problems in multi-master systems. There was a fix for that issue in 3.19.9

http://divapps.parker.com/divapps/iqan/Downloads/IQANdesign%203/ReleaseNotes3.19.9.htm


But this bluescreen does not show the exact symptom as that one did.

It seems as if the the function for discovering the module is being blocked on your PC, probably a setting in the firewall.

What IQANdesign does when you bring up the Connect via Ethernet dialogue is that it sends out an UDP broadcast, and waits for the responses (by the MD4:s). Perhaps the UDP broadcast is being blocked?

Could you try to connect to the MD4 with your firewall temporarily disabled?


Also, a correction about when the tools use TCP and when they use UDP. I wrote that TCP is being used when the MD4 has got a fixed address, but it does not matter how the MD4 gets its address. If the MD4 is responding to the UDP broadcast, it will show up under discovered modules, and when connecting to it UDP will be used for the communication. It is when IQANdesign/IQANrun is connecting to a "Static module" that TCP is used.

One difference with Auto-IP is that it takes a while to negotiate the IP address, it normally takes about 30 seconds or more after plugging the MD4 C3 connector into the PC until Auto-IP is ready and the IQAN software can detect the MD4.


If it does not work, it is possible that Auto IP is not enabled.


To use Auto-IP, make sure that Automatic private IP address is ticked under alternate configuration



You should not have to reboot the MD4, even if it was just connected to a DHCP server, it will get an IP address via Auto-IP when you disconnect it from the network and plug it straight into the PC.

You will be able to see in the MD4 menu system if "IP address 0" ends up in the range 169,254.x.y.


You can keep the Connect via Ethernet dialogue open, when Auto IP completes, you should see your MD4 showing up under "discovered modules".



I have a possible explanation to why there is a problem when sending the project file update to an MD4 with a fixed address. When setting a fixed IP address, the traffic is sent with TCP, while it uses UDP when it is on a network with a DHCP server and when running Auto-IP. I got a hint from one of the developers that we have an open bug report on unstable communication when sending over TCP.

PGN 55808 is a PDU1 message, and this can appear a bit confusing in IQANdesign.

In IQANdesign 1-3, the PGN property on the JFIN always represents the to bytes PF and PS in the identifier.

This is perfect for J1939 PDU2 messages, since there the PGN is matching these two bytes exactly.


For PDU1 messages, the easiest way to configure reading of a PDU1 message in IQANdesign 3 is by first entering the PGN (e.g. 55808), and then bringing up the dialogue box that lets you enter PF and PS separately.


Then change the PS to the Desitination address, in this case 250:


The property "PGN" will now be changed to 218*256+250=56058, and the identifier will now match what is sent on the bus. With the JFIN assigned to your engine module (address 0), the IQAN master will now check for an identifier where the last three bytes are set to 0xDAFA00


I hope that we will be able to make a more intuitive way of setting this up in version 4.

This should be fine, but as you mentioned, one possible issue is CAN bus load.

Misinterpreting messages won't be an issue, the Expansion module bus is using 11 bit identifiers, that never collides with the J1939 29 bit identifiers, so that never collides.

Another thing to think of, as with any CAN network, is to ensure that drop-lines are not too long, and that the terminations are in the right places.


I am not sure that I understood exactly how you connected, but if you have specified a static IP in the MD4, then it will not take an address via DHCP. Auto-IP should still work also in this case.


I don't understand what it is that stops the download halfway. Just to check, a colleague just ran some extra tests going from 3.15 to 3.19 (MD4 connected directly to the PC via Auto-IP), that works fine here.


Hi Kevin,


1. When saving your application with IQANdesign 3.19.9, the firmware in the project file will also be updated to this version.

It does not matter if you use another version of IQANrun to download. IQANrun never changes the version of a project file, it loads the version that is in that file.


2. Yes, it is probable that the increased number of APPOUT:s have had the system reach the tipping point for too much CAN traffic on one bus. That could have this symptom on the MC3.

To understand if this is the issue, it could be good to check a few things:

How many APPOUT:s do you have in the system?

What is the system cycle time?

Do you have the project check warning about a high number of APPOUT:s ?

What is the bus utilization when measuring with e.g. IQANanalyze?


Note that the APPOUT:s is using up quite a lot of bandwidth, one CAN frame per APPOUT. If you have some non-safety related signals that you send as real-time data, you could reduce CAN bus load by mapping some signals to J1939 channels instead.

Hi Zach,

We did not put the solution to the problem in version 3.19 as we first planned, the issue that was found still exists.

The way we could reproduce a change of reset value on the ECNT was by using the Import adjustable values in IQANdesign. It is the reset value in the application that changes when the Import adjustable values function in IQANdesign is used for updating application defaults. IQANrun never changes the application, so it should not have anything to do with it.

Did you use the get application and import adjustable values function on this application?