Jump to content

Modbus Check Sum


Jenkins

Recommended Posts

To whom it may concern:

I would like to the ability to change the byte order in the CRC of the Modbus Config FB. My reason for this is primarily by use of modbus and VFDs. It seems that depending on manufacturer, the byte order could be LSB, MSB or MSB, LSB. If we had the ability to change this with a simple setting it would replace "work around" code using the Protocol FB.

Just a suggestion.

Jenkins:huh:

Link to comment
Share on other sites

  • External Moderators

Hi Jenkins,

Just out of curiosity, what is the brand of the VFD?

From what I've read on the Modbus Protocol Specification, the CRC should always be sent in MSB then LSB Order.

The Data of a Modbus Message is reversed, so everything is sent in LSB then MSB order.

Chances are the VFD Manufacturer has not kept to a Standard for CRC16.

Still, I do see the use of this addition to VisiLogic as we cannot guarantee every manufacturer will stick to a "Standard".

Link to comment
Share on other sites

Hello Ash,

From what I have read in document PI-MBUS-300, it is the opposite where the data is high byte, low byte and the CRC is low byte, high byte.

post-52-013204800 1301075112_thumb.png

post-52-072668500 1301075110_thumb.png

The brand VFD I am talking about is a Mitsubishi FR-D700. Below is their message structure.

post-52-042579700 1301075111_thumb.png

Another product that adheres to this structure, that I have found, is Motortronics VMX Soft Starter. This is taken from their Modbus documentation.

post-52-055484700 1301075112_thumb.png

On the flipside is Yaskawa. I have used these VFDs with great success using Modbus and they structure their message the same as Unitronics (high byte, low byte on data & CRC)

post-52-095126300 1301075112_thumb.png

We could easily use many more products with built in Modbus FB's by adding an option for changing byte order on CRC and maybe even on the data if some manufacturer decides to go off the standard.

Thanks for listening!

Jenkins

Link to comment
Share on other sites

I've done a ton of modbus over the years, and I have never seen a byte swap on the CRC.

Maybe I've just been really lucky.

If they did this, they are making it virtually incompatible with every other modbus device out there I would think.

Byte swap on the data value is pretty common. Is it possible you mean this instead?

Link to comment
Share on other sites

I've done a ton of modbus over the years, and I have never seen a byte swap on the CRC.

Maybe I've just been really lucky.

If they did this, they are making it virtually incompatible with every other modbus device out there I would think.

Byte swap on the data value is pretty common. Is it possible you mean this instead?

Hi Jenkins,

I did some more looking and can't find one single instance of a manufacturer using a byte swap on the CRC. The confusion seems to be with the modbus documentation itself. Apparently the algrithm for generating the CRC already effectively performs the byte swap during the processing. As a result, the calculated low byte of the CRC is stored in the High byte, and the calculated high byte of the CRC is stored in the low byte. I have done modbus to Mitsubishi drives in the past, and everything worked fine.

Have you actually attempted to try the communication "as is" between the Uni and the FR VFD? You'll probably find it actually does work and that it is just a matter of some very poor documentation that is at best very confusing and misleading.

this is a link to a discussion I found that covers it.

http://modbus.control.com/thread/1026168695

D

Link to comment
Share on other sites

Damian,

Thanks for the response. Reading those forum posts were very enlightening. Here is some history on my end.

On the soft starter I listed above, there was a RS485 Modbus network with 20 Yaskawa VFDs and 1 VMX Soft starter. The VMX was in the middle of the daisy chain and was not communicating but all of the other devices were. In contacting that company and explaining our situation. They came to the conclusion that it was the CRC byte order.

I was not present but had a trusted associate actually attempt to connect to the Mitsubishi VFD. Over the phone, we troubleshot the cable, parameters, terminal resistance, addressing, ladder logic, baud rate, parity, stop bits, etc. We made a test program, with only the modbus in it with one present single holding register command. Still no response.

I wrote down that string that was being sent via INFO mode. It was 65 06 9349 0000 7E68. I saw how the CRC was being sent "7E68". I then went to this website here. The bytes were swapped "687E". I made the conclusion that the byte order is reversed.

If you have ever programmed an Automation Direct C-More HMI, when setting up the driver for Modbus you have options to change byte order. Maybe they have found something or decided to appease people. I don't know.

I have an appointment with our customer with the Mitsubishi VFD and I will hopefully come back pleasantly surprised. Either way I will definitely post back what I find.

Thanks again for you responses.

JENKINS :huh:

Link to comment
Share on other sites

Damian,

Thanks for the response. Reading those forum posts were very enlightening. Here is some history on my end.

On the soft starter I listed above, there was a RS485 Modbus network with 20 Yaskawa VFDs and 1 VMX Soft starter. The VMX was in the middle of the daisy chain and was not communicating but all of the other devices were. In contacting that company and explaining our situation. They came to the conclusion that it was the CRC byte order.

