Not able to understand it

[manmeetvirdi]

I am calling FC4 through which I am just monitoring the input, which if persists for more then 10seconds continuously, will make the output high and output will remain high till 10 seconds after the input has gone

Now the problem is if I am using DB1.DBX0.4 at #OUTPUT then even if M16.5 remains ON for 10seconds, DB1.DBX0.4 does not goes HIGH



But if I use any M bit, say M40.0 at #OUTPUT then it goes HIGH after 10seconds.



Then writing

A M40.0

=DB1.DBX0.4



makes DB1.DBX0.4 high!



I have checked the cross reference and it shows that I am not setting or resetting this bit elsewhere, and also I have not used any word or real in DB1



PLC is 313c-2DP

File attached shows the contents of the FC4

 

[L D[AR2P#0.0]]

For a fully qualified DB reference, which DB1.DBX0.4 is, you have to use an IN_OUT parameter if you want to use SET RESET type instructions inside your FC.

 

[manmeetvirdi]

Problem solved!!Thanks L D[AR2,P#0.0]
But puzzel remains!!
*Why DB bit has to placed in IN_OUT? While M bit does not requires it?
*Can you explain in layman terms?

 

[L D[AR2P#0.0]]

All FC parameters are passed as area pointers e.g.

P#M0.0
P#I0.0
P#DBX0.0

When a parameter is accessed within an FC, the FC uses the area pointer to access the variable. When you refer to an input, for example, that is passed as M16.5, the value read is the value of M16.5 at that instant, not a copy. If you wanted to, you could change the value of the M16.5 with a SET or RESET and M16.5 would change.

Now, DB1.DBX0.4 cannot be passed using an area pointer as the db number is not part of the area pointer. Instead, it passes P#L0.0 as the parameter to FC4 and the editor places some code just after the call to FC4 that performs the following:

A L0.0
OPN DB4
= DBX0.4


In this case, the value accessed by FC4 is a local data variable, not a copy of DB1.DBX0.4 taken before the call. If you use SET or RESET, the value passed backout will simply be the random value of the local data variable at the time.

IN_OUT variables are copied to local data before the call, and then copied back after the call.

(Note that if you code the block call in ladder, the ladder editor copies the inputs to locals before calling the block anyway)

 

[PeterW]

If you want to remember the state of a parameter that you pass to the FC, you should always use IN_OUT.

To me it is irrelevant that you are planning to use fully qualified or not, if the call is changed later on or someone else uses the block without knowing then errors would occur.

Simple really, if you expect the block to remember the status of a parameter, use an IN_OUT every time.

 

[manmeetvirdi]

Hmmmmmmmmm
Thanks LD[AR2,P#0.0],PeterW
Getting the groove of this idea.
Cheers!!!!!!!!!!!

 

[manmeetvirdi]

CALL FC 105
IN :=MW90
HI_LIM :=0.000000e+000
LO_LIM :=-2.500000e+001
BIPOLAR:=FALSE
RET_VAL:=#TEMP2
OUT :=DB2.DBD 8

NEGR
T DB2.DBD 4

////////////////////////////////////////////////////////
Getting desired value at db2.dbd4
But if I replace db2.dbd8 with md216 then I need to add the TAK before NEGR to get desired value in dbd.dbd4
Why?

What I am expecting is that ACC1 should hold the data (same as db2.dbd8) after the processing of FC105 is done.
ACC1 is indeed doing so when Iam using db2.dbd8, but not when Iam using MD216,instead in later
case the value is going to ACC2, because of which I have to use the TAK before NEGR.

Surely I did not got the groove of the idea, Which l D[AR2,P#0.0] tried to explain.

PLease give one more try !

 

[L D[AR2P#0.0]]

This new problem is not related to your previous problem. When you call an FC with parameters, the value of the accumulator when returning from the function is not defined.

If you want to negate something, you must load it into the accumulator first.

For example

L DB2.DBD8
NEGR
T DB2.DBD4

 

[kamenges]

While I agree that you can't count on the value in the accumulator when the program returns from a function call and you need to explicitly load the value you want prior to the operation, in this case the plc seems to be doing something relatively deterministic. I'm just as curious as manmeetvirdi about what might be happening here. It seems like the plc is performing an additional data load operation on a consistent basis in the MD case.


Keith

 

[L D[AR2P#0.0]]

An additional load is taking place in the case of the DB2.DBD8 as it is a fully qualified DB address. FC105 writes the return value in local memory then code "in the background" loads the data from local memory and stores it in DB2.DBD8. In this case, the last thing in the accumulator is DB2.DBD8.
If MD216 is used, the local memory transfer is not required and the last thing in the accumulator will be a function of FC105's processing.

It is related to the previous problem

 

[manmeetvirdi]

CALL FC 5
r_in :=MD220
r_out:=DB2.DBD16

T MD 228

//////////////////////

CALL FC 5
r_in :=MD232
r_out:=MD236

T MD 240
/////////////////////

But in both the above cases ACC1 holds the data after completing FC5(simple load and transfer),irrespective to fact that I place r_out in OUT or IN_OUT parameter !!

 

[PeterW]

manmeetvirdi, why are you persisting, you've been told the correct way to handle this.

On return from the block do not presume that ACCU1 holds the data you last calculated in the block, that is why the parameter addresses are there, for you to pass information in and out of the block.

Once you have left the block, to transfer the data from r_out, you MUST first load the accumulator with the value transferred out via r_out. You do this in a manner such as L DB2.DBD16.

Apart from anything else, the program flow could be interupted!!!

 

[L D[AR2P#0.0]]

manmeetvirdi - re-code your FC5 so that the last instruction executed is:

L 0

 

[manmeetvirdi]

Ya L D[AR2,P#0.0] now nothing is getting transfered to MD 240.
Getting the physics behind it ...........

 

[kamenges]

PeterW, just doing what you are told to do doesn't increase your general level of understanding. This is actually a big problem with the education system here in the US. We are cranking out all sorts of people who can perform the mechanics of all sorts of operations but don't understand why they work or where to use them.

In manmeetvirdi's case the plc was doing something very deterministic and manmeetvirdi was simply asking why it was doing that. By understanding the mechanism behind what the plc is doing (which L D[AR2,P#0.0] explained quite well, by the way) manmeetvirdi may be able to keep himself out of a related but not identical situation in the future. That is the power of understanding and not just copying.

I, for one, applaud manmeetvirdi for taking the time to actually understand the cause of his issue.

Keith