I am using the OPC-UA Server on board a Siemens S7-1500 rather than the inbuilt Ignition Server as it supports OPC browsing and doesn’t require addressing etc. I am using v7.9.6 of ignition.
Generally it works however it does fault when pushed.
The problem doesn’t appear to be loading of tags but rather the rate of loading. For example I can get all the tags to read if I import them slowly. However if I import them too quickly or I restart ignition or the PLC (such that all the requests come at once) the connection faults with the messages attached (chunk count exceeded). I cannot then re-establish comms until I restart the OPC server (PLC) and load the tags in at a slow rate.
Is this a problem with ignition or the OPC Serve? i.e. is the chunk count error being raised by ignition’s OPC Client or being passed back from the OPC Server? I have attached the log below.
Hi,
I had the same issue while connecting to a Lenze PLC, with onboard OPC UA Server.
Try changing your “Max Per Operation” settings in Advanced section for the OPC connection.
I had to lower this value to 50 to make it work.
Ask support about OPC Next, assuming it is still called that. We ran into similar issues, and there was a joint IA/Siemens push to develop a solution that better integrated with the Siemens OPC server for a customer using a very large number of S7 PLCs. I don’t think it was part of the standard release software but should help in your use case.
Yes, using the “OPC UA Next” module should alleviate these issues.
It’s a separate module that can be installed side-by-side with the existing UA module and adds a new OPC connection type. It’s basically just a preview/beta of the new OPC UA client implementation going into Ignition 8.0 but wrapped up into a module that works in 7.9.
You can request it from support or email me directly (my first name @ inductiveautomation.com)
Interesting, in the list of random things we tried I lowered the number of operations from 8192 to 1024. When it still didn’t work I concluded that the setting wasn’t having any impact.
I’d be most interested in using the new module but would just like to ask a few questions (some of which are fairly general so I hope may be interesting for everyone)
OPC-UA is an agreed protocol. Why did the OPC client need to be changed to work better with Siemens OPC server? Was it OPC-UA version incompatibility for example?
I have a strange thing happening when I look at tags in designer. I import tags they work. I import more and they don’t update at all. It’s like the server is refusing to register them. Is this one of the issues the new module may fix? I understand the Siemens server is limited to the number of items it can monitor and subscriptions it can serve etc so this may be what is happening here; in which case the new module may not fix this.
Is there any way I can monitor the number of subscriptions, nodes being accessed for a given connection in Ignition?
I’m trying to limit the number of subscriptions by using array tags as much as possible and the using derived tags within data types to pull out the results from the array values. Is this a good way of doing this?
The chunk size error you're seeing is only loosely going to be affected by changing the max per operation. The underlying problem is that in 7.9 there's a hardcoded max message size allowed and the Siemens server is exceeding that in some messages (buffer sizes are exchanged, so it may actually be a bug in the server. I'd need to see Wireshark to be sure). The Next module increases that as well as makes it configurable (or will).
The other major difference is just un-implemented OPC UA features, like support for custom datatypes. Until we started seeing OPC UA servers embedded on PLCs from vendors like Siemens and Beckhoff custom datatypes weren't really used.
The Siemens server exposes extensive session and subscription diagnostics. Ignition 8.0 will have a page that gives some insight into the UA client's bookkeeping for subscriptions as well.
Yes, and if you use OPC UA Next you can subscribe to structured values and pull the members out using derived tags as well.
I'm curious... is there any other 'benefits' of using onboard OPC UA server of Siemens PLC (or any other device), than that it supports browsing and doesn't require addressing?
As a programmer, I always want to know the address of the tag I'm using. That's why I always use the Ignition server (despite more work and in the long run it turned out to be useful).
If you're using device OPC server, then you don't know the addresses, all you get are nodes...
And another thing: how do you create UDT's in Ignition with using device OPC?
I'm just asking because I never used device OPC UA (I tried, but didn't like it) and I might miss something...
S7-1500 and S7-1200 no longer require you to know the “address” of the memory being used, anywhere in the code (TIA automatically assigns DB, FB and FC numbers)
If global datablocks are set for optimised rather than standard the onboard Siemens OPC-UA server can be used.
This has the following advantages (some of which you’ve already pointed out):
Supports browsing
Symbolic structures can be used
According to Siemens all accesses to addresses in optimised datablocks are faster
Values able to be retained on downloads (do not return to initial or default values)
As all references are symbolic, structures be changed without destroying links (for example I can insert an integer element into a structure used for a valve without causing an error by offsetting all higher addresses by a word.
I don’t need to write a whole lot of code to move data from structures into arrays of integers and reals for the SCADA to pick up…
Hope this helps. It may not be right for everyone and addresses are still mandatory for IO.
Yes, I know all that… I/we are using mainly Siemens PLC for over 30 years now…
But all that are benefits of the programming the PLC code in TIA, not for the Ignition (or other SCADA software) ‘programmers’…
I was asking from Ignition stand of point if using inbuild device OPC UA is better than Ignition OPC server and Siemens driver… because I really don’t see any benefits, only troubles in the long run…
I believe the benefits of purely symbolic programming in the PLC provide benefits in the SCADA as well.
If I wish to show an additional real variable (assuming no spares in the UDT) on the SCADA for every valve object in the PLC compare the actions required in symbolic versus addressed programs.
Symbolic
1 Add a new variable in the valve UDT and compile
2 Add a new tag to the valve data type
Addressed (using S7 driver)
1 Add a new variable in the valve UDT and compile (worry about all the values in DBs that have been reset)
2 Add a new tag to the valve data type
3 Adjust all offsets of all tags using same DB
This is why I want to use symbolic but Happy to be corrected if might be missing something.
Thank you Kevin for the driver. I'd love to keep using it but it seems to be having a strange effect on the S7-1500 PLC.
Whilst the OPC-Client is connected, after one or two downloads or going on line a number of times programmers are unable to go online with a "Too Many Connections" message. The online connection for programmers is only able to be restored by resetting the PLC working memory (stopping the process).
When the OPC-Client is disconnected I do not have this problem. However, I believe this is very much in Siemens court as matter how badly behaved the client is their OPC-Server should not fault in such away as to affect other functions on the PLC.
In the meantime I am pursuing this with Siemens via a Service Request and looking into using the old address based driver.
The OPC UA server built into the S7-1500 is preferred because:
Better performance (probably already, if not in the long run)
OPC UA connections can be secured
Symbolic access (and data types and all the protection you get from this, e.g. you can't accidentally clobber data by getting the type wrong on some consecutive addresses in a block)
Browsing
(maybe most important) this is the Siemens-endorsed way to access data going forward. The S7 protocol has never been, and will never be, openly documented and supported by Siemens, and it's already causing issues with the "extended" S7 format they've started using, which is why you have to disable optimized blocks and security and everything else to access data on the 1200 and 1500.
Most testing has been against 2.1.x, but only because the customer is not able or willing to upgrade for other reasons (not OPC UA related).
That being said… I know the OPC UA server has been under constant development and improvement and I’d try to stay on the latest version possible unless there’s an absolute blocker you’re encountering.
I haven’t seen the particular issue you’re describing though.
Hello jcroxton,
I see the same problems as you with the OPC server of the CPU Siemens S7-1500 (V2.5):
Since April, did you find a solution?
Is the communication between Ignition and Siemens better with the firmware V2.1 of the CPU?
Did you try the “OPC UA next” module?
