We are getting a consistent group of I/O output failure events relating to one module that occurs exactly every eight hours at 06:22, 14:22 and 22:22. An example of each group is as follows:
Time
Delta (s)
14:23:11
0
Water split I/O output failure error
14:23:13
2
Error cleared
14:25:30
137
14:25:32
14:27:50
138
Steam split I/O output failure error
14:27:54
4
14:29:52
118
14:29:55
3
Water split and Steam split are linked composites each containing two AO blocks. Although the event says the I/O output failure relates to the composite itself, I guess they are originating as Output failures on the AO blocks inside. As you can see each failure lasts a few seconds and I am assuming that each one relates to one of the AO blocks. There is is about 2 minutes between the errors on each AO block.
At the moment I have no idea what might be causing this. Any ideas as to things that happen every eight hours on such a regular pattern? There is no function blocks relating to chronological time in the module. It is a fairly simple PID control module. This is DeltaV version 13.3.1 with the latest hotfixes.
I am still trying to get to the bottom of this. For a while the errors became more random then settled back to occurring every eight hours but in two groups. Two questions someone may know the answer to.
What is an I/O output failure?
I thought it corresponded to the IO Ouptut Error bit in the MERROR parameter and was due to a problem communicating with an output channel. However I filtered the Event Chronicle for "I/O output failure" and found two other modules that had regular I/O Output failures. In one module the DESC1 field in Event Chronicle suggested the error origintated from an ACTION function block and another module, which has no I/O, where the I/O output failure was ascribed to a CALC block in an SFC composite.
Could the "I/O output failure" be due to slow updating of outputs?
The module that is of the most concern has four AO blocks each with a conventional M-Series output and a HART_SV readback. The scan rate is 1s. Andre Dicaire said in a post in 2020 that "Specifically, the Module must not write to an Output channel faster than the IO subsystem can process the output to the Output channel" Is this likely to be a problem with a 1s scan rate? I also read that HART updates can take 600ms at least. Would failure of the HART readback to update fast enought be classed as an I/O output failure or an input failure?
In reply to Cedric Dawnhawk:
In reply to LBDeltaV:
Thanks for your response. I intend to increase the scan rate to 2s and see what difference it makes. However I have been unable to find anything about the "timeout" value. Any further clues as to where it is documented?
In reply to Uchenna Oparaji:
I would not think this is related to Module scan with module set to 1 second. The local IO bus scans at a typical 30 to 50ms, with M series controllers having a minimum 20ms cycle. Actual cycle depends on number and types of cards. Outputs are written only when the module executes. With a 1 second module, your IO bus updates will have scanned 20 to 30 times. Setting scan time to 2 seconds doesn't seem like the answer. However, if there is some sort of timing issue in the system, changing the scan time will cause the module to be rescheduled in the controller and that might change some relationship that affects your observations. But something else is at play here than just module scan time.
On an AO channel, there is no time out value for communication. I'm not sure what LBDeltaV is referring here. Maybe LBDeltaV can provide some clarification on this?
You indicate the issue follows download of a similar module. Any chance you've got duplicate IO references in the modules? I would start by investigating the modules. As you discovered, IO Output Failure seems to be related to Expressions. IO Failure is typically what is reported on IO related faults.
When an expression performs and Assign statement, if this fails, you would get an IO Output Failure. An Input Transfer error or Output Transfer Error relates to wired connections. Action blocks and SFC expressions don't have wired values for data flow. I'd be leaning towards an expression, especially one with some conditional logic that might only be true every eight hours or so?
Andre Dicaire
In reply to Andre Dicaire: