Your comments

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.


I have received information about similar symptoms, MD4 bluescreen, in a couple of other applications too. Your observation that it seems to have come when minimum cycle time for the MD4 was dropped to 10 ms in 3.16 matches what I have seen on those other applications, but I am not sure. It has been seen on versions 3.16, 3.17 and 3.18.

The symptom is a bluescreen, and on there it is a name of a driver and the text “HB warning low”. It indicates that one software driver has not deliverd heartbeat on time, so the safety monitoring kicks in and stops the MD4. Afterwards, you may also find this “HB warning low” in the system log.

We are working on solving this for 3.19, but so far we have not been able to reproduce the issue with a realistically sized application. What we have seen during testing of 3.19 is that a high utilization test application that bluesceen in 3.18 will continue to operate without problem in 3.19, so the fixes we are working on look promising.

This could be a nice option. On text parameters, the way they are entered now is via a touch keyboard


For adjusting e.g. function parameters, I am guessing it would be an option if they should be adjusted wtih +/- buttons or if a popup number pad should show up. Or alternatively, clicking on the value to get a popup or a second page with the numeric touchpad.