Siemens FB dev mon/mod values in VAT for debug... and other FB dev questions.

[Nick Birke]

For starters, Timer logic should be fed to the IN pin, EN should be true all the time.

I could isolate it like that... but so far this has worked fine.

 

[Nick Birke]

Ok so I made a new FB... I noticed in its properties... it calls no DBs. my FB78 is somehow calling DB79 "in the code..." this might be a clue... I don't know of any calls to the DB in the code... I'll have to take a closer look at this.

One more thought... if EN always has to be on, and you think this is a problem please make that very clear. However this has worked with conditions before EN before.

 

[Nick Birke]

I think I may have a new course after following the leaders...

For starters, Timer logic should be fed to the IN pin, EN should be true all the time.

Actually... I think I get this... this is a must for the block for it to maintain proper states and function, and why it wasn't before. This would make a lot of stuff in the FB unnecessary. I took those conditions before it and just put them on a rung that turns another internal bool on and that applies power... I think I am going to do some serious cleaning... I still want to know why it is pointing to DB79... I think at one point, I had an SFB inside the FB that was attached to DB79... but that is long gone.

PS... sorry if I am thinking out loud here... I am not trying to bump the thread.

 

[TurpoUrpo]

For FB's, if EN is not true, that block is not executed at all. For simple example. If you have SFB4 and there is some condition #power that is for both EN and IN, when timer is passed its time and Q is true, now false at said #power would result Q being true as code that controls Q is not executed at all.

 

[Nick Birke]

For FB's, if EN is not true, that block is not executed at all. For simple example. If you have SFB4 and there is some condition #power that is for both EN and IN, when timer is passed its time and Q is true, now false at said #power would result Q being true as code that controls Q is not executed at all.

Yah... that makes perfect sense. :nodi: And in fact I do remember having to mess with Q after I added those conditions... before I did it behaved as expected. I am pretty sure this was the course of events anyway. This is very good.

I still want to know where the call to DB79 is though

Again, my continued thanks... a very passionate community! You are all invited for a round on me... but you have to pay for your own plane tickets. Damian you are in driving distance.

 

[Nick Birke]

Well taking care of the issue with the EN power (note the small change to do this in the image) on the embedded SFB4 solved the problem in the case of using it in a single instance... it still gets confused when I use two in OB1... somehow data must be shared or crossed, or overlapping somewhere.

 

[TurpoUrpo]

In network 5 there is sfb4 call with instance datablock 79. That is why it shows up in properties and that is why it cannot be used as multi-instance.

There is lot to clear tough. It seems very complicated, it takes some time to get what is done and where and why.

Edit.

In your last picture #_TONON will always be true.

 

[Nick Birke]

In network 5 there is sfb4 call with instance datablock 79. That is why it shows up in properties and that is why it cannot be used as multi-instance.

There is lot to clear tough. It seems very complicated, it takes some time to get what is done and where and why.

Yah there is a lot of stuff in here so that the FB would behave just the way I wanted to. A lot of it is driven by preference... a lot of it is unnecessary... especially considering my mistake of conditioning the EN.

Yah that timer on N5... forgot about that... its not even used as you can see... I need to wipe that out of there. Good spot

 

[TurpoUrpo]

It sure shows you are new to siemens.

Temp cannot be used the way you use it in some cases. It must always be written to before its read in same fb or fc.

SET and RESET do not always write to, neither does move if its conditional.

 

[Nick Birke]

Showing a problem and a little background.

See one of the behaviors that is trying to be achieved is if power is turned off to FB78, or when the timer is done and the internal power is on... the internal preset should be updated to the PRESET input... this works fine with one timer but not two... see images... notice the values of md20, md65, md35, and md75... particular with m2.0 off. Note that I have changed the program a bit so the network numbers you see in what I sent you would have to be subtracted by one... I am also modifying OB1... to have two timers or one.

Ack that is hard to see I just wanted it to be a file attachment.

 

[Nick Birke]

It sure shows you are new to siemens.

Temp cannot be used the way you use it in some cases. It must always be written to before its read in same fb or fc.

SET and RESET do not always write to, neither does move if its conditional.

Yah I am just trying to get my hands dirty here. I am in a big rush to understand it and have little resources to get straight answers... HEY... if they would just use normal timers ...like everyone else I wouldn't be on this crazy side track. But I am glad I am because I am learning quite a bit.

 

[Nick Birke]

Having said that... is stat a better place to put internal variables?

I am really thinking of dropping my current FB and starting over.

 

[TurpoUrpo]

Yes that is most likely becouse of incorrect use of temp variables.

When you call FB (or FC) it gets its temp memory allocation from common stack (L data area, previous blocks temp can be accessed trough use of V). That means other block can change value of memory at same place as its used in other block.

First thing to do, is change all your temp variables to stat, regenerate idb's and try again.

 

[TurpoUrpo]

SFB4 is as "normal" as it gets. Its called IEC timer as its pretty much standardised timer. For example CoDeSys uses exactly same kind of timers and CoDeSys is tought to be most standard (IEC) following implementation.

Siemens has its quircks as AB, Omron, Mistu etc. have theirs.

I do recommend starting from beginning and doing one functionality at time, then testing it, then doing next.

 

[Nick Birke]

I just don't like the way the IEC timer use TIME DTs and I of course hate S5TIME. The main main purpose of the wrapper is to have an interface that is in all DINTs... so that liner scaling, and other simple calculations... like getting remaining time are encapsulated and don't have to be repeated over and over and over again.

WinCC does not do these things well, and it seems redicilous to have several rungs of logic for each timer in the PLC program.