Whilst I compile my response you might answer a lot of questions with one answer - how close will the tool sit with AF and AF extensibility? If the tool concentrates on the presentation and AF deals with the data retrieval, I can see a tool with no VBA requirements (although extending ProcessBook with VBA keeps me far too busy right now ). For example, all time issues would be catered for by event frames, DataSets/ODBC etc all catered for by AF Data References.
I think no matter how good the new tool is, convincing customers to move away from ProcessBook is going to be the hardest part. What ever happens, I would say renaming the tool too far away from "PI" or "ProcessBook" wouldn't work (aka "Rt") - but then again I don't work in marketing.
Hey Rhys! We missed you at vCampus Live! this year, although you had the best of reasons.
As far as where the data would come from for a display, the Asset Framework will play as big a role as ever. The new tool would support the built-in capabilities and data that are part of the PI system now, along with whatever advances we accomplish. And, for the most part, folks would be able to directly re-use the content they've developed with PI ProcessBook, sans the VBA part. Ergo, my question(s).
Generally, our strategy is to make upgrading to whatever the new tool is (something PI, but I don't know yet if it will be called ProcessBook) easier than upgrading an existing installation of ProcessBook on client computers, so that the benefits of using a new tool would far outweigh the reluctance to change. How's that for marketing spin?
I look forward to your well-considered response.
So long as the tool has some form of automation, I don't really mind.
I have used VBA for the following purposes:
- Little scripts that implement 'failings' in Processbook, like the lack of a command to make multiple objects the same width or height.
- Tools to apply company or industry standards, like colours and fonts, to selected objects
- Tools to provide specific 'application' functionality
One of the benefits of VBA is that customers do not have to go through a separate deployment to put a VBA application onto the client machines. For large projects, this is not normally an issue so some method of access via .NET and Visual Studio would be fine but for small usability enhancements it can be quite handy to be able to 'knock up' a little script without needing a separate IDE and for that script to be available just by opening a display.
Unless the new tool has an almost identical object model to Processbook then I doubt that many VBA scripts could be easily ported, so I think I would rather see a clean break and the lack of any scripting language at all, although painful, would probably not be the end of the world.
Thanks for your input, Alistair!
I suppose my main worry is the number of customers who will need to re-implement those "little fixes" that are currently possible within PI ProcessBook, in particular the "specific 'application' functionality". If the community here thinks that a "clean break" is an acceptable path forward, that would be quite re-assuring.
It seems likely that the "tools to apply company or industry standard" fonts and colors would be fairly straightforward to provide, and something we're considering anyway.
Likewise, the sorts of layout tools you describe, such as "make objects the same width or height," are a consideration and the difficulty of laying out a ProcessBook display is a well-known issue.
I'd welcome the opportunity to hear from others of you on just how "painful" if not "the end of the world" such a clean break might be.
For me (and the company) the dropping of VBA in ProcesBook isn't a big issue. We do have some VBA but nothing serious.
Daft question but does our friend Microsoft have a suggestion? They face a far bigger issue with Excel. Does OSI know how they plan to handle that? This could provide OSI will some ideas; although I have the feeling that MS does really know themselves.
Thanks for your response, Michael. That's a re-assuring answer.
As for Microsoft, we had explored some years ago a switch to VSTA, which they were pushing pretty hard at the time. What we learned was that there was no upgrade path from VBA scripts and they were recommending a side-by-side deployment of both VSTA and VBA. We said no thanks. We note that Microsoft Office 2010 continues to ship the VBA IDE....
Other than the VSTA/VBA path, Microsoft seems much more focused on the implementations of .NET in WPF and Silverlight. Their stated goals are to make WPF and Silverlight so closely bound, that you can write for one and deploy with the other, also including the Windows 7 phone platform. While it doesn't appear that they are quite there yet, there does seem to be movement in that direction from what we see them working on and the work we are doing now with these technologies. Fortunately, our entrenched partner status with Microsoft provides us with channels for both understanding their directions and providing feedback on their work.
We've certainly seen cases in the past where Microsoft has abandoned things and sort of started over. While they can do that without too much fear of backlash from their customer base, OSIsoft feels a little differently about trying to move our customers forward in a helpful way. However, this is one area where we can't see a straightforward migration path, so we're looking at how to ease the burden of a major shift in how customization is made available.
What wie develop in VBA are mostly scripts which are replacing Tags (More a Matrix Kind of view.)
Must of the stuff we do in plugins (main reason ist, because we can't have a master makro which applies to all processbook - Files)
Stuff we did or which are on our todo list:
* Matrix View of the Data (which I hope i can provide to the community in the next couple of days)
* Navigation Panel (combined for the files and the data
* Directly generating Configurations files for 3rd Party programms to analzice the data
* Directly generating Datalink enabled Excel File out of the processbook
* Enhanced cursor tools...
* Enhanced analyzing tools..
I think what would be important in my point of view is the a create plugins, because there will always be the need for some features, which aren't on the priority list of osisoft. (or als an alternative a customization abbility like SAP)
Before we switched to osisoft we also thought about developing the GUI by ourself. Using WPF and the Microsoft Expression it is very to create processbooks like applications (especally most of the features are already standard (zooming, colors,.....) and scripting is also very easy possible.
My developer heart always says throw processbook away you can do it better, just use WPF and get some usefull symbol and plugins that brings much more "value" to our users ... my projectmanager heart says use a finished product ... because of this I'm in a constant inner pain...
There are various companies which have the same approach (just google for scada and wpf).
I think with drawing processbooks pictures there can't really be much differentiation to competitors ( I see WPF and Microsoft Expression as a kind of standard or minimal requirements) the dataintegration, the attributes, the scripting is finished and ready to use.
The one thing you can really differentiate are good symbols which are tight integrated to pi (trend, spider chart, sqc,....) and a userfriendly surrounding (creating the trends, choosing the time., export, integration with datalink,... and so )
Thats also the question how would you differentiate with your new product from the rest of the market.... ?
Be able to script some stuff is one way
Thanks for the response, Wolfgang!
I hear what you're saying about the internal conflict between customization and ready-made. We face that challenge as well (where there are things we "could" do, but which would probably not be a complete solution for more than a few customers, we have to decide how we can provide enough functionality that folks like yourselves could take it to the finish line).
I agree about the ability to draw pictures being of nominal value by itself and that the real value of ProcessBook today is its tight integration with data. We'll keep our eyes on that particular prize, for sure.
I think Wolfgang needs some paracetemol for his inner pain I agree with pretty much everything he said in his post (as usual)...
If the next version really is a presentation layer on top of AF (with some new display object additions to the core of AF) then a lot of what is currently customised by VBA is not a worry (for me). One big demand at the moment is manual data entry from ProcessBook, which can be nicely executed via an add-in that uses AF (done). It would be nice though if this was just core of the product, especially if based on AF & AF's WIS.
I have a vision of Event Frames in the new tool too, have accessing to all the Event Frames for the connected server(s) and just dragging them on to a control or the display. Once an Event Frame is associated with a control you can expose the child or related Event Frames to quickly move the data to the various events with the click and drag of the mouse. This would be especially useful during abnormal events to analyse data to find causes. Anyway, I am sure you are already looking down this avenue (click once do more...).
I started to compile a list of all the VBA customisations that I have done over the years for ProcessBook, maybe it would be useful to post up when I finish it (some free time would be nice). Apart from manual entries, the most intensive VBA development I had in the past was a trending package in PB that did everything & much more than operators got on DCS. Would be better suited as an add-in now (or even it's own application), but it was one of those projects that started out small but snowballed in to a critical part of operations.
Thanks for the input, Rhys.
I would love to see your compiled list of VBA customizations (I don't know how others would feel, but perhaps it could be a source for further discussion around what the most important capabilities are). I understand it may take some time to compile that.
We've also heard the demand for manual input in the context of a number of our tools (PI ProcessBook, PI WebParts and PI DataLink among them). Some of us feel, though, that it's a slippery slope to build in manual data entry because you typically want to put that entry in the context of really important business rules. And that's where you start down the path of solution-building. We already have a product that is designed to address manual entry: PI Manual Logger. I'd certainly entertain further discussion on how to navigate the path between a product that serves as an interface to the PI Server (albeit, collecting data manually rather than through instrumentation) and the convenience of having the actual entry UI as part of another product that serves other purposes.
If I haven't said so yet, I appreciate everyone who's contributed to this discussion so far. Let's keep the dialog going!
Microsoft has "connect.microsoft.com" where every user can post feature requests and also vote for it => wouldn't this also be a good idea for osisoft.
The feature request and "real" roadmap plan is very intransparent.... or the "List from the techsupport - site" compared to the felt reality is very different...
I think it's already sort of been mentioned in an earlier post in this thread but I'd like to say again the ablity to manipulate PB objects programmitcially needs to be maintained in some form. Most of the major PI projects I am involved with require the development of PB graphics, sometimes in the 1000's and if there are some generic changes needed (for example, changing multi-state colours for all valves) as a result of a customer review etc, then being able to do that with VBA in PB is a life saver (I usually write the macro, make a new toolbar and then assign an icon to the macro. Select the object to be changed, click the icon - can literally make thousands of changes in a very short time this way).
I think most of the calculation and analysis requirements can be handled adequately between AF, PE's and datasets for most of the deployments I've come acrosss so far but I personally would be lost without VBA when developing graphics for my customers.
You mentioned a good point, a big weakness is now that you cannot make graphical templates (object based).
I like to define a default valve,... and so on for my company.
There was the possiblity with AF-Templates in Processbook, but this feature had a couple of bugs and also disappeared (because of sigmafine was sold)
I think to create templates (object oriented --- when you change the master all the the derived should change too ) whould be a very important features and in the most SCADA Systems it is state of the art.
To enforce "standard lookalike of the processbooks" through vba scripts isn't the best way... but at the moment i don't see a way around.
I've seen that template feature in many SCADA/HMI products as well as in most DCS's too.
I toyed with the idea of developing something like that for PB as an add-in but the more I thought about, the more complex it became and so it's on the back-burner for now and on my "someday/maybe" list.
Looks like we're stuck VBA scripts for now...
Templating of symbols was the idea I had in this community project where a future version would keep the symbols synchronised with the 'master'. At the moment I am struggling for time to work on it and wonder if I should given the nature of this thread, i.e. the next visualiation tool.
I, for one, am really enjoying the path this thread is taking. What I've been hoping for is to get this community involved in a discussion about where there is a need to build in better base functionality (the notion of templated symbols would be an excellent example of that), and where we really must provide some way to customize whatever product we build.
In the meantime, what I seem to be hearing from most of you is that moving existing scripted solutions forward is less important than providing a way to continue to provide the customizations that are possible now, where the features are NOT built in. Please weigh in if I'm misreading your feedback.
OSIsoft is listening with all ears! Keep the discussion going....
big weakness is now that you cannot make graphical templates (object based)
I would like to see the ability to manipulate AF element in the client; something along the lines of a plugin. You assign the dispay script to the AF element template and the clients would then load this "script" rather than the script being part of the display. My reasoning is that this would be far easier to maintain.
The danger is that the OSI client is not a SCADA and nor should it be a SCADA.
OSI would still need to maintain the ability to add "scripts" directly to the displays and the client application as a whole; these are useful.
Regarding calculations on the client side. I have found we don't do this a lot; we mostly build these calculations back into PE/Totalisers/ACE/AF. But it is useful to have a calculation capability on the client for mocking up displays and for users would don't have the rights to build calculation back into the servers.
I agree with the idea that:
1) We need extensibility
2) It does not has to be VBA or VBA compatible.
To me, it looks like .NET languages will become available as 'scripting languages' in the near future. The big issue now was the inability for .NET languages to evaluate code (on the fly). With the introduction of dynamics in .NET 4, and the possibility to eval code in .NET 4+, .NET programming languages will become a viable option to replace VBA scripts. (IronPython and IronRuby already do this, for C# there is Mono.Csharp as a 'compiler as a service')
I for one, would like to see a .NET language support (C#, IronPython) as the primary means of automation or 'scripting'.
Can you also provide a little feedback about whats going on in terms of davinci or next generation visualisation.
I know there was a kind of closed curtain prasentation at the last userconfernce in SF.
What is really the goal?
What is the focus, which decisions are already made.
Is there a way to get involved, and place feedback before the first release... (NDA? )
I'm not sure if there is another post or forum to ask for features for the new graphic tool. One of our employees came to us yesterday asking about how Process Book would handle multi touch. I have a tablet PC with Windows 7 that is multi touch and we're going to try loading Process Book onto it and see what happens. I'm assuming basic mouse functions will work fine but there won't be any advanced type things like rotation etc. It might be something to think about in your next graphic program.
Oops... you guys caught me napping! Geez, I take a day to spend some time with other customers and the posts come flooding in--guess I'll have to do that more often
I'll try to address the last few posts all together here, but if I miss something, feel free to call me on it.
We're using a codename for this brand new product because, frankly, we haven't come up with a product name for it yet (there's another discussion thread somewhere about our newer use of codenames for things that are still in the planning stages).
The intent of the first release of this product is to address the need to quickly build displays of data in an ad hoc fashion. As such, the sorts of features that are the focus of the product are searching capabilities and display components like tables, trends and gauges.
As such, this isn't a new display development tool intended to replace ProcessBook. It is intended to facilitate in-depth analysis of a problem that's been identified. No features are currently planned to support the use of images in any way.
While we charge toward a first release of this ad hoc analysis tool, we are also thinking about how to extend this offering to include the sorts of graphical displays that are possible now with PI ProcessBook. That's the motivation for this particular thread, where extending the platform on which DaVinci is being built is not going to support VBA and we're looking at the best way to provide the capabilities that VBA provides now in PI ProcessBook.
As I stated near the beginning of this thread, I'm expecting that the result will be some combination of built-in features that make some of the existing scripting unnecessary (in other words, cases where you've all worked hard to overcome the limitations of ProcessBook authoring features) and some means for extending the functionality of the product where the desired behaviors are specific to a solution or application, rather than central to how the product works.
So, there isn't a secret club for offering feedback on these products. That's what I'm asking you all for here. Really.
OK, switching gears here dramatically, PI ProcessBook is not designed to support touch screen interaction. When ProcessBook was first developed, touch screens were not a common element of the desktop assets our customers had. The newer products that we are working towards and discussing here have much more potential to lend themselves to supporting this type of interaction because they use newer technologies that have mechanisms for supporting this type of interface.
My (admittedly limited) understanding of these technologies is that touch interfaces (and multi-touch, in particular) is a separately defined set of behaviors within an application. What that suggests to me is that PI ProcessBook (as it exists today) will mostly ignore any attempts to manipulate it from a multi-touch device. Of course, I could be wrong there.
Keep it coming, folks! This is all good stuff here.
Hopefully you are still monitoring this thread - I have some guys just starting to look at adding some surveillance type capabilities on top of ProcessBook and WebParts.
I created a huge infrastructure to do this for a client many years ago, with multiple ACE applications doing the analytics and thousands on lines of VBA code to provide the front-end in ProcessBook. I talked to the team at the last DevCon - the only solution we could come up with would be to super-class code on top of the existing web-part - but nobody was going to give me the code :-)
For me the killer feature for surveillance is the need to provide data summarisation in the front-end, so that it is tied to the current time frame. Because we want to use a portal environment, my current team have been looking at whether we could use data-sets to do the summarisation. So far they have been unable to find any way to write a data-set which picks up the start and end time from the display. This might be a route which could facilitate the development of surveillance type capabilities without reliance on VBA.
Feel free to give me a shout if this is still an active topic.
It would be nice if OSI gave us something like Event Frame Relative Displays so all summaries would just be AF Attributes (e.g. Formula DR) using the time context of the assigned Event Frame. In fact, probably a project anyone could do via an add in or two.
Yes, this thread is still active and I continue to monitor it. Thank you for posting... the future of extensibility, and VBA in particular, is a major area of concern to me in moving our client products forward with newer technology.
I'd be interested in further discussing your need for dynamically time-boxed summary data in displays. I think Rhys may be pointing in the right direction with the notion of configuring things in the Asset Framework and I would generally believe that this approach would be more portable across various client products (you wouldn't need to ensure that you had datasets defined all over if you are just getting the formula from a central place like AF).
I'll be roping in other Product Managers for this particular discussion as it has broad applicability across the product line. I'm sure they'll chime in as appropriate.
Thanks again for re-invigorating this discussion.
@Mike. AF calculations that use the TimeRangeMethod do use the start and end time of the display to do their calculations. That AF functionality may be worth investigating if you haven't already.