trends and VBA

This is a two part. I've been trying to teach myself instead of blindly asking questions. this forum has helped alot in my learning process and allowed me to make some very nice interfaces and reliable programs.

FactoryTalk view SE
Part 1: (should be the short one).

The user at runtime likes to move his trend view lines around a bit as to see information more clearly. However when he closes out of a display, all changes are reset back to the original settings I put in when I made the display the next time he reopens it.

Is there a deeper setting I've missed or have the trend graphs never saved?

Part 2:

I have a hidden display that is to run some VBA code I made to write certain tags values out to text files that I later send out through an email activex control.

When I run my test project locally it generates the text files properly and with the correct information first time every time. When I use the same code on his end in the same method no files are generated. No errors are generated, the interface just continues running as if nothing ever happened.

Any help, as always, is greatly appreciated!

Not sure I can help at all with the first part of your question.

Are your scripts event triggered or do they run continuously? The scripting engines are, historically, single threaded and if another script is running then it will not run anything else. I once incorporated some code for socket comms to an RsView32 SCADA but found that nothing else worked so had to put the socket comms in a separate VB app and used DDE to transfer the data. Just a thought.

Nick

The trends are never saved by default. FTView makes anything that should be simple ridiculously complex, and generally breaks something in the process. You can let your users explicitly save a template from the trend property pages, but that is a pain.

1) Open up the display with your trend.
2) Right click on the trend, select "Property Panel", Make Sure that "Expose to VBA" is set to "VBA Control" and make note of the (Name) property.
3) Save the display.
4) Open up the VBA editor for your trend display window.
5) Switch to the window, since it opens behind everything else.
6) Menu bar, Tools, References - Make sure at least the following are ticked:
Visual Basic for Applications
RSView Display Client Object Model
OLE Automation
RSView Display Client Object model (yes, there are two with the same name)
Rockwell Software TrendX

7) Now, assuming that your trend is named "Trend", add the following code in VBA:


8) Save the VBA, and try it on a live client.

-----------------------------------------------------
Part 2 of the question:
Remember that VBA in FTView is only run in the client. Running it with "Test Window" doesn't work well. If you are actually running the client and it works on your end:

Make sure the window with the code is not closed. I run my resident VBA windows with the /B and /ZA switches to keep them in the background and always updating.

Make sure there are no hard-coded paths that might be missing on the target system.

Create a client with the Debugging option, and step through the VBA on the actual runtime enviornment.

In FTView, the VBA does not run continuously, it is only triggered by events. You must fire some kind of event in order to process code, are you doing that? For my hidden monster VBA window I have a bunch of integer fields scattered around on it. If the PLC changes any of them, it triggers the associated code.

Sorry you too are stuck with FTView.

Ok, I really like that, I didn't know about those VBA functions for trends, I'll definitely give those a shot.

For the vba script, it is triggered on a hidden display's animation start and is my only VBA script. I have a 20 second delay before the meat of the script runs as my tags update every 10 seconds. I wanted to be absolutely sure it had placed a value in appropriate area. It only runs three times a day with hours between runs based off of an event triggering a macro that opens the display in the background based on the time of day (or my manual triggering of the display as an exception as below).

For giggles, on his machine I made my own display key so that I could manually trigger the display "on top" in case it was because it was being run in the background, but keeping it on top made no difference. I would be satisfied if it threw an error. That would be something I could research. It is difficult to work with nothing.

On my end the script actually ran fine both in a test window, and actually running the test client.

I have two separate projects, an experimental project where I teach myself new methods and test them before implementation, then the clients actual application. on my experimentation project it created my text files no matter how i ran it.

Just doesn't wanna run on his system and its making my head tilt. I do have three hard coded paths to C:\reports\<textfilenamehere1-3.txt> but I did make that directory even being sure to keep the cases correct.

Eh factorytalk is finicky, but it is the first I've ever used. Maybe it's better to start with a difficult mistress. She'll teach you to appreciate the rest!

Are you actually using the /ZA switch?
And.... in the display settings itself, do you have it ticked off to "Cache after Displaying", "Always Updating" ?

If you don't have both of those settings, and it doesn't have focus, it will probably ignore anything on it.

Also, using a loop in VBA to keep things chugging along is an exceptionally bad idea. VBA is built on a single-threaded apartment model, so if you have a loop running watching the time, it will ignore most everything else.

Update:

Got around to trying the trend.loadtemplate() command, looks like it works a charm. We are testing it on a smaller display that if it gets messed up it wont mean much.

The VBA code for the reports doesn't run in a loop, I actually have the event listener watching the time and when we reach a specified time it opens the display, gives it 5 minutes to do it's thing (only takes around 22 seconds including delays) then closes the display.

Worst come to worst I may just have it watch the system/minutes tag and begin running the vba code whenever the tag equals 00 or 30 with the /b /za flags. Akin to what you do with the numeric values offscreen.

Ok so loading the templates via vba code does work, however everytime it loads the template it reverts the tags model in the pen menu back to live data instead of setting it to the log source.

It is checked to be saved and i even created a manually saved template for it to load that had the pen set to my test log, it reverted. any clues?

It does actually read my data log, I just have to delete and readd the pen from a datalog during runtime to get it to show thanks to that reversion on the template....i may just get with the customer to "hardcode" the min and max values to format his display...this is a huge oversight on rockwells part.

If you have models checked in the template area and you tell it to save it, you expect it to save it. Not just ignore it and blank it out or throw it to a live model.

I've never seen that problem, but that doesn't mean that it doesn't exist.

Are all of your pens actually defined/included in the trend? Or do they manually add/delete pens at runtime?

I always put all tags on the trend, set the limits, colors, etc. Those remain persistent, but I only toggle the visibility field of each individual pen.

The workaround apparently is to tell it to not save the model....sigh.

yeah they are all defined and included.

The vba way of trend saving saves everything, which pens i have, their min/max settings line width, data type, etc etc. it is on nearly all accounts perfect.

With exception to saving the pen model.

I found what i have to do, is in the dev environment, save an initial template with the pen model unchecked in the save options. once i do that it will load and save just fine for my purposes. If i had to actually change the model by loading a template i'd be screwed.