As I described in Monday's blog, there are some control systems which rely on outputs holding last state in the event they are no longer under control. These events could be as simple as s network cable being disconnected, to a programming error resulting in a controller fault.
While no major control system I know of lacks this feature, in November 2013 Rockwell published a “Release Note” document describing a firmware bug discovered on the 1734-OE4C. This bug prevented the 1734-OE4C from correctly implementing it's “hold last state” feature.
Honestly, I'm surprised this information was put forward in a “Release Note” instead of one of their “Product Notices.” Announcing a bug in “Release Notes” alone seems to me to be reserved for the most minor bug fixes. And the inability for an output module to “hold last state” frankly seems more serious than that.
Note: You can read Rockwell's 1734-OE4C release notes using this LINK.
Not a compete fix?
While the new 3.003 firmware does fix most of the hold last state issues, surprisingly one still remains. Today, even with the new 3.003 firmware, if you preform a download to your controller the 1734-OE4C module still will not hold last state. This is quite unlike how Flex I/O and 1756 I/O operates.
As confirmation of this remaining issue has been sent to Rockwell, it's my hope that we will soon see updated firmware allowing all Point I/O modules to “hold last state” under all conditions. Until that time, if holding last state during a controller download is important to you, you may wish to use another I/O platform until the Point I/O line is patched.
I hope the above article on the 1734-OE4C not holding last state is helpful. If you have any comments, questions, or corrections please don't hesitate to share them with us by using the “post a comment or question” link below.