Hi everyone,
I have a question regarding the efficiency of using Groov View IO tags vs variable tags on the Epic. I have often been using IO tags directly in my Groov View projects, in an effort to keep things simple. For some situations I will instead assign Groov View tags to elements of a number table and run that through the strategy to control outputs with a pointer table. Does either one of these methods have advantages over the other?
I don’t think groov View can do table block (bulk) read / writes, but lets ping @Jonathan_Fischer just to be sure.
If this is the case, then I think going to the IO tags would be the most efficient.
But more to the point, how many screens and tags are we talking about such that you are thinking about how to connect the tags to those screens?
I’d be more mindful of the size of the screens—i.e., the number of tags on any / each screen and the total number of trends—before I’d be worried about the tag connection path.
I’m not thinking about bulk read/write from Groov View, more wondering if either case puts more demand on the Epic Specifically. I recently read a post discussing how Pac Display interacted with the SnapPAC IO and I was wondering if the concept applied to the Epic. If I understood it correctly, it was more efficient to pass the values of, say, a HDD module into a table and reading those values to Pac Display. It got me wondering if having my HMI polling the IO rack instead of variable would bog things down.
To answer your question, some pages have a fair number of tags. Its not uncommon for a page to have over 100 tags, with most referencing table elements, some to digital outputs, and some to digital inputs. There is often between 5 and 10 pages like this in a project
I guess my question is coming from a place of wanting to understand best practices when it come to planning out my Groov View and Pac Control projects.
Thats correct, PAC Display will more efficiently pull in a full table of data via its OPCUA scanner.
groov View uses a totally different scanner.
I’m working on re-writing the ‘Best Practices’ guide, let me check what it suggests…
This is what’s in the ‘Best Practices / Optimization’ guide currently (I reserve the right to change this since it’s a document that is under heavy editing).
The Opto 22 Controller device can be used to scan all tags, including I/O tags, via the PAC control engine’s default host task (TCP port 22001). But as with other host software, scanning I/O tags through the host port can slow performance significantly. Instead use the follow method to optimize communications with the controller, I/O and groov View:
- Add an Opto 22 I/O Unit device to your groov View project and configure the gadgets to use the I.O Unit device tags. With this option, groov View scans the I/O tags directly from the I/O unit (UDP on port 2001), which improves performance. It is common to have both Opto 22 Controller and I/O Unit devices configured in a project.
I’m just not sure, since on EPIC everything is localhost, how much of a difference using two different ports and TCP vs. UDP would actually make without digging into things a bit more.
Ah, I was wondering what the difference was between those two methods! I have always been going through the Opto 22 Controller, as all the variables are there too. I’m going to have to try that out. Thanks!
The same advice still applies. It’s a little bit more efficient to scan I/O tags directly than to go through the Opto 22 Controller, for two reasons:
groov View <--> Opto 22 Controller <--> I/O Unit, it’s just groov View <--> I/O UnitOur product support team has been asking me to automatically promote Opto 22 Controller I/O reads to direct I/O reads for several years (as I understand it, that’s what PAC Display does), but with just the idb.txt file that we use to keep tags up to date I don’t have the information necessary to derive the proper memory map addresses.