0:03
Good morning everyone, thanks for joining us on this webinar on Modbus RTU master setup and troubleshooting.
0:08
It’s slightly longer today, it’s about 25 minutes of presentation and if you’ve any questions you can put them in we’ll get to them at the end.
0:16
Hello and welcome to today’s webinar.
0:19
Today we will look at Modbus RTU master setup and troubleshooting. Let’s take a look at our agenda for today.
0:27
We will begin by having a quick review of Mudbus RTU and then we are going to walk you through the setup process.
0:33
We are going to give you some testing and some troubleshooting tips.
0:37
The goal for today is to give you lots of good information that you can use in your project and there will be demonstrations throughout and we will finish with a Q &A session.
0:46
So what is Mudbus?
0:48
Mudbus is the most common protocol available today for interfacing devices from different manufacturers.
0:54
It is not the most advanced protocol but it is the most common and it has many forms.
0:59
We have MudBus over internet, MudBus over radio called MudBus ASCII and there is also MudBus RTU which is what we are going to be talking about in today’s presentation and that is MudBus over a twisted pair hardwired network.
1:15
So how does MudBus work?
1:17
Let’s start by talking about the memory structure that MudBus was based on or the way data is organized in MudBus.
1:23
Modbus was based, modelled around a traditional PLC.
1:27
Traditional PLCs have digital inputs and outputs, and analogue inputs and inputs.
1:32
So Modbus was organised into coils, inputs, input registers and holding registers.
1:38
That is the name for each of the four different types of memory used in Modbus coils.
1:43
The input are boolean data, where coils can be read or written, and inputs can be read only.
1:48
and then input registers and holding registers are word type data where input registers are read only and holding registers are read write.
1:57
Now let’s talk about the mudbus addressing in the traditional five digit mudbus addressing.
2:02
Each of the four different memory types has its own unique address range that keeps it simple.
2:08
So if you’re looking at mudbus address of 35 ,000 you know you’re looking at an input register which is read only.
2:15
Unfortunately not all Manufacturers follow the traditional five digit scheme so manufacturers will number each of the four different memory types the same One to ten thousand so if you have got one base Start and ten thousand total memory locations within each type others will list what is called offset in other words They are using zero based addressing for the same amount of registries or the same amount of addresses per memory type Now you may be wondering how those manufacturers who list all their addresses the same for each of the four different data types, how do they expect you to be able to differentiate them?
2:51
Well they are counting on the fact that each memory type has a unique function code or series of function codes for reading and writing to them.
2:59
So in their charts that shows the available data available on their device they will show not only the memory address or memory offset they will also the function codes that you can use to access that data so the combination of function codes plus the address or offset will give you the information you need to access that data.
3:18
Now let’s start talking about the physical wiring use used in Mudbus RTU.
3:23
Now Mudbus RTU is RS for the pipe based it is also what is called half duplex that means it uses the same data pair for both transmitting and even from every single node on the network.
3:37
Now most manufacturers recommend a total of three wires, a twisted pair for the data and an extra conductor which could be half of a twisted pair or a common. Why do they need a common?
3:48
RS, 45 devices can be several thousand feet apart which means they have slightly different ground reference and if the ground reference is different enough then there will be communication issues due to common mode so they use an extra common conductor.
4:02
Now let’s talk about shielding.
4:04
You would use shielded twisted pair wiring however if you are going to use that sort of wiring you need to be committed to grounding the shield.
4:12
Because if you do not you are going to have a big old antenna attracting electrical noises to your data pair.
4:19
Another tip if you happen to be communicating with variable frequency drives or other devices that are electronically noisy it is usually better to ground the shield away from that noisy device.
4:29
One of the advantages of Mudbus RTU is that it supports multi-drop wiring.
4:33
In other words, you are not limited to just two devices talking on a network.
4:38
One master can talk to multiple slaves.
4:40
You might have a master and 31 slaves in theory.
4:43
And when you wire the network, you wire everything straight through, plus to plus, minus to minus, common to common.
4:49
And when you have shielded wiring, you want to interconnect your shield drains so that you end up with a continuous shield on an entire network which is grounded at only one Now whether you have two devices on your network or 32 devices on your network, you are going to need a termination resistor, one at each physical end of your network and the value of the resistor should be based on the type of wiring you are using for most or S for the pipe wiring.
5:16
That means 120 ohms at each end.
5:19
If you are using something like CAF 5, it would be 100 ohms at each end.
5:24
Why would you need termination resistors in the first place?
5:28
Well, when you have signals travelling down a network, when they get to the end they bounce back and reflect, and that is noise that you do not want.
5:36
So terminating resistors absorb the energy and prevent that from happening.
5:40
Now there is another set of resistors that can come into play, RS45, and that is called Bison Resistors.
5:48
So what are those?
5:49
Those are pull up and pull down resistors that are added at one place on the network, and their job is to take spurious signals and pull them up or pull them down so they do not become ones or zeros and mess up your data.
6:02
Now our recommendation is to not add biasing to the network unless you need it so leave biasing off until the end.
6:09
After you have done some testing and if you do not need them you do not have to use them now you probably will not have to get out there with your soldering iron because a lot of devices like the Horner OCS all in one controller have switchable biases for resistors that can be turned on from the system menu or some other setting.
6:27
We are now at the portion of our project where we need to look at the specifics on the mudbus.
6:32
There are two slaves that would be interrogating and that means at this stage we need to find out what mudbus addressing scheme is used by this particular manufacturer.
6:42
Now if we look at the users guide and we see mudbus addressing listed that look like what you see on the screen.
6:48
That means you have got the best possible case.
6:50
this manufacturer is using traditional 5 digit mudbus addresses and there is no conversion required we can just write those addresses down and use them directly.
6:59
If all we are looking at instead are numbers that look like the following small numbers that are one base and we also see function codes listed that tell us that we are going to have to build our 5 digit mudbus address by adding offset. How big of an offset do we add?
7:15
Well that depends on the function code so if the for instance, then we need to take that register number in the chart and add 40 ,000 to get it to our 5 digit traditional Modbus address.
7:28
If it is an input register with a different function code, you would need to add 30 ,000.
7:33
Similarly, if you are looking at a small but zero base register number listed in the documentation, we are going to have to add a slightly larger number to the register in order to build our 5 digit address.
7:45
So again, if you are looking add a function codes associated with a holding register.
7:50
We are looking at zero base registers listed in the chart so we are going to have to add 40 ,000 and 1 to the value to come up to our 5 digit address based.
8:00
Now we are going to make a list of all the different mud bus addresses that we want to read.
8:05
We have wired up the network, we have figured out the data we are interested in and the 5 digit format.
8:11
Now it is time to set up the slave device so we can talk on the mudbus.
8:15
Now every slave is going to be different, so the setup process is going to be different as well.
8:20
There is some commonality, however, each slave must have a unique mudbus address somewhere between one and 247, and each slave, along with the master, have to have matching data rate.
8:32
In other words, they need to be transmitting and receiving using the same BUD rate, data bits, parity, and stop bits.
8:40
Now normally, our recommendation is to use the default settings on the slave if at all possible and adapt your master to adjust to the data rate of the slave that is typically easier to do.
8:51
Now in addition to address and data rate other things need to be set up as well.
8:55
With some devices you will have to enable mudbus, there will be a setting somewhere in the product to do the enabling and other products have a convenience feature for adding network termination if they are a device at the end of the network.
9:08
Maybe it is just a switch that you throw to add termination to the network.
9:13
Maybe it is just a jumper that you add if there are devices on the end to add to the termination.
9:19
So check out the manual for your slave device to get it set up.
9:22
Now it is time to configure the Mudbus master.
9:25
We are going to talk about setting up the Horner Controller as a Mudbus master.
9:29
You will need to start by setting up the data rate, data bits, purity in the master to match what you are using on the network.
9:36
and then you will need to set up your pull-in scheme. What is a pull-in scheme?
9:41
Well the Mudbus master is going to be continuously pulling a series of slaves reading and writing data.
9:46
Do you want to pull the data every five seconds? Do you want to pull it as fast as possible?
9:52
That is the pull-in scheme. Also you will need to tell the master about the slave device.
9:57
With slave devices from address standpoint are connected and what is their Mudbus data format?
10:03
Usually it is 5 digit traditional mudbus addresses that we use but the Horner controllers have the ability to adapt to other formats if necessary.
10:12
Also you are going to have a list of all the data that needs to be read or written from each slave.
10:17
Now when you are setting up this initially, start simple.
10:21
Start with one device and one piece of data.
10:24
Get that working and then you can add more data later.
10:27
Also if possible read or write big stretches of register consecutive address ranges instead picking and choosing a bunch of individual locations that you are interested in.
10:38
So if you are interested in 4001, 4003 and 4006, just read 4001 through 4006.
10:46
In one read entry instead of having three separate entries, it will be more efficient and much faster in the end.
10:52
Here is the general process we will use to configure the master.
10:55
We are going to use Cscape 10 and we are going to go to the hardware configuration.
10:59
We are going to go to the Serial Port section because MudBus RTU is a serial protocol and we are going to select MudBus Master from the pulldown list typically MJ2 has the Serial Port that supports RS45.
11:14
Next we are going to go in and set the pull-in parameters and the data rate for the master along with things like status, registers and disabled variables that we can set for convenient purposes later.
11:26
Also, we are going to tell the master about each slave that is configured and for each slave we are going to give it a name.
11:33
We are going to enter its MudBuzz address between 1 and 247 and we are going to indent its address and scheme, usually using MudBuzz PLC 5 digit address and scheme.
11:43
And then we are going to add status variables or a disabled variable to the list of each slave.
11:49
Finally, we are going to start adding entries to our MudBuzz.
11:53
scanlist that is the list of data that needs to be read or written to each slave and then as we add an entry to the scanlist we identify with slave it is coming from what mud bus register looks like how many consecutive mud bus registers we are looking at and whether we are reading them or whether these are read write and we also have to map those mud bus registers into a local variable space and in the end we end up with a scan list of all the data we need to read or write for each the slaves and again it is always better to use more consecutive data areas instead of individual data areas which end up causing your list to get large.
12:31
Let’s talk about our specific demonstration today.
12:34
For the UniDrive M4-100, the first step was to install an add-on module to support RS485 Modbus. Not all drives require this but the UniDrive M4-100 does.
12:47
Next we had to pair it up with our RS45 network in our demo.
12:52
You can see we used a twisted pair wire for this data as well as an extra conductor for the ground.
12:59
You will also notice an extra jumper wire on the M4100 side for termination.
13:04
This is how the M4100 handles termination.
13:07
Very convenient on the OCS side.
13:09
We have a setting in the system menu to enable termination on the OCS side.
13:14
Our next step was to perform a factory reset and we have performed a factory reset from menu 11 parameter 43 so that is the none in the middle chart and you can see there on the screen with the menu number, the dash and the parameter number.
13:29
We used that throughout this presentation.
13:31
Now in terms of the serial parameters we did not change any of them but we did go in and have a look at them in menu 11 and you can see the BUD rate, data bits along with the Next we set the start stop method we wanted to use for the drive to the US style.
13:50
The M4100 has a Europe style and a US style.
13:54
Start stop method we choose the US style in menu 6.
13:58
We also enabled the mudbus control word in menu 6 parameter 43.
14:04
And then finally and we had to make sure that we were handling saved torque off properly by connecting a switch to STOP1 and then going in and verifying the status of this hardware enable again from menu 6. So how does CT handle Modbus addresses?
14:19
First of all, they use traditional 5 digit addresses and secondly they link all their parameters to Modbus addresses through a 2 digit menu number and a 2 digit parameter number.
14:31
So our example on the screen from menu 6 is a parameter 06-043.
14:37
So we take the 2 digit menu number and we pair it with a did a parameter number to build a mudbus address 4040643 and here is the list of the data we accumulated for our demonstration today of the mudbus data and we are going to be reading and writing from and to the drive and you can see it listed here includes a status word a controlled word which are mapped registries where each bit has different meaning here all the details for the status word which you can freeze frame if you want to study it and on the slide we have got the control word details again available for freeze frame.
15:14
For our demonstration, let’s start by taking a look at how to configure RTU Mudbus master in the Horner all-in-one controllers.
15:22
We start from hardware configuration, navigate to serial port, because RTU Mudbus is a serial protocol, MJ2 is our RS45.
15:32
We will select Mudbus master from the list of available protocols, and we will start the configuration by pressing the network button.
15:39
This is where we adopt our data transmission parameters, bud rate, we always recommend you adopt the master to the slave.
15:47
So we are doing that here with 19, 208, 2 in terms of stop width.
15:52
We also set our timeout value for our RS45 network.
15:57
So we have got our reset to about half a second here.
16:01
We have set our number of re-entries, how many times we will retry to talk to a particular slave, and then if that slave goes offline, because it has not replied to us for instance, how long we will wait before we will try to talk to it again within another 3 tries and that is required time.
16:16
Now this required time could be set to a higher value if you have got a lot of slaves on the network.
16:22
A couple of other things you have a bit variable you can assign that will disable mudbuzz altogether.
16:28
When the value is 1 that can sometimes be useful, we went ahead and allocated it here.
16:33
Also very important, you have a block of four double word stylus registers available to you.
16:39
This is the status of the Mudbus master.
16:41
Now from setting up the pull rate, if you just want to pull the slaves as fast as possible, you set your updated interval to zero.
16:49
It will then pull them as fast as possible.
16:52
If you want this fixed scan rate of five seconds, then you can set this 5 ,000 milliseconds and that is the first level of configuration.
17:00
On the next level, we need to the master about all the different slaves it is connected to, for our example that is just one slave and here is the information, the important information is what is the ID of the slave and then also what is the format of the modbus data that it is presenting.
17:17
Now nearly all the time you will select modcon plc 5 digits addressing, the Horner OCS 101, we will leave everything else at default and then a couple more things, just like with master there is a status variable you can assign here in this case it is a 2 consecutive 16 bit word and then finally there is a disable bit that you can assign to each slave so you can disable just that slave from being pulled that is very useful if you have a network with multiple slaves after we just told the master about all the different slaves that are available or that it will be talking to next we are building our scan list and our scan list is the of all the data that we are going to be reading or writing from the different slaves so let’s take a look at our first entry that we have previously added to our scan list here we present the slave that we are going to be talking to in this case it’s device one what is mudbus register we are going to be reading or writing how many consecutive registers is that and what variable or variable array are we going to be reading that data into or writing that data out from and then what type of operation is this are we just reading the data from the mud bus into our local variable, every read writing, every read writing it, in other words every read in the day data on the normal basis and occasionally writing it, if it changes on the OCS side and then there is also a variation of that where on power up the OCS will write its value to the slave and then go about its normal pulling routine and then you can also trigger reads and writes that are not part of the pull list but only occur when you a trigger bit that gets turned on in your logic.
18:56
If you have triggered read or write then you have to assign a trigger bit. Now for most applications plain read and read write work fine.
19:03
The pull list is not too large everything works fine.
19:06
If you have got especially large lists for the data that you need to read or write for some of them you might have to make them triggered so that they are not regularly part of the pull list that will help you keep your scan rate down.
19:18
so if there is a data you do not care about getting frequent updates on you can trigger it once a minute or once every few minutes to get a copy of the data.
19:27
Now one other scan item that we need to look at this is a pulled read where we are reading four consecutive registers so not just 4501 but 4501 through 4504 and again since it is a block of data we have to read it into an array variable not as a plain variable so that is the scan list so that’s the three different of configuration that we need to do to set up the RTU master for the CTM400 drive demo that we are doing today.
19:56
We have got some ladder logic to review, so this is a special routine that we named CT that is handling the mudbus data in and out and mapping it over to variables and doing some other housekeeping.
20:08
Here at the top one of the words of data that we write in over a mudbus from the drive is status information.
20:15
The status word we have showed you as a screenshot and we have copied 3 of the bits that we are interested in over to the local variables, a held variable and an active variable so we have taken 4 more words that we have received over Mudbus and copied them over 2 variables for an actual frequency, the actual voltage and the actual kW.
20:35
And then in terms of control bits going out for controlling the drive we have taken local variables and map them to specific bits inside the control word which the OCS is writing out of the logic over mudbus when necessary.
20:50
And then finally down here we have a few runs of logic where we have built a mudbus ok bit and this mudbus ok bit will let our logic know that all the communications is fine, how does it derive that?
21:02
***** uses the status information available from the mudbus master to determine everything is working properly and then sets a local bit that we can use throughout our program including LED indicator on the screen.
21:15
Finally let’s take a look at some of the screens that we have created to tie some of these variables that are being read or written out over Mudbus and allow us to control the drive.
21:25
Let’s start with some of the data coming back from the drive itself.
21:28
These are four consecutive words that we showed you with the actual frequency, RPM, kilowatts and volts. So this is all read only data coming back from the drive.
21:39
These are all bits that are part of the control work. So we can start and stop the drive.
21:44
We can switch between manual and automatic mode.
21:46
Manual mode being where the OCS on one controller is not controlling the drive, enabling and disabling the drive, changing direction using the frequency.
21:56
Reference from the all on one controller instead of the local drive could be an analog signal that is also wired into drive or it could be this reference here that we can set from the OCS.
22:06
Here is that mudbus ok bit that we have derived.
22:10
We have a run indicator as well so these are mostly bits from the control word with some status information as well.
22:16
Now on the other screen we have taken the status bits and shown them all here on the screen along with the control bits that we are interested in and then here is mudbus RTU master status and down here is the slave status that is and then as a word in hex format we went ahead and copied that status and the control words here as well this data over here for the CT demo let’s go ahead and operate the demo on the bench so here are those operators that are for the most part that are tied to the control word different bits within control word we have also got a word which is the speed reference that we can write down to the drive we have got our mud bus ok indicator which is green everything is good so if we switch from manual mode into auto mode which means the OCS is in control you will see we have got an inhibit message on our drive that is because the OCS has not turned on its enable bit which we will do so now and now our drive switches already operate so right now we are going to turn on the frequency reference switch which says we are going to use the speed instance for a different speed reference we will use the one here from the OCS and then we will start and then you can see we get our actual data fill in as known zeros our run bit is on as well and you can see that is happening on the drive screen we take a look at the second page we have here that breaks down the status word and the control word you can see we have got the individual bits that are on and off there and then on the right you can see that we are currently running at about 130 or 150 milliseconds pull rate to read and write data right now it is all reading data and we are getting good responses both of the words and the slave status are zero and that is good that means there is no problem with our scan list so that is what things look like here from the bench with our demo of the ct mpore 100 unidrive let’s finish up with some quick installation and troubleshooting tips first of all keep your network limits at 32 nodes or fewer and 4 000 feet or shorter on your network there are ways go beyond that but in general those are the acceptable limits for mudbus RTU.
24:30
Also use good cable, use twisted pair cabling where two twisted pairs or one and half twisted pairs is ideal.
24:37
Also if you are going to be using shielding be committed to grounding the shield properly.
24:41
Have a single ground point on a continuous overall shield for your network and usually the ground point is where you have the best ground and it is usually away from noise components.
24:52
Also terminate your network, install physical resistors where you need them or take advantage of switch or system menu settings or whatever is built into the slave or the master’s support determination. When it comes to Bison, only use it if you need it.
25:07
Start with your Bison disabled if everything’s working fine. Enable it if you’re having some troubles.
25:12
Adding Bison is one of the things you can do to see if that corrects your issue.
25:17
Also use the default setting in your slave When you can, match your bold rate, purity in the master to match the slave.
25:23
Also if you are building a larger network, start simple, test a smaller network first, maybe only two nodes, once that is working add nodes and take it from there.
25:33
When it comes to your scan list or the data that you are reading and writing, do the same thing, start with a small scan list with just a small amount of data, after that works expand from there.
25:44
Use your status register, there is a lot of good information in here.
25:47
In the master, the status register will tell you how many good responses you have had from slaves, how many bad responses and how many no responses.
25:56
They will tell you how long it has taken you to get through your scan list of data or if you are working on a fixed pull rate.
26:02
It will tell you how many times you have exceeded that pull rate.
26:06
On the slave side of things, the status register tells you if you have any problem in your scan list. That concludes our webinar for today.
26:14
Thank you so much for listening and the Q &A session will begin shortly.
26:26
Okay, hopefully that was beneficial to you. Our next webinar is using constant stand rate.
26:33
That will be next Thursday at the standard time.
26:36
As usual, if you want to register for that, the link is on the website.
26:42
I don’t see any questions in on that, so I think on that note we can leave it there.
Thank you all very much and I will see you next time.
