Ignition Designer in Groov

I see that you can get into Ignition Designer if you’re running Ignition Edge. Is that a fully functioning version of Designer? Can I use it to create a UI that I can use instead of Groov build?

I would answer that question myself but I can’t get my trial version of Ignition to work.


Yes. Its fully functional in all the limits that EDGE places on it (scripting is limited etc).
Yes. You can build a UI that you could use instead of groov.
Will take a look at your other issue hopefully sometime this morning.

Here is a link to what Ignition Edge can do: https://docs.inductiveautomation.com/display/DOC79/Ignition+Edge

The biggies: Only one client connection, no DB access at all, and no gateway scripts.

Is that true of the Groov implementation of Edge?

Just to throw my two cents in. The Panel UI functionality is not included in Ignition Edge for Groov. You would have to purchase it from Ignition and include it into the gateway license.

If you are an experienced Ignition Engineer planning on integrating Ignition Edge for groov into a total distributed Ignition architecture solution, then using the designer module to develop an operator interface is an interesting way to go, but again it’s advanced features are not for beginners and only come into play when used with main Ignition Servers.

Groov View, on the other hand is a simple to set up and implement solution that can connect directly to Opto22 Controllers, I/O and Modbus devices, and also connect to the Ignition Edge OPC-UA server embedded in groov-EDGE and groov-EPIC, to integrate PLCs and other industrial protocols. Its HTML5 interface runs on any web based client device including phones and tablets with little to no overhead and no client licenses. Groov View is included in the price of your groov device, which is probably one of the best reasons for using it.

My advice, unless you are an Ignition Pro, start with Groov View and explore its possibilities. Using groov data stores with Node-RED in groov VIEW opens up a powerful scripting language, just in case you were wondering why groov VIEW does not have one.

1 Like

Just to be clear, groov uses vanilla Ignition EDGE. We do not modify or limit or change it in anyway.
What ever limits Inductive have placed on EDGE will be the same in groov.
What ever features Inductive have included in EDGE will be the same in groov.

Thanks for the input. I’m pretty familiar with both the Groov and Ignition UI. The problem we have is the Groov UI lacks many of the features that come with Ignition and our implementation of Groov is REALLY slow. I was hoping I could use the UI I’m developing in Ignition as a Groov UI because it uses an Opto backend. However, it’s looking more and more like that’s a dead end. Most of our customers can’t afford to put an Ignition server at their site and there doesn’t seem to be an affordable client/server solution. The Edge client is so hamstrung that we can’t use it. Because we’re in the agriculture business where reliable Internet connectivity can be an issue, we need some kind of local client as a fallback.

Just for interest, why is your implementation of groov VIEW really slow? 3G connections quality or some other factor? While obviously not as fast as WiFi, limiting the page size to a reasonable quantity of points and complexity, I find groov VIEW performance to be quite reasonable over standard 3G lines.

If you have Internet problems, you might be interested in a clever router device that we are using in our remote site projects, the RUT950 from Teltonika

If your wired network is working properly, then it just acts as a 4 port switch & local Wifi AP point in the infrastructure. Connect your groov EDGE box and any connected devices and even a tablet /iPad through its WiFi.

But if the router detects it has lost internet access then it rolls over to use its inbuilt 3G/LTE router for an Internet connection. If correctly configured, the groov device will not notice the difference. It also includes dual SIM for 2 different operators, just in case one fails. Ah, and it even includes an MQTT broker, useful for the groov EPIC MQTT sparkplugB connector.

Teltonika RUT950

What is a reasonable quantity?

Can I have a 4 column table with 50 rows like in PAC Display and expect it to perform okay?

How long does it take to set that up in build?

Please, don’t take these somewhat rhetorical questions as being critical of your comments, as your comments and advice are much appreciated.

