S7 - Oh no, not Timers again!

[RMA]

To help with commissioning the system, I've got a Test-screen which allows me to switch all the relays etc. on and off. When the Test-screen is active all the rest of the normal program is skipped. For the motor-driven switches this means sending a 1-sec pulse to the "Open" or "Close" contacts as required. This is the logic I'm using:

This has been working since last July with no problems, but hasn't been used for about six weeks. Now I wanted to test the last few modules and suddenly I've got problems. The "Open" (AUF) and "Close" (ZU) outputs are staying on permanently causing the switch to hunt back and forth. Unfortunately, in the meantime quite a lot of changes have occurred in other parts of the software!

Looking in the VAT I can see the "ZU" Timer oscillating between 1 sec and 990ms - in other words it is apparently continually being restarted - but how? The Bits concerned are set and reset in ProTool and, according to X-Ref, nowhere else (apart from here in the case the "Open" button).

 

[RMA]

Oops, just occurred to me, for those who don't know the German mnemonics:

U = A
UN = AN
SI = simple impulse Timer

 

[SimonGoldsworthy]

Comment: Using SP (english, pulse timer) then as the timers are reset when you let go of the touch screen button, you only get the 1sec pulse if you keep your finger on the button (for the ZU function) - is that what you wanted ?

Are the timers referenced any where else ?

What turns off the ZU data bit from the TP, is it a momentary acting button?

As the code turns off the AUF data bit from the TP, is this a set only type button ?

Just trying to see why you have different implmentations for the off/on buttons.

 

[JesperMP]

1st. You use Test_buttons.LTS_Crowbar_ZU for both enabling and resetting the timer.
Try to separate the enable and the reset to different buttons.
It shouldnt be necessary to program the reset at all, apart for if you want to inhibit the output (safety or a master enable), and that means you ought to use a separate addresses for that purpose.

2nd. The output of the SI timer is tied directly to the input (Test_buttons.LTS_Crowbar_ZU). So if Test_buttons.LTS_Crowbar_ZU changes quickly so will the output of the timer.
I normally use a "set bit" function in my HMI for buttons. I then evaluate the bit in the PLC, do the action required, and reset the bit in the PLC.

U "startbutton" // Button is SET in the HMI
L s5t#1s
SI "timer"
UN "enableswitch" //A separate SWITCH (not button) for enabling
R "timer"
U "timer"
= "action"

U "timer"
ON "enableswitch"
R "startbutton"

It is possible that Test_buttons.LTS_Crowbar_ZU is referenced somewhere else in the program ins ome unintended way.
You can try to check that.
But anyway, doing it like above is more robust.

 

[RMA]

@Simon

Using SP (english, pulse timer) then as the timers are reset when you let go of the touch screen button, you only get the 1sec pulse if you keep your finger on the button (for the ZU function) - is that what you wanted ?

I'm using a PC, not a TP and the button is using a "Set_Bit" command to set a Bit in the "Test Buttons" DB. So the signal is on until it gets turned off by the operator clicking the "Open" (AUF) button on the screen.

Are the timers referenced any where else ?

I'm pretty certain the Timers are not being used accidentally anywhere else, that's one of the reasons I named the Symbols so explicitly. Certainly there's nothing in X-Ref.

What turns off the ZU data bit from the TP, is it a momentary acting button?

As mentioned above the ZU Bit gets turned off by a Clear_Bit command when the operator clicks on the "Open" Button.

As the code turns off the AUF data bit from the TP, is this a set only type button ?

Yes.

Just trying to see why you have different implmentations for the off/on buttons.

I'd like to know the answer to that myself! I wrote this code so long ago, when I was still having trouble with Timers and I can't remember why I didn't used the "Close" button to reset the "Open" Bit just like I do with the "Open" button. I assume that the code wasn't working and this turned out to be (apparently) part of the solution. I think I'll go back and try to implement it that way.

@Jesper

I've effectively answered both your questions above, I think. As I said, I think I'll try using the other button to clear the Bit.

Actually, I've got a gut feeling that this is maybe going to turn out to be a Timestamp problem. I went through my back-ups until I found two versions where one (5A) worked and the next one (5B) didn't, however, one time after downloading 5A into the SPS I decided to have a look at something online and clicked the online View in Simatic manager. When it came up, it informed me that I was looking at 5B, so evidently some blocks had not been replaced.

I've now deleted all the Blocks in the online view before downloading 5A once again and I'm just about to start loading the blocks from 5B with a different "last modified" date one by one (as soon as I can get my hands on the system again!), to try to identify which (if any) is/are causing the problem. Under the circumstances I won't be too surprised if I get them all loaded and it's still working!

I'll post agin once I've been through the loop.

 

[RMA]

Gotya!

Problem solved. I finally found the difference between the working and non-working versions. In the non-working version I had enabled the transit-time supervision of the motor-driven switches so that I would get a count of operations during testing as well. As I had already discovered and discussed here, that program does not like being started and stoppped, because of the undefined state of the outputs when it starts to run, until the switches are first opened or closed.

The significant difference since then is that after discussion with the customer any fault now causes an abort, which, amongst other things, causes all the motor driven switches to be openend. I'm still not quite sure of the mechanism, but the net result was that both the "Open" and "Close" output contacts finished up permanently on.

How the Timer is continuously being started in this state is still a bit of a mystery though.