Does any one have a map of all the status bits available for Logix 5000, in Control Logix and Compact Logix controleurs - ie: like "s" bits in Logix500

This is a very good question. One of the SLC features I miss are status bits. CompactLogix is a different animal, and Allen-Bradley did not make it easy to find this information out.

Refer to Allen-Bradley publication #1756-QR107C, page 6-2. (too big for me to upload...link below). I believe you have to use Get (GSV) and to move the status of the status flag or status register to a tag that you define. This may help you to get the ball rolling on your task. I do believe this page is just a short example of what status bits/flags/registers that lurk deep within the Compact/ControlLogix.

Be warned, the page I reference is VERY vague, but will give you a starting point.

http://literature.rockwellautomation.com/i...qr107_-en-p.pdf

If you do find a more concise list, please do post a reply.

The GSVs are used more in the Controllogix to get non-critical information about the systems but there are a few status flags
http://rockwellautomation.custhelp.com/cgi...mlyc3QgcGFzcw**

No such animals. There is S:FS (first scan) and a couple others that are just arithmetic status info (overflows and such). But nothing like the clock status, IO status, etc.

All these are accessed only through the GSV and SSV instructions. According to AB, the reason for doing this is for performance. An additional reason is because on the CLX (not the case with CompactLogix), the IO processor is just that...a completely independent CPU running on it's own divorced from the main processor. Making it run lock-step with the main CPU and updating the S bits on every scan would add a lot of coordination and slow down IO (and CPU) speeds.

If you want to use status information, you can still get it. You just have to use the GSV/SSV instructions. Otherwise, the CLX processor never has to calculate it and never has to update the S: file on every scan. This turns out to actually be much nicer than the S: files once you get over the extra instructions. For instance, the CLX keeps track of time as the number of microseconds since January 1, midnight, 1972, UTC (at least in Rev 16 and later), in a 64 bit register. This is further complicated by the clock synchronization protocols (IEEE 1588 or equivalent) that are operating between the IO, network, and processors that use it. It allows for time resolutions on devices in the microsecond range but converting it to a date/time is very complicated programmatically.

You can get this information directly in the 64 bit form (split across 2 DINT's), and then convert from there, but fortunately, you don't have to. You can simply run GSV and ask for LocalDateTime in the WallClockTime Module. It spits out the usual YYYY/MO/DD/HH/MM/SS/MS for you. Setting the clock is just as simple (use SSV instead of GSV).

In a similar way, you can capture faults at the PROGRAM level. And you can enable/disable individual programs or tasks without affecting any others. Why does this matter? Think about what I use it for. We simply can't expect to shut down most of our equipment to do an offline download of program changes. The equipment is expected to run 24/7 in many cases, especially cooling water systems. Equipment is almost always running while minor programming changes are being made. My last chance to make major program updates was in August. My next opportunity will be over Thanksgiving. After that, nothing until January. Then barring a lucky break, nothing again until perhaps August.

So we live on online programming changes, like it or not. The problem is that there are lots of ways to make fatal programming errors which could fault and shut down the whole processor. One approach to minimizing mistakes is by using multiple PLC's to isolate the damage. But with a CLX, this isn't necessary. We just put each piece of equipment in it's own program or task. When a fault occurs, we run a fault routine that checks the status information to determine which program faulted and whether it's a "recoverable" fault or not. For recoverable faults, we simply turn the enable bit off on that program, save all the status information, and return from the fault. All the other tasks and programs are still running. Only the offending program gets shut down. This makes online programming worlds safer than it was before.

Thanks guys , you have been alought of help this will aide in my programming the code.

Now all i need is if there is a way of shutting down the automatique fault I get on a power failure which faults the processer on a compact logix, or a routine for self correction. I have always coded for power loss worst case recoverey.

I'm not sure I'm understanding you. Are you having a problem with the processor faulting on power up and the cause showing "Power Loss?

Yes that is exactly what is going on - Is there a way of turning off this fault

Put this in your power up
[attachmentid=6922]


Here is a better example, see attached file

Thank-you very much gentalmen....