0:04
Good morning everyone, thanks for joining us on this webinar for controlling a VFD using a modbus.
0:11
Presentation is roughly about a half hour, but if you have any questions you can put them in and we can get to them at the end.
0:19
Hello and welcome to today’s webinar.
0:22
Today we will be looking at how to control a VFD using its built-in modbus RTU port. Let’s look at our agenda for today.
0:33
We will start with a quick review of the Modbus RTU protocol and discuss some of the benefits of using Modbus RTU for VFD control.
0:43
We will then look at the integration process for this protocol and your OCS.
0:49
We will look at the RS485 wiring involved in this process as well as how to identify the key VFD parameters that you will need for communications.
0:59
The particular drive you may be using will have a unique parameter map, so we will be talking in general about the type of parameters that need to be adjusted.
1:10
We will also look at how to set up the VFD and finally how to configure the OCS all-in-one controller to communicate with the drive over RTU Modbus.
1:21
There will be demonstrations throughout and we will finish with a Q &A session.
1:25
Modbus is the most common industrial protocol for interfacing industrial devices and is widely supported by many devices.
1:35
The Modbus protocol has many forms, so that it can be used with different media in different applications.
1:42
Modbus TCP is Modbus protocol over Ethernet.
1:46
Modbus ASCII is often used for Modbus communications over a radio, such as wastewater type applications or for applications where you have several devices spread across a wide geographic area.
1:59
Finally, Modbus RTU, which we will be focusing on today, uses Modbus protocol serially over an RS485 network.
2:09
Modbus is a register-based or address-based protocol, so it’s not an object-based protocol like a lot of the newer, more modern protocols.
2:17
However, it still works extremely well for interfacing with devices such as drives.
2:23
As Modbus is a register-based protocol, the registers are organized like a traditional PLC.
2:30
There are four different types of Modbus registers.
2:33
Coils emulate digital output bits.
2:35
Inputs emulate digital input bits.
2:38
Input registers emulate analog inputs or read-only inputs.
2:43
and holding registers emulate analog outputs or internal PLC registers.
2:49
A lot of drives, such as the InverTech drive we will use in our demonstration, are primarily based on holding registers from a Modbus perspective, so any data we need to read or write in this case is mapped to holding registers.
3:04
How these registers are numbered will vary depending on the manufacturer.
3:09
Modbus is traditionally mapped with 5-digit addresses.
3:12
As you can see, in each of the four different types of registers, there are 10 ,000 entries.
3:18
So we have 10 ,000 coils starting at entry 1, 10 ,000 input bits starting at 10 ,001, 10 ,000 input registers starting at 30 ,001, and 10 ,000 holding registers starting at 40 ,001, and 10 ,000 holding registers starting at 40 ,001.
3:37
So this is the traditional type of Modbus numbering system, where each memory type has its own unique numbering range.
3:45
Some manufacturers may instead use a number from 1 to 10 ,000 for each of the four different types of registers for the addresses of the Modbus data.
3:54
For example, they may specify input register number 1 or holding register number 1.
4:00
Some manufacturers might list an offset instead of an address number.
4:04
Modbus is a one-based address numbering system, however if you give an offset, then you’re giving a number starting with zero.
4:12
So if you’re giving an offset to the first holding register, this would be offset zero.
4:18
Some manufacturers may also list this in their documentation as address zero.
4:23
Next we will look at Modbus function codes.
4:26
These are the commands usually in the background that will act as the Modbus master.
4:30
The OCS is executing these function codes to communicate with the drive.
4:35
However, you don’t always need to know specifically which function code is being used.
4:40
You just need to understand what function codes are there and which ones are supported by your particular drive.
4:47
There are function codes to read coils, to read inputs, to read holding registers and to read input registers.
4:54
You also have different function codes for writing a single coil.
4:58
for writing a single register, for writing multiple coils, and writing multiple registers.
5:04
So these are the most common Modbus function codes needed to communicate with the variable frequency drive.
5:11
So now we have discussed some of the background on Modbus, how it’s organized, how it’s numbered, and what function codes are supported.
5:20
Now we will look at some of the benefits of using Modbus RTU to control a drive.
5:25
With most drives, Modbus RTU support is included for free on the drive.
5:30
Modbus RTU provides the ability to start and stop the drive, control the speed, and monitor power and current data.
5:39
It also allows you to read and write individual drive parameters if needed.
5:44
Modbus RTU allows you to read faults as well as reset faults.
5:49
Using any of these functions over Modbus will also reduce the amount of PLC I.O.
5:55
that you need to allocate to the drive.
5:57
You can choose to have some functions of drive control done using hard wiring from your PLC or your Horner OCS, and also some functions done over Modbus.
6:08
So there are a lot of benefits to using this free built-in protocol.
6:12
Now let’s look at the wiring of RS485, which is commonly used with Modbus on drives.
6:19
Most manufacturers will recommend a twisted pair wire for communications, as well as an extra conductor that’s used as a common reference.
6:28
These two communication conductors may be labelled as plus and minus, or as A and B.
6:34
Regardless of how these are labelled, you will wire straight through plus to plus and minus to minus, or A to A and B to B.
6:42
So this is the RS485 wiring from the standpoint of the conductors for communications and for the common reference.
6:50
In addition to this, if you choose to use shielded wiring, then you should make sure that you connect the shield drain to earth ground.
6:58
Most drive manufacturers will recommend that you do this at a good earth point away from the drive and not inside the drive chassis.
7:07
Regardless of whether you use shielded wiring or not, you will need to have termination on both ends of your communication pair.
7:15
Depending on the wiring you use, this could be 100 ohm resistors or 120 ohm resistors, but in most cases, 100 ohms will work.
7:26
So if your OCS or PLC and your drive are the only devices on the network, you need termination on both ends or on both devices.
7:35
In the case of the Horner OCS all-in-one controller, there is a system menu entry that allows you to enable termination, so you don’t have to physically add a resistor on the OCS end.
7:47
Instead you can simply go into the system menu and turn on termination resistance, and this will automatically add the 100 ohm resistor internally to the OCS to the communications path.
8:00
To add termination on the drive end, you may need to add a physical resistor depending on the drive.
8:06
Other drives may have a setting or switch that you can use to do this instead.
8:11
In the case of the invertec drive in our demonstration, we added a physical resistor to that end of the network.
8:18
You can also add bias resistors to the system if you choose.
8:23
The only reason you would need to add bias to the system is if you are getting some stray bits or some stray communication errors that are occurring, so usually you don’t need to add this.
8:33
In the case of the OCS when being used with a If you decide you want to turn biasing on, you can do that from the system menu.
8:42
We recommend that you start with bias turned off and only use it if needed.
8:47
Biasing also only needs to be added to one location on the network.
8:52
The next thing you will want to do when you integrate a drive with a PLC or Horner OCS is decide how you want to break up the functionality we mentioned earlier.
9:02
whether you want to do everything over Modbus or choose to use Modbus for some parameters and hardwire others.
9:09
You will need to consult your drive documentation to see what control the drive manufacturer gives you over what is hardwired and what is Modbus controlled, as this will vary by manufacturer.
9:21
At this point in the integration process, it is important to look at the manufacturer documentation to see what parameters are available over Modbus.
9:31
Many drive manufacturers will have hundreds of parameters available, so you will want to identify which ones you need for your application.
9:39
In general, most drive manufacturers will have some form of control word, which will give you the ability to start and stop the drive and to clear faults.
9:49
Some drive manufacturers may have individual bits to access Modbus for doing this.
9:55
In the case of the Invertec drive we will be using, they use a control word approach for starting and stopping and clearing faults.
10:02
Once you determine what functions are available over Modbus, and what you need for your application, you will also need to look at what address format the manufacturers use for Modbus.
10:14
Here we have some of the Invertec documentation for Modbus. In the left hand column, it lists register numbers starting with 1.
10:22
The document also states that InfraTech devices use holding registers for all of its functions.
10:28
This tells us that the Modbus registers are numbered from 1, so they are not offsets.
10:34
This means that we will have to add a value of 40 ,000 to the register number to come up with the 5 digit Modbus address which we will look at in further detail in our demonstration.
10:45
So once we have looked at the parameters and figure out the format for the Modbus addresses we will also want to look at the documentation to see what modbus function codes are supported.
10:57
Once we have looked at the documentation for the drive we need to set up the drive by adjusting a few parameters for modbus control.
11:05
In the case of the infertech drive you will need to adjust parameter number 12 if you want to set modbus as the primary command source.
11:13
So for our demonstration we have set our parameter to a value of 3.
11:18
This means we will control the over Modbus RTU but we will leave the acceleration and the deceleration to the parameters that are in the drive.
11:27
We can also adjust parameter 15 and set its value to determine how we want to break up the control between the drive and hardwired I.O. For our demonstration we have left this at the default of 0.
11:40
This means that we have to make sure that our first digital input DI1 is on.
11:46
If we the drive to be enabled so that we can start and stop it over Modbus.
11:51
Then digital 2, 3 and 4, along with the two AIs, will be ignored from a control perspective.
11:58
The next step to set up our drive will be to set the Modbus address, the baud rate and other parameters for communications over the serial port. We have chosen to leave these at the default settings where we can.
12:11
For our InverTech drive, the default address is 1, a baud rate of 115.2, and a timeout of 3 seconds.
12:20
In other words, the drive will wait up to 3 seconds to be commanded before it flags a fault.
12:26
The only setting that you would need to change here would be the address if you have multiple drives on the same network.
12:32
Now we will look at our configuration in CScape 10 for communication via RTU Modbus to our Invertec Variable Frequency Drive.
12:43
First, we will configure the Modbus communications with the drive.
12:46
We will navigate to the Hardware Configuration settings in the ribbon toolbar, which is under the Home section.
12:53
For this demonstration, we are using a Micro OCS X7 controller, which is an ideal choice for pump control type applications and applications with variable frequency drives.
13:05
The Modbus serial or Modbus RTU configuration is found here under Serial Ports, so we will select Config.
13:14
MJ2, in the case of the Micro OCS, is the RS485 port, which is what we will use to communicate to the drive.
13:22
From the pull-down list we have selected Modbus Master from the list of available protocols.
13:29
There are three levels of configuration we need to do for our OCS to act as a Modbus RTU master.
13:36
First we will look at the network level.
13:38
This is where we configure the baud rate, parity, data bit and stop bits that we are going to use when we communicate with the drive.
13:47
For our demonstration, we have chosen to use the default parameters for our infratech drive.
13:53
On the right hand side we have selected Modbus RTU, and then down here under timeout, we have made sure to set this as a small amount of time, in this case as 1 second.
14:04
The default setting is higher than this.
14:06
If we have a direct connection, and especially if we are only talking to one drive, we don’t need to have a higher timeout value, so 1 second is You can then set retries to any number between 0 and 255.
14:22
Another important parameter to adjust is reacquire time.
14:26
The timeout is how long the OCS will wait for the drive to respond to any particular message.
14:32
When it times out, it will retry the number of times that are specified here, and when the retries are exhausted, it will then wait until a reacquire time expires before it starts this whole process again.
14:44
So keeping the timeout and the reacquired time short is what you should do if you are only talking to one device or a few devices over a hardwired connection like we are here.
14:56
Finally, under Update Scan, we will leave the update scan set to Automatic, and we will set the update interval to 0.
15:04
So this basically tells the OCS to pull the slave as fast as you can.
15:08
Then underneath this, we have an optional bit type variable that we can assign under Disable Network.
15:15
This will give us a Modbus reset bit that will reset Modbus communications in the OCS master.
15:21
This can be useful if you have any communication errors after you have been communicating normally for a period of time.
15:29
As well as this, we can assign a Modbus master status, which is a double integer type variable array with four consecutive 32-bit values.
15:37
Here we have assigned a variable called modbus status, which can tell us everything about our communications, such as how fast we are pulling the slaves, how many good messages we are getting, and how many bad or corrupt messages we are getting.
15:53
This can be a valuable tool that we recommend you take advantage of.
15:57
So this is the network level of configuration.
16:00
Next we will look at the device level configuration.
16:03
This is where we tell the OCS about the slave or slaves that we’re going to be communicating with.
16:09
We have already added our infratech drive here, which we will double click to look at our configuration.
16:15
First we named the drive vfd and entered the modbus slave address.
16:20
The default slave address for an infratech drive and most other drives is 1.
16:25
If we had multiple drives, we would have multiple entries in the device configuration and they would vary by their device ID.
16:33
So if we had three identical infratech drives, this configuration would be nearly identical, but the IDs would vary by drive.
16:41
To change the ID in the drive, we could go into a specific drive parameter and adjust it.
16:48
But in this case, we will leave the ID at the default value of 1, because we only have one drive.
16:54
Under device options, we can set the Modbus addressing style.
16:58
In the case of the Invertec drive, it only uses holding registers, which have a typical Modbus 5-digit addressing style of 40 ,001 and so on.
17:09
In the Invertec documentation, it lists these holding registers as 1, 2, 3, and so on.
17:16
So it uses the Modbus holding registers, but it doesn’t use an offset, which is a zero-based number from the beginning of the memory location.
17:24
It uses a one-based address, but it doesn’t start it at 40 ,001 in the documentation. Instead it starts it at 1.
17:33
So none of our options in our drop-down list are very close to this.
17:37
If we were using an offset, we would use one of these generic decimal or generic hexadecimal choices.
17:44
We would only use of addressing if another OCS was the slave that we were talking to, which is not what we are doing here. Instead we are talking to a drive.
17:54
We would only use 6 digit addressing if it was modbus tcp over ethernet, and we were talking to a larger device such as a drive that had 100 ,000 holding registers instead of 10 ,000 holding registers.
18:08
So for our demonstration, the closest approximation of the addressing we want to use is the default of five digit addressing.
18:17
The disable bit can be very valuable if you have multiple drives on the same Modbus network.
18:23
For example, if you have three drives such as a triple x pump system and at any given moment one drive can be down for service, instead of trying to pull that drive that’s down for service, you could assign a disable bit for drive in your system, which, once set, would cause the OCS to ignore that drive completely. So this disabled bit is a boolean 1-bit variable.
18:48
Then under status, we can assign a Modbus status variable from a drive perspective.
18:53
So if we attempt to access a legal parameter from the drive, for example, we will get an error message that’s Modbus related that we can look up for diagnostic purposes. This is two 16-bit words.
19:07
So we have created an integer variable that is an array with two members, and we can monitor this to make sure everything’s working properly.
19:16
If it’s working properly, these values will just be zero.
19:19
If we have a Modbus-related problem with this slave, then these values will be non-zero.
19:25
So this is the device-level configuration, and we have just one configured here for our demonstration.
19:32
Finally, we have the scan list configuration, which is the list of data we will read and or write with the Modbus slave, which in our case is a variable frequency drive.
19:43
If we didn’t have any entries on the scan list, this would be blank and we would have to select add to start. We have already added entries, which we will look at now.
19:54
For our first entry, we have the device that the data will read or write is coming from.
19:59
In this case, we are only talking to one drive, so there is only one device to choose from.
20:05
If we had multiple drives, they would be listed here in the drop-down menu.
20:10
Underneath this, we have the five-digit Modbus starting address that we want to read or write.
20:16
Our InfoTech drive has two registers at the beginning of their Modbus map that we are interested in.
20:22
These are the control word and the frequency setpoint.
20:25
These are both read-write values which we want to map to our PLC variables.
20:30
So we will start at 40000 and 1 and set a length of 2.
20:35
In the Invertek documentation, it lists these in the Modbus documentation as register number 1 and 2.
20:42
Once again, this is using one-base addressing, so we have to add 40000 to these register addresses to make this a true 5-digit Modbus reference.
20:52
So here we have our starting register and our length of 2 because we are getting 2 consecutive.
20:58
All of our modbus data with the drive will be mapped into this word type variable because we are only using holding registers with the infratech drive and holding registers are always word type variables.
21:10
We have created a long word type array where we can push all the modbus data that is going to be read and or written.
21:18
Then in our OCS program, this is where we will find the holding register data to either read or write.
21:24
In this case, these two words are read-write data.
21:28
So normally, the OCS will be reading the data, but if we change it in our program, such as by changing the speed, or changing the start or stop status, then that data will be written.
21:40
So these are the first two words we are mapping with the drive.
21:43
When we’re creating a Modbus scanlist, we always want to optimize that scanlist so that we have the fewest number of entries possible.
21:52
For example, if we have 7 words of data we are interested in reading, and they were scattered among 20 consecutive Modbus holding registers, instead of having individual polled reads for those 7 different values, it would be much faster for us to have a single read that reads 20 consecutive values.
22:10
and then in our program, we would just access the 7 that we’re interested in.
22:15
Now let’s look at the second entry in our Modbus scanlist, which starts at 40000 and 6, or in the Invertek documentation, this is labelled as register number 6.
22:26
There are 3 consecutive words that we are interested in, and this happens to be read-only data.
22:32
These are the drive status and error code, if we have one, the output motor frequency, and the actual motor current.
22:40
So we are specifying the starting modbus five digit register here and mapping them into the same array.
22:47
This time however instead of starting at zero we have skipped the first two entries which are already mapped and we are now starting at the third entry which has an index of two. Once again this is read write data.
23:00
The third entry in our list is also read data, but this is five words that start at 40 ,020.
23:07
We have set the update type as a polled read and we are mapping this information into indexes 5, 6, and 7 in our modbus-data array.
23:16
These five words of data in the infertech drive are the two values of our analog inputs, which are the speed reference value, in other words the speed that the drive will move to the next time it runs, as well as the bus voltage and the drive temperature.
23:32
So this is the scan list that we’ve created for our demonstration with three entries.
23:37
Everything else in our application is mainly ladder logic for manipulating monitoring status and manipulating the control word to tell the drive to start, stop and clear faults.
23:49
Here we have some ladder logic that is a simple start stop circuit where we have a start and stop push button that are touchscreen objects on our OCS screen.
23:58
We also have a status bit we are reading from the drive to make sure the drive is ready.
24:04
Then we are creating a coil which is run enable, so if we start the drive, this run enable coil will turn on.
24:11
We have mapped this coil over to the first bit in the control word, so this is the first word of Modbus read write data with the drive.
24:19
We are copying the run enable coil from our logic over to that bit, so when we start the drive up here, that will turn When I stop the drive here, that will turn off.
24:30
We also have a fault reset push button, which is just a touch object on the screen, which is mapped over to the third bit in the control word, because that is in the Invertek documentation.
24:41
That is the bit that resets a fault.
24:44
Then these other three bits here are taking status from the third word in the modbus data array. The first bit in that third word tells us if the drive is running or not.
24:54
The next bit tells us if the drive is faulted, and then the 7th bit tells us that the drive is ready.
25:00
So this is the status word here, vfd, index of 2, which is the 3rd word in the array because the array starts at 0, and we have mapped these 3 useful pieces of information over to coils that we can then use on our screen.
25:16
Finally, we have taken the fault code from that 3rd stash’s word, which is in the upper and moved it to a new variable in the lower byte so that we can display the fault code and interpret it if we choose.
25:29
We’ve also created a few screens for our demonstration which we will look at in more detail in our bench setup.
25:35
So we have one screen with the control panel with some information and fault codes and another screen that tells us what’s happening from a Modbus perspective.
25:44
Now let’s look at our bench setup for this demonstration.
25:48
Here we have our x7 controller along with our infratech drive and our motor.
25:53
First we will look at what is happening on our OCS screen.
25:57
In the upper left hand corner we have a control dashboard that shows us if the drive is ready.
26:02
We can also start and stop the drive with push buttons.
26:05
We can see if the motor is actually running which is feedback coming from the drive itself and we can see what the speed reference is currently set to.
26:14
Then in the center of the screen we have the to change the speed reference if we choose.
26:19
On the lower right hand side of the control panel we can see that the actual motor speed is zero because nothing is currently running.
26:27
Underneath this we have indicators for faults so if we have a fault condition happening a red pilot light will turn on.
26:34
We will also get a fault code along with a message that explains the fault and an ability to reset that fault with the reset push button.
26:43
On the upper right hand side of screen we have some information about the drive such as the current drive temperature and the DC bus.
26:51
In the lower corner we have a button that will bring us to another screen with diagnostic information for our RTU status.
26:59
This is where we are utilizing the Modbus master status and the four double words of information.
27:05
We currently have a poll time of about 40 to 50 milliseconds which tells us how quickly we are reading data from the drive.
27:14
Our good Our responses are increasing and our no responses and bad responses are at zero, which means we are communicating with the drive successfully.
27:23
Underneath this we have the specific status words coming back from the drive in regards to Modbus.
27:29
These are both zero, which is what we want.
27:32
Then in the lower part of the screen we have our drive status control word, which we put there for informational purposes.
27:40
Now we will run our drive and return to our control screen.
27:43
We will select the start push button. As we can see, our actual motor speed is increasing, and our drive current has increased above zero.
27:52
We will increase the speed using our motor speed button from 30 Hz to 45 Hz, and then to 60 Hz.
28:04
We will stop our drive again, and once we do this, our actual motor speed goes down quickly and returns to zero.
28:11
Once we stop the motion run, feedback will also be set to zero.
28:16
If we change our motion speed reference, or the motion speed that we want to set to, our speed reference goes down to 45 again.
28:24
The next time the drive starts, if that speed doesn’t change again, then our motion will run up to 45 Hz.
28:31
In this particular example, the acceleration times will be set in the drive itself.
28:36
So this is our VFD bench setup.
28:39
Finally, we will look at how we can turn on termination and bias in our OCS menu system.
28:45
We are using a micro OCS, so we will push the upper right hand corner here to pull up the menu, and we will select the system bushing to access the system menu.
28:56
Then under serial ports, we can set termination and potentially bias.
29:01
So under MJ2 RS485 termination, we have set this because the OCS is on one end of the RS485 network, so it needs to be terminated.
29:12
As we mentioned earlier, wiring bias should only be added if it’s absolutely necessary, such as if you are receiving errors on the communication line.
29:22
We do not have any errors, so we will leave this such as no.
29:26
That concludes our webinar for today.
29:29
Thank you so much for listening, and the Q &A session will begin shortly.
29:40
Okay, hopefully that was beneficial to you all.
29:44
There’s nothing in currently so we are back again next week with another webinar on using a USB camera with Canvas.
29:52
So if you’d like to sign up for that it is the same section of the website under support where you can register for that.
30:00I think we will leave it there. Thank you all very much. I’ll see you again.
