modbus?

Hey all,
I am trying to spec a plc for a small system. The machine is a beadblaster utilizing 8, 30 Hp. motors.

The customer has chosen ABB ACS355 drives with modbus comm cards. I need to monitor and transmit speed and load for each of the eight motors. the customer is also comfortable with Siemens plcs, so I am looking at an S7-224.

I have not worked with the modbus protocol so I am stumped as to what all I need to call out.
Thanks for any help!

As I understand the Modbus implementation is done with user-defined functions, rather than a built-in firmware feature of the S7-200 family.

The official method is to buy an add-on function package for the S7-200 development environment:

http://support.automation.siemens.c...lib.csinfo&lang=en&objid=27832511&caller=view

I've also seen some third-party libraries:

http://www.s7-200.net/libraries/Scripts/entry4d07.html?entry_ID=24&Part=3

In my opinion it would be a lot easier to choose a controller with built-in Modbus RTU Master capability or choose a drive with a Siemens native interface.

Modbus as a protocol is about as simple as serial protocols get. You can read up on it or download the whole specification at modbus.org.

You may want to consider a PLC that uses Modbus as a native language like GEIP, ABB, or Eaton.

Or Schneider Electric?

Hey,

I have some printers talking to an Allen Bradley 1756-L61 controller over Modbus. I had to use a third party ASCII comms card that allowed me to develop my own modbus headers and message structure that the printers needed as they had user defined functions that had to be accessed. It was an almighty effort to work out what was going on there, not to mention the lack of support from both the comms card company and AB tech support... it is funny how each blames the other when something goes wrong..

I agree with the previous poster, if you can use a controller that talks the drives lingo... go with that!!

Looks like Modbus is an option on the ACS anyway.
I would just go profibus on the drives and use a small S7300.
Did the customer spec the S7200 model?

First, thank you for all of your input. Second, I apologize for the delay returning to this post.

Ok. I am doing the programming for a small local mfg. He is sold on Siemens (first PLC he ever installed in his equipment) The end user has spec'ed the ABB drives, and my customer has spec'ed the PLC (with help from a salesman). I think I am stuck with this combo. If I had my choice it would all be Ethernet... problem solved.

The problem came down to price. The modbus comm for the ABB drives is one third the price of the Ethernet comm card. What I need to accomplish is to send load and speed info from eight drives, monitor for correct range and output these parameters to a database.

Can I feed information to a PC from the PLC in .csv format?

The ACS355 will do Modbus with ease.
Just set up the parameters you'll need to read/write to the PLC and you're good to go.
If you read the 355 manual there's a section that explains what needs to be set in order to utilize the fieldbus module of the drive.
I believe those are in the 9xxx range of the parameter set.
9300 comes to mind.
You'll also need to map actual values of your drive to words that will be transfered over modbus to your PLC.
You'll need to select which actual value to be mapped.
Haven't used Modbus with an S7-200 so can't help there.
Though, if you set up your S7-200 port for "freeport" you can utilize it to send data to a PC for logging.

Thank you all for your replies. I will let you know how it works out.
Robert

Robert, Instead of the S7-200 family - how about the S7-1200? The programming software includes a Modbus master or slave instruction for use with the RS-232 or RS-485 modules.

The 1200 is new and has more life than the S7-200 which is on its way out.

Does your customer realize how incredibly slow modbus is going to be?
If you are using modbus to transmit values while the motors are running I hope you don't want anything to stay synchronized: you can't rely on how long its going to take for all the devices to receive their modbus transmissions so if those motors need to do anything in unison you'll be unhappy. And just using modbus to talk to a handful of parameters across 8 drives has the potential to take many seconds for each loop.

I use a rough rule of thumb that each modbus send/receive is going to take about a second (very rough, but close enough). So if you have 8 drives with 8 items each you could easily be over a minute to see any change or cause a change. I use hardwired discrete IO to start/stop my drives: even Modbus TCP/IP is too slow to produce repeatable synchronization like you get for free everywhere else in your ladder logic.

Modbus is handy for logging data but when you try to use it for control/write/transmitting it is difficult to write the rest of your code to deal with the slow modbus, IMHO. I had a similar application with more drives and used the modbus to gather statistical data and faults for HMI display but gave up on ever using it to control my synchronized processes.

Your PLC may likely perform nonblocking read/writes of the modbus comms, hence another reason it is so difficult to time anything with modbus. PLC's tend not to do blocking read/writes of comms because you don't want your comm errors to cause the ladder logic to just up and die...

nwboson said:

Does your customer realize how incredibly slow modbus is going to be?
If you are using modbus to transmit values while the motors are running I hope you don't want anything to stay synchronized: you can't rely on how long its going to take for all the devices to receive their modbus transmissions so if those motors need to do anything in unison you'll be unhappy. And just using modbus to talk to a handful of parameters across 8 drives has the potential to take many seconds for each loop.

