Cycle Time Alias(?), S7-1200

Hello,

First time poster and first time Siemens programmer here.

I have an S7-1212 FC I'm programming in TIA Portal V15.1 and I'm hoping there's a word or two somewhere in the program that will allow me to create an alias for the programmed cycle time of the Fail-safe Organization Block.

In other words, I want to read the programmed cycle time of a cyclic interrupt for use in my program.

My goal would be to have an FB or FC that takes five samples from an HSC and averages the pulse rate based on the cycle time, without the use of a separate database constant.

I also see other applications where this would be useful, so I figured it was worth asking.

Thank you

Isn't this one of the variables inside the OB? Or I may be confusing with OB1? Haveyou checked the parameters inside your OB?

The timed interrupt block for safety is locked. If you are a first time Siemens user then you will have bigger fish to fry and I would not worry about having to use a hard coded constant.

The actual cycle time of the F OB is in: System Blocks -> STEP 7 Safety -> RTG1SysInfo -> F_SYSINFO -> TCYC_CURR


Note also that the 1200 HSC can be put into a frequency mode, so you might not even need to do this at all.


ALSO also, why are you sampling your HSC in your safety program? Not saying its wrong necessarily, I've just never seen that need to be a fail-safe function before. If it is just a standard process function, you could create a standard cyclic interrupt.

If you want the configured value, not the actual value, you can try the QRY_CINT instruction, called out of your main code. I know that works for standard cyclic interrupts, not sure if it works for failsafe ones as well.

cardosocea said:

Isn't this one of the variables inside the OB? Or I may be confusing with OB1? Haveyou checked the parameters inside your OB?

Click to expand...

It's a variable I can change within TIA Portal, but I'd like to be able to read it within my runtime. That way, I could do ((HSC Total)-(Previous Scan HSC Total))/(Cycle Time)x10^6=Rate. OB1 is a program cycle OB, so it does not have a programmable cycle time.

