How to do modbus mapping & addressing

John Morris said:

I understand where you are coming from Dan. How to begin.

I have read all the links (many I have seen before) and I understand much better now how Modbus is supposed to work. The fundamentals.

But if I had to sit down and write out a Modbus program, I wouldn't know where to start. Big grey area there. I can write program don't get me wrong, 5000, 500, Idec, National instruments. You get the idea. But I don't know how to write out Modbus. That being said someone will come along and say "It's the same as........." and we will of course feel like Derp's

I have to write a program in the fall that will communicate with a burner control, along with all the warnings, failure notices, ect. In Modbus with a PLC and HMI

I have been trying to figure out how to put into a program for about three weeks now as side work, but I am completely clueless on what the program would look like.

So Dan, I feel ya. and if I figure it out, I send you my notes and some code to get started.

Click to expand...

Hi John, you really understood my situation. I appreciate. I've been reading some materials but honestly, they are not hitting the nail on the Head. If I can see a sample, my life will not remain same. Lots of challenges at hand running co-currently in my head right now and at the office. I will appreciate.


Regards

there really is no generic modbus addressing or mapping info out there. the problem is that while modbus is supposed to be a standard protocol, its an open protocol. meaning its been *******ized a lot over the years. other posters are right when they say its very specific based on the master device and slave device. how you program both are on a case by case basis.

the basics are you need to know the device address, and the function code and register you want to access. sometimes, if the master device is smart enough you dont even need to know the function code you want to use. they are right to point you to the modbus links for the basic understanding of the protocol. you just need to start there then read the manuals for the devices you plan to interface.

also when you do figure out the basics and get them talking, there is an issue that most manuals wont warn you of. zero address offset. depending on the devices, you will run into an issue where you want to read holding address 40015 but you are getting the data in 40016. sometimes you have to set your master to read 40014 when you really want to read 40015, or vice versa. this is because some devices are base 0 and some are base 1.

essentially the modbus basics are where others pointed you to, and as soon as you get into specific devices it gets very specific very quickly.

Ok

I get that, but what would it look like in say rs5000. Would it be as simple as a MSG instruction.

And if there is an alarm in the burner control? Since communication is initiated only in one direction, do I pole those addresses once a second. (all 126 of them too)

John, it depends on the Gateway you are using.

Generically speaking, anytime one works with communication, engineer the comm on paper. What I suggest is you create a spreadsheet that document the memeory location from one end to another and also the physical and protocol link.

Example.

From (A) Logix 5000 to (B) modbus Gateway to (C) Burner.

Physical: A-B, ethernet; B-C, 2-wire RS485

Protocol: A-B, Ethernet/IP; BC, modbus RTU

Modbus specific: BC, B-Master, C-Slave

If that works out from end to end, proceed to map the memory locations, best using a table or spreadsheet:

A (Temp TI-425) - B (3000) - C (30450)

etc..etc..

John Morris said:

Ok

I get that, but what would it look like in say rs5000. Would it be as simple as a MSG instruction.

And if there is an alarm in the burner control? Since communication is initiated only in one direction, do I pole those addresses once a second. (all 126 of them too)

Click to expand...

Might this be a Weishaupt or Siemens Combustion Manager?

Here are a few basic points to help summarize the information, as I have been learning modbus on this project as well:

There are some basic functions and data types of modbus. The implementation and naming varies a bit between vendors, but there are a few consistencies:

Coil: this is basically a BIT that represents ON/OFF states
Register: This is a 16 bit integer that represents a value

Each type of read has a function code that is put into the packet. To read a Coil, the function code is 0, to read a register, the function code is 3.

You can read multiple coils or registers. You do this by specifying a start address for a coil or register. Then you specify a length. The length is the number of coils or registers you wish to read. The function code determines if you are going to read 16 coils (which would be 16 bits) or 16 registers (which would be 16 words). EACH DEVICE IS HAS ITS OWN MAX NUMBER OF COILS OR WORDS YOU CAN READ OR WRITE AT THE SAME TIME

There are subtle differences between each device, and you MUST read the manual to understand the requirements and limitations of modbus on that device. There is no "way to configure modbus" as it is very specific to each unique device. Modbus only deals with the actual format and transfer of the data. It is a PROTOCOL.

Hope this helps a bit.

Boneless it's a Honeywell

It does, thank you Sparkie

Harry, Thank you, that is a world of information I will use.

And all, Please forgive this derpish question

[].......[]............()<<<<<<<But what goes here? How do I get the request out of the PLC on to the Ethernet.

My experience in comm's is limited from the PLC to the HMI and my laptop. I have written for Scada once but I never saw it implemented.

Your understand and tolerance is very much appreciated.

John Morris said:

Boneless it's a Honeywell

It does, thank you Sparkie

Harry, Thank you, that is a world of information I will use.

And all, Please forgive this derpish question

[].......[]............()<<<<<<<But what goes here? How do I get the request out of the PLC on to the Ethernet.

My experience in comm's is limited from the PLC to the HMI and my laptop. I have written for Scada once but I never saw it implemented.

Your understand and tolerance is very much appreciated.

Click to expand...

What kind of specific PLC? What kind of specific HMI? What is that supposed to be? Is it addressing? Is it in the PLC? Without any context that is gibberish. Could you provide screenshots of what you are trying to set up?

