- Software
- IQANdesign
-
Questions
Using MD5 as sole master module for machine functions
With the recent obsolescence of the MD4 modules, will the MD5 modules be able to be used as the sole master module and control machine functions in conjunction with expansion modules?
What are the risks of using the MD5 with expansion modules (XC43, LC5, XC23, etc.) to control machine functions without additional master modules?
I know another post implied that the main concern with not using the MD5 to control machine functions was the slower cycle time, but it appears that issue has somewhat been fixed with the lower minimum cycle time now listed at 20ms for the MD5. Is that no longer or less of a concern now?
We have had many bad experiences with multi-master systems, so I would like to avoid going back to an MC43 module, if at all possible. We've been using the MD4 modules with XC43 modules to control machine functions with very good success with a cycle time of 50ms, so the cycle time would not be an issue for us unless there are other limitations of the MD5 that make it unreliable for machine function control.
IQANdesign lets me use the MD5 as a direct replacement for the MD4 modules without any warnings about not using it in conjunction with expansion modules to control machine functions.
Customer support service by UserEcho
It all about functional safety requirements...if you are required to use functional safety modules - then you will require at least one MC4XFS to run the code on then it can be a master to other XC43's etc. The MD5 is not a functional safety module.
Thank you for the insight!
Is this also the case with the MD4 modules? I don't see them listed as "FS" capable, so maybe we've been operating without functional safety functionality this whole time. (We haven't had issues and our machines typically don't require this level of safety certification or operate in an unsafe manner.)
MD4 is not a functional safety controller either. XC4x expansion is functional safety, but only FS when connected to a master that supports FS, such as MC4xFS. The logic inside the MC4xFS needs to be functional safety and constructed in a way that meets requirements.
MD4 with XC4x is not possible for functional safety.
MC4xFS with XC4x is possible for functional safety, provided the logic in constructed safe and additional requirements are met with installing components external to the module.
Find the installation manual for MC4xFS modules, it lists requirements for the additional FS inside red boxes, worth a read as it explains it very well.
I appreciate the information.
If the only concern is meeting functional safety requirements, then it seems weird that they're making it a big deal that the MD5 is intended only as a display module and should be used in conjunction with an MC4x module for machine functions, when they didn't do that with the MD4 modules.
The MD4 instruction book explicitly shows it as the primary controller:
Whereas the MD5 instruction book explicitly states it's recommended to be used only as the display in a multi-master system:
If the concern is truly only about meeting EU functional safety standards, it should be stated clearly that the MD5 can be used as the primary controller in applications that don't require functional safety.
The MD5 series feels like a step backwards in functionality. I thought the "M" stood for Master module, when it seems like these should be treated more like expansion modules. But actually worse, since it will also come with all the downsides of multi-master systems and the requirements for matching project checksums to avoid system mismatch errors. And the inconsistent firmware update times when updating multi-master systems can be extremely frustrating. The single master system with expansion modules just makes field replacements and updates SO MUCH easier.
I suppose it is probably best practice to use the MC4x for machine function control code and we'll have to bite the bullet and move to multi-master systems with the MD5s, but it is disappointing and will be painful.
The MD5 also has longer cycle times then the MD4, we like to keep our cycles around 40Hz or faster, The MD5 supports 20Hz at the fastest so watch out for mismatched cycle times between masters and the display from now on, means you have to be more careful with delays as well
Good discussion, lots of important points here.
I have some comments on functional safety and performance:
Functional safety
First, my recommendation for mobile machinery is to use functional safety certified modules for all hydraulic motion control. IQAN-MC4xFS controlling XC4 expansions.
Looking back just ten years ago, the situation was different. Back then we only had the MC3 as a safety controller and it was only feasible to use it on the most important safety functions.
With the MC4xFS and XC4 expansions, it is now much more affordable to follow standards also for the functions that are both normal functions and safety functions. Such such as hold-to-run control on operator controls.
I agree that it has been a very nice feature of the MD4 to run graphics and machine control logic in the same product. But it does not meet modern functional safety standards.
Real-time performance
While the MD5 is about four times faster than an MD4, it does not have the same real-time performance as the MD4 or an MC4/MC4xFS controller. Meaning it doesn't have the same ability to prioritize the application and CAN traffic over graphics.
Some observations from comparing MD5 and MD4 side-by-side, with equivalent applications:
To illustrate, here I'm comparing MD5 and MD5 applications both running same size 20 ms applications (on 7.06), and graph the cycle utilization.
This may be fine as long as application logic completes within the application cycle, but there also needs to be consistency in the time between periodic CAN messages. That is where I think you could have practical problems in a system built with MD5 and IQAN expansions.
Thank you for the reply, Gustav.
We also use the MD4 (and previously MD3) as a simple engine parameter display and TSC1 speed controller for more basic machines without any additional expansion/master modules. Having to add additional modules just to control the engine speed and display engine parameters is certainly not ideal.
I think I've made my point clear that it is a disappointment that the MD4 series is being discontinued without a functionally equivalent replacement. I appreciate Parker's commitment to functional safety in applications, but I wish more consideration to compatibility of existing systems in both form and function.
Justin. We use an MD4 as a TSC1 controller(among other things as well). We have it set to 50mS cycle time due to the amount of code running in it. On the TSC1 message channel itself we set the transmit rate to 10 mS. It runs just fine.
I HAVE NOT tried that with the MD5 but hopefully it will behave the same.
That's pretty much exactly how we've been using the MD4 (and MD3) for years and have had great success.
I hope you're right that the MD5 can also be used this way, but the way I read it, they don't want you using the MD5 for any "real time critical functions" and the fluctuation in the outgoing CAN traffic noted by Gustav above makes me think it might not be able to handle the TSC1 messaging properly. Hopefully I'm wrong on that though.
Our main application for the more basic engine control applications uses a couple of voltage inputs from pressure senors to vary the engine speed to control an engine driven pump, so we're going to have to add an additional I/O module anyways since the MD5 doesn't have any analog inputs. Not at all ideal, but I guess we gotta do what we gotta do.