Groov EPIC 3.4.0 Firmware released

Greetings Opto Forum Fans.
We have yet another tasty EPIC Firmware release for you to sink your teeth into and push your data in more ways than ever.
The big news with this release is the addition of an OPC UA server, so you can now ingest all your EPIC PAC Control tags to your existing SCADA systems via that very popular protocol…. As usual, that is just scratching the surface, so let’s bullet point our way through some of the highlights.

EPIC Firmware
New Features

  • Data Services. OPC-UA server, multi MQTT broker, SNMP I/O options.
  • Updated Ignition, Ignition EDGE and module versions.
  • Security updates and patches. (Linux Kernel and library packages)
  • Updated root certificates in the store.
  • Re-name a few groov Manage menu items.
  • Update Node-RED version to 2.2.2 (See Terry’s Blog/Forum).
  • Add groov View management/status screen in groov Manage.
  • Add ‘Make Public’ option to MMP scratch pad area.
  • Add option to download all status and configuration files in one download (mostly done for the Opto22 Support Group - but handy for keeping a record of what any given EPIC is running).
  • Add option to send MQTT Sparkplug alias or tagname.
  • More information added to the ‘About’ page in groov Manage.
  • More information added to the Web Server Certificate page.
  • Add I/O Diagnostics page in groov Manage.
  • PAC Control email enhancements - add ‘From’ and ‘Importance’.
  • On PR1 hardware, when running Ignition, its Java memory allocation is bumped to 320Mb
  • On PR2 hardware, when running Ignition, its Java memory allocation is bumped to 1024Mb

Bug Fixes.

  • FTP duplicate data and ‘dir’, ‘get’, ‘del’, ‘appe’ command fixes.
  • Improve Node-RED status screen in groov Manage when Node-RED is busy.
  • Network port stability improvements.

groov View 4.4
Build Mode / Editor Improvements

  • Added rulers and layout guides, accessed from the View menu. Add viewport grid size data in view mode to help you know your custom screen size.
  • Pasting or duplicating gadgets improvements.
  • Z-ordering in general got a refresh.
  • The tag browser has been given a facelift.

View Mode Improvements

  • Folder based Page menu option can be enabled in Project Settings.
  • You can now hide the Events page for Kiosk users, and a Back button was added to the Events page for those users who are running without any browser UI visible. (for example, on the PRx touchscreen)
  • Text Box Input gadgets now support an option to hide the entered text (ie, ***** mode).

Other Bug Fixes / Notes:

  • #89845 - A resource leak was identified in the Video Gadget image proxy service, which could lead to the server becoming unresponsive over time.
  • #90109 - It was possible for Events to get into a broken state, preventing you from editing them.
  • Log4J has been removed from groov View’s server and replaced with Logback.

groov View 4.4 will be the last major release to support:

  • GROOV-AT1
  • GROOV-AR1
  • Internet Explorer in Build mode
  • Microsoft Edge prior to version 79 in Build Mode

Ok, that’s the overview for this update.

The only other thing I’d like to mention is that due to the global supply chain issues we had to make the choice between shipping products with a firmware tweak, or not shipping products at all. Obviously, we went with the former.
So what’s the tweak? Some EPIC hardware will have different chips and those that do will have this 3.4.0 release as their minimum installable firmware version. You will be able to see that clearly in groov Manage about page, so it won’t be a mystery what the lowest version that can be installed at any point. We also block installing lower versions so you won’t waste your time in that regard either. In other words, we have tried to make it as seamless as possible.
The performance is exactly the same, just the firmware ‘drivers’ are different… so no super charged EPIC processors… yet……

As usual, hit up manage.groov.com to download the latest firmware for your PR1 or PR2.
(And yes, we are working on the 3.4 update for the RIO family).

5 Likes

Thanks for the rundown Ben. There are some great upgrades in this release. Can’t wait to get into it.

Could you provide the link to Terry’s Blog/Forum post? I did not see it here.

I beat the team it seems.
His blog has not gone live yet… Im sure @torchard will post a link here when it does.

1 Like

:heart_eyes: Thanks to all the OptoTeam for pulling another rabbit out of the hat. groov-EPIC just keeps on getting better!

5 Likes

So far looks like this will be a great addition. I am trying to connect it now, actually got it connected using no encryption and anonymous connection. Haven’t check yet to see if tag groups work, but I noticed that in groov man it apparently does not let you connect more than one controller at a time…at least you do not get to add another controller.
In my layout, currently have Epic running pac control, and another R2 located on same network.
How do I add another “remote” Pac Controller?
Remote as opposed the Epic which the driver refers to.

Or is the intent to add Edge at the additional Pac Controller in order to have an OPCUA connection?

If you need any of the R2 I/O, add it as a generic MMP to the EPIC.
If you need any of the R2 tags, move them into the EPIC scratchpad and make them public.

Either way, you have to put the R2 data into the public areas of the EPIC, you can’t configure / add another controller on the EPIC for the OPCUA server to expose.

I have a NUC running the HMI at each well site, so in this case, the hmi will be running from remotely on this site, but the Edge package would allow me to have store and forward as well as OPCUA to the R2 controller.
Therefore, if I am going to do it right, is the Edge package from Opto capable of being run on windows, or do I need to buy it from Ignition?

I just got to thinking about this further, it I use an Edge package on a windows machine locally, will the pac driver that comes with it, provide full functionality such as tag browsing and tag groups?

Ok, sorry for thinking out loud, but the OPCUA sever you released, does it allow an additional R2 to connect along with the Epic, or is the local controller referring to the Epic running Pac?

There is a bit to unpack here, but I will try and give a better overall view of the additions this firmware brings.

Ignition Edge on EPIC is the same as Ignition Edge as sold by Inductive, it just, for the price, includes the two Cirrus Link modules, MQTT Transmission and an Opto 22 SNAP PAC / EPIC driver.

