Your comments

A flash memory will wear out with repeated write operations to the same positions, but a 2.x application, the log will not automatically wrap around, it will fill up and stop. To repeat the writing to the same positions you would have to keep clearing it, a lot.

The MDL2 has got 16 MB of log memory, each holding about 40000 events, and in version 2 there was no property to control the size of the log, so in this case with only the system log, all of it is available for the system log. That is a lot of individual events before filling it up completely. One speculation is that perhaps the MDL2 only just now got into an area that it cannot write to. In that case, just attempting to clear the log would be worth trying.

You can disable the dialog about failed writing by disabling the system log, there is an enable property on the logs:

To avoid the division by zero you could put it inside an if statement that checks if the denominator is zero before performing the division. This is a good method when using Qcode in 4.x.

To avoid division by zero in a 2.x system using object list, you can implement it like this:

avoid division by zero.ida

Yes, this is a system generated message.

It is not the message for a normal log full (that one will eventually get if the log is not set to recycle), the writing has failed for another reason.

When I have seen this in the past, it has been enough to restart the module, and then it has been possible to read the old log records and to continue to log.

What I would also recommend is to upgrade the application to 3.19.7 or later. In that version we made a small improvement to retry if writing if a log event failed. But if there is an actual fault in the log memory you could still get this also in later versions.

A question about the application is, do you have only event logs, or do you also have statistics logs? In general, the statistics logs will cause more write operations.

No, faults in the flash for log memory does not affect the flash where the application is stored.

I am not aware of any message in the IQAN system that is phrased like this. Unless you have any CMSG or IMSG in the application with a similar text, my guess is that it was a different message.

For the question about whether this could be a project ID mismatch, no, if this was the case, then the multi-master system would not have had any communication between modules and you would have seen an 'alien online' message instead.

The use of IQANconnect will be in the form of buying connection keys instead of paying a fixed subscription fee. These will be available in a web store (rather than shipping boxes as we do today with software licenses), but this is not launched yet.

For now, you can test the IQANconnect service using the trial license Johan posted.

Good idea! I have done it with a static variable and some Qcode, but a built in function for delay-on would be a nicer way I think.

state machine with timer delay.ids4

Hi Kevin,

Did you get a chance to try version 4.03 in this application?

Did it fix the problem as expected?

There is no reset button for an adjustable PCC in any of the module menu systems (MD4, MD3).

In IQANrun, a Reset button exists for the group, but if you try to reset a group with a PCC in it, it will show the information that reset of PIN is not supported.

I just realized that the IQANscript action "reset to factory default" can be connected to a PCC; when executing this script action it will present a dialog asking for the PIN code, but it does not appear to accept the PIN.

Just to show some ideas on how to achieve the switching of units, there is a solutions library example on how one can switch units here:

\Documents\IQAN Files\Solution Library\Metric-Imperial units.ids4

That one uses overlapping text controls, which is a bit difficult to work with when you have a high number of signals.

Then it could be better to do the formatting in a TFC channel instead, like the attached application:

Pressure unit.ids4

For older MD4 units, it is possible to get a similar symptom if you ramp up the supply voltage slowly. Perhaps taht could be the issue? There was a hardware update to make it more robust against this situation: