1756-EN2TR Flash to Lower Firmware

I'm not endorsing or advocating this sort of thing, I am just wanting to know if it even a possibility.

We have an L61 PLC with an IO Configuration that calls for the EN2T card at 2.1 fw. The fw on the PLC is v17. The EN2T is actually v4.4.

With v17 Logix, v4 fw revision is not an option in the IO configuration for that card. Have to go to at least v19 for that. Mgmt is leery of flashing the plc. I don't foresee any problems, there is no motion, no dnet or c-net either, but you never know.

So I'm just exploring all of our options, is "downflashing" even possible? Couldn't find anything on RA's website that speaks to it.

Thanks,
Dustin

V17 will work with en2t v4.4 without any issues.
Ser C en2t can't go below 3.3

Contr_Conn said:

V17 will work with en2t v4.4 without any issues . Series C en2t can't go below 3.3

Click to expand...

Thanks for the reply, but I am unable to select v4.4 for the en2t in v17.
My question is whether it is possible to flash the card to 2.1 or if there is a way to select 4.4 in v17.

I'm 99% certain that flashing the processor to v19 will cause no issues, but that 1% could mean 5 figures of lost production

You dont have to upgrade to v19 unless you must have CIP SYNC or CIP motion

Advice - stay in v17.
in V17: You don't have to select rev 4.4

- select 2.1 or what ever is highest major rev you can select
- set electronic key to "Compatible Module"

At this point any module rev 2.1 or higher (including your module 4.4) will work without any problems. But you will not be able to use V4 features like CIP Motion and CIP SYNC


If your module hardware is series "C" then you can't downgrade to ver 2.x - ser "C" hardware must have FW 3.6 of higher

Do you have a spare processor? Flash the new spare and try it. If you have issues snap the original back in.

Contr_Conn said:

You dont have to upgrade to v19 unless you must have CIP SYNC or CIP motion

Advice - stay in v17.
in V17: You don't have to select rev 4.4

- select 2.1 or what ever is highest major rev you can select
- set electronic key to "Compatible Module"

At this point any module rev 2.1 or higher (including your module 4.4) will work without any problems. But you will not be able to use V4 features like CIP Motion and CIP SYNC


If your module hardware is series "C" then you can't downgrade to ver 2.x - ser "C" hardware must have FW 3.6 of higher

Click to expand...

I have the module set to "Compatible Module" keying, and no we are not using any CIP motion or syncing. The issue is we have a proprietary SCADA system that we are having issues with, and all the HMI's communicate to this central PLC over the EN2TR in question. There have been some issues with loss of data transmissions from SCADA to PLC, and the tech support guys from the SCADA company are punting at this point, since they can point to the "physical mismatch" message in Logix and blame all problems on that.

It's not my baby, I've just been called in to offer input and potential workarounds. As I said, I don't think the card has anything to do with the problem, it's just buck passing.

I was able to get v2.1 firmware off the web, and downflashing is possible. But I'm not going to advise them to go that route. I think the best course is to wait until a holiday shutdown and upgrade the processor, then put the ball back in the SCADA guy's court.

@The PLC Kid,
I suggested the spare processor pre-flash, but mgmt was still uncomfortable. We have plenty of spares, they were still just worried about potential downtime. Our whole operation hinges on this one machine, so it's understandable. Thanks for the suggestion though.

Thanks again, guys.

Dustin

I am not sure how EN2TR came in this picture, we were talking abour EN2T?

All comments I made earlier and below are related to EN2T only:

Even 2.1 is selectable, you must check module label to make sure it is not a ser C.
A and B are OK
Ser C has different hardware and you WILL destroy the module if you do it.

It's possible that SCADA wants exact match but this has nothing to do with Logix - logix controller will be happy with no Faults.
You may see "Mismatch" warning under the "Module Info" tab, but this is only a warning and not a fault.

There are many other ways to troubleshoot Ethernet connections and verbal blame game is not one of them.