L D[AR2 said:

The timed interrupt block for safety is locked. If you are a first time Siemens user then you will have bigger fish to fry and I would not worry about having to use a hard coded constant.

Click to expand...

I think this is my last fish to fry. Most of the programming is still ahead of me, but I have a working program and all of the other self-checks I hope to implement have been tested in their own environment.

Thank you, both. I guess I'll use a hard coded constant and hope I remember to manually update it with any changes to the cycle time. Worst case scenario, my flow proofing has a greater margin of error than intended.

mk42 said:

The actual cycle time of the F OB is in: System Blocks -> STEP 7 Safety -> RTG1SysInfo -> F_SYSINFO -> TCYC_CURR

Click to expand...

My understanding is that this is a running count of the current cycle time, whereas I want the programmed interval the interrupt is supposed to run at.

Note also that the 1200 HSC can be put into a frequency mode, so you might not even need to do this at all.

Click to expand...

I'm using the HSC to count pulses from a flow meter to automatically fill drums. The total count is more important than the average for my application, but the average would be useful for proving that the HSC is functioning properly.

ALSO also, why are you sampling your HSC in your safety program? Not saying its wrong necessarily, I've just never seen that need to be a fail-safe function before. If it is just a standard process function, you could create a standard cyclic interrupt.

Click to expand...

I'm sampling the HSC in my safety program for two reasons. One, my assumption is that fail-safe memory is redundant, and so, by immediately passing the HSC count to fail-safe memory, I can monitor and proof changes to it with some semblance of integrity. Two, using the fail-safe interrupt saves me the need of having of having to use a second cyclic interrupt.

If you want the configured value, not the actual value, you can try the QRY_CINT instruction, called out of your main code. I know that works for standard cyclic interrupts, not sure if it works for failsafe ones as well.

Click to expand...

I'll look into that now, thank you.

Solution

mk42 said:

If you want the configured value, not the actual value, you can try the QRY_CINT instruction, called out of your main code. I know that works for standard cyclic interrupts, not sure if it works for failsafe ones as well.

Click to expand...

That seems to be exactly what I wanted and it compiles without error. Thank you for the help.

I've got no code to speak of in the safety program but the cycle time is reported back as the time set for the cyclic interrupt i.e. 100ms

l****ters said:

I'm sampling the HSC in my safety program for two reasons. One, my assumption is that fail-safe memory is redundant, and so, by immediately passing the HSC count to fail-safe memory, I can monitor and proof changes to it with some semblance of integrity. Two, using the fail-safe interrupt saves me the need of having of having to use a second cyclic interrupt.

Click to expand...

Fair enough, I guess. I'm curious what application that's necessary for, but I always approve of a bit of overkill.

l****ters said:

That seems to be exactly what I wanted and it compiles without error. Thank you for the help.

Click to expand...

Fair warning, the compiler won't check if the OB number is valid. That won't get checked until RunTime, so be on the look out once you DL.

There is no separate memory for the fail safe program. If the data is not coming from a safety device I would be reluctant to process it in the safety program as if it did.

I agree with L D[AR2,P#0.0]... I have been adding/modding enough of other peoples code to know that I'd be head scratching for a day why is this in the safety. Is someone gonna get hurt because I added the hourly flow they asked?

I'm kinda kidding, but safety is for safety...

And also, your comment that this saves you from having another OB makes me think that you are cramping everything into safety and that I really wouldn't do..

mk42 said:

The actual cycle time of the F OB is in: System Blocks -> STEP 7 Safety -> RTG1SysInfo -> F_SYSINFO -> TCYC_CURR

Click to expand...

L D[AR2 said:

I've got no code to speak of in the safety program but the cycle time is reported back as the time set for the cyclic interrupt i.e. 100ms

Click to expand...

I was mistaken, then, TCYC_CURR is the proper tag. It would be nice if the default value was updated during compilation.

mk42 said:

Fair enough, I guess. I'm curious what application that's necessary for, but I always approve of a bit of overkill.

Click to expand...

m_turk said:

I agree with L D[AR2,P#0.0]... I have been adding/modding enough of other peoples code to know that I'd be head scratching for a day why is this in the safety. Is someone gonna get hurt because I added the hourly flow they asked?

I'm kinda kidding, but safety is for safety...

And also, your comment that this saves you from having another OB makes me think that you are cramping everything into safety and that I really wouldn't do..

Click to expand...

This isn't actually for a safety system; we've had people leave wrenches in a deadman valve for a bulk fill line and flood our mixing room on multiple occasions. Management insisted that we install a fail-safe system while also refusing to buy anything expensive. Also, I consider the area of installation a Class 1 Div 1 location, although our engineer disagrees. So, I've got one flow sensor and I'm just trying to do what I can to prevent the HSC from undervaluing the flow.

L D[AR2 said:

There is no separate memory for the fail safe program. If the data is not coming from a safety device I would be reluctant to process it in the safety program as if it did.

Click to expand...

Ah, I falsely assumed Siemens achieved SIL by redundancy, as opposed to diversity. That's very useful information. Since HSCs are asynchronous, I could have run into ghost problems (failed diversity checks.) Are F-DBs only really there for simplicity and F-runtime communication then?

The way siemens have implemented the safety program is to run two diverse implementations of the same logic and compare the results. Put simply, the safety compiler takes your code and re-generates it in the opposite sense. The results of the execution of the two sets of code must match - one example where you can get caught out is if you have an OB of higher priority which interrupts the safety program half way through execution and modifies a variable being used - you will then get a safety fault - make the safety program the highest priority (I generally use priority 15 so that comms will not interrupt the safety program). The safety DBs are also used for status/diag information when the CPU is communicating with safety cards.

L D[AR2 said:

The way siemens have implemented the safety program is to run two diverse implementations of the same logic and compare the results. Put simply, the safety compiler takes your code and re-generates it in the opposite sense. The results of the execution of the two sets of code must match - one example where you can get caught out is if you have an OB of higher priority which interrupts the safety program half way through execution and modifies a variable being used - you will then get a safety fault - make the safety program the highest priority (I generally use priority 15 so that comms will not interrupt the safety program). The safety DBs are also used for status/diag information when the CPU is communicating with safety cards.

Click to expand...

I think I understand. An inverse OB is generated during compilation and run after the initial OB. The results are compared and, should a logical XOR produce any 0, the processor will fault. This does lead me to assume that each F-DB is actually two DBs stored within the same memory, in which case there is still benefit to moving my HSC count to one; I just need to make sure my value doesn't change during execution of the F-runtime Group.

Sample

Here's some screenshots I threw together to demonstrate what my flow-proofing would look like.