0
Answered

MC2 - Cause of Internal error/ose?

Pankaj Ramole 3 years ago • updated by Ulrik Zakariasson (Software development) 3 years ago 6

Please help me to get the details about above mentioned fault code

This blink code (4 red, 1 yellow) comes when the internal montioring of the IQAN-MC2 has detected something abnormal, and stopped the application. In this state, the application does not run and all outputs are switched off.


If this is a new application and this happens during development, the most likely issue would be that there is a watchdog reset, that the cycle time is set so low that the application cannot be executed on time.

It could also be something in the specific application that does not work with the IQAN-MC2 software, a bug.

In both these cases, the problem depend on the specific application.

Then, a way to get the MC2 operation again is to start it in "Safe mode", by shorting the address pins, and powering up the module. This will bypass the application, and allow you to send a different application to the MC2.

See "Safe mode" on page 28 of the IQAN-MC2 user manual:

http://www.parker.com/literature/Electronic%20Controls%20Division/Literature%20files/Iqan-mc2_uk_instructionbook.pdf


There should not be any wiring faults for the MC2 that could trigger this fault code.

If this fault occured in the field and it has worked without problem, then it could also be an internal hardware fault of the MC2, but this is very unusual.

Had this problem once with an MC3,

In our case, our application was to heavy/big for the module.

this does show up as warning before uploading, but I was still able to upload the application anyway.

Resulting in the same error.

Maybe this shouldn't be a warning but an error in Iqan Design?

Thanks, that is a good point you are making. In addition to the possible issue with the cycle time being to short for the application that I mentioned, there is also the possibility that that the application uses more memory than available in the module.

Depeding on which memory it is that runs out, you could have three different warnings in the Project check:

-Application too large (not enough flash to store the application). This one will if it is way too high also prevent downloading.

-Too much memory used (not enough RAM to load the application and start running).

-Heap check failed (an indication that too much FRAM settings memory is used)


Out of these three memory limitation, the RAM usage is the most probable one to have on an IQAN-MC2.

It could probably help sometimes if this was shown as an error instead of a warning. The reason for keeping it as a warning has been that it is based on an estimate made on the PC, and that the real memory usage will differ slightly.

Also notice that the cycle utilization (probably the one thing that is most likely to cause this symptom) cannot be checked accurately at design time.

Thank You very much for your Feedback.

Actually we are facing this issue on a water well rig on site. Here we are using MTU engine with ADM2 and MR controller. Via ADM2 controller we give CAN connection to MC2 for engine data monitoring.


After troubleshooting i figured out that, as soon as we connect engine CAN to MC2, above mentioned error starts coming in. This is only happening whenever we are using IQAN 3 program.

Now i shifted back to IQAN 2 program and everything is working fine.


Looks like there is some conflict between engine can and MC2 with new IQAN 3 firmware.

Is the upgrade from version 2 to version 3 the only change that was made, or were there other changes in the project file? Such as adding or modifying channels in the application?

It would be very unlikely that only upgrading firmware version and not changing anything in the application could trigger this.

With the previous verion that works, what cycle time do you have set on the MC2, and what can you measure as cycle utilization?

What can you measure as memory utilization? (actually, the information that the error shows up only when connecting one CAN bus hints that the memory utilization is less likely to be the problem)