The speed issue has nothing to do with our Internet connection, we have this app in several different environments. The problem is the number of gadgets on a single page. We have a scheduling program which was actually written by a former Opto employee and the issue is the lack of single gadget which would solve our problem, that is a dropdown list. Without that we’re forced to iterate every hour and and every minute interval of every day in check boxes. It’s kludgy but it works. However on a single page it can take 2 or 3 seconds for the Groov to respond. That’s why I got excited about Ignition Edge, which I’m using for a current project, because it’s a real SCADA system like PAC Display. But like I said earlier, it’s so hamstrung as a UI that it’s useless for our application.

Phillip. I have set up a demo display for you showing real time data using 4 columns each with 11 rows on a groovbox display. It handles 1 second updates quite nicely.

Send me a private email on gmitchell @ optomation .es (remove the spaces) and I will send you the connection details, user account and password. The groovbox you will be connecting to is actually in Madrid, Spain, but it makes little difference!

You can then see for yourself realtime build time and response time using networked, Wifi and 3G connections from your different devices, also the differences between handling desktop display and mobile display. Typically update is about 1 second.

The problem with trying to fit 200 data values on the same screen is that the information on mobile displays is just not manageable, especially on mobile devices. My advice for clarity would be to cut down on the data on each page and use multiple pages.

For your information. the display page took me about an hour to set up. You can see realtime data changing in index[00] and read and write data to indexes [01] to [10], index[00] in addition to connecting to data in our SNAP Learning Center.

1 Like

Hi born2see.

It’s not so much the case that Opto22 can’t write the code to come up with the functionality you want, its the fact that it has to be pure HTML5 to run on any device and any browser. Most list control is orientating you to a specific web programming tool, platform or browser

Assuming that Opto22 are not going to come up with pulldown boxes anytime soon, maybe some thinking outside the box is required here. I agree that hundreds of grid gadgets that need selecting on or off in order to try and create a schedule program is not going to fit nicely into a groov display, but have you considered using the power of Node-RED to add the intelligence that you are looking for in groov and using groov DataStores to provide the connection between Node-RED and the groov operator display?

Don’t really know what your project consists of, but here is a nice scheduler in Node-RED that might meet your demands and with a bit of work in Node-RED javascript can be connected to be configured using groov VIEW groovDataStores or through PAC or EPIC controller data values

Node-RED does have some nice dashboard tools, including pull down select lists. Example in the below screenshot. Batch Selector > Formula1, Formula2, Formula3

Once you set up a Node-RED dashboard you can link it to a Page Navigator gadget in groov VIEW


Finally, don’t forget to include a page link in the Node-RED dashboard menu to lead you back to the safety of a groov VIEW page or you will be stuck in the depths of hell of Node-RED dashboard displays, which is not a very nice place to be!


Also, note that creating Node-RED dashboards is mainly used today as a form of medieval punishment for people who complain about groov VIEW capabilities !!!

I appreciate the effort you have gone through for the demonstration. I actually have a groov in service with about 120 values on a page - it is not a mobile interface and it is a manageable size for a PC or tablet. In this case the performance is just okay - when all the tags load, sometimes it needs to reloaded. This may be fixed in later firmware though.

Yes, that has been my experience as well, and every time you need make an edit, to add a “column” or move them around it takes just about that long too. Especially when you have to scroll down hundreds of points every single time to bind to a tag. These are the pain points I would like to see addressed. In PAC Display the find/replace and index offset commands help tremendously to speed up HMI creation - it would be nice to have something like that in groov.

Combo boxes/select tags have been around since the beginning of HTML. That is all that Dave is asking for.

Oh, can you right justify your floats please? Oh, and if you are thinking of a certain work around, I would like them to be red. :wink:

See the post by Johnathan regarding “auto text search on tag selection” under Groov forums.

This was probably one of my first issues…

Ahh, can’t search when the tree is built dynamically. Even if we could just edit the tag field directly in a text field (to change the index or whatever), instead of having to go through the tedious tag selector would be a huge improvement.

I’ve even gone as far as editing the groov SQLite database directly to get things done faster. This is not fun either, as a lot of the details that you would want to edit are in a text column that is in JSON format. :man_shrugging:

The problem is when you build the foundation at an angle…the walls will never be plumb…
Try building a decent size project, and the monotony of the tag system will put you to sleep.