AB 1769-L30ER Key Switch Position

Is there a way to get the key switch position of 1769-L30ER when the switch is in Program Mode?

I am using the GSV command for Run and Remote. When the switch is in program, the ladder isn't running so GSV doesn't update. Not sure if there is a way to ping the PLC for status. Logix Designer can do it as it shows the key switch position. Is it possible to access the same info?

Thanks,
Jim

With what device are you trying to read the keyswitch status? Or where are you trying to display it?

I've previously set up an Ignition SCADA template to show all kinds of PLC information, including keyswitch status, from the inbuilt PLC status tags Ignition creates when you define a new device connection. I'm sure it's possible on other SCADA platforms as well.

In what application are people changing the key position?

I guess I can see run and remote run but access to the PLC should be restricted.

You might be able to use a MSG instruction and pull that info from another PLC but when in program mode the code isn't running so GSV isn't going to do anything if the PLC doesn't run it.

Many communication drivers will query the Controller object and read the keyswitch position.

I know that RSLinx expresses it as a string, in the predefined @Mode tag for each controller OPC connection.

Thanks for the responses. I'll look into the controller object.

ID: QA32457 | Access Levels: TechConnect
Reading Keyswitch Position Programmatically

The ControllerDevice Status is your friend.

You may pull bits 12 and 13 out of the destination DINT, read in via GSV.
Then examine the value of the 2 bits to determine the keyswitch position as either...

1 = RUN MODE
2 = PROG MODE
3 = REM MODE

Regards,
George

See attached file

@JIMWAWAR47 AND GEOSPARK:

I did it , In my case the key is in REM position so number is 3.

Ken Roach said:

Many communication drivers will query the Controller object and read the keyswitch position.

I know that RSLinx expresses it as a string, in the predefined @Mode tag for each controller OPC connection.

Click to expand...

And kepware OPC server expresses it as a string by using #Mode tag for the PLC connection

This is so obvious - ANY attempt to read the keyswitch position using running code will fail if the code is not running.

So you can only detect "RUN" or "REM" while in a RUN mode, and if you read "REM", you must be in "Remote Run".

You will never be able to detect "PROG" or "Rem PROG" with code.

Of course this is a CIP object that can be interrogated by connected devices, but you can only get half a story with on-board code.

+Daba

jimwawar47 said:

I am using the GSV command for Run and Remote. When the switch is in program, the ladder isn't running so GSV doesn't update.

Click to expand...

daba said:

This is so obvious - ANY attempt to read the keyswitch position using running code will fail if the code is not running.

So you can only detect "RUN" or "REM" while in a RUN mode, and if you read "REM", you must be in "Remote Run".

You will never be able to detect "PROG" or "Rem PROG" with code.

Click to expand...

We have come full circle.

daba said:

This is so obvious - ANY attempt to read the keyswitch position using running code will fail if the code is not running...You will never be able to detect "PROG"...with code.

Click to expand...

I'm assuming, like many others might be, that you are basing that off of your understanding of how the controller acts when transitioning to Program Mode and that you have not actually attempted this yourself? On the face of it, it's very easy for many of us to question the Rockwell technote's assertion that we can read out Program Mode while transitioning to Program Mode. Let's keep an open mind on this, though?...

I had to wait a few days as I was busy but I am just starting into a small project so I was pulling out some hardware yesterday. This gave me the opportunity to throw this together as a quick demonstration. I'm just getting time now to post it up before heading home.

I'm using a CompactLogix 5370 1769-L16ER-BB1B controller (r32) connected to a PanelView 5510 2715P-T10CD HMI terminal (r6).

I've got the GSV and BTD instructions added to the default MainRoutine and configured as instructed by the Rockwell technote.

I created 2 DINT Controller tags "ControllerStatus" and "KeyswitchPos". The former stores the GSV destination and the latter contains the result of the BTD instruction.

On the HMI I've created a simple screen with objects referencing the "KeyswitchPos" Controller tag which is expected to read out the keyswitch position values...

1 = RUN MODE
2 = PROG MODE
3 = REM MODE

I've also created a text object referencing the Predefined System tag of data type string "::[Shortcut]Controller[x].Mode", traditionally referred to as "@Mode" in FactoryTalk View/RSLinx Enterprise. This is expected to read out each main controller mode including "Remote Run" and "Remote Program".



Note 1: The line object representing the REM keyswitch position is using an expression for visibility animation which looks at both the "keyswitchPos" numerical value (=3) and the System "Mode" tag for the Remote Modes specifically.

Note 2: The update rate for the Predefined System "Mode" tag is noticeably slower than the update rate for the "KeyswitchPos" Controller tag.

Note 3: Note 1 & 2 both contribute to the visible delay in some of the switching of the graphical object states.

Note 4: While in Program Mode, the PanelView 5510 will display a Controller Connection warning icon on the right side of the top banner whenever the controller is not in Run Mode.

Result: I was going to take a series of pictures but instead I've made a short video which I feel demonstrates the test much better and much quicker than me blathering on with lots of pictures...

To play the video file directly:

https://www.dropbox.com/s/fvvvvbazpdr85mv/20210311_181229.mp4?raw=1

To download the video file if preferred:

https://www.dropbox.com/s/fvvvvbazpdr85mv/20210311_181229.mp4?dl=1

My apologies for the background noise. The plant is noisy but I want you to be able to here the keyswitch transitions to know when to expect the next graphical update.

I have also repeated this test using a 1769-L33ER which is the closest I have to the OP's 1769-L30ER.

Now, this is what I have experienced. I cannot say what will happen for others who may try using other hardware and programs. But nonetheless, it does prove that it "is possible".

Regards,
George

And the academy award goes to ...

Geospark said:

...

Click to expand...

Geospark said:

I'm assuming, like many others might be, that you are basing that off of your understanding of how the controller acts when transitioning to Program Mode and that you have not actually attempted this yourself? On the face of it, it's very easy for many of us to question the Rockwell technote's assertion that we can read out Program Mode while transitioning to Program Mode. Let's keep an open mind on this, though?...

Click to expand...

A detailed reply George, thanks.

However, I have read the technote, and nowhere does it say HOW the GSV and BTD can be executed when in PROG or REM PROG modes.

The only way I could envisage being able to get the status bits is if the Controller makes another scan after detecting the mode change to PROG from REM RUN.

Do you know if this is the case ?

OK, so I have now tested the GSV BTD code, and can categorically state that is DOES NOT WORK EVERYTIME as can be seen in the picture ....

And if I turn on the bit "Execute_My_Code", it NEVER shows PROG keyswitch position.

And I can also say that if you turn the key rapidly to the PROG position from the RUN position, the Key_Position tag shows as in RUN mode.