Step5 / Step7 IN- and OUT- parameters

Does anybody know if the following was normal practice in Step5. This FC handles the (90°) "corners" of the production line conveyor system. It is called from an FB which runs autonomously on the same PLC in which I've had to add fairly substantial program modifications. The whole FC looks as though it was copied unchanged from an original Step5 version of the program, but it raises the question of whether you could do this safely in Step5.




I certainly don't like seeing it in a Step7 program and I'll be moving the HIME variable to a marker word anyway, but I'd be grateful for any comments - especially about the Step5 aspect.

I see what you mean.
As #HIME is an output, and it is loaded in the 1st instruction, what does it contain ?
Does the program work at the moment ?

Maybe it should have been an FB and not an FC.
As far as I remember, there were only FBs in S5. There was not the distiction between FBs and FCs. It is such a long time ago, I dont remember how instance DBs were assigned to an FB.

That may have worked in S5 and also in a Step 7 FB, but not an FC.

In S5 there were PB's and FB's, PB's had no I/O parameters.

S5 had no equivalent to instance DB's, no DB's were linked to FB's.

FC's are almost a cross between FB's and PB's in S5.

EDIT:
Change the #HIME to an IN_OUT and it should be fine, I'd check your other outputs and also ensure they are not updating IN's in the block!!

It has apparently worked for about two years, at least the people working on the line say they've never had any problems before. The problems appear to have started since I added my modifications, which have increased the amount of code by about 10%.

Whether it's the cause of the problem or not, I just don't like it and will definitely change it. What worries me more, is how often they've done things like this - I don't fancy the idea of having to check through all the FCs to see if there's more of it!

If I recall correctly, there were OB's, PB's, FB's and DB's.
PB's were jumped to (conditionally or unconditionally); FB's were called and parameters could be assigned to. I don't recall instance DB's, the correct DB had to be opened at the start of the FB?

I thought only IN & OUT parameters could be assigned to an S5-FB, so one had to create some 'scratch' memory part that could be used like S7-TEMP variables. There was also no RETURN value...

Sparkz said:

If I recall correctly, there were OB's, PB's, FB's and DB's.

Click to expand...

Correct

Sparkz said:

PB's were jumped to (conditionally or unconditionally); FB's were called and parameters could be assigned to. I don't recall instance DB's,

Click to expand...

There were no instance DB's

Sparkz said:

the correct DB had to be opened at the start of the FB?

Click to expand...

Not really, DB's were the same in S5 as shared DB's in S7, you didn't need a DB opened at all in an FB, you only opened a DB if you wanted to access the data.

Sparkz said:

I thought only IN & OUT parameters could be assigned to an S5-FB, so one had to create some 'scratch' memory part that could be used like S7-TEMP variables. There was also no RETURN value...

Click to expand...

IN_OUT's didn't exist, just IN's and OUT's. If I remember correct you could modify them inside the blocks etc as well.

EDIT: just re-read that last part, correct IN's and OUT's only. Scratch memory could be used, usually flag bytes 200 and above, we used a lot of indirect pointers (DO's) to get stored info when the amount was fairly large.

PeterW said:

Sparkz said:

the correct DB had to be opened at the start of the FB?

Click to expand...

Not really, DB's were the same in S5 as shared DB's in S7, you didn't need a DB opened at all in an FB, you only opened a DB if you wanted to access the data.

Click to expand...

You're right Peter, but what I tried to say is, IF you needed data from to a particular DB, you would have to open it yourself first.

In Step 7, all FC parameters are passed using area pointers. In the case of an elementary data type, (say MW100 is passed in as #HIME), then all accesses to #HIME in the FC are actually reading/writing MW100 directly.

Also note the following: if you pass MW100 as an input variable, if you write to that input variable inside an FC, it will write to MW100 !

To amplify, here is call to FC1 with HIME as an output parameter assigned MW100.


and here is the STL not formatted nicely for you by the editor:


Now here is another call but this time HIME is assigned DB1.DBW0:


and here is the STL unformatted by the editor:


As you can see the actual parameter passed is the local data area of the calling block.
In this case the value read by FC1 if it loaded HIME would be the value of the local data before the call (most likely random data). The Value of HIME is only written to DB1.DBW0 after the FC returns, the calling block expects that the FC has written the value to the local data area as specified in the passed parameter.

To answer RMA's original question, by inference Step 5 must operate in the same way as the Step 5 converter only produces FC's

I say, that was an excellent explanation.

Simon, I'm not sure that I understand 100% what you're saying. Do you mean that if the HIME parameter is a marker flag, that the program will work reliably, but not if it is a Bit in a DB? I was under the impression that the IN- and OUT-parameters were undefined local memory areas that were copied from or to the defined parameters at the start of the FC run for INs and at the end for OUTs, meaning that reading an OUT at the start of the FC, as in this case, would be reading an undefined value.

If I've read your example correctly, in the case of a marker flag, the program would reliably work correctly - is this indeed the case? If so, I've got a different problem from what I thought (not for the first time!).

So basically, it would be safer to declare all exchanged variables as IN_OUT's?

Roy,

RMA said:

Simon, I'm not sure that I understand 100% what you're saying. Do you mean that if the HIME parameter is a marker flag, that the program will work reliably, but not if it is a Bit in a DB?

Click to expand...

As long as the parameter is passed as an elementry type, the call to the FC will pass an area pointer to the variable, there is no copying to/from local data and the FC will access the variable directly (in effect using a L W[ARx,P#0.0] type of instruction)
So if the parameter is MW100 or DBW100 or IW100 for example, the FC will read/write the parameter irrespective of the parameter being an IN or an OUT.
If you pass DB1.DBW0 as the parameter, the FC cannot actually accept this as it can only acccept an area pointer, so the editor produces code that points to a local variable and then passes an area pointer to the local variable, after the call has finished, the calling block (not the FC) reads the variable from the local data and transfers it to DB1.DBW0

I was under the impression that the IN- and OUT-parameters were undefined local memory areas that were copied from or to the defined parameters at the start of the FC run for INs and at the end for OUTs, meaning that reading an OUT at the start of the FC, as in this case, would be reading an undefined value.

Click to expand...

Only in the case of fully defined parameters - all the copying takes place before and after the call to the FC, the FC just operates on the area pointers it has been passed.

If I've read your example correctly, in the case of a marker flag, the program would reliably work correctly - is this indeed the case? If so, I've got a different problem from what I thought (not for the first time!).

Click to expand...

Yes, it will work reliably.

Regards, Simon

Yes, it will work reliably.

Click to expand...

OK, that's nice to know, but it gets worse!

I've now found a couple of instances where the calling FC is passing an OUT-parameter to the called FC, in which the OUT-parameter is being read before being written (under some circumstances, not always). This parameter is itself a TEMP in the calling FC, how safe is this?

Cheers

Roy

Just as a side note to try to complete my understanding in this area, am I right in thinking that changing OUT-parameters to IN-OUTs will always cure the problem, regardless of whether we're dealing with Marker Bits/Bytes etc or DBs?