--Symphony Harmony Composer - What Fails if FC225 in FDD Chain Has S5=0?
A client reported deficiencies in operation of FC 225 IOC/DOUT Digital Out/Channel blocks in a FC 228 FDD chain when S5 was left at the default value 0. The documentation clearly states for S5:
"(Readback enable) The output channels can have optional readback hardware present. This specification must match the hardware configuration with respect to whether this option is enabled.
. 0 = disable readback
. 1 = enable readback
This option must always be enabled for foreign device definition (function code 228) channels."
The client reported "The logical input will not match the output of the function code at times, even though the physical output will. Also, it was noticed that even overriding the output will not update this. The exception reporting is the output of the block. So in our case, we have these trended in PI and have graphics showing the state of these blocks. All of these, were reporting the wrong state when there were changes to the input. This leads to misconceptions when troubleshooting. Also, problems with reporting if external logic is using these exception reports (PI calculations, graphical procedures, etc.).
We typically don’t use the output exceptions for alarming. But did notice a few, while monitoring in composer, (that were setup to alarm) to have similar symptoms. So, I would assume the alarm state to be dictated by the output state and not the input. Given that, I would also assume that if there was logic built based on the output of the block, it would not function correctly. I don’t think we are doing this anywhere, but others may."
The client then changed S5 to 1 for the blocks. Here is an additional statement:
"Some did change state or got exception reported as expected. Also, the problem seemed to have cleared when an online configuration was made to something unrelated but in the same module, only to show up again on different blocks within a day or so. The problem seemed to be with the block output more than the exception reporting. Monitoring the block outputs of the suspect blocks from Composer or DBDOC did not match what it should’ve been. Don’t know the internals on how the exception reporting is done, but, it sure seems like if the output doesn’t change state (when it is supposed to), exception reporting does not function as well. Could not see any correlation of the errors, seemed random. Now, after the spec change, we don’t see any mismatches, so far (~3weeks)."
Bottom line is that the output of the block does not match the input, affecting tags, history, exception report inputs as well as local use of the block.
This seems inconceivable. What am I missing? Can someone explain what happens in FDD chains to FC225 output values if S5=0, as it clearly must be 1? What goes wrong from your knowledge? In a scan of half a dozen systems, I found only one that used the correct value - that is, about 10,000 errors in five systems.
Voted best answer
FC225 NOT UPDATING THE "OUTPUT INDICATION" HAS BEEN A PROBLEM FOR A WHILE.
IN ALL MY EXPERIENCES THE PHYSICAL OUTPUT IS ACTUALLY STILL WORKING.
POWERING DOWN THE AFFECTED I/O AND RE-POWERING ALSO RESETS INDICATIONS.
THE MOST RECENT SOLUTION TO THE PROBLEM WAS TO INSTALL BRC 400/410 REV M5 FIRMWARE AND S800/810 FIRMWARE TO G5.
I HAVE DONE THIS AND HAVE NOT SEEN THE PROBLEM SINCE.
I HAVE NOT HAD TO UPDATE S5 AS INDICATED TO SOLVE THE ISSUE, BUT THIS SEEMS LIKE A PRUDENT THING TO DO, EITHER WAY.
ALSO SEE CASE