Does somebody knows if it is possible to change the colour of for  example a bar graph by a variable.
Now yo have to choose a fixed colour.

I want to change the colour if the input value is above a adjustable setpoint.

The way program it now is to have two bar graph with different colours, and use the visible input to select the color.

Maybe a idea for a next release???

I think it would be a good idea if there were three modes of operation for the run mode button.  The first is the current mode where the animations of the gauges and lamps occurs.  The second would be an off position where all lamp controls show the on image, all gauges move to the max position, and all bar/arc controls move to the max position.  And last would be an off position where all lamps controls show the off image, all gauges move to the min position, and all bar/arc controls move to the min position.

This would be useful for verifying the layout of the display interface without having to invoke the simulation step. 

Also, it would be useful if IQANdesign could remember the visibility setting in the project.  If i toggle the visibility off for a layer, group or control and save the project, IQANdesign will remember that setting until i change it.  Function in the simulator and on the hardware could remain unchanged.

This would be helpful so that controls that are positioned on top of each other didnt need to be toggled visible / invisible every time a project is opened.

It would be really helpful to be able to add a help text to adjust items.

This would ensure technicians/users have relevant instructions about what they are adjusting on screen.

The items with help text could show in a pop-up like when editing text parameters or in fullscreen like when adjusting input channels.

Would it be possible to implement free Comment Fields on the System layout page, the same way as it is implemented on the FG pages

Would be nice if you could use an integer parameter to set the window size of
a moving average.

We work with NMEA 2000 devices and have had a great deal of issues with the dynamic Source Address nature of the standard. On startup the devices will jockey for Source Addresses and, depending on what's powered on or connected at the time, the Source Address scheme will be different.

We've made due so far with GFINs and using an ajust parameter for the Source Address to build the Identifier, but this requires one of two things to reconnect to a module: 1) blindly cycle through addresses until we find the right one, 2) connect a CAN analyzer to the bus and find the right address. Also, GFINs don't allow for the "Don't Care" option for priority that JFINs offer, which has also been a problem with manufacturers using different default values.

What I'm proposing is kind of the best of both worlds, where we can have the Identifier flexibility of the GFIN, but with the wildcard capability of the JFIN. That, or native NMEA 2000 support...

It is now possible to purchase licenses also for the developer tools IQANdesign and  IQANscript on

IQAN store.

Previously it was only possible to get the licenses for  IQANrun and IQANconnect via the store, the licenses for the developer tools were ordered in the same way as hardware and shipped in boxes.

Since version 5, the tools IQANsimulate and IQANanalyze are free.

The PC tools that require licenses are:

• IQANdesign
• IQANscript
• IQANrun

We are also rolling out a new IQANdesign upgrade subscription, to help drive the development of new and improved functionality for IQAN software. For more details, see the new IQAN software updates and licensing FAQ. 

The IQAN store also introduces a feature for retrieval of licenses bought via the store, and a way of updating existing licenses via the store.

Highlighted features

It is now possible to configure MD4 display pages for control with external buttons/encoders:

Activate/Navigate with Encoder or key Up/Down.

Interact with controls with key Enter, Slider and State selector will lock focus. Abort interaction (Slider and State selector) with key Escape/Menu.

Remove focus frame with key Escape.

Key interface is selected when using touch buttons, with external buttons/encoder, the spinner is used.

Property control of JFOUT and TSC1 source address

All master modules must be connected to diagnostic bus

Important problem solved

Triggered due to a touch chip communication problem, problem was introduced in 4.03. It is recommended to upgrade IQAN-MD4 applications to avoid this issue.

http://divapps.parker.com/divapps/iqan/Downloads/IQANdesign%204/ReleaseNotes4.04.25.htm

http://divapps.parker.com/divapps/iqan/Downloads/IQANrun%204/ReleaseNotes4.04.8.htm

http://divapps.parker.com/divapps/iqan/Downloads/IQANsimulate%204/ReleaseNotes4.04.14.htm

I have been working with IQAN Design 4 for a few months now and would just like to say that having the ability to change the channel scope to public was a much needed addition. Some programs can get fairly large and any attempt at organizing the logic ended up in multiple FGIs and ended up being even harder to follow. That being said, I was quite used to the Function group output shortcut, shift+ctrl+o. It would be nice if there were shortcuts for the other scope options as well, or pressing the shift+ctrl+o shortcut to toggle through the scope options would also be handy. As long as I'm asking, It would be great to change the scope of multiple channels at a time.

When the COUT regulator on an IQAN-MC2 or IQAN-XA2 is unable to deliver the commanded current, the COUT gets the status saturated.

Saturation happens when it becomes impossible to deliver the commanded current, this is when the supply voltage is too low, the coil resistance is too high, or the max current has been tuned too high.

The available supply voltage depends on the +BAT supply to the module, the internal voltage drop in the COUT, and also on the maximum pulse width, that varies with the dither frequency.

An example of when a saturation warning may be triggered is during cranking in a 24 V system, where it is usually possible to keep the IQAN system powered up. There, if a COUT is tuned close to the maximum current that can be driven through the coil during normal operation, if an output is kept on during cranking it would have the saturation warning.

The saturation status can be seen when measuring on the channel, for example in IQANdesign:

The COUT status can be seen when adjusting in IQANrun:

But the saturation warning also gets logged in the system log:

We have been getting some comments about the saturation warning, that it in some application just fills up the system log without providing much useful information for design or service.

Does anyone think that saturation warning in the log is useful?

Or that it should be removed?