Hi to all,

i have a FB block that i use several times for to manage some valves. This FB is then called several times in multi istance inside a main FB.

Sometimes after a donwload the timer doesn't work like in the picture. I have TIA 17 update 1.

How do you solve this problem?

Many thanks

Hello,

Try in front off network maybe put FirstScan bit, maybe this will help to your network work correctly, otherwise i have no other ideas 

 Hi Gigi,

check in the instance DB of the timer if the IN input value has been initialized to TRUE.

Second check:

-are you calling that instance one time only, right?

gigi_plc

Hi to all,

i have a FB block that i use several times for to manage some valves. This FB is then called several times in multi istance inside a main FB.

Sometimes after a donwload the timer doesn't work like in the picture. I have TIA 17 update 1.

How do you solve this problem?

Many thanks

 

are you using each TON for each valve, i.e. one to one relationship? it could be a copy and paste error where same TON has been called with different preceding logic by mistake, hard to tell with the network you shown below unless we see the rest of the code.

you could start by debugging TON time one by one in your FB by commenting out other TONs and start with TON instance no.1, then continue to others. It could be that networks further down within the FB that disables the TON.

Suggest not to use M bit in a FB, you should declare the bit as an block parameter of the CALLING FB, and pass it onto the CALLED FB. Reason being if M bit inside needs to be used for something else in the future, then you have to going to each network where this M is used and replace it with something else, where as if you declare as a parameter, you just change/re-wire a new parameter without modifying internal FB M tag.

gigi_plc

Hi to all,

i have a FB block that i use several times for to manage some valves. This FB is then called several times in multi istance inside a main FB.

Sometimes after a donwload the timer doesn't work like in the picture. I have TIA 17 update 1.

How do you solve this problem?

Many thanks

 

Hello.

The IN parameter on the TON timer instruction should see a transition from FALSE to TRUE before it will start running. The timer might never start if there is something that interrupts this process. Most likely changes in the instance DB structure with a download to a live system.

To counter this occurrence, I have inside the FB a STAT bit I call #firstPass. Its default value is TRUE. #firstPass is reset in the last line of the FB. Elsewhere the #firstPass bit resets timers. This does the job of "first scan" but also activates when the instance DB reinitiates.

#firstPass  #condition
--| / |-------|  |------[ TON ]

#firstPass
----(R)

Hi Mr. qwazee, i think your idea can be a good solution even thougth it could be a problem inside the TIA. However i will follow your suggestion.

Many thanks. 

gigi_plc

Hi Mr. qwazee, i think your idea can be a good solution even thougth it could be a problem inside the TIA. However i will follow your suggestion.

Many thanks. 

It would be most interesting to know what type of problems you see within the TIA software. 

I 'cheat' a little as I use SCL. Using a proper text editor (like VS Code) makes it possible to type code on multiple lines. It is easy to produce [below] without much efforts.

Here what Siemens writes about this problem.

You are right, TIA has no problems about this situation.

Many thanks. 

gigi_plc

Here what Siemens writes about this problem.

You are right, TIA has no problems about this situation.

Many thanks. 

When drowning, do not wet your hair.  /s

Loading changes to the parameter structure of an FB onto a live system, disrupts the timer instance. This case is also mentioned in the caution you are quoting. Triggering a RESET_TIMER() instruction does not add to the already problematic case. The instruction call tries to handle the case to better the situation. But it should be done as an exception. Fighting fire with fire.