using Modbus overlay in Codesys
I am running a Neuron M203 with OWFS and codesys. Access to the 1W sensors works nicely by reading the data at OWFS's mountpoint using the sysFile library in Codesys.
But how can i access the I/O's? I guess using the modbus overlay is the solution. So Codesys needs to be the modbus slave... how can this be realized?
@tom84 You are correct, if you install the overlay + Modbus Server: https://github.com/UniPiTechnology/neuron_tcp_modbus_overlay
you will just need to create a Modbus TCP Slave at codesys and connect to the Server on 127.0.0.1:502. The list of registers/coils can be found at https://downloads.unipi.technology
But the full support for Neurons in Codesys is underway and we expect it to be released during this/next month.
I have been running the above system for the whole winter as heating controller and everything worked fine so far. For accessing the modbus tcp server I am using the function blocks from the OSCAT network library.
Now I want to add some more functions to my system which require faster access to the I/O's.
Therefore I tried the new codesys neuron package for I/O implementation but when configuring codesys like described in the manual I get the modbus error that the gateway does not reply.
When trying to add an modbus slave manually I get the same message.
Any ideas where the problem could be?
The UniPi Neuron for CODESYS should just work and give communication to all group 1 parameters with no more configuration than adding the few devices as described in the data sheet.
Just based on the issues I have heard of to date I suspect a CODESYS version issue, please confirm the versions of UniPian, CODESYS, CODESYS for Raspberry Pi and UniPi Neuron for CODESYS that you are using. The datasheet identifies the versions required, in particular, CODESYS and CODESYS for Raspberry Pi must be at least version 220.127.116.11. (There were small changes in the 3S Modbus devices in 18.104.22.168, and the Neuron drivers require this change).
I suggest that after installing the various packages you run the Demo Application. If everything has installed correctly then it will demonstrate functional Modbus communication.
If you are just having issues when adding the device to your existing application having installed everything as directed, then it is likely that you need to update the application. If you open the application in CODESYS 3.5.12.x having developed it in an earlier version you will be prompted, asking if you wish to update. I recommend updating everything, you will also need to select each 'device' in the device tree, right click and 'update the device'
I am running CODESYS 22.214.171.124 and Raspberry PI 126.96.36.199.
The demo application shows the same error.
I am not using the UniPian Image, but the official Raspian Stretch operating system with fixed ip adress (dhcpd), W1 disabled, OWFS running and TCP modbus overlay for UniPi installed.(https://github.com/UniPiTechnology/neuron-tcp-modbus-overlay)
My idea was to build a combined alarm clock with internet radio (squeezelite) and light alarm clock (codesys controlled dimmer over pwm). For easier setup of OWFS and squeezelite I would prefer to stay with the official Raspian installation instead of UniPian.
Could you please provide the correct modbus configuration steps on Raspian needed for having access to the device?
UniPi Neuron for CODESYS is only supported on the UniPian platform. Using UniPian gives a controlled environment that makes life much easier for most users.
Having said that UniPian is based on stretch lite, so you may find it easy to add OWFS and squeeze lite.
The area that I suspect will have a conflict is 1-Wire, however as long as you are not trying to use the CODESYS 1-wire solution you should be able to remove the kernel drivers. Or if your 1-wire device is supported by CODESYS then you could switch to using the built in drivers.
I believe there might be a problem in the Modbus interface as well, since the UniPi overlay is a very simplified version of our drivers which is only intended to be used with EVOK. CODESYS requires using the full UniPian configuration, or at the very least our kernel drivers. You can find source code for them at http://git.unipi.technology:3000/UniPi/neuron-kernel. But I would strongly suggest just using UniPian.
Thanks for your help.
I now installed UniPian, removed the DS2482 DT overlay and replaced it by the owfs installation. At first i tried access with a manually configured modbus slave in codesys and everything worked fine. Then i ordered the UniPi for Codesys license and switched over to the Neuron Slave. Now I am a bit confused on how to setup the 0-20mA output. The word "wAOSettings" is set to "I_0_20" and I am trying to output the current with the "SetAnalogOutput_mA" function. For some reason I get an Output of 20mA when i call the function with a value of about 155 (mA?). The demo application shows the same behaviour.
please provide information on how to use the analog output properly. So far i did the scaling in my own software. i would also be fine to output the value as "raw value" for the DAC. how can this be done?
Great, pleased youre moving forward.
Regarding the mA output. The NeuronGroup1 function block is installed automatically when the driver is created, and channels are mapped into it to make life easy for most users, this doesn't prevent you overriding the behaviour and doing your own thing.
The method SetAnalogOutput_mA takes and argument rValue which is the desired mA output, this limits the demand to what the hardware can achieve, so if you demand 155mA, it will only output 20mA.
If you wish to access the raw register then you will need to stop the NeuronGroup1 block from overwriting your data and also map the register that you wish to write. This can be achieved in one step by re-mapping the channel used to write the output. In your NeuronM20x device on the mapping page, find the mapping with the description "Analog Output", and change the mapping so that it references the WORD you want to send.
You can make more substantial changes, deleting unused channels too if you wish. However - be aware that if you choose to update the device in future these changes will need to be re-made.
thanks for your fast reply!
I have changed the modbus mapping like your suggestion and send the data to the dac using my own scaling block, which works fine so far. my block scales my control value of 0-100% to a dac value of 0-2300 which gives me 0-20mA output.
as you mentioned any of these changes in the mapping has to be re-made each time there is an update in the device. therefore I would like to configure my block for an output value of 0-20 and send this value to the dac using the built-in function "SetAnalogOutput_mA".
And here comes the unexpected behaviour: rValue=0 gives 0mA output as expected (+low clipping message). but to get 20mA output I need a rValue of about 155 (without high clipping message). At rValue=157 the dac output is set to 2297... so I guess there is something going wrong with the scaling function...
That sounds odd, the DAC numbers you mention sound odd to me. So a couple of questions.
What load have you got connected on the output?
I should be able top track back and see what is happening if I can see the values of the Group1 registers. Please post images of the values of the Group1A and Group1B mappings page while the system is running with a known rValue.
If you want me to have a quick look at your application then please contact me via https://www.cososo.co.uk/contact/.
the load is an industrial isolation barrier. all measurements where done with the barrier disconnected and an amperemeter connected directly to the Neuron.
for test purposes I decided to download the demo application to my device. It is made for S10x and I am running it on a M203, but it shows the same behaviour:
The mA problem is an issue with older hardware. UniPi Neuron for CODESYS will be updated to resolve the issue at the next service release.
Please note the issue does not occur on current Neurons. No Neuron products shipped since the release of UniPi Neuron for CODESYS will see this problem.