Sorry Sparkie

It was my bad attempt at two bits and an output.

We will probably end up using a small compact logix. I have not made the design layout yet. just know it's going to be in rs5000 and a Honeywell burner control.

The whole thing is stupid simple, it's on/off, no modulation, PID,

The Idea is that all of the error, warnings, codes from the Honeywell are retrieved interpreted and displayed to the operator with comprehensive instructions for correction or repair.

The Honeywell comm's in Modbus.

sparkie said:

Here are a few basic points to help summarize the information, as I have been learning modbus on this project as well:

There are some basic functions and data types of modbus. The implementation and naming varies a bit between vendors, but there are a few consistencies:

Coil: this is basically a BIT that represents ON/OFF states
Register: This is a 16 bit integer that represents a value

Each type of read has a function code that is put into the packet. To read a Coil, the function code is 0, to read a register, the function code is 3.

You can read multiple coils or registers. You do this by specifying a start address for a coil or register. Then you specify a length. The length is the number of coils or registers you wish to read. The function code determines if you are going to read 16 coils (which would be 16 bits) or 16 registers (which would be 16 words). EACH DEVICE IS HAS ITS OWN MAX NUMBER OF COILS OR WORDS YOU CAN READ OR WRITE AT THE SAME TIME

There are subtle differences between each device, and you MUST read the manual to understand the requirements and limitations of modbus on that device. There is no "way to configure modbus" as it is very specific to each unique device. Modbus only deals with the actual format and transfer of the data. It is a PROTOCOL.

Hope this helps a bit.

Click to expand...

Very informative,
Thanks bro.

Sapper307 said:

there really is no generic modbus addressing or mapping info out there. the problem is that while modbus is supposed to be a standard protocol, its an open protocol. meaning its been *******ized a lot over the years. other posters are right when they say its very specific based on the master device and slave device. how you program both are on a case by case basis.

the basics are you need to know the device address, and the function code and register you want to access. sometimes, if the master device is smart enough you dont even need to know the function code you want to use. they are right to point you to the modbus links for the basic understanding of the protocol. you just need to start there then read the manuals for the devices you plan to interface.

also when you do figure out the basics and get them talking, there is an issue that most manuals wont warn you of. zero address offset. depending on the devices, you will run into an issue where you want to read holding address 40015 but you are getting the data in 40016. sometimes you have to set your master to read 40014 when you really want to read 40015, or vice versa. this is because some devices are base 0 and some are base 1.

essentially the modbus basics are where others pointed you to, and as soon as you get into specific devices it gets very specific very quickly.

Click to expand...

I appreciate your input bro

My app note, Baker's Dozen Rules for reading the Modbus Fault Code" from a Honeywell RM7800 flame safety controller covers some of the things you'll encounter with the Honeywell. Variables other than the fault codes can be read from an RM7800; what you get depends on which register addresses the master requests.

https://danstips.files.wordpress.co...s-dozen-tips-modbus-rtu-honeywell-rm7800s.pdf

Since the Honeywell is the slave, the note does not cover setting up a master (the PLC) to poll for the data, and as others have pointed out, setting up a Modbus master is very device-specific.

https://danstips.files.wordpress.co...s-dozen-tips-modbus-rtu-honeywell-rm7800s.pdf

I ran across that paper about two months ago searching out Modbus protocols.

Ya know what, I haven't asked the right question yet!

What format in RS5K would I need to write the protocol in. A msg instruction is what i am most familiar with, but what other formats can the protocol be written in to accomplish polling coils, registers, errors, warnings, ect. and how is it sent out of the PLC (1769 series).

Honeywell BMS modbus functions are described in the "keyboard display module" manuals. Honeywell BMS are made up of a bunch of different modules, but Modbus tables are in the keyboard manual. for instance, an S7800A1142 is described in appendix e. fault codes newest to oldest would start at modbus register 40017 and end at 40076. you would get a series of integers that represent fault code, fault string, sequence state, first line message, second line message sequence time, total cycles, and total hours. all but the last two are 16 bit integrers. the last two are 32 bit, meaning the master would have to poll two consecutive 16 bit registers.

once you get the integers, you have to decode them. the manual has table for that. IE a fault code 31 would be a "LOW FIRE SW OFF". There are 255 possible codes. A sequence state 6 would be "STANDBY", there are 82 possible sequence states. There are 223 possible string codes. It would take alot of programming on the HMI side to associate the string of modbus values to get an alarm "LOW FIRE SWITCH OFF - STANDBY MODE" from the total possible array of values. I know, I've done it.

In my case the slave was the honeywell keyboard module (which you set the modbus address from the keyboard itself). the master was a GE RX3i PLC with an IC695CMM002 serial communication module. GE serial comms programming is obviously specific. Honeywell keyboard is RS485 only, so make sure you use correct terminal resistance on both ends even if you only have two devices.

Honeywell modbus capable keyboard manual:
https://www.ccontrols.com/support/dp/65-0288-1-S7800A1142.pdf

I have that downloaded already. Thank you.

That's a gazinta I need a gozouta. ( What my third year professor use to call inputs and outputs.)

How do you write the protocol inside the PLC to request this information. Last piece of the puzzle for me ( and probably for Dan too). What form would the request take.