Your comments

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?


The MD4 comes from our production the firmware already loaded. What you can do is to create a minimal application with an earlier IQANdesign version, and use that to downgrade the MD4 to the version it had when leaving the factory.

Currently, we load the MD4:s with version 3.16.9 in production, the closest match to this that you can get is the 3.16.7, this is part of IQAN Creative Studio 3.16.2

http://divapps.parker.com/divapps/iqan/IQANStudiosOld.html

Ah, then I see. The connection via a static IP address is also considered a remote connection, and will by default show the dialog to the operator asking for confirmation on the connection, and confirmation on remote stop.

We will have a set of properties that covers remote connections via ethernet in version 4.00.

For the CAN connection, yes, the MD4 is default terminated on all CAN buses when there is no application in it. With an application loaded, termination of the individual buses is controlled by the application. But it seems strange, over terminating with just one 120 ohm resistor too much is normally not causing any problems.


If you have a DHCP server, then it should be enough to have the PC and the MD4 connected to that.

When connecting the laptop directly to the MD4, without a DHCP server, it should normally be able to connect with the MD4 using Auto IP. The PC would just need to be set to "obtain IP address automatically", the same setting as when you have a DHCP server.

But I have experienced that if this function is blocked, then setting the PC to a static IP in the same address range as the MD4 is a workaround that can be used.


The "reset" function for the MD4 is to start it in safe-mode. By either disconnecing or shorting the IdTag, it will start without its application, and only run the firmware.


There is a property for "allow remote connection" on the G2 modem. Is that the method of connection you are using?