Your comments

Yes, this problem is triggered if these DOUT:s are activated at exactly the same time as the XC10 is enabled, The workaround is to extend the delay-on time for the DOUT:s, it should not have to be as long as you have set it now. In the example application for the workaround, I have put it to 100 ms after enabling the XC10, and that works.

We are just about to release an XC10 firmware update to support DOUT diagnostics features in combination with IQANdesign 3.15 and later. But this update we are releasing now does not resolve the problem of DOUT:s requiring flank after module enable.
I am not sure that I understood which method you used, but there are basically two ways for bringing up a display page.

The method I use the most is that I set an action on a button, where the action is to go to the page you want to navigate to. Like this:




The other method is to use the Show property on the display page. That way you can control the showing of the page from you application. The last display page to see a change from false to true on its "Show" property will be displayed.



Hi Kevin,
Do you use the Enable property on the XC10?
Normally all IQAN IO are level triggered, but we have a problem in the XC10 firmware has the behavior that some of its DOUT:s will need a flank after module disable. It is the DOUT:s that are also combined as XC10 PWM:s that have this behaviour. Here is an example of how to make a workaround for it, I only used 100 ms after the XC10 enable for delaying the DOUT.
XC10 DOUT workaround.ids3

Frank,
The issue above should not exist for the XA2, but there is another possible explanation for the problem you experienced.
If there is a fault that affects outputs, the behavior is that these outputs will remain off with the error status until the error has gone away and there is a zero command to the outputs.
The purpose of this is to avoid unexpected restart for outputs that are controlling machine movement, if the error is intermittent.
This functionality is controlled by the master module, and in IQANdesign you would see the error status and that the DOUT has the value false.
If you want a function that automatically restarts the DOUT after an error, you can achieve this by blocking it when there is a fault.



The font selection is today mainly used for supporting languages with non-latin characters, e.g. Chinese.

One workaround for the example you mentioned where the unit "°C" is a static text could be to bring that in as an image instead of a value control or text control, and use the font that is set for the selected language only for the value controls on the display page.
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.