The processor upgrade is the last thing that I would recommend
I push to all my customers that you should not upgrade processor unless:
1. you have confirmed issue that only can be corrected by FW upgrade
or
2. you must have a new feature that is available only in new rev only.

In your case #1 does not apply at all,
#2 may apply only if SCADA guys have a solid proof that FW upgrade will fix the issue - so far they don't.

I am sorry yes the card in question is an EN2TR, ser B.
We have to upgrade the PLC to v20 at some point for the security features anyway (AssetCentre on remote server), so I believe the plan is to upgrade over the Memorial Day shutdown.

I realize that there are lots of ways to troubleshoot Ethernet connections, none of which I have done other than pinging the module and and verifying comms and device properties with RSlinx. I don't know to what extent the SCADA guys have dug into the problem, and I know very little about the SCADA software. I'm just a 3rd party in the situation, and I don't have time at this point to dig much deeper into the problem.

Rules for EN2TR ser B are similar to EN2T ser C:
- you should not go below 3.6, module has a different hardware than ser A
http://literature.rockwellautomation.com/idc/groups/literature/documents/rn/1756-rn659_-en-p.pdf

Hey everyone. I'm struggling with this problem myself and here is what I know.

DO NOT FLASH Rev 5.028 to the1756-EN2TR in a DLR scenario it has the following problem.

540274 - 1756-ENxTx rack optimized outputs briefly transition to an un-commanded state on connection establishment
Access Level: Everyone
Date Created: 04/16/2013 09:03 AM
Last Updated: 04/24/2013 02:58 PM

Anomaly Description
When a 1756 Discrete Output Module utilizing a Rack Optimized connection in a remote chassis establishes a connection, outputs will briefly transition to a random non-commanded state. This time period starts when a new connection is established and ends when the first data is received from the Controller.

Connection Establishment can occur by:
1. Network cable break and reconnect
2. Project download to the controller
3. Power cycle
4. Inhibiting/uninhibiting the communications bridge or adapter in the Logix application
5. First time the connection is made
Rack Optimized connections are made by configuring the communications adapter rack connection to "Rack Optimization". This configuration is done in the I/O Configuration of RSLogix5000 or Studio5000 programming software. To use a direct connection the rack connection should be set to "none".

Effect of Anomaly
1756 Discrete Output Module utilizing a Rack Optimized connection in a remote chassis briefly transition to a random non-commanded state.

For Example: outputs that should be off may turn on, outputs that should be on may turn off.
Product Family
Firmware revisions 5.007, 5.008 and 5.028 of the following catalog numbers are affected:
• 1756-EN2F A
• 1756-EN2F B
• 1756-EN2T A
• 1756-EN2T B
• 1756-EN2T C
• 1756-EN2TR A
• 1756-EN2TR B
• 1756-EN2TSC A
• 1756-EN2TXT B
• 1756-EN2TXT C
• 1756-EN3TR A
• 1756-EN2TRXT B
Note: Firmware revision 5.007 was posted on Jan 2012.
Note: This anomaly only effects the module and firmware used as the communications adapter in the remote output chassis. For example, the controller chassis can have v5.008 on a local 1756-EN2T, but the remote chassis can have v4.xxx on it's 1756-EN2T. In this example the system would not be effected by this anomaly.
Resolution
Application Work Arounds
1. Change the remote I/O configuration in the Logix application to use direct connections. This can be accomplished by setting the communications adapter rack connection to "None". Do not use the rack connection of "Rack Optimization" for remote I/O.
2. Change the firmware in the communication module in the remote I/O chassis to v4.x. This firmware is not affected by this anomaly. Modules using v5.028 firmware will not have this option. That firmware is signed and modules using it cannot be flashed back to unsigned firmware.
Note: Logix Redundancy users do not have to have the same firmware in remote chassis communications modules as are used in the controller chassis. For example, the controller chassis can have v5.008 on a local 1756-EN2T, but the remote chassis can have v4.xxx on it's 1756-EN2T. In this example the system will synchronize as normal and not be effected by this anomaly.