Critical Issue with ControlNet

dougrb

Member
D
Join Date
Oct 2005
Location
Kansas
Posts
39
This has not been officially released yet, but we have been given the O.K. to spread the news.

To: International Product Managers, North American FBL / TC / SA's, and RCM's

There is an issue embedded in ALL Series E 1756-CNB(R) and 1756-CN2 modules.

After 71 days without a power cycle, the module will stop communicating. Many customers are seeing this now. We are in the process of doing a Product Service Advisory. However, if you have critical ControlNet customers, with these modules, we suggest that you tell them to cycle power as soon as possible to prevent unexpected outages (with a power cycle, the problem will be fixed for another 71 days).

We will have a firmware fix available in the next few weeks.

Sincerely,
Gordon Daily

Rockwell Automation
NetLinx Product Marketing - ControlNet
440-646-3195
 
Fire ! FIRE ! Get out of the theater !

What an excellent opportunity for our Forum members to get acquainted with their local Rockwell Automation office.

For those of you in Oregon, Washington, northern Idaho, western Montana, and Alaska: Drop me a line if you have any problems, questions, or concerns about your ControlNet modules.
 
This is an actual issue. I learned about it yesterday during a monthly conference call. If you have 1756-CNB/E or -CN2 modules, go ahead and call your Rockwell office. Maybe this is a good time to call them anyhow, if you have any concerns about compatibility or performance of any of your modules.

What it's not is a safety hazard (the modules fail to communicate but do not perform uncommanded actions, and report their failure correctly) or a reason for non-ControlNet users or Rockwell competitors to get excited about a relatively small number of modules (several hundred, as contrasted to the tens of thousands of 1756-CNB Series A, B, C, and D modules in service).

Upgrading these modules is a two-minute exercise using the ControlFlash utility.
 
Ken Roach said:
What it's not is a safety hazard (the modules fail to communicate but do not perform uncommanded actions, and report their failure correctly) or a reason for non-ControlNet users or Rockwell competitors to get excited about a relatively small number of modules (several hundred, as contrasted to the tens of thousands of 1756-CNB Series A, B, C, and D modules in service).

Upgrading these modules is a two-minute exercise using the ControlFlash utility.
Click to expand...

Ken,

it may seem easy , but when you have these cards in plants that run 24/7 with high temperature sterilizers, shutting down the process for 2 minutes means 2 - 3 hours of lost production time to resterilize the equipment.

Ian
 
Believe me, I'm not happy about this either.

I'll amend one statement above; there are a lot more CNB/E in the field than I'd estimated. I just haven't seen more than a few hundred in my own territory.

I just wish we could handle technical support at, you know, Technical Support.
 
Last edited:
dougrb said:
This has not been officially released yet, but we have been given the O.K. to spread the news.

To: International Product Managers, North American FBL / TC / SA's, and RCM's

There is an issue embedded in ALL Series E 1756-CNB(R) and 1756-CN2 modules.

After 71 days without a power cycle, the module will stop communicating. Many customers are seeing this now. We are in the process of doing a Product Service Advisory. However, if you have critical ControlNet customers, with these modules, we suggest that you tell them to cycle power as soon as possible to prevent unexpected outages (with a power cycle, the problem will be fixed for another 71 days).

We will have a firmware fix available in the next few weeks.

Sincerely,
Gordon Daily

Rockwell Automation
NetLinx Product Marketing - ControlNet
440-646-3195
Click to expand...

Is this another issue on top of the one that was corrected in version 10.6 and 10.7 as per Rockwell's firmware update site?
 
This little snippet of code must have been used in a fair amount of firmware before it was caught. We had drives do ime out and not start back, some L55 processors with certain V15 firmware quit working, and now these. All of this in the last 6 months. I like AB stuff and use it a lot, but hopefully they are learning something from this.
 
I just wish we could handle technical support at, you know, Technical Support.
Click to expand...

I'm not sure I get what you're saying Ken? From what I understand, this issue has been known for about a month... and now we're hearing about. We have a system going in next week. We think we will be able to get some downtime within the 71 days to update firmware. If we had known about it a month ago we may have elected to go with series D's. And another tidbit... you cannot backflash a series E to a D. Different hardware.
 
To my knowledge you have never been able to "Flash" a series change, only the rev within the series. I do not think that has ever been possible?

RSL
 
While I agree that this isn't the end of the world as we know it, it is also of no value to downplay it. Sure, it doesn't affect everyone and the fix is easy. But it sure could be a serious pain in Ian's groin when he has to power down.

It really is about information. This is alot easier to manage if you know about it. I'll let you know when I get my Rockwell technical bulletin on this. I know that Rockwell is a big company but the letters should be in the mail as we speak.


Keith
 
Is this another issue on top of the one that was corrected in version 10.6 and 10.7 as per Rockwell's firmware update site?
Click to expand...
Correct, this is still open issue.
FW 10.6 and 10.7 supposed to fix this issue, but issue still exists.
 
Contr_Conn said:
Correct, this is still open issue.
FW 10.6 and 10.7 supposed to fix this issue, but issue still exists.
Click to expand...

Beauty,
We just installed a Series E. Plc has been online for about 30 days, so I guess we have 41 more to go. It is in a plant that runs around the clock producing egg patties for breakfast muffins.

Ian
 
curlyandshemp said:
Beauty,
We just installed a Series E. Plc has been online for about 30 days, so I guess we have 41 more to go. It is in a plant that runs around the clock producing egg patties for breakfast muffins.

Ian
Click to expand...

Are you saying I ought to enjoy my Egg McMuffin while I still can?

Can anyone say why the hardware got upgraded to Rev E? Was there something wrong with the Rev D hardware?
 
Can anyone say why the hardware got upgraded to Rev E? Was there something wrong with the Rev D hardware?
Click to expand...
I can answer this question:
Some Ser D componets no longer available as well as connection limitations.
CN2 and CNB/E have similar hardware design based on 1756-ENBT.
With CNB/E (after FW fixed) you can get more connections per NUT than with CNB/D.
CN2 module has additional enhancements that allow double performance of CNB/E and CNB/D.
New CN2/B based on 1756-EN2T will be coming out next year.
 

Similar Topics

Y
RnaAlarmDetector, RTE_ERROR_CRITICAL
Hi All Does anyone know what is a root cause of such an error? How to avoid it?
Replies
0
Views
960
Yashka
Y
T
System Platform 2020 R2 P1 - Secure Critical Severity Alarm Ack by User/Role
Is there a way to tie the ability to acknowledge different alarm priority or severity levels with security roles? It's not looking like there is...
Replies
0
Views
1,038
Tanquen
T
K
Schneider Modicon Premium TSX P57203Controller issue
Everything was working fine, but suddenly CPU went into error mode, and the ERR and TER LEDs lit up. Now I can't download or connect with the PLC...
Replies
0
Views
36
[email protected]
K
A
WinCC Unified and PLC weird communication issue
I have created a project in TIA Portal v16 Upd6 with S7-1200 (6ES7214-1AG40-0XB0) and WinCC Unified (PC station). The communication between the...
Replies
4
Views
145
mk42
M
P
AB PLC, Rslogix 5000, alarm issue
Hi folks, in the alarm manager of Rslogix 5000, the tag-based alarm has been created. But when I tried to change the condition, it was found the...
Replies
2
Views
153
PLCbug123
P
Back
Top Bottom