Who here has cracked Modbus RTU in PLC IDE (not regular IDE)?
At this stage the Arduino documentation is incomplete. Some hero needs to make a video tutorial.
For posterity here is my demo setup, with one temperature+humidity sensor connected. My vision is to have many Modbus RTU slaves, so reading the temperature and humidity from one seems like a good beginner's goal So far I've made the Opta's LEDs blink and respond to the button using Ladder Logic.
In these kinds of projects, it's generally easier to connect the slave devices to a PC using an RS485 adapter then using a Modbus polling program to verify correct communications prior to deploying it to the PLC. This saves a significant amount of time trying to troubleshoot if the issue lies in the device or the PLC.
There are lots of variables at play here. Baud rate, start / stop bits. address offset, device address, etc. Continually modifying your program to test these different things can be time consuming and frustrating. Using a Modbus polling program to figure these things out will allow you to integrate these findings into your PLC and save the headache of continually changing the PLC program to figure out how to communicate with the device.
All of that said, the Generic Modbus catalog in PLC IDE works very well in the Modbus RTU applications I've tested it in.
Hi, I use an easier method to test Opta: I attempt to substitute PLCs (Siemens, B&R, Weintek, Fatec, and many other masters) with Finder HW.
Every other device works fine in all conditions 24/7, so the only variables are the Opta hardware and Arduino software.
I started programming under the same conditions that I used with Parker SBC Drive (with Logic Lab PLC inside and Esa HMI with Modbus connection) but haven't achieved any results because the PLC IDE tools are not compatible with the standard I found in other versions of Logic Lab.
At the moment, I'm waiting for updates or further news.
I have a working example with the OPTA and XY-MD02 here on the bench. First issue I found in your picture is the polarity is incorrect on your RS485 connections. You have the A from the OPTA connected to B on the XY-MD02, and same with the B on OPTA being connected to A on the XY-MDO2. They need to be connected A to A and B to B. Correcting that may solve your issues.
Attached is a project I just created showing the XY-MD02 working fine with the OPTA without any special things needing to be done in the PLC IDE to make it work. It's very simple and straight forward.
It works! What a relief.
Thank you so much for the demo code. How serendipitous that you had the XY-MD02 on hand.
I've followed your suggestion and bought an RS485-USB adapter so I'll be able to get the rest of the devices working.
That's basically how I got it working with OPTA. I put the XY-MD02 on the bench with the RS485 to serial adapter and then used Modbus Poll to communicate with the device to figure out addressing, and any other potential issues with the device before deploying it on the OPTA. I wrote down all of the particulars (9600, 8, N, 1), punched those settings into the OPTA, and it just worked on the first shot.
One issue I ran into with the XY-MD02 is trying to change the calibration offset as mine was reading too high on temp and too low on humidity. I used Modbus Poll to send the corrections to addresses 0x103 and 0x104. The device acknowledged the command, but a change was never made to the reading. Little things like this can get aggravating to diagnose on a PLC, and in this case some will be quick to blame the PLC for the issue, but in reality the device itself is the issue.
Another weird thing I noticed with the XY-MD02 on the bench is that when it is first powered up, it takes about three failed polls to actually start communicating with the device. Not sure if this is part of the UART / Modbus detection in the device, but it's still a strange behavior nonetheless. Again, this was easily diagnosed using an RS485 adapter with Modbus Poll. Just making sure I know how the device acts before putting it in the PLC loop and wondering why it acts weird.
In this case, all of the weird behaviors are part of the device and not the PLC in this particular instance. Best of luck moving forward!
You'd use the Shared variables on the Resources page. The Outputs are variable from the project to the sketch, and the Inputs are the variables from the sketch to the project. Took me a while to figure this out, kind of counter intuitive.
From there, in your sketch you can call the shared variables by using PLCIn.variable_name or PLCOut.variable_name
Unfortunately there's too many variables here to say why it doesn't work. I wish I could upload my project as an example, but it exceeds the 8mb limit for this forum.
In my particular case, I am using the sketch to create a rolling time average filter for the temperature value. I pass the value from the project to the sketch using a shared variable output, process the data with the sketch, then return the filtered value to the project using a shared variable input. With this I can use the watch window to monitor both the input and output of the sketch.
What may help in your case is to create a shared variable input and use the sketch to simply populate the the input value from your shared output value, then you can watch both values in the watch window. If the shared input returns the same result of as your shared output value, then there is likely an issue between your Arduino and the server you're trying to upload information to.
It may be very useful if you can upload your code (or part of it if you want) or can you send it via email
(ivan@amarotti.it)
I can edit PLCIn.variable and I can see in Watch, but the value of PLCOut.XY_MD02_T_INT is always 0.
Tried also to pass cnt global variable but is always 0.
It's nice that it shows both sides of the setup from the PLC IDE perspective, though there were points where I ran into trouble and where the tutorial falls a tiny bit short in my opinion.
Near the end of the section about setting up the PMC as a slave device, it says to navigate to the Projects window & double-click "Modbus_Vars"... and it doesn't explain that node will not exist if you select a variable in the preceding step instead of typing a new variable name in.
Ultimately, I still didn't get my PMC Board communicating without analyzing the Modbus requests with a PC to figure out that the IDE is shifting the register(s) that you configure by 1. I get that there could be some design consideration that led them to make the indexing 1-based, but I feel like that's a bug. Having to type "10" in the register field so that it will send "9" to the device isn't intuitive at all. In case this issue only occurs with certain functions, In my case I was writing to the register (Modbus function 06).