Glad you moved forward. With regard to refreshing of configuration - in theory it should work on demand, however given multi bridge initialization (ams / network connection / ads) sometimes its easier to restart whole binding or even openhab.
With regard to numbers - you need to use different syntax - for example Symbol:INT, Symbol:REAL or Symbol:FLOAT.
This determines how you want value to be read or interpreted. On openhab side type conversion is automatic and you will get just an Number.
after a whole evening of trial and error, it is only possible for me to make a link to 1 variable on the PLC.
Everything i try with more than 1 link results in the errors that I posted before.
That’s pretty bad result I must say. I can’t confirm behavior right now (have no ADS device & busy on linux where I can’t run twincat simulator). I will take a look on the issue later this week when I get myself out of customer project.
@marchano You’re right there was a typo in XML files which caused number fields to be faulty. I’ve made a fix for that. Overall stability troubles (after reconfiguration of bridges) comes for faulty connection termination which I can not currently solve. This means that update to AMS parameters or username/password will require openhab restart in order to terminate stale/leaked connections and launch new one.
I also did a small command line program which can be used without openhab, just to debug connection to/from PLC. Additionally it list symbols available on the PLC. I will attach it to first message in the topic once I will have updated binding.
Thank you very much for contributed testing so far!
@marchano FYI, I’ve updated bindings and released 2.5.1 version. It includes latest Apache PLC4X (0.6) sources and fixed connection handling. For Beckhoff there is also new utility which allows to test connection settings.
Links to downloads/connectorio webpage are available in first post in the topic.
Sadly due to unknown (so far) reason Beckhoff PLC still requires hard restart of openHAB in order to re-establish connection.
Hey @RafalO,
Glad you come and shared your experiences. With regard to your points and major differences:
Major advantage of ADS over Modbus are following:
– Support for symbolic fields - reading is based on PLC names and not indexes
– Support for device discovery (limited but still)
– Support for multi-get requests without manual aligning of registers in modbus server
– Understanding of data encoding on PLC side (dword/int/bool/real etc), again no aligning of reading side.
– In theory there is no need for program modifications
– ADS binding will soon be able to discover symbols from PLC
– Values can be subscribed and not polled (not supported yet, but on roadmap).
It is not an adult binding for sure. It works, after some tinkering. Major troubles come from setup pains since AMS/ADS have its own semantics which are not obvious for most of us as well as people working with Beckhoff (ie. which AMS port to use), how to setup parallel connections, how to debug read/write requests at AMS level.
Is it faster - I believe it can be much faster especially with subscriptions and not polling, you just get bidirectional communication with device which is much more efficient. AMS network overhead is bigger than for Modbus TCP but it knocks into different doors on PLC side.
What variables are supported - I can’t really tell you, cause I don’t have real device and program. My knowledge of Beckhoff (PLCs in general) is fairly limited and we do rely on community support. Below you can find symbols discovered from sample program I got from one of folks involved above.
I say that we are able to read the same data as your TwinCAT/Visual Studio, as long as it goes over ADS. It is just a question of figuring out some structs which are not entirely documented by Beckhoff.
You can check symbol scanner which I published above with your PLC to see what it returns for your setup before going any further.
As of stability - there are some troubles caused by PLCs which terminate connection without possibility to reconnect. I am not sure why it happens, but only one way to solve this is OH restart. Yet it is not a binding itself which is to blame but cryptic ADS logic specified nowhere.
Binding code is quite basic - it just submits read/write requests using documented ADS encoding.
Hope it answers some of your questions. If you know more about Beckhoff then I encourage you to test. We are able to improve this integration, but only in cooperation with community.
One update on the stability part - I noticed a bug (see PLC4X-207, PLC4X-257) in underlying library related to timeouts and late answers. As we know this, can happen due to many reasons for IP communications. This bug affects for sure last release (20201006), probably 20200504, 20200102, 20191231 are likely to suffer from same issue.
Symptoms which you can observe is freeze of any communication to PLC after glitch happens. I am going to publish new version in coming days which will address that.
Modbus is always an option and I have no doubts it is well tested extension. Let me know if you are able to configure PLC to talk with Beckhoff ams/ads binding.
Thanks for letting me testing your S7 binding.
It took some time before the binding was installed but after rebooting my Raspberry it was running.
The connection to my S7-319 is working. Now I want to configure a channel but what is the notation for the field. I want read and write to a DB. For example a bit (db803.dbx0.3) and to a byte (db803.dbb4). I tried multiple notations with %DB… bot only get errors. Is there documentation available?
Thanks.
There are some minor updates to align PLC4X format with Siemens tooling to be published. From what been told to me some of “low” number S7 (200, 300 or 400) support subscriptions. Binding does not support that yet and work on bringing subscriptions into PLC4X is in progress.
Reading of the symbol works, but if I try write a value to the plc I get the following error:
2020-11-30 21:32:23.937 [ERROR] [nal.common.AbstractInvocationHandler] - An error occurred while calling method 'ThingHandler.handleCommand()' on 'org.connectorio.binding.plc4x.beckhoff.internal.handler.BeckhoffPlcHandler@522670': Invalid encoder for type DirectAdsField{indexGroup=61472, indexOffset=48}
org.apache.plc4x.java.api.exceptions.PlcRuntimeException: Invalid encoder for type DirectAdsField{indexGroup=61472, indexOffset=48}
at org.apache.plc4x.java.base.connection.DefaultPlcFieldHandler.encodeBigDecimal(DefaultPlcFieldHandler.java:69) ~[?:?]
at org.apache.plc4x.java.base.messages.DefaultPlcWriteRequest$Builder.lambda$build$0(DefaultPlcWriteRequest.java:247) ~[?:?]
at java.util.TreeMap.forEach(TreeMap.java:1005) ~[?:1.8.0_265]
at org.apache.plc4x.java.base.messages.DefaultPlcWriteRequest$Builder.build(DefaultPlcWriteRequest.java:242) ~[?:?]
at org.connectorio.binding.plc4x.shared.handler.task.WriteTask.<init>(WriteTask.java:50) ~[?:?]
at org.connectorio.binding.plc4x.shared.handler.SharedPlc4xThingHandler.lambda$handleCommand$2(SharedPlc4xThingHandler.java:113) ~[?:?]
at java.util.Optional.ifPresent(Optional.java:159) ~[?:1.8.0_265]
at org.connectorio.binding.plc4x.shared.handler.SharedPlc4xThingHandler.handleCommand(SharedPlc4xThingHandler.java:113) ~[?:?]
at sun.reflect.GeneratedMethodAccessor119.invoke(Unknown Source) ~[?:?]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_265]
at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_265]
at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:152) [bundleFile:?]
at org.eclipse.smarthome.core.internal.common.InvocationHandlerSync.invoke(InvocationHandlerSync.java:59) [bundleFile:?]
at com.sun.proxy.$Proxy351.handleCommand(Unknown Source) [?:?]
at org.eclipse.smarthome.core.thing.internal.profiles.ProfileCallbackImpl.handleCommand(ProfileCallbackImpl.java:74) [bundleFile:?]
at org.eclipse.smarthome.core.thing.internal.profiles.SystemDefaultProfile.onCommandFromItem(SystemDefaultProfile.java:48) [bundleFile:?]
at sun.reflect.GeneratedMethodAccessor118.invoke(Unknown Source) ~[?:?]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_265]
at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_265]
at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:152) [bundleFile:?]
at org.eclipse.smarthome.core.internal.common.Invocation.call(Invocation.java:52) [bundleFile:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:1.8.0_265]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_265]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_265]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_265]
Did I miss anything in the configuration? Can you help here?
Your configuration is perfectly fine, what’s broken is handling of INT type. There are updates in this area to align parsing logic with IEC 61131-3 data types. It should be better with next update. As work around please try other types: UINT, UINT16, WORD. All these types should utilize 2 bytes of incoming payload.
I changed it in the ads thing config. Without success.
Also I tried to change the datatype to UINT / WORD in the PLC (and the thing config accordingly). Same result: reading work, writing of data not with the same error in the log.
Before you go - beckhoff support in recent alpha release is broken. There is connection setup problem which I can’t debug and need to confirm. If you scheduled test please hold on to next update or workaround.
Hey @Nete88, welcome to openHAB - setup procedure might be automatic or manual.
The automatic procedure rely on discovery of ADS devices through network broadcasts.
Use “Things > Add thing > Beckhoff ADS” and then click big “scan” button. If everything goes fine after a moment you should find your first results. First it is a suggested ams network. If you add it then second scan attempt should find your PLC. After you click add on PLC you must specify username and password to complete ADS routing setup.
Manual procedure requires creation of ADS route through Beckhoff tools.
You can setup a static route also in PLC settings. You gonna find sample values in one of above posts.
Once you have routing in place you need to add a Thing (Beckhoff AMS/ADS Network, Beckhoff ADS Network Bridge, Beckhoff ADS device). This is multi step separation is necessary to separate levels defined by PLC communication layers.
Once you have “ads” device defined you can start mapping its input and output to openhab channels and items you normally use for visualization.
I just need to notify you that openHAB 3.x version is not stable and there are connection setup problems. So to save you frustrations - if it doesn’t work after second attempt leave it until next update.
The openhab 2.x version proved to work for some people already so you can give it a try before above issue is fixed.
Ok, I did trace an issue with 3.0. It seems that route creation logic I updated/ported over is not working as expected. Sadly there is no option to disable buggy behavior other than by updating code.
The workaround for you, if you wish to sacrifice more time, is to create AMS route manually. It should then make communication working.
I still didn’t get my 11 year old CX9000 (can’t pass some of twincat 2 complains), but once I will have it working I will be able to make better test effort prior releases.
