My client had designed the application with each software service (FTVSE, RSLE, and FTAE) in their own areas, much like you see Rockwell do in RSTechED Labs, View SE samples, and on the Rockwell Knowledgebase.
Strangely though, after running in this configuration for several weeks some of the binary “BITS” in certain arrays stopped triggering FTAE alarms, even though the same BITs were correctly animating graphic objects. Stranger still, other BITS in the very same DINTS still continued to trigger FTAE alarms…?
The only way the engineers found to get these non-responsive alarm BITS to work again was to copy their existing alarm definitions into new alarm definitions. When this was done the new alarm definition would work, albeit in most cases only for a limited number of days. This behavior also followed the project when it was copied from the server and run on the engineering laptop.
We spent much of the morning on the phone with Rockwell Tech Support, and tried many different product software patches and settings, but nothing we tried resolved the issue. It was at this point I recommended we move the FTAE server into the same area as the RSLinx Enterprise server. It was a stretch to be sure, as I could find no documentation stating this is how the system should be designed. In fact, I found many examples of FTAE in being located it's own area. But as soon as we made this change all the alarms which previously had stop working began to work.
If you've run into a similar problem, or can add some insight to the above situation, please use the below “post a comment or question” link to add your comments to this article.
Click HERE to scroll down to view or leave comments