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:
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.
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.
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 ?
ID-tag 4 to 7 does not exist for Molex MX123.
We use 4,5 and 7 today and have to re crimp those ID-Tags for MX123.
When do you plan to offer ID-Tags 4 to 7 for MX123?
IQAN Design refers to CAN bus on the MC4X as A, B, C etc, manual (under installation) refers to it as numbers 1, 2, 3 etc. Although its obvious to work out, its better for us if its one designation across the board to avoid confusion when cross referencing documents.
We are using a MD4-7 and x2 MC41's on some of our machines (we actually wanted to use only x1 MC42 for these jobs but we are still waiting for the parts to arrive and have deadlines to meet so we are just using what we have available to get the job done)
But last night we started testing the machine and went through all of the procedures and functionality when all of a sudden an error appeared on the display telling me that one of the MC41 controller lost comms, but the other one was still fine and giving readings... So the 1st thing we tried to resolve this was typically switching the machine off and on, but this time there was no CAN comms at all.
We went though the wiring harness and made sure that everything was correct and the wiring was all good, so we then went and replaced both these controllers with new MC41's we had in stock, we plugged it in uploaded the software and the system was happy again with the new controllers and it is still working fine at this moment... So I took the 2 faulty MC41's to my office and connected it all together to try and diagnose the issue.
Each time I tried uploading software (using IQANDESIGN 5.01 via ethernet) it kept on warning me about the incomplete system and that only the MD4-7 will be updated.
Eventually we switched from CAN-A to CAN-B only on the MC41's. but upon each attempt to upload the software, the same "incomplete system" warning appeared.
So I just left it for a while and a few minutes later decided to just try again uploading once more. Well it worked all of a sudden and that is also a big problem, because I didn't change anything where I could say " there, that was the problem".
This is worrying us a bit, because we have no idea why this happened in the first place and secondly these machines are going to the middle of Africa... So this sort of thing must not happen at all!
I have only been using MD4's and MD3's with XA2's in the past without any problems at all, these are our first machines using the MC4x family and this is also the 1st time that I encountered any issues like this on IQAN.
Have anyone else experienced this before? I have no idea why it failed or why it started to work again and this is definitely not the correct answer to give the person asking this question when there are deadlines to meet.
The other thing to mention also is the LED's on the controllers which blinked bright yellow 3 times then blinked dimmed yellow 3 times while it was not communicating. which also does not correspond with these fault codes in the manual. There was no RED LED blinking at all.
I have a critical problem with MC41-FS stand alone controllers (ie it’s not connected on Multi-Master system). FW level 6.05.18.6047
We see operation continuous for about 2 months with no error, then multiple devices on the same mahcine just stop working ll within minutes of each other (with no CAN output) and no reported/broadcast faults or recorded System Log errors. This problem is seen on multiple machines now, and a pattern is emerging of this failure. Resetting 24V power, resets the module and the error.
Clearly having a module just stop operating with no reported or logged system errors is very dangerous, as we have no means to quickly diagnose.
We have managed to collect the LED blink code when in error state: This sequence is not listed in the manuals.
- There are 3x MC41-FS modules per machine (all independent)
- MC41FS power supply is continuous 24V
- The machine has a "main" Multi Master system which comprises of 2x MD4-7 and 3x MC43FS modules all on MM system.
- The 3 independent MC41FS modules are connected to each MC43FS module on J1939. As far as MM system is concerned, the MC41's are another J1939 module on the common J1939 line.
- The machine MM system is operated with switched power supply (24V)
Originally I thought this was possibly a CAN bus issue, but no other IQAN modules are reporting CAN bus errors (ie the MC43 modules) as they share the same J1939.
There is one possible interaction between MC43 and MC41 module that could be contributing (depending on what the fault LED codes are from above). The MC41FS module has enabled TDA for time sync, and the MC43 is configured to send TDA PGN onto the shared J1939 continuously every 10 seconds to time sync the MC41FS. As mentioned above, the MC43 modules are connected on switched power, and the MC41 on continuous. So very night the MC43 (and full MM system) is powered down overnight). I am unsure if this is a problem, or has no effect.
Please can someone contact me to discuss this directly. I am not able to share the project file publically.
I'm working on a project, where i want to control the speed of a brushless SPAL fan and a BOSCH cooling pump via a PWM-Signal from a PARKER MC43.
However, I'm running into some issues with this.
1- First of all, I dont know how to wire the components. The fan und the pump, both have only 3 pins when it comes to PWM controlling. 24V + , 24V ground and the Sinal pin for PWM. On the MC43 i do have 2 pins per PWM signal. Could anybody show me how to wire those components? I added a unfinished schematic:
Maybe I'm missing something completly obvisous here but additions to not knowing how to wire these components, I don't understand what has to come on the PWM*/E* pin of the fan. From the picture it looks to me like this pin needs a PWM signal, wich is switched to ground. I'm not an electrical engineer but from what I understand, there is a difference between GND (-) and not having a actual potential difference. Like when something is on two pins connected to 24V DV there is no actual potential difference but there is no GND. Can anyone explaine what needs to be connected to the PWM*/E* pin of the fan?
2- The second point is, I found this threat on the Parker forum wich comes kind of close to some of my problems:
Where is written:
" You could use the PWM output on e.g. an XA2 or XC10 to do this, but there are a few limitations to think of The most important is the off-state leakage current on the highside driver. This is just as relevant for the case when one wants to use DOUT as a signal to another controller. If you do not pull the output to ground, you will see a voltage on the output pin that is close to +BAT level. The other will have some voltage threshold that you must be sure to be able to come below.
It is very probable that the PWM input on the other device have a pull-down resistor in the kOhm range. Then you will need to add an external pull-down resistor to load the signal. Which is tricky because this low resistance component will also have to cope with the power during the on-phase.
Another limitation you need to consider is the PWM out range. As the IQAN PWM outputs are primarily intended to drive valves, none of the outputs go all the way to 100% MR.
For modules that has undercurrent detection (like XC10), you might need to switch this off, depending on how much you load the output."
When it comes to the MC43 Module, are these problems still the same or has anything changed since that?
Because this Answer is around 5 Years old. Sorry if there are some obvious solutions to my problems, I'm still quite new in this.
Customer support service by UserEcho