Doubt in multi instances of an FB

manmeetvirdi

Member
M
Join Date
Oct 2004
Location
India.
Posts
750
Hi there,
How are you all??

Ok question:

I have an FB 'A' which is calling FB 'B' four times.
In FB 'B' am using IN, OUT, STAT as well as TEMP.
I saw that bits used in TEMP area sometimes misbehaves. That is even if logic wise they have to be FALSE, they somehow remains TRUE !!
This problem is gone once I initialize TEMP area of FB 'B' at the very starting.
Ex: L 0
T LW 0

Am I doing something wrong because of which bits misbehave. These bits stuck once in a while or you can say once in a blue moon !
 
Cant think of any reason other than that you have conditional logic that does not always write to local variables which are read.

Posting the code would ofcourse reveal that..
 
are you reading temps before conditioning them first seeing how zeroing them solves the issue?
 
Hi,

Temp variables cannot be used like that. If program execution jumps straight to BE5 (without going through J13) the value for #Ignore_HH2 is coming from the local memory. #Ignore_HH2 is reset here but L22.0 is set previously in the program execution.
 
Classic error using SET to condition a local variable without resetting it at the start of the block.

Code: 
J13:  +AR1  P#2.0
      +AR2  P#2.0
      L     #count
      LOOP  J12
[B][COLOR=red]      SET   
      S     #Ignore_HH2
[/COLOR][/B]      JU    J15
J14:  LAR1  P#DBX 10.0
      LAR2  #Ar2_index_HH2
      +AR2  P#10.0
      TAR2  #Ar2_index_HH2

      L     #out_count
      LOOP  J11
 
J15:  LAR2  #Ar2_save
BE5:  A     #Ignore_HH2                 //<<<---Problematic bit (Bit remains TRUE)
      =     #same2                      //<<<<--This bit remains TRUE because of above bit, LOL!      
      R     #Ignore_HH2                 //<<<<---The traitor does not resets here :-(
 
Hi,
Well cant get the point still.

Temp variables cannot be used like that. If program execution jumps straight to BE5 (without going through J13) the value for #Ignore_HH2 is coming from the local memory. #Ignore_HH2 is reset here but L22.0 is set previously in the program execution.
Click to expand...

But #Ignore_HH2 is name of L22.0, so reseting #Ignore_HH2 should mean reseting L22.0. Also my believe is that local memory gets initialized between calls, that is when a block is called Local memory becomes zero. Is this not true !!:rolleyes:


Classic error using SET to condition a local variable without resetting it at the start of the block.
Click to expand...

What I can make it out is that by transferring zero to local memory Iam resetting the bits, approach which I took to overcome the problem.

But why in first place that bit did not reset when I say

A #Ignore_HH2
= #same2
R #Ignore_HH2

:unsure:

Eagerly waiting for replies.....
 
manmeetvirdi said:
Hi,
Well cant get the point still.



But #Ignore_HH2 is name of L22.0, so reseting #Ignore_HH2 should mean reseting L22.0. Also my believe is that local memory gets initialized between calls, that is when a block is called Local memory becomes zero. Is this not true !!:rolleyes:
Click to expand...

(y)

You need always make sure u write to l area variable before reading from it. Otherwise it has "some" value.

Code: 
J11:  T     #out_count; 
      L     5; 
J12:  T     #count; 
      L     W [AR1,P#0.0]; 
      L     W [AR2,P#0.0]; 
      ==I   ; 
      JC    J13; 

      JU    J14; 
J13:  +AR1  P#2.0; 
      +AR2  P#2.0; 
      L     #count; 
      LOOP  J12; 
      SET   ; 
      S     #Ignore_HH2; [B]//YOU DONT ALWAYS GO TROUGH THIS PART OF CODE, BUT QUERY STATUTS OF Ignore_HH2, ALWAYS WRITE FIRST TO L AREA VARIABLE BEFORE QUERYING ITS STATUS[/B]
      JU    J15; 

J14:  LAR1  P#DBX 10.0; 

      LAR2  #Ar2_index_HH2; 
      +AR2  P#10.0; 
      TAR2  #Ar2_index_HH2; 


      L     #out_count; 
      LOOP  J11; 



J15:  LAR2  #Ar2_save; 
BE5:  A     #Ignore_HH2; <<<---Problematic bit (Bit remains TRUE)
      =     #same2;      <<<<--This bit remains TRUE because of above bit, LOL!      
      R     #Ignore_HH2; <<<<---The traitor does not resets here :-(
[code]
[/quote]
Click to expand...
 
Last edited:
Yep,

might be that L22.0 is set in the previous call of FB 'B' as #Ignore_HH2. It remains true when program executes the second FB 'B'.
 
Uninitialised temps can catch you out years later. I once wrote some code for controlling the automatic unloading functions of a machine - it worked fine originally and was subsequently used on several machines before one developed a problem whereby it would sudenly begin unloading on its own; this was caused by an uninitialised temp variable. This happened because of a change to the software elsewhere.

Temp memory is allocated dynamically in runtime and its contents will be whatever the last program to use it left there - it might be zero or it might not!

Nick
 
Thanks..
Got very clear idea how to go about using The TEMP.

Rule of thumb for using TEMP

**Do not attempt to read the temp memory unless you have written something to it.**
otherwise.... you can end up doing this o_O or this 🔨 instead of doing this 🍺.

In my case i jump over if condition is false without writing to temp bit, this I need change to Reseting #Ignore_HH2 before any jump instruction so that even if conditions is false I have written meaningfull value to this bit.
 

Similar Topics

A
General doubt
Hello Guys, Hope everyone is doing well. I have a general doubt about ladder programming. The outputs are not getting energized when I used the...
Replies
13
Views
1,881
advmin
A
K
factory talk studio doubt
Hi all, I'm working with FTVS and I'm trying to give a title to a dynamic popup that shows what device it is currently operating. I've seen that...
Replies
5
Views
1,950
kuppe35
K
K
rslogix 5000 - newbie doubt
Hi all, I'm quite new to the automation world. I've used a bit Tia Portal in the last month and now i have a new working in rslogix 5000. From...
Replies
10
Views
5,068
daba
D
R
Doubt about emulating safety programming
Hello everyone! I'm currently programming a safety logic on Studio 5000 Logix Designer V33.00.00 and I wanted to know if there's a way to test...
Replies
2
Views
1,591
lee1968nh
L
K
Studio 5000 code doubt
hi all, I'm working on Studio5000, structured text language. I have several buildings and for one of each several BOOL alarms in an array...
Replies
7
Views
2,023
daba
D
Back
Top Bottom