FactoryTalk View SE datalogging

Thanks for your time.

I have added a new pen to a trend which works fine as long as you stay on the trend screen but resets when you navigate off the trend screen and back to it.

I am trying to log this tag as well and have added it to the datalog model, stopped all of the datalogs and restarted them with no errors, stopped the server and restarted it, and powered the pc down and back up to no avail.

All of the other pens on the trend log fine and all of the tags in that datalog model log fine.

It is using native SE logging and the new tag in the datalog appears to be setup the same as the other tags.

I keep getting the feeling that I am missing something obvious but for the life of me I can't think what it is.

FTView SE... The worst example of HMI software ever developed; Sorry you are stuck using that garbage, but even so... Try this:
Open up your trend display (in Studio, of course), right click on the display, and choose VBA Code. Add the following two snippets to the VBA code for the display:



That should persist changes made during runtime between display closings and openings.

Good luck.

I am no fan of FTView either but am stuck with what we have.

I added the pen in studio, sorry for being vague.
We consistently navigate the trend timeline, zoom in and out on certain parts of the process being logged.

Won't this code make those persistent until a restart of the client?

That would cause a lot of confusion to the operators.

Actually, I find it makes things generally easier, but I also put buttons at the bottom of the display with the trend to set it to default, set the time span at 1 minute, 2 minutes, 5 minutes, 30 minutes, 1 hour, 4 hours, and 8 hours, as well as some others.

You might be able to limit what is saved in the template by using VBA to turn off some of the saved attributes, but I haven't played around with that.

So just an update...I did finally figure out the obvious.

I added the pen to the trend in FT view studio to make sure it would see the tag data . After doing this I added it to the data log model, so apparently the trend never made a connection to the historical data log.

To fix I simply deleted the pen on the trend and saved the page. I then added the pen again and at runtime it was displaying historical data fine.

When you added the pen, did you select "Data Log Model" as the pen source or "Tag (Live Data)"?

Any RA guys in here?.. can you ****ing fixed this TREND issue .. database issue .. you make our lives very complicated with this supposed to be simple matter!..

Nigasai said:

Any RA guys in here?.. can you ****ing fixed this TREND issue .. database issue .. you make our lives very complicated with this supposed to be simple matter!..

Click to expand...

Simple answer... No.
We've been having datalog/trend issues since version 6, and numerous calls to Rockwell, and all the money for support yield nothing. Zip. No help, no fixes, just ticket numbers and no closures.

Dears,

sorry but i'm new here in this website, and i don't know how to post a new question....

i have FTView Server with 2 clients, i'm logging data every one hour to one access file but when checking the access file i find that the data logs 3 times every hour one at min 00 and 04 and 59.
the setting is periodically every one hour.

can anyone tell me why it's logging 3 times ????

Thank you

Apparently 8.1 has updated trends on, vantage point style ones apparently. We may be upgrading soon so I hope they have been

8.1 has not fixed the trending, if anything, it is broken worse than ever.

After literally years of trying to get a solution from the brain-dead "Software Engineers" at Rockwell, and constantly being told "That will be fixed in the next release" (Translation: We will either leave it completely alone, or break it some more because we are brain-dead idiots), I have started to dig into the crappy code they have myself.

Here is part of what I have found...

Datalog tags MUST be in the tag database.
Datalog tags MUST NOT be direct referenced. It writes these as the wrong datatypes.
MIXING tag types in a datalog can easily corrupt the data.

FTView SE likes to write things to a STRING type, even if they aren't. The work-around here is to Stop the datalog, Remove all tags from it, Save it, Close the dialog box, Re-open the box, Add in tags from the tag database only, and restart the datalog.

I seriously hate this product.

rdrast said:

I seriously hate this product.

Click to expand...

Ive noticed your dislike for it

rdrast said:

Datalog tags MUST be in the tag database.
Datalog tags MUST NOT be direct referenced. It writes these as the wrong datatypes.

Click to expand...

I am in the long process of upgrading to 8.1 (modifying a lot of older screens as i go) but i have been directly logging data and have not found any issues. So they're recommending to put them all in the tag db? Im at a routeco (UK distributor) event Tuesday so ill see what they say then

Ash

I've no doubt rdrast has had issues. And we all know his feelings toward FTV. But that is not everyone's experience.

HE is saying "Datalog tags MUST be in the tag database"
HE is saying "Datalog tags MUST NOT be direct referenced"

I've used direct tags without issue for ages. Never seen any issues. The solution to the OP problem was pretty obvious from the get go and was explained in post #5. Of course, that's easy to say, but I think sometimes we get clouded with our own experiences and maybe don't see the forest for the trees.



OG

Version 9.0 is supposed to have updated trending (from Vantagepoint) and a new recipe system.

I have 12 lines with FTView SE, and we migrated all up to 8.1 early this year, based on Rockwell's recommendation to "Fix" issues we have had with datalogs.
Every single one of them that used direct tags in the datalog failed to log the direct tags, usually immediately, but sometimes after a week. It didn't matter if they logs were going to SQL or to File Sets.

In tracking it down, somewhere in Version 8.x, they decided that the tag type information would be imported from the tag source. If you use the tag database, it imports the types correctly to the datalog. If you use a direct tag... correction, ADD a direct tag, it just treats it as a string. Existing datalogs would import correctly to 8.1, but make a change, and all direct tags become switched from say "Floating Point" to "String" types. They are dutifully logged in file sets, SQL also logs them, but in the string tables. Of course, the viewer doesn't read the string tables.

I spend more time debugging Rockwell "Software Updates" then I do actually working on my job.


Rockwell has (of course) no comment on the issue, except as mentioned above "Just wait, a whole Shiny New Datalog/Trending System is Coming Soon!!!" (And that happens to be stolen entirely from Wonderware, lock, stock, and barrel).