Why did you guys make it mandatory to run a multi-master system with the MD5? With the improved specs they should have been fully capable of Controlling a machine. Multi-master systems are way more difficult to program and manage. Are there any plans in the future to release versions that support direct machine control? 

That is a very good question, and the answer is not straightforward. 

The IQAN system has traditionally had an almost unique feature in the ability to combine control functions and display functions integrated on the same module. The MD4 (and MD3) modules are able to prioritize CAN communication and application thanks to it running an RTOS, real time operating system.

Especially for the MD4, priority to application logic comes at the expense of graphics performance. With the MD5 the focus is on improved graphics performance. The OS we selected for the MD5 display gives many advantages when it comes to adding features, but it does not give the same real-time performance as an MD4. 

There is also a drive especially in Europe for proving functional safety on all mobile machinery motion control functions. New ways of designing the systems with one or more safety controller was the driving factor for introducing IQAN multi-master when we first launched the feature in 3.00. 

The multi-master approach gives the diagnostics advantages of an integrated system, while safety functions such as hold-to-run operator controls can be built on MC4xFS. 

An interesting challenge with a broader move to multi-master will be the increased used of CAN bus bandwith. A really nice feature on the MD5 platform is that it enables for feature growth with CAN FD on all its buses. 

I really hope you guys walk back this decision at least partially.

I have a camera display system utilizing only one CANbus and the ethernets for IP cameras. Now I would have to add a master controller as well, drastically increasing cost/complexity.

Surely some concessions could be made.

Perhaps you don't need a controller IF no expansion modules are used, and no MD4 outputs are used.

To prevent people from using it for machine control applications.

Since this so dramatically increases cost I would have to look for non-IQAN solutions.

It sounds as if you are already using your MD4 as a dedicated display system? 

Then the MD5 is a perfect upgrade, with its increased resolution and better display. 

There is no need to add a controller to the project file if HMI is the only functionality you use it for. 

There are applications where a single MD4 or MD3 is used together with XC4 or XA2 expansions, with machine control logic in the master display. When redesigning such a system in 2024, the recommendation is to put the machine control logic in an MC4x, preferably MC4xFS, and use MD5 for HMI functionality. 

Great news.

So the additional controller requirement only applies when connecting to IQAN modules with output capability?

I currently maintain three systems:

HMI MD4 with IP Cams

HMI MD4 with MC43FS and XC43

Master MD4 with XC43 and XC44

It sounds like MD5 is perfect fit for my first two.

And I'll just have to move to HMI MD5 with MC43 and XC44 for my third.

Yes, the need to incorporate an MC4 is when the application is controlling outputs for motion control. 

The example with MD4+XC43and XC44 could be upgraded to MD5 exchanging the XC43 with MC43/MC43FS, and moving the XC44 to be as expansion of the MC4.  

It sounds like its possible to use an MD5 in the same way as an MD4, just that its advised to use a separate controller as the machine controller? Logic wise you can do everything in an MD5 as you would do a MC43, but just not advised rather than an actual limitation within the controller hardware?

For non safety critical applications, can we use an MD5 with expansion controller such as XC21, or XC4x?

There is no limitation in what module types you can connect to the MD5 in IQANdesign, the only design limitation discouraging machine control we put in there is the 50 ms application cycle time. 

If you for example have an XC21 as input for buttons and switches controlling things like heat and ventilation that is the same as using the MD5 local input or a 3rd party J1939 keypad module for it. 

So for functions that are not safety related at all, you can use an IQAN expansion with application logic in the MD5. 

On a mobile machine where there are hydraulic implements, you should have an MC4x or preferably MC4xFS in the system for the hydraulic implements. 

Perfect! thanks for clarifying Gustav.

-Link for MD5 planned updates missing?

-Also any demo /example file available? 

Ah, the link for planned updates was missing. Updated the article also, thanks for noticing. 

An example file is coming. 

With the release of the MD5, is there any current plan to begin phasing out the MD4 modules?

We heavily use the MD4 as the master controller in almost all of our applications. We try to avoid multi-master systems as much as possible, due to their added complexity and possibility of system mismatch errors in the future if we need to replace one master on a machine in the field and don't have the exact same project with matching checksum as was originally loaded on the machine.

The MD4 graphics performance is plenty sufficient for our needs, so I don't see much advantage in switching to the MD5 in our applications.

Moving away from the Deutsch DTM connectors will also require harness modifications for retrofits and new designs. The I/O count and number of CAN buses being different between MD4 and MD5 will also further complicate retrofits.

I'm sure you all realize this, and I'm sure there's plenty of complications that I don't understand that led to the MD5 being designed the way it is, but I just hope to highlight the need to continue support for the MD4 modules for the foreseeable future.

There is some discussion on this in the post IQAN-MD5 - release of 5" and 8" / Hardware / IQAN

Update to version 7.02.31 is released:

• Adding MD5-10 and MD5-12
• Bug fixes for MD4, MD5 and IQANdesign