RSLOGIX run mode detection?

[bfdm_mexi 1]

Is it possible to use instruction to check to see if the Program is in run/remote run mode... I need for people in the field to know if the PLC is either A) Running B)In Program mode, or C) Faulted, without ever opening the control cabinet. I've used the GSV/Controllerdevice/status but it only gives you keyswitch position (hard to use because the bits dont change when its in program, remote program, or remote run; only in Run.) more than likely the key will always be in Remote run. hope that makes sense... It did in my head.

[b_carlton 61]

A running instruction can only say that it is in 'Run' mode obviously. How about a tranparent panel on the front of the cabinet?

[TConnolly 13]

Its easy on a SLC, you can monitor the status bits with an HMI. But I don't know of any way to monitor those bits on the CLX without using a GSV, which of course requires that the PLC be running. However, if you have an HMI then you can use a periodic script in the HMI to set a bit in the PLC. If the PLC is running it will clear the bit. After a brief delay the HMI checks the bit again and if it is clear it sets it again. If the bit remains set then the PLC is not running. If you don't have an HMI then you could use an external timing relay to create an external watchdog. The running program in the PLC will pulse an output periodically to reset the timer. If the timer doesn't get a reset before it times out then it turns on an indicator.

[Ken Roach 194]

It depends on the HMI's ability to connect to internal objects in the controller. RSLinx Classic and RSLinx Enterprise both have an internal tag called @Mode that gives you the mode of the controller (run/remote run/program/fault).

[paulengr 44]

I highly recommend buying cabinets with plexiglass or even better, Lexan fronts from the beginning. It's much more useful to be able to check these days without opening the cabinet, especially with arc flash concerns being what they are. But you can't always have a plastic window, or the window might get gunked up so fast that it's not even worth doing. Solutions to detecting running vs "something else" already suggested, but the simplest solution is to use 1756 IO which already has built in "fault state" logic, or HMI programming. GSV tags are generally barking up the wrong tree. If you have a new enough revision, the local chassis (1756) IO has a special tab to determine the output state during program mode or fault mode. The default is "Off" but you can set an output on. And you can force an output state from your program such as "OTL <tag name>" or "OTU <tag name>". Thus, you could have two outputs which would potentially show "power loss" (no lights), running (first light), program mode (both lights), or faulted (second light), simply by what settings you configure in the IO card and the outputs that you force in run mode. Choices for IO are "Off", "On", or "Hold Last State". Look in the 1756 IO user manual for additional details. If you want to check the processor status from within an HMI, RS-Linx at least has several predefined tags that DO NOT SHOW UP in the tag browser that you can use. They are @Status (returns "OK" or "Faulted"), @Mode (returns Run, Program, Remote Run, or Remote Program), and @IsPresent (1 if the processor is responding or 0 if it's not). You can't really detect anything with a GSV command because the processor is not operational during program mode. However, you can write fault routines to execute "dying breath" type functions to attempt to communicate to the outside world just before a fault occurs. You can even capture the fault and if it's a nonfatal type, even store the data and possibly recover from it. For instance, you can detect the fault type and if it's something like a "negative timer PRESET" type error, use an SSV to Inhibit the errant program and shut it down, allowing any other remaining programs to continue to execute. If you do this, you REALLY can't see the fault light because you are clearing the fault under program control. It then falls upon you to build your own fault light.

[Guest]

if you don't have a suitable HMI and you're just trying to turn on a few stack lights, you might be interested in the basic ideas shown here ... this approach makes use of the output module's "Output State During Program Mode" configuration settings ... this is a little-known and seldom-used feature – but it might come in handy for your purposes ... BASICALLY the approach is to turn the output for the Program_Lamp ON whenever the processor is not in the Run mode ... specifically, whenever the processor is in a Fault or Program mode condition ... the configuration is set to HOLD the output for the Fault_Lamp in its last state ... that state is set to an ON condition by the Controller Fault Handler shown on page 2 of the attached PDF file ... this is along the "dying breath" lines suggested by my distinguished colleague paulengr ... note that pre-scan will automatically turn this OTE-controlled output off when re-entering the Run mode – so no additional "reset" action should be required ... I've built this around the use of a 1756-OX8I relay output module – but it should be possible to achieve the same results by properly wiring a set of interposing relays tied to just about any other output module ... if you're interested in going further with this, I'll try to find time to clean it up – if that's necessary ... disclaimer: I have successfully bench-tested this program MANY times using a 1756-OA16 output module ... I don't have a 1756-OX8I module available for testing ... I see no reason why the logic shouldn't work identically with the relay type output module I've recommended ... there are only three or four rungs necessary - and these are shown in the PDF attached below ... further disclaimer: this was written pretty much just to introduce the basic ideas involved ... whether it will work reliably in YOUR specific application remains to be seen ... please test it carefully ... Run_Program_Fault_Lamps.pdf Edited 19 Aug 2010 by Ron Beaufort

[paulengr 44]

In a PM, Ron described the "fault" that the IO modules refer to as a comm/module fault problem, NOT registering processor faults. Knowing that Ron is incredibly thorough on something like this (he has to be...he does training classes and those darned students will trip you up every time), his suggested fault detection method should work.

[jimdi4 2]

If you want to check the processor status from within an HMI, RS-Linx at least has several predefined tags that DO NOT SHOW UP in the tag browser that you can use. They are @Status (returns "OK" or "Faulted"), @Mode (returns Run, Program, Remote Run, or Remote Program), and @IsPresent (1 if the processor is responding or 0 if it's not). Edited 18 Aug 2010 by jimdi4

[Ken Roach 194]

[Armadillo852 25]

Yes use: GSV Controller Device Status Bits 13-2 show which position the key switch is in. Do a help and search for the following inside logix5000 Accessing the CONTROLLERDEVICE object

[jimdi4 2]

(hard to use because the bits dont change when its in program, remote program, or remote run; only in Run.)

[jimdi4 2]

Ok ...(If you are using RS-VIEW ME) What I discovered is that the @MODE, @STATUS, and @everyyhingelse is located in the RSView ME Tag browser under <Diagnostic Items> In order to get the display to properly work do the following: Click on <OBJECTS> NUMERIC and STRING> String Display> Put down your little square box, Double Click on it and go to the Connections Tab at the top. Doubleclick on <Connections>, then Tag> Select Diagnostic Items> Then pick the @MODE tag. make sure your Online with the PLC and its running,,,Then Go to the top of RS-VIEW Me Select the Test Display button > switch the key-switch on the PLC and watch it change values on the RS-VIEW ME String. I believe this answers the original question by the thread starter.... Edited 19 Aug 2010 by jimdi4

[Armadillo852 25]

It works in run and remote run, but not in program. Because the program does not scan in program mode, but it does work in remote and run mode. I tried it today. V17

[nog 0]

This worked for me, I tried it on an emulator v17, Is there a reference manual for all of this diagnostic tags? Thanks!

[dovi_k 0]

I tried it yesterday and according to the table on page 189 in 1756-rm003l-en-p manual the bits 12-13 worked fine also for program mode. to find what mode the cpu when in remote you should check also bit 14. when in remote run this bit is 0 and when in remote program the bit is 1. I'll try the @mode on rslinx as well.