Ok, so having messed with the EPIC for a bit, we figured we’d give CodeSys programming a shot. Specifically, I cobbled together a Structured Text program. Here’s my first impressions:
Codesys is a very comprehensive development system encompassing a dizzying array of vendors and platforms, which means that it’s complicated beyond imagination. It’s documentation is basic at best. What you’ll find for answers on the web is best described as a hot mess, and generally will just cost you days of searching without any clear answers.
My understanding from some of the Facebook posts and articles are that the Groov View will be able to access the information in a CodeSys program. However, I’ve been completely unable to find the first bit of information as to how. I’m thinking it’s by address, but I couldn’t tell you how to determine the address of the variables in the program. Any ideas from anyone?
On the whole, I’m thinking that the CodeSys support is great if you know the platform well already, or have a project on it already that you’d like to use with EPIC hardware. But if you’re starting fresh on a project, and either don’t use CodeSys already or are willing to learn something new, the Opto tools seem more straightforward and are better documented. The only thing we’d like to do that’s available in CodeSys but not Opto is Profinet… IF I can figure out how CodeSys does that- the rabbit hole on information about how to do that is deep indeed.
First up, thanks for your time putting this post together - very interesting and helpful to hear of your experience.
Yes, it is very comprehensive. Keep in mind that they have a USA office now and they provide some support.
Also, not sure if you knew, but we have basic training here; groov EPIC Training Series
You should be able to do this now. In groov Build, add a new device, an OPC-UA server.
‘localhost:4840’ is the address and port you want.
Once you do that, you should be able to walk your way down their tree and find your tags and you can connect them to groov Gadgets.
Note that you will need to tick the OPCUA box for each tag you want exposed. They are not ticked by default. (So I’m told).
Sounds like we need to add it to the docs sooner rather than latter…
That’s as I understand it as well. If you have had on the job training, or some official training, its a lot easier to get going.
Regarding the Profinet, not sure, will have to ask around.
To expand on what Beno said, you need to make sure have added the Symbol Configuration Object under your Application in the Device Tree, and select the tags you want exposed to the OPC-UA server there. Then you can use the localhost:4840 to pull those tags into groov Build. It can be kind of tricky to find your tags in groov Build, Here is a screenshot of where you would need to navigate to:
If you want further information on the Profinet module, and how you can configure it, you can use the online help from Codesys, it is very thorough: CODESYS Profinet Config
You can find example configurations for each of the fieldbus modules there.
Thanks for all the great answers on this- it’s extremely helpful. However, as we’ve gone ahead with this we’re still hitting a bit of a wall, so I’m going to post a few screenshots to show you where we’re failing, and see if we can get this moving. At this point we’re just experimenting, so it’s not mission-critical.
I added the Symbol Configuration object, checkmarked the ‘Support OPC UA Features’ option while doing so. This got me a screen with all my current variables, where I could select the ones I want. I chose to make each read/write- the tiny icons aren’t super-clear about what they mean. I downloaded the program and ran it, it’s running like this:
Back on the Groov Build screen, I added a new device, an OPC UA Server, like this:
On the Gadget Pallet now I get the following:
I’ve checked a few things- first, in Groov, on the ‘Configure Devices & Tags…’ dialog, selecting the OPC server and clicking ‘Update Static Tags…’ gives me a report of ‘Unable to complete the operation.’ I wondered if the port 4840 was open or not in the firewall- it is, by default. I wondered if it was a security certificate on the Codesys side- the documentation for OPC there has a section on installing a certificate. I tried that, it says ‘The device does not support this service.’, which leads me to believe that it’s not that.
I’m a bit baffled at this point- if you’ve got any ideas, I’d be forever grateful. To me it looks like the OPC server in the controller isn’t running, or I don’t have it enabled or something.
There are two things that may be causing this, be sure, that when you build the symbol configuration, you do it twice, then download it. Also, you may have to add .local to your hostname in groov Manage, to get groov Build to see it. You can go here for a more in depth look at this:
Thanks for the suggestions. I’ve tried both now- I hit the ‘build’ button a couple of times before downloading. I’m guessing this is because the first ‘build’ just builds the list in CodeSys, the second one actually registers any changes to selections. That didn’t make any difference.
Next, the suggestion to change the address of the server in Groov - I’m not sure why we’d do that, as the word ‘localhost’ is normally a thing in IP addressing meaning ‘127.0.01’, but I gave it a shot anyway. This did change things a little- when I clicked the ‘Update static tags…’ button, instead of ‘unable to complete the operation’, I got this:
That sort of bears out what I’d thought, that the address with ‘.local’ on it isn’t recognized as a valid address. This does make me think that earlier it’s getting a valid connection, but something else is awry. The error now looks like it’s not finding anything to connect to.
Thanks!! oddly enough, I was just logging in to let y’all know that one of our other engineers just stumbled onto this answer- he changed the name in Groov Manage to ‘Test-EPIC.local’ to match what was in your linked thread, and it picked up and worked, because it had the ‘.local’ on the hostname.
I’ll be completely honest- this is incredibly obscure, and really makes no sense to me. I’ve got no idea how the addressing is working here. Hopefully we’ll see some careful documentation soon.
Thanks again to everyone who helped on this one- I really should take the blame for not reading the entirety of the other thread more carefully when it was first posted. As a long-time network programming geek, I made the assumption that the Groov View would convert ‘localhost’ into ‘127.0.0.1’ like most things do, and at some point I may have even tried using ‘127.0.0.1:4840’ instead of ‘localhost:4840’. Like I said before, this one is pretty strange.
In any case, now that we’ve got the secret naming thing worked out, we’re golden. Thanks again!
Congratulations on being the 10.000th person to get caught by the .local extension when defining EPIC hostname. Let’s hope Opto22 can resolve this annoying “feature/bug” this year. It seems more of an EPIC application level problem than an operating system level problem as the Ignition Edge internal access has no problem in handling 127.0.0.1 “as is”
If you feel happy using PAC Control and your only problem in life is providing a VIEW operator interface for Profibus devices or integrating limited Profibus data into the PAC Control Engine environment, then perhaps the answer is to use the Ignition Edge Gateway to handle your Siemens connectivity and then read/write the data into the PAC Control Engine, using PAC Control Subroutines.
Obviously, using HTTPS Get/Post commands is not the most optimized highspeed industrial polling protocol out there, but for low capacity requirements, they are good enough and at least you get to go home at night, which is more than you are going to manage, diving into the murky depths of CODESYS.
I am currently testing the prerelease version of the 1.3.1 firmware and am happy to say that we got to the bottom of the .local issue and it is (so far) resolved in this patch and thus all versions going forward.
