FTView 5.0, a Real Headache

Hi:

I was working with FTView 5.0 and Historian 2.0, server/client application, and the continuous bugs an errors makes me sick. Here is a list of some of them:

- When you drag a pop-up display (On Top display), the background screen flashes.

- The alarms (FTAE) sometimes disconnect from Server, with no reason.

-The alarm banner can’t show the alarms sorted by event (time and date of the trigger), for example to show the last alarm ocurred, like RSView32.

-Sometimes in the activity bar appears the message “Server is running in grace mode”, although the licenses are installed correctly in server (Server and RSLinx Enterprise).

-The TrendX control doesn’t works correctly reading data from FT Historian. It hangs when tou try to navigate in the X axis (time). Also, the ActiveX doesn’t show the real time data value (in the legend in bottom). Also it hangs when you try to read more than 15 or 24 hours from a datalog.

- Another error from TrendX (don’t care where is reading data from). When the display is opened, the last lapse of time shows wrong in the pens, it seems like the data in that period of time doesn’t exist and the graphic try to interpolate that space. If you open again the display, the previous error lapse shows correct, but the new last lapse shows with error, and so on. The error only occurs in the last lapse of time, from the end of X axis to 1 or 2 minutes backward, depending of the scale used.

-Sometimes, when you execute the display command, the display doesn’t appears, although in the activity bar the command shows executed. With this, the client application state in a grey background without a display and you have to apply the classic Ctrl.+alt-supr to exit to Windows and then restart the client.

-Sometimes, the animation color of a object (red for 0 and green for 1) is not reflected in the client display, although the bit in ControlLogix has toggled. You have to close and open the display to see the change. This happens random and is very problematic because you don’t know the real state of the tag. For example you start a motor and the motor graphic continues in red, but in real the motor is running and the running bit in Clgx is in 1.

- The tooltip text in the objects that references global objects sometimes works and sometimes no. They looks flashing and you can’t read the text.

- When you copy and paste and element (for example a button) from one display to another, an error appears. You have to make with drag&drop, although sometimes this action makes the program crash and appears the Windows errors report.

- When you right click “add component to application” to add a display from another application, with the same language even, then all the texts of the added display appears with ?

I don’t remember more bugs for the moment, but I have to say that any of this errors was corrected with the patches from Rockwell.

I hope that FTView 5.1 version and FTHistorian 2.1 might be released soon. I'm can't downgrade to RSView Supervisory 4.0, because I understand that the displays are not compatible.

If anyone knows how to correct some of this bugs, I would be very grateful.

Thanks

(almost a whisper)

Did you call Tech Support ?

You have a raft of problems, some of which point to a very badly damaged operating system and/or network installation. The only one I've actually heard about (and know the answer to) is the Activation error. Drag and Drop does not crash FTView Studio in any installation I've ever seen.

I really think you would be better off taking up this discussion with the support resources available to you locally and at RA in Cleveland and Vancouver.

We implemented the first release of FT Historian about four months ago on a project. We ran into a number of issues as well, but many of them are answered in different knowledgebase articles. The new historian is the PI historian, which is arguably one of the best in the industry, and with any third party integration, there will be strains in dealing with the multitude of different configurations possible. We were very pleased with the historian and the way Rockwell implemented it for its first pass (believe me, there have been worse...much worse) After reading a number of your issues, I think you can get most of them answered using TechConnect, but even better, search the knowledgebase. In addition, for future reference, anytime you do ANYTHING with a rockwell product, read the user's manual first and the "Tips and best practices" knowledgebase article, if one exists.

Here are some Knowledgebase articles to check out.
47410
48727

Specifically, you must update the trendx object on all of your clients to be able to trend the historian data, and you have to use the historian archive to choose the pens for historical data using the SMT (System Management Tools) interface in the new trendx object. The only thing that we were never able to accomplish, even with the expertise of a certified Microsoft and Cisco specialist, was to get the trend objects to read the historical data if the historian was placed in a DMZ behind a firewall. We ended up leaving the Historian Server in the process network and then shipping out a single port thread to a flat file for external data acquisition. After discussions with the product personnel, we are still attempting to finalize those issues for our next project.

Hopefully that helps. TechConnect on this issue is AWESOME!! There are only like three or four people there that are assigned to FTHistorian, and they are all top notch.

On the historian "Loading Historical Data...." This was rooted in network connectivity issues and the reverse DNS Lookup table. We had the EXACT same problems and found two issues.

1. All rockwell distributed components work better with deterministic network connections. You really should have all NICs forced to the same speed, i.e. 100M full or 1G full. Also be careful of the MDI/MDIX negotiation. On Cisco and an older Moxa managed switch, we had spurious disconnects that caused all sorts of issues in CPR7 FTView and with CPR9 FTView, even on the new TCP/IP Default comms in CPR9. I have a suspicion that if you find anything that doesn't match this, you may change it and miraculous things can happen. This may solve a number of things that you have encountered outside of the Historian issues.

2. We found a little known tidbit from rockwell techconnect, that requires that you have a Reverse DNS lookup table in the Domain Controller for each computer in your system. This will prevent historical data from being able to be served to the client.

Hopefully more help. As time permits, I will take a look at your other issues and try to share any useful information we have. Good Luck.