XC10 output high in software but low directly on module

We appear to have this abnormality on multiple outputs on the XC10 module. Putting a 'on delay' of 1000ms on the IDC controlling the output cures the issue but isn't ideal for our application. Once the machine is started and the IQAN system is running it appears to be functioning correctly when the output is commanded low or high, ita only seems to be a problem on initial boot of the system.

Is this something you are able to replicate?

I have similar issue for a long time with output on XA2. I would need to put an initial timer to block the output at start up. XA2 works with MD3 or MDL2, both have same issue.

Hi Kevin,
Do you use the Enable property on the XC10?
Normally all IQAN IO are level triggered, but we have a problem in the XC10 firmware has the behavior that some of its DOUT:s will need a flank after module disable. It is the DOUT:s that are also combined as XC10 PWM:s that have this behaviour. Here is an example of how to make a workaround for it, I only used 100 ms after the XC10 enable for delaying the DOUT.
XC10 DOUT workaround.ids3

Frank,
The issue above should not exist for the XA2, but there is another possible explanation for the problem you experienced.
If there is a fault that affects outputs, the behavior is that these outputs will remain off with the error status until the error has gone away and there is a zero command to the outputs.
The purpose of this is to avoid unexpected restart for outputs that are controlling machine movement, if the error is intermittent.
This functionality is controlled by the master module, and in IQANdesign you would see the error status and that the DOUT has the value false.
If you want a function that automatically restarts the DOUT after an error, you can achieve this by blocking it when there is a fault.

Hi Gustav,

We have a IDC in the MD4 application which has a true to activate the IDC. We then applied a 500ms 'delay on' for the IDC so that it will enable the XC10 module after 500ms. We have also added a 'delay on' on some outputs of 500ms, maybe this is why its not activating because its enabling the XC10 module at the same time as the output? We found that increasing this to 1000ms enabled the output successfully, effectively enabling the output 500ms after the module has booted?

Can the firmware be changed in the XC10 to cure this problem? If the XC10 module is booted can it get a signal from the module holding the application to see which outputs should be energised? This would resolve any need to insert delays in the software.

Yes, this problem is triggered if these DOUT:s are activated at exactly the same time as the XC10 is enabled, The workaround is to extend the delay-on time for the DOUT:s, it should not have to be as long as you have set it now. In the example application for the workaround, I have put it to 100 ms after enabling the XC10, and that works.

We are just about to release an XC10 firmware update to support DOUT diagnostics features in combination with IQANdesign 3.15 and later. But this update we are releasing now does not resolve the problem of DOUT:s requiring flank after module enable.

Could we insert the delay on directly on the property inspector on the module instead of a separate IDC? Will this work the same way or do the module output delays get processed by the XC10?

If we energise the module output as soon as the application starts (a true function) and remove the module enable function completely will the outputs still need a flank?

No, the delay must be on the activation of the XC10 DOUT:s, so if there is a delay in enabling the XC10, then the DOUT activation comes at least one cycle after the module enable.
The output delays (IDC) does not get processed by the XC10, the XC10 only sees the DOUT:s as its commands.

Yes, if you do not have any delay in activating the XC10 via the Enable property, then you can activate the DOUT as soon as the IQAN master starts, and the XC10 will activates its outputs without the need for a flank.