Your comments

Hi Graham,
If you are controlling a solenoid valve, then it is only the current you will need to control. With the peak current being 780mA, you should be within the range of what you can drive with an IQAN-MC2 COUT.

The COUT is driving a current using a PWM. During the on-phase, the switch is open and you will have a voltage just below the +BAT level. The COUT measures the current, and regulates it by varying the pulse-width. This means that you will get the commanded current even when the supply voltage and load resistance varies. As long as you are not limited by the law of Ohm of course.

So if you set your max current to 780 mA, you should be able to drive this current, assuming that you have sufficient supply voltage to the MC2.
For a system with a non-touch MD4-5 the idea with a system information channel from the MD4-7 that reads the actual backlight setting is interesting.

You could of course use a slider on a display page for a parameter that controls the backlight of the MD4-7, and send this paramer to the MD4-5-T0, but it seems as if you already figured this out. The drawback of this is that when adjusting from the built-in menu system, the backlight parameter does not get updated.

The parameter "J1939 error check" will have two effects if the parameter is outside the data range (bit value above >250 for a 1 byte parameter)
The channel status will change from OK to error, and the channel value will become the Error value defined on the JPIN.
The error status will also be logged in the system log.

Below is a printrsceen from a simulation, in the IQANsimulate window on top the raw value is shown (254), and in the IQANdesign window, the channel value is shown, here it is 0°C, the error value defined on the JPIN.

If you set J1939 error check to No, the JPIN will not consider the value 254 to be an error, and instead use the value sent out to calculate a temperature that is outside of the data range for Engine coolant temperature (-40 to 210 °C). The JPIN would get the value 214°C.

Since there is conflicting information about the priority, I would recommend setting Priority to don't care. That way you can use the same application for both the priority 3 and priority 6 variants.

I agree that it could be a bit confusing, but this one would actually be quite tricky to change. The property would have to be disabled due to a selection of another property, and also the master module type. If there is an MD4 somewhere in the system, the rigth button and the help text will be shown.

For now we have solved this by writing about it in the hint for the properies 'Right button' and 'Help'

One trick you could use on an MD4 is to take the Gauge control, make the scale color transparent and place on top of the image gauge.

See attached example:
Gauge overlapping image gauge.ids3

When I tried this, the tricky part was to get the needle anchors to align in a good way. If that is an issues, one way to solve it is to make the top needle anchor larger.
That is a good question, a lot of people have asked me about that.

Yes, it is normal for the internal temperature sensor to be about 10-20 °C above ambient air temperature.
The MD4 is rated for up to 70°C ambient air temperature, so at that temperature there is still margin to not overheat the internal components that are rated to +85°C or higher.

On the MD4, the bonding of the display glass means that there is no air-gap, so the heat dissipation is felt more on an MD4 compared to an MD3. The largest contributor to both the internal temperature and the surface temperature of an MD4 is the backlight setting. If you are worried about the temperature, you can reduce the backlight.

Below are some thermal images with the same scaling, for 100%, 70% and 40% backlight on an IQAN-MD4-7

100% backlight, 24°C ambient air, internal 44°C, max surface 49°C

70% backlight, 24°C ambient air, internal 39°C, max surface 43°C

40% backlight, 24°C ambient air, internal 36°C, max surface 36°C

About the priority on the JFIN, one recommendation is to use the 'don't care' option for this property, then the JFIN:s won't be filtered out based on priority, but only on PGN and Source Address.

About the J1939 error, you will get this status on a JPIN if it uses the property J1939 error check, and the bit-value is outside of the standard error detection range for J1939.

The error range for J1939 values depends on the size of the parameter:
  • 2 bit: Error > 1
  • 1 byte: Error > 250
  • 2 byte: Error > 64255
The special case is when all bits are 1, then that means the parameter is not available.
IQAN will use the status "J1939 not available" for the case where all bits are one, and "J1939 error" for all other cases where the parameter is outside of the error detection range.
"J1939 not available" will not be put in the log, but "J1939 error" will.

The strange thing is, I don't see why you would get a "J1939 error" on these parameters. It would be expected if the offset within the data field was set wrong on the JFIN, or if the lenght was wrong on the JPIN. But this looks correct.

Hi Nick,

No, in the LTC you input a fixed data set from e.g. an excel file. In the IQANdesign 4 array, you modify the content using application logic. It is more like you had a bunch of MEM channels that you can access and modify from one point.