Siemens 300 SFC20 Ret Value

Siemens 300 SFC20 Ret Value of -32478 = HEX 8122

8x22 Range length error when reading a parameter.

I have a remote I/O profi bus unit with 4 8 bit Input blocks and 2 8 bit Output blocks. I get this error when trying to use SFC20 to copy P#I 125.0 BYTE 4 to P#DB78.DBX20.0 BYTE 4. When i create a VAT table to monitor I125.0 to I128.7 all the bits in IB128 say "cannot monitor".

this is on a CPU 315 2DP.

Anyone have any ideas it would be greatly appreciated.

-Joel

I'm guessing this module has a max Input value of 127 for bytes?

A quick look at the spec for a 315 reveals the max process input image address as 127. Re-address your module starting at IB124
Note you can use the following instead of SFC20.

Why are you copying the inputs to a DB ?

Thanks.

I just found the "performance data" under "Module Information" that also lists the max addresses for I/O. It always takes me a while to find manuals or information on the Siemens site, I use that as my last resort.

As far as the SFC20 we use that at our company since no one in this area knows anything other than ladder. Keeps the confusion levels down

Also the only reason I have for copying the Inputs the DB is that i'm following the original job structure. Although the fixture's have different profibus addresses some of them are set to use the same I/O addresses. I would prefer to see the I124.6 instead of the DB address for it, but to many cells to change so I just let it be.

JOLTRON said:

As far as the SFC20 we use that at our company since no one in this area knows anything other than ladder. Keeps the confusion levels down

Click to expand...

Byte
Words
Doublewords

They can all be transferred with the MOVE-ladder box. No need for SFC20 in this case since you're only moving 4 bytes.

L
T

Is just the STL representation of the MOVE instruction.

I figured that. It looks like the original programmer used this for copying parts of strings and secitons of data blocks and then just carried over and used it for everything. Is it a waste of memory to use SFC20?

-Joel

JOLTRON said:

Is it a waste of memory to use SFC20?

Click to expand...

Think scan time...
For the example you give above 4 input bytes -> 4 data bytes on a 31x CPU then typically:

Using SFC20 = 81μS
Using MOVE (Load & Transfer) = 0.8μS


**edit**
Actually, MOVE in this case is 0.9μS as the NOP 0 used for displaying in ladder eats up another 0.1μS

Interesting, how did you come up with those numbers? And at what point does scan time become an issue? In this program the SFC20's are used all over the place instead of the move statements. What would I gain by changing them all over?

JOLTRON said:

Interesting, how did you come up with those numbers?

Click to expand...

Siemens instruction manual.

Link Here


Document A5E00105517-09, Manual S7-300 Instruction List CPU 31xC, CPU 31x, IM 151-7 CPU, IM 154-8 CPU, BM 147-1 CPU, BM 147-2 CPU

JOLTRON said:

Interesting, how did you come up with those numbers?

Click to expand...

Oh - just a wild a$$ed guess.....

JOLTRON said:

And at what point does scan time become an issue?

Click to expand...

When it becomes too long to enable processing of the fastest event required by your program.

JOLTRON said:

In this program the SFC20's are used all over the place instead of the move statements. What would I gain by changing them all over?

Click to expand...

A shorter scan time

SFC20 is still the way to go for large transfers though - lots and lots of MOVE or 'Load and Transfers' can get messy.




** Ooops cross-posted with Peter **

JOLTRON said:

And at what point does scan time become an issue?

Click to expand...

At the point you cannot control something.

An example, I started working at a company on a contract basis taking over from a guy that moved on. They had a conveyor line where at one point they had a little gizmo to flip a tray of powder packs.

The gizmo could not stop accurately at the speed it run, its stopping position was inconsistent, at the time I started they were beginning to design a hard-wired circuit as they said the PLC (S5-115u) was not fast enough.

I looked at the program and found that the previous guy (who was an AB guy through and through), had written a little FB to act as a one-shot (typical AB guys complaint at the time that S5 had no one-shot command). He used this FB all the way through the program as he also liked one-shots.

A quick calc, based on direct addressing verses passing parameters via an FB led me to believe that the problems with scan would be solved by getting rid of the FB and replacing with two line of code in each case (what the FB contained in any case).

Once done the gizmo worked perfectly.

The moral of the story is, wasting scan time for a one off function may not be too bad, add them up and they can be a problem.

I'd look at all the SFC20 calls if I was you and only keep what's necessary.

Shortest 8ms
Current 14ms
Longest 35ms
This is what my module information is reporting back to me at the moment. Is there a rule of thumb as to when I should start looking to reduce? Aside from nearing 150ms mark.

JOLTRON said:

And at what point does scan time become an issue?

Click to expand...

Look for Combo's post about high scan time. Perfect example of when it's becoming a problem.