We have a system with MD4 connected by master bus to MC3. We have a XC23 connected to the MC3 via expansion on different bus to master.

On ignition switch on the system appears fine and all outputs and inputs into XC23 are OK, during engine start there appears to be a dip in voltage which causes the XC23 module to show 3 red, 1 amber LED flash (can error / timeout). When we get this error flash, IQAN run says system health is OK under the XC23 and MC3 modules and IQAN design shows the outputs on XC23 going true and false as expected. XC23 module outputs however are non functional, the module is in error state and refusing to operate outputs whilst the LED flash sequence above is active.

There are no logs in the MC3 for failed communication with XC23.

Are there any recommendations for how to resolve this? Is this normal behaviour for a dip in voltage on XC23? All other modules appear to be unaffected by voltage dip, its almost as if XC23 does not recover and outputs are non functional even though IQAN design thinks they are? Would pulsing 'enable' property just after engine start re-enable the module in event of this error flash?

Running IQAN Design 4.07 with machine voltage 24V dipping to around 10/12V on startup.

We are having issues with a system that has 2 XC10's on the same expansion bus. This is the first system we used multiple XC10's and have been having issues since we got it online.The XC10's expansion bus is connected to a MC43.

Changing different settings seems to have some affect but I feel like no matter how we change settings this issue is still around it just might not popup as much.

We either get a multiple address error or a no contact error. When we get the no contact error if we look online the device is working however any outputs that were active are faulted and we need to cycle them to get it going. This seems normal for a no contact issue. We see these errors on startup and occasionally while running.

Here are settings I changed. When I changed them I cycle power 25 times to try to gauge where we need things set. The settings I played with are the MC43 cycle time, expansion bus divider, delaying and staggering the 'Enable' for the XC10's. And I recorded the occurrences of each message.

There is a pattern but I'm having a hard time decided where to set things. We currently have the system set with settings that didn't give us problems during the test, but during further testing we occasional see them.

20 ms MC43 

Expansion bus divider =  2(40mS)

Cycle util = 11% 

XC10[0] Enable delay = 0000 

XC10[1] Enable delay = 0000               

0 - No Contacts     

0 - XC10 Multiple addresses

10 ms MC43 

Expansion bus divider =  2(20mS) 

cycle util = 21% 

XC10[0] Enable delay = 0000 

XC10[1] Enable delay = 0000                

0 - No Contacts     

2 - XC10 -Multiple addresses

10 ms MC43 

Expansion bus divider =  2(20mS) 

cycle util = 21% 

XC10[0] Enable delay = 5000 

XC10[1] Enable delay = 0000             

0 - No Contacts     

2 - XC10 -Multiple addresses

10 ms MC43 

Expansion bus divider =  9(90mS) 

cycle util = 21% 

XC10[0] Enable delay = 0000 

XC10[1] Enable delay = 0000                

0 - No Contacts     

0 - XC10 -Multiple addresses

 5 ms MC43 

Expansion bus divider =  2(10mS) 

cycle util = 41% 

XC10[0] Enable delay = 0000 

XC10[1] Enable delay = 0000                

0 - No Contacts     

4 - XC10 -Multiple addresses

 5 ms MC43 

Expansion bus divider =  2(10mS) 

cycle util = 41% 

XC10[0] Enable delay = 5000 

XC10[1] Enable delay = 0000               

0 - No Contacts     

3 - XC10 -Multiple addresses

  5 ms MC43 

Expansion bus divider = 10(50mS) , 

cycle util = 41%  

XC10[0] Enable delay = 0000  

XC10[1] Enable delay = 0000                

1(1) - No Contacts     

0 - XC10 -Multiple addresses

5 ms MC43 

Expansion bus divider = 10(50mS) 

cycle util = 41% 

XC10[0] Enable delay = 4000 

XC10[1] Enable delay = 8000                

1(1)  - No Contacts     

0 - XC10 -Multiple addresses

I have D-in G, pin #38 hooked up to the brake lights of a truck to detect when the brakes are on.

I recieved a report on one truck that the brake lights don't work when the IQAN system is powered off.

Does the impedance change radically when the system is powered down?

the book states 62 kohm pull-down in parallel with 470 pF. I can't imagine that would draw enough power to keep the brake lights from illuminating.

Is this a faulty module? or is this normal and I need to add a large in-line resistor on all trucks in the field wired this way? Are XS2 modules the same way if this is normal?

eta: when I use a multi-meter on another XA2, I get 62K ohms between pin #15 and pin #38, so I am leaning twoards this being a bad module.

Hi, Appendix A in the manual states there are two VREF supplies for the XC2x range and it delivers 70mA current max. Is that 70mA per VREF (150mA total) or 70mA total across both VREF's?

As you can see the Vref and +Bat are a bit off on MOD4.

any ideas?

Was wondering what  the temperature threshold is on XA2 units before the internal temp will trigger a warning in the system?

What happens if I try to drive a load that is greater than 2.5amps with the HS output of a XC-10?

We have an application for some voltage signals to be connected to the MC3 application. We have selected an XC23 module which compares a VIN signal on the MC3 with a VIN on the XC23. We have two of these functions (1 x MC3 VIN and 1 x XC23 VIN = one of two comparison functions in the application) measuring two different positions using sensors.

We have found that one set (an MC3 and XC23 VIN comparison) seem to follow almost exactly, however the other pair, the XC23 signal appears to increase and decrease in approx. 20mV steps. We are using VIN E and F on the XC23 and it appears the VIN F is causing the stepped signal even though it looks like it should have an accuracy of 1.22mV.

We have changed the sensor and XC23 module, but still appears to be doing it. Is there any reason for this behaviour? I have checked the VREF in the application, and all the VINs are configured to the correct reference voltage.

IQAN 4.05, application cycle of 50ms.

The updated version of the IQAN-XC10 with support for DOUT diagnostics has been released.

DOUT-A to DOUT-P

These high-side DOUT:s can be configured to detect open load when the outputs are off. The detection is based on a shared "strobe" function, giving out a limited current at regular intervals. The detection is suited for loads such as solenoids, but should be kept disabled if any of the high-side DOUT:s are driving smaller load, e.g. LED lamps that will blink when this feature is used.

DOUT-Q to DOUT-T

These low-side DOUT:s can be configured to detect open load when the outputs are on. This diagnostic feature is based on undercurrent detection. The detection is suited for solenoid valves, but should be kept disabled if the DOUT is driving smaller loads, e.g. most relay coils.

PWMOUT

The PWMOUT has open load detection based on measuring undercurrent also in previous versions. Now the option to disable undercurrent detection is available.

For more details on the DOUT/PWMOUT diagnostic features, see IQAN-XC10 instruction book, Appendix A.

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

IQANdesign support

The features are available with IQANdesign 3.15 and higher

IQAN-XC10 firmware version and serial number

The IQAN-XC10 modules have a new serial number range:

S/N: 161726-000005 and higher