Your comments

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.
Hi Zach,

Hopefully AT&T should be able to help you to find the correct APN, but here are some suggestions:
http://www.att.com/esupport/article.jsp?sid=KB424489&cv=820


I know that the GPRS service is starting to be closed down in some parts of the US.
Hi Dave,
When connecting 7 MD4.s and an MC3 in a system here, we were able to reproduce the issue you saw, and we figured out what caused it also. We should be able to get a fix for it for the 3.19 release.

About the recommendation for IdTags, yes, I would agree that it makes sense to use standard IdTags instead of the IdTags with the "T" denominator for master modules, but both works exactly the same.
Was the loss of the settings something that occurred without having any diagnostic tool (IQANrun or IQANdesign) connected?
Normally settings are kept when making SW updates, but it is possible to override this and clear settings when sending files to the MDL2.
Another possibility is ff the settings are stored in channel types that have a resetting function, like MEM, ECNT and TMR, then application logic could be resetting them.
But application logic would not be able to reset settings for channels like VIN, FP or COUT.

It seems from your description as if all the settings were lost?

Since version 3.00, all settings on MDL2 are individually checksum protected, and in case of a fault they being detected, they will fall back to using the application defaults. I have never seen this occur, but if it was to happen, then there should be records of this in the system log. Also, this would only affect one channel.

It could be an indication of a hardware fault. It the problem was to occur again, I would recommend sending the MDL2 back to our plant in Morton for investigation.

A general advice on handling settings would be to take a backup clone or settings file of the machine after calibrating. That could be a time saver if you need to replace the master module.
Hi David,

About the question of number of master modules in a system, the largest system we have connected in a single system here in Mölnlycke right now is with 7 masters, but that is built up will a variety of mast module types.
The problems look somewhat similar to an earlier issues we thought we solved in 3.15, problems finding all master modules when using routing (case 22852). One thought I had is that if you started out with some of the modules loaded with versions <3.15, then the previous issue with finding all master modules would still be there. As soon as the individual masters are updated to 3.15 or higher, that should no longer be a problem.

One of the experiences we have from testing a high number of master modules is that the way the termination is done becomes very important.
The way you have done it by setting all master modules to terminate=No, and using external 120 ohm resistors is a good solution. If the internal teriminations that is controlled by the IQANdesign application software is used, then it is easier to end up with a system that is either over terminated or under terminated.
FYI, there was some discussion about the IdTags, it could be good to know that the IQAN master modules ignore the "T" on IdTags, only expansion modules use that. The terminations on master modules are controlled per bus with the properties in IQANdesign.

We'll wire up a system with 7 MD4:s and one MC3 here and try to see if we can reproduce the problems you are seeing.
Thanks for the feedback, it seems to indicate the problem was caused by transients on the power supply that were beyond the levels we test for.
I like this idea, it could make the buttons more visible.
As it is today, the Active color is adjustable via the theme color properties, and all buttons are transparent when inactive.