Modbus RTU - "Invalid data in response" after change to 2.9

[jcb]

This could be something else but one of the guys updated the program software to 2.9 which required the PLC to be put into Program mode.

We did not update the firmware just the programming software so I don't think this could be the cause.

After it was back online we have a Modbus RTU codeblock that reads data from Motor Overloads. All the Intstructions now give Invalid data in response.

I turned off the code block and attempted a read from just one overload with the new Modbus scanner and it also gives invalid Data in Response.

My Serial Settings are 19200 / 8 / e / 1 and these are Eaton XTOE overloads. All of this has been working fine for going on 2 years. I attempted to isolate the wiring but get the error on the first branch and unable to communicate on the rest. I was going to take a test overload up and hook it right into the PLC to see if it is a comm issue or a wiring issue.

Just figured i'd post here to see if anyone ran into something similar?

I just upgraded the firmware to 2.9.3 at lunch today and got no change.

Thanks
John.

[BobO]

This could be something else but one of the guys updated the program software to 2.9 which required the PLC to be put into Program mode.

We did not update the firmware just the programming software so I don't think this could be the cause.

After it was back online we have a Modbus RTU codeblock that reads data from Motor Overloads. All the Intstructions now give Invalid data in response.

I turned off the code block and attempted a read from just one overload with the new Modbus scanner and it also gives invalid Data in Response.

My Serial Settings are 19200 / 8 / e / 1 and these are Eaton XTOE overloads. All of this has been working fine for going on 2 years. I attempted to isolate the wiring but get the error on the first branch and unable to communicate on the rest. I was going to take a test overload up and hook it right into the PLC to see if it is a comm issue or a wiring issue.

Just figured i'd post here to see if anyone ran into something similar?

I just upgraded the firmware to 2.9.3 at lunch today and got no change.

Thanks
John.

That gets set when we process the response packet and the response isn't well formed. Verify that your port settings are what you expect. The program had to go to program mode, which means the sysconfig was updated. I guess it's possible that something didn't propagate as intended.

[jcb]

I just duplicated it in my shop with another BRX and a single overload.

It has to do with termination. Maybe you guys changed something to mess with guys with dirty unterminated modbus runs.

If I enable 120 ohm termination it works fine in the shop. When i disable it i get the invalid data. My run in the shop is not terminated on the overload side.

I'm going to go check the modbus run on the plant install and make sure the end is terminated properly. where did i put those pesky resistors.

I'll post back in a few minutes

[jcb]

Well I added 120 ohm resistor to the end of the loop and another one at the plc. I have termination turned off and cannot switch to program mode to turn it on because we are running production.

Still just a log full of invalid data responses.

I disabled the code block and will have to check it out after they shutdown tonight and see if i can figure out whats wrong.

[mhw]

I just updated one of my customers to 2.9.2 this morning. Now I have lost RTU coms to four SR55s and a GS3. The termination resistor did not help. Is there a way to go back on firmware so that I can get them going again?

[jcb]

I also am not able to get comms going on my factory system.

I'm only using it for monitoring motor currents for predictive maintenace. All my critical current feedbacks are wired into analog inputs.

On my shop system I had full comms and no errors friday when I left. This morning I came in and now have "Invalid Data in response". I turned off terminatation and turned it back on and it started communicating again.

You might want to try that just to see if it gets you going?

I'm curious what changed in the sysconfig that would prevent comms from working? This happened prior to me updating the firmware. So it must be a software setting of some type that caused it.

[mhw]

My mistake, all but one SR55 came back after the termination resistor was installed. Power cycling that device brought it back to life. Now if I disconnect the term resistor it stays working. I may have just had a panic attack. Either way the resistor is staying in.

[BobO]

I also am not able to get comms going on my factory system.

I'm only using it for monitoring motor currents for predictive maintenace. All my critical current feedbacks are wired into analog inputs.

On my shop system I had full comms and no errors friday when I left. This morning I came in and now have "Invalid Data in response". I turned off terminatation and turned it back on and it started communicating again.

You might want to try that just to see if it gets you going?

I'm curious what changed in the sysconfig that would prevent comms from working? This happened prior to me updating the firmware. So it must be a software setting of some type that caused it.

That's why I suggested you review the serial setup. We fixed at least one bug in the migration of serial settings when updating the sysconfig. I'm starting to wonder if we introduced another.

[Greg]

...Is there a way to go back on firmware...?

When you do a firmware update, the previous version of the firmware is retained. So, if you power down the PLC, flip ON dipswitch 0, and power back up, the PLC will load the oldest copy of the firmware.

[jcb]

My Serial settings all appear to be the same as they where prior to the update.

[BobO]

My Serial settings all appear to be the same as they where prior to the update.

But you cycled the termination, right?

[Controls Guy]

Well I added 120 ohm resistor to the end of the loop and another one at the plc. I have termination turned off and cannot switch to program mode to turn it on because we are running production.

The termination in the software is for if you do NOT have an external resistor on the PLC port, so don't do both.

[jcb]

So I went out and enabled termination on the Local PLC and removed the Local Resistor. I also installed a RS485 POM to switch over to if problems persisted.

Powered it back up and it's working fine now.

This is the first time we have cycled power since turning off and back on termination in the software.

I will check it over the next few days and report back if I have any additional problems.

John.

[Controls Guy]

[shrug]  It's that voodoo that it do do so well.   Glad it's working.

[jcb]

So.. I didn't even get to finish my lunch before it started back on "invalid data" from a working state with no changes just like the one in my shop did over the weekend.

I switched it over to the POM and changed my MRX instruction. Seems to be working well that way.

I noticed there is no Termination switch in the POM configuration.

Problem is most likely something in the termination or noise on the line that is now causing the newer software to reject the packets.

Hopefulling it will run on the POM for the rest of it's days or next I'll migrate it to a digi IAP.

I