Hello everyone, I’m new here and I’m coming straight to a problem for which I currently have no further approach (I’m a bit lost) and I’m hoping for your support and/or experience
I have already read some posts about Modbus RTU here… ultimately without success This is my first connection of a Wago PFC to Modbus RTU and also the most tedious one.
Modbus RTU on local Sub-D, Mode Serial Interface (in PFC to RS485)
Connector on SUB-D Wago 750-960, termination resistor switched on
In the HW Config, only one Modbus slave was created (see screenshot)
Slave Addr.3 (three registers (channels) created)
When the controller is loaded and started, a bus error is displayed for Modbus (time out - no response).
The Modbus slave (eletechsup NT18B07) can be addressed, configured, and the register values can be read via ComTest Modbus (on a notebook). Connection via USB-RS485 adapter.
I assume that since no communication is established, there must be some kind of configuration or hardware error?
No application has been created yet (no FBs available to read the registers); I think it’s pointless as long as communication is not established?
I hope you still have an approach for me on what I can test/change that will lead to success. If further information is missing or would be helpful, please let me know briefly - I will provide it immediately. (If more productive, feel free to do the whole thing in English)
The integrated serial port into the controller has a dual electrical interface RS232/RS485 and by default it assigned to RS232. You need to confirm first the port is using the right interface RS485. This have to be done manually thought the WBM (web configuration pages) under the “Configuration” tab go to menu: “Administration | Serian Interface | Assign Mode of serial interface“, select “RS485”, submit and reboot the controller (not sure if the later is required)
Yes, the configuration is set to RS485 on the PFC (configured via WBM)
The “Restart” communication is also active
Yes, the client/server setup is confusing (but it is plausible given the configuration options)
Here are the requested screenshots (offline and also online (status)):
According to the error (Server Status), no reply is received (no Reply in Time). This can also be observed after increasing the Response Timeout to 5 seconds following a reset.
The next attempt will be to use a different sensor (different type) — let’s see what the port reports then It’s surprising that the sensor currently communicates flawlessly via tools like Commix or ComTest…
Yes, that is correct. I initially tested with address 3 (without success), then performed a reset to default and continued testing with address 1. Address 1 is correct (identical in the configuration and the address set on the device).
Ok, my advise, start use FbMbMasterSerial from WagoAppPlcModbus library.
In this library you can find more detailed diagnostic information.
Now we can see only Error code - Response Timeout.
Can you connect PLC COM to USB-RS485 Com to notebook, to check what Wago PLC try to do with serial com?
I have faced this kind of issues with different modbus RTU slaves before. Generally it was about the bias networking in modbus rtu line ends. I mean, if the slave device does not have pull up - pull down resistor between Vcc-D+ and between GND-D-.
Normally in most cases 750-960 will enough for you to have biasing due to it has 390 ohm in both side ( up and down ) with ending resistor but resistor will not neccessary due to the line is short in your setup I assume.
If nothing helped you, I recommend you to try at least 1k ohm instead of 390 ohm at both pull up and pull down resisting. This maybe shows you what is the main problem. You can easily take 2 pcs of 1k ohm resistors (smd or not) and connect to DB9 connectors (standart connector) pins. You can check our manual which ports are what.
My experience is that Modbus is a simple protocol but, when working with a new slave/device usually is hard to have results at the beginning, mainly because we do no have tools or enough information to figure out what the communication is not happening. I am confident that at some point you’ll have it working. I do not think it may be a problem with the version of Codeysy or the firmware in the PLC.
The most important thing is you already have a good starting point: you are able to exchange data between the device and the PC!. So i can asume that the cabling and bus termination are god enough. My next step would be to confirm connect the PFC100 in parallel and configure it to act as a SLAVE, traying to read a single register form the PC would be enough to check the pin connection and the polarity. I suppose you have a software in the PC to make request, if not I typically use “OpenModScan” (you can download it from Github), it is free an simple to use. In the PFC100 i would configure a couple of channels: 5 single Holding Register and another 5 Input Registers, both starting from address 0. Set different values to any of the register and then try to read one single register with address 1. This trick will save you to deal with the Mosbus/Modicon Addresing mess.
You can try to configure the PLC as a master an use a program in the PLC to see the bytes of the Mosbus messages. I use CoolTerm (free software) because it can show the incoming data in binary format. If your are familiar with Modbus protocol you can confirm that he transmission parameter and the polarity are correct. For this test configure a shot message as reading a single Input register with a low pooling time, one second or slower.
Hello everyone, first of all, thank you for the answers and valuable tips
I have now connected another device (a different sensor type) - unfortunately with the same result >> once the controller is loaded and started, a bus error (time out - no response) is displayed for Modbus
Next, I will follow your recommendations and use the diagnostic FB FbMbMasterSerial. Unfortunately, I have absolutely no idea (at least in CFC) what needs to be connected as input.
The documentation I found doesn’t help me at first glance; I first need to understand the various configurations defined as arrays, queries, or structs (how and where variables need to be defined or created there).
I somehow couldn’t find a good description of the FB indicating exactly which input must be connected to what. So for now, I’ll keep searching and integrate the FB correctly. (I recently found one or two examples in Structured Text online; I’ll take a look at them).
In parallel, I’ll try adding the resistors on the sensor side, even though various tools via USB-RTU adapters exchange data with the sensor without issues.
Still unclear for me: Does the RTU node in the HW configuration need to turn green in the online view? Regardless of whether a program is running or not… if it still reports a time out (and that even without running software), won’t an FB provide any further information?
Unfortunately, I have very little time in the coming weeks to test this online with the hardware… but I’ll keep at it.
and I’m coming straight to a problem for which I currently have no further approach (I’m a bit lost) and I’m hoping for your support and/or experience 
This is my first connection of a Wago PFC to Modbus RTU and also the most tedious one.
It’s surprising that the sensor currently communicates flawlessly via tools like Commix or ComTest…
