Your comments

For the discussion, and for those who do not already have a working solution for swapping between metric and imperial, attached is an example of how I have solved the switching of units.
Example application metric-imperial.ids3

As you say, this requires the use of overlapping value controls on the display page to swap between the units:

In the attached example, I have used separate channels for metric and imperial. One special case is the length, where there are two math channels for converting from [cm] to [ft] and [in], and this is then fed into a TFC that is used on the display page.

One idea we have thought of in the past is to have something like a "multiplexer channel", that would be able to switch between different channels, one for each state. This could be a nice way of getting rid of the overlapping value controls.

What are you using as reset value for the ECNT? Are you using a fixed value, or a channel?

Do you mean that the resetting condition seems to behave as intended, but that the ECNT resets to a different value than you intended?

Since you mention the check boxes that show updating from IQANdesign, do you mean that this resetting happens only when sending an application update?

The only change between 2.x and 3.x that I am aware of for the ECNT is that in 3.x there is lazy evaluation on Increasing and Decreasing, meaning that these object groups are not evaluated when the resetting condition is true.
Hi Zach,

You will need to have one J1939 module for each TSC1 channel. This is also currently the best way to avoid sending out both of your TSC1 messages, by enabling/disabling the J1939 module.

I agree that a property for the source address also on the built-in TSC1 channel would be a neater solution.
The COUT gets the status saturated when it is not able to drive the the commanded current, but there is current measured.
Normally this would be caused by tuning the COUT max current way too high, or dimensioning the hydraulics for a current that cannot be driven through the coils when they heat up.

In this cases it sounded if there was a wiring fault, but I don't understand exactly how the fault looked.
Hi Ulf,
You posted this as a helpdesk ticket, do you mind if I move it to the public part of the forum instead, as a sofware idea?
(and yes, we are working on something quite similar to what you are requesting)
There is no specific simulator function for disabling modules. On expansion modules, the Enabled property is used to disables the modules. Expansion modules can also be set to No contact in the the simulator.
These options do not exist for the master modules, so there is no built-in method in IQANsimulate to say that an optional master is deactivated.

Is the purpose to disable some APPOUT:s that are being sent to the MD4? Then one thing you could do is to use a parameter to disable the function group where you have those APPOUT:s on the MD3, just for testing it in the simulator.
For those who have not been directly involved in the troubleshooting around this problem, here is an update of the findings we made:
When testing in Sweden and Germany, we were able to reproduce issues where the connection to the remote system via G2 modem gets disconnected. This was not limited to MD4, we could reproduce this on other master modules like MD3 also.
The tests we did when we saw the issues were with Swedish SIM cards from Telenor.
With the G2 modems configured for the Telenor APN there were intermittent issues.
With the G2 modems configured for the Telenor APN we could not reproduce any issues.

We were not able to reproduce any problems when using Swedish SIM cards from Telia, or German cards from T-mobile.


One trick that I like to use for sequence controls is to build it with a combination of a State Parameter and an event counter channel. By making the ECNT the input to the SP, and then using the SP as the Function Selector on the ECNT, you can define transition condition for each states, where it can count up, down and reset depending on where you are in the sequence.

Attached is a small example:
Sequence state example.ids3
Hi Frank,

It sounds as if it might be a new bug related to export to excel introduced in 3.17.
But I am not able to reproduce the issue you are seeing when saving IQANrun measurements as .xlsx.
To be able to see the issue, could you save your measurement as .irm3 and send us that file? If we can reproduce the issue, we should be able to fix it.