I use a rough rule of thumb that each modbus send/receive is going to take about a second (very rough, but close enough). So if you have 8 drives with 8 items each you could easily be over a minute to see any change or cause a change. I use hardwired discrete IO to start/stop my drives: even Modbus TCP/IP is too slow to produce repeatable synchronization like you get for free everywhere else in your ladder logic.

Modbus is handy for logging data but when you try to use it for control/write/transmitting it is difficult to write the rest of your code to deal with the slow modbus, IMHO. I had a similar application with more drives and used the modbus to gather statistical data and faults for HMI display but gave up on ever using it to control my synchronized processes.

Your PLC may likely perform nonblocking read/writes of the modbus comms, hence another reason it is so difficult to time anything with modbus. PLC's tend not to do blocking read/writes of comms because you don't want your comm errors to cause the ladder logic to just up and die...

Click to expand...

Can you perhaps include a litte detail about the above, it sounds totally the opposite of what i know of modbus in both theory and practice.

Which PLC was all this done on, what are the slaves, what baud rate are you running on, how long is your cabling etc. etc. ?

I would look at your code if its taking up to a minute to update 8 slaves with 8 values, my rough maths suggests that's transferring 64 words, 16 bits per word, 1024 bits, if you allow 200msec between reads that's seconds per full transfer, not 1 second per modbus read\write.

Something is obviously very wrong with your:

A - PLC application or
B - PLC hardware\firmware
C - Modbus slaves
D - Modbus cabling\network

In fact probably all of the above !!

First: using S7-224 and modbus RTU is a good working economical solution as the S7-200 just need the modbus Librairy to be added in the program and it is not so much difficult to work with.
Order #: 6ES78302BC000YX0
This package is good for all your next projects using modbuss(Different from S7-300 where you need to buy the soft with a chip for each module at a high level price)
S7-1200 is kind of a bit new and you need to add a serial module to work with Modbbuss it should work but i'm waiting V11 to shift with these CPU
If you know well Microwin soft, continue using it, you may get more troubles working with a new soft and plc from either Shneider or universal models offering Modbuss

Try Modbus Master for the respective port you will be using
You would need to determine a data area to receive values from VFD and just map them with the correct communication parameters.
You may also have to make your own DB9 cable

Hi Robert!

If you like to prog. in 'real' Step7, have a look at this S7300 clone. It has RS485 interface, with Modbus RTU master (among other protocols f.x. USS), has built-in memory, with integrated passive ethernet (server), is very speedy, can use S7300 IO, is made in Germany and is far from expensive. They've got representatives in US also.
I have used it and I like it .

Kalle

It IS a good rough 'order or magnitude' approximation to expect about a second for each modbus request/response (each command). To expect anything close to the next faster order of magnitude(100mS)will be disappointing when you start measuring your design's response.

I'm sorry if I wasn't clear that a rough approximation is just that...rough. We do a lot of things in engineeering where we try to approximate within an order of magnitude when we are considering a design. The closest order of magnitude when roughing out modbus speed is to figure around a second per request/response and you will be in the ballpark.

The beauty of modbus is its incredible simplicity. The trouble with modbus is its incredible simplicity. It is a shared communication bus with absolutely no provisions to determine the speed of masters and slaves: there is no holdoff algorithm to change delay in case of collisions or slow slaves so devices usually take a fairly pessimistic view in terms of the amount of time they wait between a request and a response. And keep in mind absolutely EVERY command is a request/holdoff for the slaves to see the command and bus to settle/response.

Hence the delay in each request/response on the order of hundreds of milliseconds. And that applies to each request/response. So if it takes a couple/three commands to perform a logical operation (very common), you are up at a second for a logical operation.

In terms of 'order of magnitude' rough approximations, you will be hard pressed to find a modbus system that can request/respond faster than 100mS reliably. The majority are in the hundreds of milliseconds by my experience. The only time I've seen around 100mS is for proprietary systems that knew the physical topology (short wiring + fast real-time OS slave command parsers + proper termination of every wire) and had custom drivers with very short times to allow the bus and all receiving devices to get off the bus for the slave response. Its much more common to be in the hundreds of milliseconds since device manufacturers have to expect slaves with typical OS ioctl times (100mS or longer) for the command parsers and long transmission lines that are not optimally terminated. Command parsers for the slaves are difficult to write without a context switch and context switches are notoriously expensive.

At one point in my career I designed protocol analyzers for three years; designed the hardware, wrote the drivers (including modbus), and tested across many, many brands. I've written and debugged modbus code in C, perl, assembly. I've had oscilloscopes stuck on many brands of modbus implementations including much of the Allen Bradley and GE PLC product lines.

So I'll stick with my assertion that 1 second is the closest order of magnitude to expect for a full request/response cycle for each modbus command - you will likely do better, but certainly not by an order of magnitude.