We are on 8.1 and looking forward to using the new workstation feature for an operator console application. The operator console displays some views that are inherited from the MES application, at least that was the idea. After getting the ‘inheritable projects are not runnable as stand-alone projects’, we’re now re-considering our architecture.
The MES Application needs to be runnable and in turn inherits from the global project. It doesn’t make sense to us to move all our views into the global project, that project solely contains scripts, named queries and style classes to drive standardization across all projects, and the idea of the MES project was to be the store for MES specific views that in turn we want to share with the operator console application.
Is there a reason why inheritable projects cannot also be runnable?
I suppose the easy answer is because that’s how we designed it. Inheritable projects are like abstract classes - you can’t have an instance of an abstract class, only an instance of a concrete subclass.
Thanks for the quick response Kevin. That looks like how we’ll have to setup the projects. Problem with so many projects is the need to have so many designers open to do development, but understood, thanks.
Looking back, in 7.x days, with a single designer I could edit global resources and main project. Ended up moving nearly all scripts to global so that they could be accessed by tags and gateway events as well as templates and windows.
With 8.0, the upgrade automatically generated global project and now the number of designers needed to be open went to 2 (3 if any sepasoft modules were installed due to the MES Gateway project).
Now with 8.1 workstation feature, we see the benefit of having separate projects rather than dynamically controlling navigation, but if we can’t inherit from a project that we also want to be runnable, then nearly everything (views, templates etc.) has to move to the global project and the depth of our projects (for inheritance) is never more than 2 levels.
And this is what we’ll do I think. I currently run into the issue where I make a change in the global project, save, then click the refresh button (merge any new changes on the gateway into the open project) in the runnable project, only to find that the view or window is still referencing a cached instance of the old global script function. Closing the window/view and re-opening it will fix this, but I’ve spent a bit of time debugging an issue that I had already fixed in the global project. For this reason alone, I don’t think I want to have multiple designers open for multiple levels of projects, saving parts in each and hoping the changes make it down to the only runnable project at the end.
Wow. I have long advocated not doing this, except for the most generic and well-tested scripts. For the simple reason that edits to shared (and now inherited) scripts restarts all projects (or all inheriting projects). Very disruptive. 8.x improved the situation greatly by making tag events point at a global scripting project that doesn't have to share with other projects. You still need to keep the project scripts at the root of the inheritance tree generic and well-tested so you don't edit them all the time. Keep scripts and resources in leaf projects until you actually need to share them, and always keep them in the leaf project for on-going development. Push resources up the hierarchy when they are stable. Copy resources to the leaf for further development and testing and push back when done.
Keeping multiple designers open in v8+ is a sign of poor script/resource management, not a flaw in Ignition. IMNSHO.
It's not really a global scripting project if it isn't shared with other projects. It's the only way I know of being able to access the same script libraries from a project or a tag. I'd ideally like to only have one designer open for ease of use, didn't realize it's also bad form on my part. I concur with it being disruptive, but we always do development on a dev server, never in production.
BTW, it is called the "global scripting project" because it is the scripting project for global objects. That is, objects that "live" outside all projects. It is not the global project for all scripting, though it can be set that way and defaults to that for 7.9 upgrades.
That’s a way, although I prefer tag change event scripts defined in a UDT. that way I don’t have to remember to add the tag path in the Gateway event script each time I create a new UDT instance and sometimes that is done dynamically.
Perhaps the next logical evolution for Ignition is to have a tabbed designer with multiple projects open;)
