I recently discovered that the MC4x family does not have a RTC pin and therefore when you go to pull a log on a file, it simply gives you a "start number" and a base line of 12:00:00AM. This is not sufficient for what most of my customers needs are. 

Are there any plans to add in an RTC pin to enable us to have actual time available when logging.

Our latest generation of controllers are finally ready for production. The IQAN-MC4x family is the fastest and most capable controller range we have ever done. It comes in three sizes to support any application size, from the entry level task oriented control up to the high I/O configuration for complete machine control.

First out from the production line and available now for deliveries is the performance optimized version of IQAN-MC43. The IQAN-MC41 and IQAN-MC42 will start shipping next month (December 2016).

Work is ongoing with the Functional Safety versions and units capable for implementation of SIL2/PLd safety functions is planned for production Q3 2017.

Find more detailed info at: http://solutions.parker.com/LP=7632

On December 15th, we released the IQAN-MC4xFS series, with safety certification by RISE. 

The release means that we now have SIL2/PLd versions on all three sized of the MC4x series:

• IQAN-MC43FS
• IQAN-MC42FS
• IQAN-MC41FS

You can read more about the new product in the press release.

In the press release, we make a reference to the EN 13849-1:2015 update. The EN 13849-1 standard lets machine designers create safety functions either based on electronic components certified by the manufacturer (like the MC4xFS), or design safety functions based on the EN 13849-1 architectures. 

With the original 2006 release of the EN 13849-1 standard, there was great emphasis on on calculating hardware reliability, but requirements on safety related embedded software was not as clear as in IEC 61508. Now with the new 2015 update there is a clear limit, implementation of PLr=a and PLr=b functions are accepted on standard controllers, for PLr=c and higher, the use of controllers with safety certification is necessary. 

To learn more about this topic and how to design complete safety functions in accordance with EN 13849-1, you can sing up for the IQAN focused training on functional safety. 

For documentation of the MC4 product series, see the instruction book.

Hardware Question:

In the Documentation for the MC4x family of controllers - it says in many places to use diodes for external coil suppression, for example when driving a relay with the Digital Out HS driver from the MC4x.

A relay that I have specific to my application requires (highly recommends) the use of varistor coil suppression, which is less "harsh" on the relay device during transients. The specification requests a clamping voltage of 3x the coil voltage, i.e. 36Vdc for a 12Vdc relay coil.

Are there any adverse affects of using a varistor instead of a diode for coil suppression? 

Perhaps this could be also compatible with the hardware design of the MC4x series of controllers?

(Hint: I already have tested this configuration on my system to many thousands of cycles under load with no discernible affect on system operation or relay operation)

This module supports alot of IO and 5 x CAN. Very simple functions to serve all of the IO and CAN easily burn the available resources and I am wondering if there are any upgrade plans ?

The new -M24 versions are now in serial production:

See updated catalogs:

IQAN-MC4x_brochure_HY33-8413-UK.pdf

IQAN-XC4x_brochure_MSG17-8417-UK.pdf

Requires IQANdesign version 7.03, see Version 7.03 released / Software / IQAN

i need more output io

but it looks like a big tear up

I'm hoping someone might be able to chime in if they have seen something similar before.

I'm driving two contactors (they close at different times) off the MC41. The contactors at peak draw 3.9A for about 75ms. When the contactors close, a very short time later, the MC41 enters a critical fault. The flashing lights (4R, 1Y, 12Y, 3Y, 1Y, 2Y) seems to indicate there is a 'watchdog' fault. Looking at my CPU/RAM usage and cycle usage, we are not even using 1% capacity. Is it possible this overcurrent condition could trigger this particular fault?

As well, I can't seem to find any information on what the 12Y is supposed to mean? "R4:1 n:3:1:2" which would be the "n" in the manual. What would the 12th part of the software mean?

Hi!

Previously we used MC2 in a project. Now changed master module in the program to MC43.

We have a DIY test board (large resistors with LED for indication) to double check if the machine sends signal to valves etc.

Using COUT channels...so connectors come in pairs. With MC2 if one of the connectors wasn't connected to a load it would display "open load" error when machine would send a signal to a valve that isn' t connected, but connected one would work when output is signal is given. (no open load error when joystick is in neutral)

Now with MC43- both COUT pair connectors have to be connected for it not to display "open load" error..even when joystick is in neutral position.

Is this because MC43 diagnoses itself differently than MC2 or is there something to be changed in the program?

Hi, I have an issue with intermittent MC43 COUT overload errors on one of our machines.

Status is OK and operates well in most conditions, but will randomly report overload (even when that function is not requested).

I have tested the solenoids, plugs, and wiring harnesses within this circuit and all looks ok.

COUT circuit C1:16, 41, 57.

Is there anything else I should check to see what might be going wrong?