Your comments

That sounds really strange. When you had the input mapping problem, are you sure you did not relocate the inputs in the block diagram and started measuring without first sending the updated application to the MC31? 

Yes, a VREF error on the MC31 should show up as a popup on the IQAN-MDx, if you have a master display in the system and they are connected on the Diagnostics bus. You should also be able to see this error if measuring in IQANrun or IQANdesign.
The error description of the DOUT sounds as if this DOUT has been damaged, except for the part where you say that it seems to be an issue with the I/O mapping.
What do you have connected on DOUT-J?


For the problem with the VREF, does that error continue to shwo if you disconnect connector C2? Most cases of VREF errors are due to the VREF being overloaded or shorted.
There currently seems to be a problem with sending larger updates via the G2 modem. Online diagnostics is also affected. 
We are checking if there is a problem on the Proemion server side.
If the IQAN-MD3 is not involved in any calculations for the application, and is only used to show values from the MC2 in on the display pages and in the measure groups, tune adjustable values and view the log, then it is enough to just connect the IQAN-MD3 and IQAN-MC2 on the Diagnostics bus, like this: 

You don't need to set any J1939 source address on the modules. The only thing you need to do for addressing is to make sure that exactly one of the IQAN master modules is has IQAN address 0. (note this is not the J1939 source address)

On the IQAN-MD3 display pages, all channels from the IQAN-MC2 automatically becomes available, like this:
For the first problem, with the MD4 that sometimes goes blank when cranking the engine, is that happening in a 12 V system? I assume the power supplyt to the MD4 on during cranking?
We have seen on the bench that you can get the MD4 display to become blank if supply voltage is ramped very slowly between 6 V to 9 V, but we don't see this behavior when running the normal ISO 7637-2 test pulse 4 cranking. 

For the second issue, with the open load on COUT and DOUT during cranking, I have not seen this before. Are these outputs activated during cranking? If so, do they have to be on during cranking? What I am thinking is that the supply voltage may be insufficient to drive the loads during cranking, and therefore causing an undercurrent, that will be shown as an open load on the screen.

For the question about the 2-color 3-wire LED, I cannot think of a way to connect this to the MC3 DOUT without triggering an error. The MC3 DOUT:s are designed to work in a pair of one highside+one lowside for each load. 
To control this 2-color LED, you would need two separate highsides.
For this reason, the low-side DOUT on the MD4 you have in the system cannot be used either.
One option if you don't need the safety certification on both MC3:s in the system could be to replace one of them with an MC31. On the MC31, you can control the 5 DOUT highsides and the 5 DOUT lowsides independently.
For performance reasons, the video control on the MD4 overwrites everything on the screen, that is the reason for the "overlapping video conrols" warning that Ulrik mentions.

But there might be another way, depending on what camera or video encoder you use. E.g. the Axis cameras and video encoders can be configured to add an overlay image on the video stream. I have only tried it with some simple text information and seen that this works, their manuas show that it is also possible to upload an image to the camera and use as an overlay. See for example:
http://www.axis.com/files/manuals/um_q7424r_45412_en_1203.pdf
Hi Aurelio,

On the IQAN-XT2, there are two properties for each COUT, one for dither frequency, and one for amplitude.
The XT2 is able to control the dither amplitude independent of the dither frequency by using a high-frequency PWM for the COUT control, and superimposing a sinosoidial low frequency (e.g. 100 Hz) dither on top of this.
For some applications, like the control of hydrostatic pumps that are very sensitive to the dither, the XT2 can still be the best choice.


On the other IQAN modules, such as the MC2, MC3 or XA2, the control of dither amplitude is indirect. 
The dither amplitude is given by a combination of the low frequency PWM used for the COUT control, and the inductance of the coil.
These modules are also used in applications where a smaller dither is needed (e.g. some hydrostatic pumps). To reduce the dither amplitude, increase the COUT PWM frequncy.

Hi Arno, thanks for an interesting question.

For most of your channels, e.g. when calculating the command to a proportional output, you should use Real values, as this gives you more precision, without adding any significant cost in calculation performance. 
All modern IQAN master modules (those on the IQANdesign platform) have processors that handles 32-bit floating point numbers. 

There are only a few cases I can think of when you actually have to use integers.
One is in the unusual case that you need to do some bitwise operations. This could become necessary for some CAN messages, but the GPIN/GPOUT introduced in 3.00 has built in functions for handling the more common cases, such as reversing byte order.
Note that if you are performing bitwise operations, that the Integer type we use in IQAN is a 32-bit signed. In cases where you have a high-precision signal sent on CAN, it is often represented as a 32-bit unsigned, with some scaling. Then it is best to use the JPIN/JPOUT.

For the J1939 CAN channels JPIN/JPOUT, you will automatically work with real values if that is needed, as the J1939 scaling and offset is built in as properties, and change value type depending on these.

Another case where you have to select an channel of integer type is if you use this channel to determine a state, e.g. using the IMAC as input channle to the SP channel. 

A third case that I also think is extremely unusual for machine conrol is if you calculate a very large value where you need accuracy with >7 signifcant digits. 



Then there are cases where using an integer gives a slightly nicer design. For example if you have a paramter that is adjusted in steps of one, you could use the IP channel instead of the FP channel for this. The visual difference is that when adjusting in the menu systemyou will see the value change from 1, 2, 3 and so on instead of 1.00, 2.00, 3.00.
As Ulrik points out, the entire application is a loop in itself. 
Each enabled channel and object in the application will be calculated exactly once, each system cycle. 

For me, the great benefit of this is that I will know that the application will always complete the calculation on-time, every cycle. A simple mistake in application logic cannot cause it to become stuck in a loop inside the application.