I was not present but had a trusted associate actually attempt to connect to the Mitsubishi VFD. Over the phone, we troubleshot the cable, parameters, terminal resistance, addressing, ladder logic, baud rate, parity, stop bits, etc. We made a test program, with only the modbus in it with one present single holding register command. Still no response.

I wrote down that string that was being sent via INFO mode. It was 65 06 9349 0000 7E68. I saw how the CRC was being sent "7E68". I then went to this website here. The bytes were swapped "687E". I made the conclusion that the byte order is reversed.

If you have ever programmed an Automation Direct C-More HMI, when setting up the driver for Modbus you have options to change byte order. Maybe they have found something or decided to appease people. I don't know.

I have an appointment with our customer with the Mitsubishi VFD and I will hopefully come back pleasantly surprised. Either way I will definitely post back what I find.

Thanks again for you responses.

JENKINS :huh:

Hi Jenkins,

To what address are you trying to write to in the VFD? Based on your data field above, you are using a function code 06 to write a value of 0 to address 37,705. This address value does not appear to be in range of any holding registers in the VFD. When you are entering a value into the slave operand address, are you entering it as a HEX or a DEC value? What value is it? The address value 9349 doesn't seem right.

D

Link to comment
Share on other sites

Hi Jenkins,

In order for me to duplicate your output buffer i had to use a modbus offset of 37705. Looking at my FR-D700 manual, they do not list any offsets above 4000. At least in this specific instance, it is very likely that you aren't getting a response because you are trying to write to an unavailable memory area.

My transmit buffer is as follows 65 06 93 49 00 00 7D 7C

I'm also not susre why you were getting a CRC of 7E 68 as on my V570 it shows it as 7D 7C.

D

Link to comment
Share on other sites

AHHHHHH!

This is what I get for doing this at work when I am slammed and half the office is out.

Damian,

I made a typo. It is suppose to be address 9C49 hex, which is 40009 dec. In the Mitsubishi manual, that is the register for "Inverter status/control input instruction". Apparently you read and write to that register.

Sorry for the typo.

J3nkins

Link to comment
Share on other sites

AHHHHHH!

This is what I get for doing this at work when I am slammed and half the office is out.

Damian,

I made a typo. It is suppose to be address 9C49 hex, which is 40009 dec. In the Mitsubishi manual, that is the register for "Inverter status/control input instruction". Apparently you read and write to that register.

Sorry for the typo.

J3nkins

Hi Jenkins,

There is more. If you are looking to read 40009 in the drive, you need to subtract 40001 from you parameter number. Therefore, the number you need to put in as your target address is actually (40009-40001) = 8. This is considered the "offset". The 40000 part is implicitly understood in this case by way of the function call you are using. So the actual stream you send to the "inverter control input" parameter of the drive should look like this. 65 06 00 08 00 00 XX YY where XX and YY are whatever the checksum ends up being.

From page 206 in the FR-D700 manual.

gallery_93_13_19668.jpg

Please try this and let me know how you make out.

Also, I made a post yesterday that still hasn't made it through moderation yet. So it will be a bit behind the times. I hope this goes through at least at the same time.

D

Link to comment
Share on other sites

Damian,

THANKS! We have successful communication! I really appreciate you helping me. I will admit, I feel a little foolish for missing that but am happy to report it works with the Mitsubishi.

On a side note, I have talked to my customer on that soft starter I mentioned in earlier posts and we can't get that to work.

He is going to put his sniffer back on and "fake" some example messages as they are still not communicating. We don't have an offset issue there, thankfully. I will also post any update from that project as well.

In case anyone is interested, I am attaching the modbus documentation for the Motortronics VMX Modbus instructions.

Thanks again!

Jenkins (needs to improve reading skills) :blink:

VMX_mb_reg_map_07292009_release.zip

Link to comment
Share on other sites

Damian,

THANKS! We have successful communication! I really appreciate you helping me. I will admit, I feel a little foolish for missing that but am happy to report it works with the Mitsubishi.

On a side note, I have talked to my customer on that soft starter I mentioned in earlier posts and we can't get that to work.

He is going to put his sniffer back on and "fake" some example messages as they are still not communicating. We don't have an offset issue there, thankfully. I will also post any update from that project as well.

In case anyone is interested, I am attaching the modbus documentation for the Motortronics VMX Modbus instructions.

Thanks again!

Jenkins (needs to improve reading skills) :blink:

Jenkins,

Your welcome. Glad to hear you were at least able to get the VFD to communicate. For some reason I was unable to open the file you posted. It says it is corrupt.

D

Link to comment
Share on other sites

Hi Jenkins,

I do believe still that you raise a good point regarding a word and byte swap on the data values. I have been really fortunate when communicating with the Unitronics that the device i was communicating with had the word swap features built in when they have been needed. I have yet to see anything that requires a btye swap as well, but I did read theat they exist. But at least the word swap on the data value is pretty common and should be built in to the Uni somehow.

D

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...