If you want to run Edge on your NUCs, then you will need to buy (from Inductive Automation) Edge and the Snap/EPIC driver and you should be up and running.
This refers to your comment ‘is the Edge package from Opto capable of being run on Windows’… Opto generally does not sell or provide an ‘Edge package’ beyond whats included in the EPIC/RIO firmware. Its the same package you or anyone else would download from Inductive Automation… But yes, Ignition Edge is cross platform. It will run on Windows, Linux and Mac.

Your next post is also addressed in my first comment there. Edge on EPIC does come with the Opto 22 SNAP PAC / EPIC driver, you will need to add this to your Windows install to be able to get the tags out of the R2 on site.

Lastly, unlike Ignition Edge, our OPC UA server cant be ‘un-bolted’ from the EPIC firmware and run on another computer, its a core part of the EPIC firmware.
Thus your last comment is correct ‘is the local controller referring to the EPIC’… Yes, the new OPC UA only works with PAC Control running locally on the EPIC.

Here is how it was summed up internally here at Opto HQ:

The new groov EPIC OPC UA Server in 3.4 only works with PAC Control and groov I/O and provides the following:

  • Exposing PAC Control strategy variables and I/O via OPC UA
  • Exposing I/O values and Scratchpad areas (OptoMMP) via OPC UA

In short, the new OPC UA Server only works with Opto 22 software/hardware, not 3rd party devices or other software running on an EPIC.

My closing comment is this: with your mention of remote sites and wanting store and forward, it sounds like the perfect application for MQTT SparkplugB, not an old poll / response protocol.

Ok so then what you’re telling me is the only way to get around using the partial Cirrus driver is to pitch the R series controllers you have, and replace them with an Epic. Yes, my other option is to add an Epic and use the R2 as a brain, a cleaner solution than most I have, but really, the problem here is all the if ands and buts I find out about after I’m in the middle of the job. This means that any change I make here is coming out of my pocket.
Going forward I do hope you are planning on revamping the Cirrus driver, or even better yet, make UA version of the OPCDA server Opto already has. We do not expect it for free, make it a paid option.
This is something we have been waiting for since UA came out.
Don’t get me wrong, it is nice that Opto has provided an OPC UA server here, but a server implies that it is going to serve multiple devices, not essentially one device.
This is a perfect example where I would rather add the cost of a OPCUA server, versus replacing the R2 with an Epic. What if I had 10 R2’s out there, and one or two Epics? Would not a paid for server make more sense for me or my customer than having to add yet another 10 pieces to the puzzle?

Has any schedule to add OPCUA Client in EPIC?

@Edmund EPIC has OPC-UA client functionality already. It is depending for what purpose you need it.

Perhaps you can specify a bit more what you need the OPC-Client feature for.

1 Like

@Barrett If you are looking for an OPC-UA Server for PC install and PAC Control based Opto 22 devices, it is available from Kepware: Opto 22 Ethernet Driver | OPC Server | Kepware

Thanks Gerhard, but I only use view if I have to, I have heard over the years that Kepware is lousy, I’ll never use Codesys, and yes you get a client on Edge, but it is the Cirrus client that does not support multiple polling rates and does not support tag groups in Ignition. I bought the Cirrus driver from Inductive but was not happy. Yes it does poll, at one rate, you have to go through and individually make public each and every tag you need to use, so my question is, why bother with tag browsing? The whole point of tag browsing is to select the points you want, in Ignition, then put them in tag groups based on poll rate or other considerations. If you use the Cirrus driver, the only way you can utilize tag browsing is to set all tags in Pac to public, then browse the tags in Ignition, the only problem is that you still poll all the tags, and at one rate. If they’re going to supply a client driver, then actually supply one that is fully compliant.

That’s NOT what I said and I cant find anything like that in my posts in this tread.

Since you can find ideas from unmentioned options, have you considered running Node-RED on the NUC at each site?
That would afford some interesting options you might find helpful.

I have just had this wierd thought of Barrett unwrapping all of his presents on Christmas morning and promptly dumping them in the bin as “not fit for purpose”. Perhaps we shouldn’t shoot the piano player just yet, this firmware revision has only been out 72 hours and there is still a lot to learn here. :rofl:

3 Likes

I apologize if I put words in your mouth. That was not the intent. I am just trying to figure out what actually works and what doesn’t. Its kinda like getting that toy for Christmas and having no idea what it is supposed to do…
If the direction to go that Opto has been pushing is MQTT, and it will actually do what is advertised and it works correctly in Ignition, then I’ll be fine with that.
At this point, I am not convinced it will work as expected in Ignition based on the results I got with the Cirrus driver.
I also see that there are more than one version of the Cirrus driver, one that provides MQTT and the one I bought from Inductive. Which one is provided in the Edge Package from Opto?
As far as Node Red, I think it is interesting stuff, but do not feel comfortable using it generally. I was able to get it working ok for the Ping utility. Now I know the millennials all think its great, but of course, they’re aliens as you know…
In as far as the new fw, I think it’s great with one exception, it should have allowed for multiple clients or a full fledged server would be a paid for option. I realize you may have marketing reasons for this, but like I said, I think an OPCUA server is now considered a basic tool for any control system these days.

What is wrong with Codesys? I use it for every project and it provides a OPC-UA server. You just have to either select the vars that you want to publish under symbol management or just write a symbol attribute above the var name in the variable decoration. It seems very easy an efficient.

Heheh, I’m glad to be old enough to be considered a millennial… It’s a tool. You can do some amazing stuff with it, it has some strengths, it has some shortcomings, just like PAC software, just like any software.
I’m not saying it will solve your issues in this specific case, but I think it might be worth a second or third chance.