+10
Completed
Disable all DOUT open load detection
Michael Carlyle 4 years ago
in IQANdesign
•
updated by Gustav Widén (System support) 3 years ago •
16
As a feature request - can this be set in the channel to have a no open load errors option. We have had many issues with this error coming up when the output is off when driving a load through a diode for example(another computer is also controlling this load as well). Diesel Pre-heat for example which must work with the Iqan off or on. I realize the output can be put in a function group and disabled - but it is definitely not intuitive and requires extra programming and memory etc.
Customer support service by UserEcho
Converted to topic, original posted as comment here: https://forum.iqan.se/communities/1/topics/1231-disable-open-load-dout-mc42
I agree with MC. I have multiple outputs that come from an MC4x controller that go, for whatever reason, to very high impedance locations. One into a PLC/controller for a "enable input". One into a diode bridge for an OR enable of a relay... and so forth. I will add resistors (10k pull down) where practical, but this will add system cost and complexity.
Implementing a software disable has its usefulness!
Thank you!
This minimum current load of 60mA is a problem for us as well. We have many examples where this is a problem when interfacing with other systems and even finding a warning buzzer that doesn't hum due to leakage current is a challenge. I'm not sure if this can be fixed with software, we have found that turning off open load detection does not stop the leakage so I guess it might be something on the hardware side that cannot be changed?
I have also experienced the problems with excessive leakage current, especially with LEDs. Additionally the "open Load" fault is just a nuisance fault when driving high impedance loads. I would prefer if that fault detection were disabled. I would rather write my own function for detecting and processing an open load fault by commanding a small current (not high enough to cause a solenoid to actuate a valve) and compare the commanded current to the feed back current. If the feed back current is close to zero mA, then I would declare that an open load. But, I have not found a way in IQAN to read the feed back current.
In response to Seneca, Tim and Mike G, I think there are a few related product characteristics that could use some more explanation:
-under current detection (open load when DOUT is on)
-documentation on minimum load
-off state open load detect (open load when DOUT is off)
-leakage current
With the MC4 DOUT on, open load can be detected using under current detection. The reason behind the "minimum load" of 60 mA in the documentation is this under current detection.
For driving smaller loads like relays, this undercurrent detection can be disabled. So "minimum load" is not as limiting as it may seem from the documentation, and is not directly related to the leakage.
Then there is also the function for open load detection with the DOUT off.
Each Digital out HS has a pull-up resistor to supply, by measuring voltage on the inactive output the controller can determine if the load has connection to ground or not, thus checking for open load. It is mainly this pull-up resistor that cause the leakage current.
There is no switch to disconnect this, the leakage current is determined by the hardware.
What we could do with an IQANdesign update is to add another property to make the reporting of the off state open load detect configurable.
It won't reduce the leakage, but I think this would solve the issue Michael describe, as well as a similar request here.
This has been a source of suffering for us on a variety of projects. While the idea was great, it seems to cause more harm than good. Like the others mentioned, we are (for a variety of reasons) not going to just a standard type of coil and are going into PLCs, Relay coils, and other things that do not neatly detect.
Sadly our 'go-to' has been to turn these off on every project on every channel to begin with and we turn them back on if there's a specific need.
We plan to add an option to also disable the off-state open load detect.
It will not change the leakage current, but it will help for those cases when one simply wants to avoid unnecessary reporting of an open load, without having to disable the output.
"We plan to add an option to also disable the off-state open load detect." Any plan when this is available?
Hello Gustav,
Do you have any news about this update? If it can help someone, we found a work around adding un pull down of 30kohms (Vbat 24V) to avoid the alert. We tried to add the DOUT in a function group activated only when we need to use this output, but, even if there is only a digital set to true, the message has time to pop on the screen before the output becomes active.
I just had to add a pull-down resistor to a very high input impedance load. Simply to avoid the error.
Just wanted to put a +1 on this.
Having the same issues myself.
We are using the XC43 to power a relay in-line with the engine starter to prevent the engine from starting when certain criteria aren't met. I have the output disabled through a function group once the engine is running but still get the problem when the IQAN first powers up.
I know it's just a nuisance error but some customers can be very particular about not wanting any error codes.
Implemented for DOUT HS (and PWM out HS) on MC4x/XC4x in IQANdesign version 6.07.
Is there a reason why this is not also implemented on DOUT LS on XC21/XC23?
There was an issue with over-sensitive open load detect on XC21 in 3.x, but after that was fixed I have not heard of any request for disabling open load on that module.
In general, I'd say that any change or new variation on the I/O diagnostic functions is quite complex to do in a good way.
Will under current and open load detection become a parameter that can be set via the initialization in the future?
There is currently no plan to make under-current and open load detect configurable with initialization channels.
I think it would be tricky to add to the complexity of the I/O diagnostics, but it is always good to understand the use-case for this.