Change "Major fault if connection fails" in logic

cd36

Member
Join Date
Nov 2018
Location
Mb
Posts
6
Hey,

I'm working on a system that is going to be somewhat modular in nature, and Ethernet based, using CompactLogix and Studio 5000. For all my modules I need to have the "Major Fault on Controller if Connection Fails While In Run Mode" enabled, to make sure I don't lose connection to a module I should have communication to.

The issue comes in when they change configurations of the equipment, they may remove some of the modules. They'll have to make the corresponding change in the configuration section of my program when they remove a module so that the program knows it is missing. Now I will want to disable the "Major Fault on Controller if Connection Fails While In Run Mode" function, using logic.

My reseller gave me instructions on how to inhibit the module all together using an SSV, but I'm not sure if inhibiting the module will prevent a major fault from occuring if the module is missing. I won't be able to do any testing until this weekend, so I wanted to ask if anyone would know if inhibiting the module is going to work for what I need it to do, or if there is a SSV command I can use to enable and disable the "Major Fault on Controller if Connection Fails While In Run Mode" selection, depending on configuration.

Thanks!
 
Great question, and fortunately the answer is Yes !

The two check-boxes on the Connection tab for the I/O modules can be read and written by the same GSV/SSV instruction.

It's the Mode attribute of the Module object.

From the Help file, under "GSV/SSV Objects":

Bit 0 If set, causes a major fault to be generated if any of the MODULE object connections fault while the controller is in Run mode.

Bit 2 If set, causes the MODULE object to enter Inhibited state after shutting down all the connections to the module.
 
Great question, and fortunately the answer is Yes !

The two check-boxes on the Connection tab for the I/O modules can be read and written by the same GSV/SSV instruction.

It's the Mode attribute of the Module object.

From the Help file, under "GSV/SSV Objects":


Hey thanks for the help, that's quite simple. I'll just change my software from toggling bit 2, to toggle bit 0 instead. Easy!
 
Hey,

..... For all my modules I need to have the "Major Fault on Controller if Connection Fails While In Run Mode" enabled, to make sure I don't lose connection to a module I should have communication to.


This does not "make sure you don't lose connection to a module you should have communication to.."


You cannot prevent losing comms, but you can react to it more elegantly than Major-Faulting the controller. Perhaps a more orderly shut-down of your process or machine would be better, at least then you can annunciate the fault ...
 
This does not "make sure you don't lose connection to a module you should have communication to.."


You cannot prevent losing comms, but you can react to it more elegantly than Major-Faulting the controller. Perhaps a more orderly shut-down of your process or machine would be better, at least then you can annunciate the fault ...

Yes, I had poor wording, I know I can't prevent losing comm to a module, if someone unplug a cable not much I can do about it.

Yes you are right I can probably do it more elegantly. How would I go about monitoring the communication status of a module in the logic?
 
I'm experiencing this error myself right now. For the time being, to get the machine back into production, I just un-checked the major fault tick box and they've been back up and running ever since. Anyone have any idea what CAUSES a module to lose connection to controller in the first place...?
 
I'm experiencing this error myself right now. For the time being, to get the machine back into production, I just un-checked the major fault tick box and they've been back up and running ever since. Anyone have any idea what CAUSES a module to lose connection to controller in the first place...?

The same things that cause any kind of failure:

* Bubba
* Random equipment failure
* Failure due to external factors (heat, water, Bubba with steam cleaner etc)
* Poor installation practices resulting in your ethernet link either out right failing, or intermittently failing.
 
I have experienced "losing connection" issues. This was to a ControlNet bridge module in a ControlLogix chassis that had been installed for over 12 years.

I discovered that removing the module from the chassis and replacing it got it working again.

I deduced that the contacts could be dirty or tarnished after all those years. We cleaned all the module's contacts with a quality spray cleaner, and pushed the modules in and out a few times.

Never had the problem again....
 

Similar Topics

We had one go down. we have a new one. Their emergency Number don't work. The Model is TLSA046AAH-330N01-007 A catalog says we need software TET...
Replies
2
Views
136
“The HMI files we cannot open—they were saved in V13—we do not have that—I cannot restore file –please have them save in V11 and send them back to...
Replies
4
Views
135
Hi guys! I'm working in Studio 5000 and have a bunch of armorstarts there (+- 40). I need to set up parameters for each of them, mostly just same...
Replies
0
Views
75
Hello brothers We are contacting you because an error like [display change is currently controlled remotely] occurred while using the equipment we...
Replies
2
Views
173
Hi all. I'm trying to set up communication between a 1756-L72 (EN2TR) and a 1756-L82 (CPU port) using produced / consumed tags. From the L72...
Replies
13
Views
343
Back
Top Bottom