AB 1769-L30ER Key Switch Position

That is interesting, daba. As I said, I cannot speak for everyone's experience, just what I am seeing. But I have more on that later. That is why I did not state it "categorically" does work but just that it "is possible", as in the controller "can" update the BTD destination during a transition to Program Mode.

What hardware are you using, as a by-the-way?

daba said:

...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 ?

Click to expand...

Here is what I do know...

The word "transitioning" is important as it reminds us of the fact that we are transitioning from one mode to another and not immediately and abruptly changing. This, if we think about it, is good practice as under the hood we wouldn't want certain things not "tidied up" before changing or done in a disorderly fashion. Doing so could leave certain things indeterminate or unsafe.

Whether "hard" transitioning to Program Mode, via the keyswitch, or "soft" transitioning via software, transitioning to Program Mode does some housekeeping before it completes.

As we know, for instance, certain output modules will take control of their outputs and ensure they are set to their configured "Output State during Program Mode" (default "Off"). To do this in an orderly fashion, the controller must first update the modules of the request to transition to Program Mode. Once the modules have acknowledged the request, they are now in control of their outputs and the controller may carry on with its business. For output modules that may not have their own configuration, the controller fully manages them during transition.

User Tasks are ordered to stop. Where this "stop" is I cannot say, as in one more full scan or "wherever the scan happens to be when ordered". I think at this stage we can both agree that from our tests the scan does at least continue for "some" period after changing modes.

"Cached Connection" messages are ordered to close. These, as we know, are CIP messages that are sent as "Connected" but are also "Cached" which means the connection is reserved for the message.

OPC/DDE topics via RSLinx may continue to update before the connection is closed.

HMI terminals or SCADA may continue to update before the connection is closed.

Motion Planners are ordered to Program Mode. This will allow any current axis movement or safety required axis movement to be executed first.

The controller will then wait for everything to report back as stopped.

The Controller Log will be updated to time stamp and record either the mode change via keyswitch or software, including your user name and workstation name, among other things.

The Run LED is turned off.


I have tried the quick key switching, which I had not done, and I can confirm that it struggles sometimes or at the least it is not consistent. In my video, I was slow to transition as I was waiting for each slower update of the Mode tag to update before moving on. Ignoring the Mode value now and just monitoring the GSV result, I have tried it a little faster and it still updates ok for me. It's just the very rapid switching that struggles - direct from Run to PROG may retain a value of 1, as you have also found.

What I will say for this is that the fact that it could remain as in Run Mode (value 1) when changed to Program Mode is "not good" as it defeats the purpose of at a minimum detecting the controller is not in Run Mode.

One other thought I had was that we could place this rung in several places in the project and it may increase the odds of the scan executing it once more after the request has been made to transition to Program Mode. However, in my two test controllers, there is only this test rung. So that rung is being continuously executed as fast as the processor will allow. It is averaging 12uS in the L1 and still it may fail to execute just once more after the request is made and completed. I cannot think of anything else we could do to improve on this?

We could try a periodic task but I don't think the transition is told to wait for those to finish the current cycle +1?

Because the Predefined System Mode tag is still able to read out the verbose controller mode from the CIP Object while the controller is in Program Mode, it is definitely the better and more reliable option to go for, where available.

I'm of a mind to politely provide feedback to the technote on our findings in that it may work, but not reliably enough.

Regards,
George

George, I did my tests on a 1756-L63.

As you so rightly say, if we want to use code to determine the keyswitch position, then we have to have a 100% reliable way of doing so, and at this juncture I cannot think of a reliable way.

Another failing of any code method is the total inability to detect the REM position when you turn the key from PROG to REM.

In effect, the only reliable information that can possibly be gathered is either RUN or REM RUN positions.

But then, why do people need this information in the user program ? What could you possibly do with the knowledge that the keyswitch is in the PROG position ?

There simply is no point in detecting the PROG position, because you don't know how long the transition period is, and will vary on different systems. I suspect there will be a world of difference between an L1 and an L8x series.

I would suggest that the only possible reason for gathering the keyswitch position is to animate an HMI graphic, and since the HMI can read the keyswitch position reliably, why use code at all.

Another controller may want to know that this controller is in a RUN mode (either), and for that I would add the CONNECTION_STATUS member to a Produced/Consumed tag, which has the added advantage that it also informs that the connection is valid. Nothing else is needed in the consumer, those two BOOL flags give you all you need to know about the health of this controller.

How about have a test button or DINT entry on the HMI that writes 0 to the DINT. The PLC even in PROG will have the DINT value changed to 0.

The PLC if running will change it right back so the bits for 1 or 3 can be read - if it stays 0 then the PLC is not running.

I_Automation said:

How about have a test button or DINT entry on the HMI that writes 0 to the DINT. The PLC even in PROG will have the DINT value changed to 0.

The PLC if running will change it right back so the bits for 1 or 3 can be read - if it stays 0 then the PLC is not running.

Click to expand...

But why does the PLC need to know if it is running, or, more specifically, that it is NOT running ?

What is it going to do with that information ? It can only DO something if it IS running ...

Being able to read, programmatically, that it is in PROG mode is about as much use as a chocolate teapot.

Even if you could find a reliable way of determining the switch position, the only useful thing you could use it for is an HMI graphic, and you can do that anyway without writing any PLC code.

daba said:

But why does the PLC need to know if it is running, or, more specifically, that it is NOT running ?

Click to expand...

My take on the OP was he wants to show on the HMI the mode.

If the DINT is written to 0 when not running it will stay 0 and the HMI will know. It will not turn OFF the RUN or REM BOOLS, that would need PB's, or instead of BOOLs use bits of a DINT and write 0 to that.

As for the PLC code, it will never need to know if it is in PROG.