S7-300 Efficient Program?

Hi All,

As you know, the work memory for the S7-300 PLCs are limited. Maximum size for the 317 is 512KB and the 315 is 128KB only. I am using the 315 for my project and just wondering how i can write a super efficient program to fit in the 128KB memory. My application requirement requires more programming memory than expected. It is getting more than the 128KB limit....

Anybody know if there is a difference if my program is written in STL, FBD or LAD ? My program is 95% written in LAD and is structured in function blocks. The OB1 will call a series of FBs to do the required tasks.....

Anybody knows if this method will take up more memory? or is there another alternative way to it?

regards,

...the work memory for the S7-300 PLCs are limited...

Click to expand...

Well I've never yet found a PLC with unlimited memory. Those damned manufacturers always seem to stop the memory a few Kbytes before the end of my program. How dare they? Don't they know how I write my code?

Anybody knows if this method will take up more memory?

Click to expand...

Than what?

In general STL allows you to use more terse instructions than either FBD, LAD, ST or SFC. However, equally generally this may be said to be at the expense of comprehensibility. The issue of using FBs is presumably one that is determined by your software design rather than your chosen programming language. Could you have used FCs? Very probably. Would that have made a difference? Maybe, maybe not. Depends on what your design called for.

Have you tried re-coding any of your 'typical' ladder functions as STL to try to get a measure of how much saving you can achieve? Everyone's mileage may vary. Are there any DBs you can create as unlinked to save on work memory? What memory-saving techniques have you tried and to what extent have they been successful?

regards

Ken

If this is a one off machine then upgrade to a 317 now. If you haven't finished yet and have exceeded 128kB you could spend a lot of time saving a bit here and there to make it fit in a 315 only to find during final commissioning that you need even more space - that is not the time to find you have to wait for a 317 to be delivered to continue.

What's efficient code? To you it might be code that does what you want in as few instructions as possible. In that case I figure you're a software engineer who'll have nothing to do with maintenance once the code has been delivered.

For me the most efficient code is the one that doesn't make me jump out of bed in the middle of the night because a maintenance technician can't read the program I wrote and doesn't see that the source of the error is a mere sensor not being aligned.

The most efficient code can also be the code that gets the most result out of the least effort on my side. For that reason I use parameterized functions all the time, regardless of the memory it takes.

I think it's far more efficient to use a better equipped CPU (meaning more memory) than investing a lot more man hours to design a tighter fit program.

Remember: you program the thing once, but you (or someone else) have to do the maintenance for the next 20 odd years. And this is true in the majority of the cases.

Kind regards,

My suggestion is, try STL on calculation, it will save some memory space, cause Siemens LAD is too odd in math.

Try to use more FC, less FB then you'll have less DBs.

As experts said, keep logics in LAD as much as possible, it's easier for you, easier for others.

One more thing, you can use loop if you have lots of repeat logic - the down side is it's hard for maintenance guy.

I find you can reduce code size by using standardised functions.
For example, you could have one function to contain the logic for a DOL drive, andother for a VSD, and a third for an air solenoid. We have done this on a fairly complex machine recently, and used a 317 cpu. We found it only used 72k of work memory in total, meaning it could fit in a 315.

Other tricks to get your functions to use less memory:
1, passing variables seems to take up a lot of memory the way Siemens does it. Passing individual bits takes more memory than passing an entire word. Passing DB variables takes more memory than M type variable. A test I did once showed that exaclty the same function took up 4 to 8 times the memory where it was called if you used DB memory in the function's inputs and outputs compared to using M memory.
2, Our European contractors have a tendancy to use "letterbox" type memory passing with global variables. i.e. they will load memory locations in the code, call the function which will access these locations, then pick up the returned values at another memory location. This memory is re-used each time the function is called. This saves memory, and seems to run faster. The down side is searching on this memory location will show it being used everywhere, and trouble shooting is far more difficult.

Appleplc07 - what are your thoughts on these replies ?

sorry for the delay in my reply. Was busy trying out to make my program efficient but yet easy to maintain. So far i have managed to shorten my program work memory requirement by changing most of the FBs to FCs. I am actually controlling about 80 plus micromaster drives per PLC. So you can imagine how big my program will get.

I do have an option to use 317 but i just want to get it right in the beginning as i am worried i will exceed the 512KB limitation for the 317 model. As for coding in STL, preliminary tests done by me shows no difference if coded in LAD.

Very big for 315, what is the scan-time ?

pboll said:

Try to use more FC, less FB then you'll have less DBs.

Click to expand...

(English Grammar 101 - 'less DBs' should be 'fewer DBs' but what the hell.)

Yes this may be possible but may not be desirable. An FB certainly requires some data area in which to store its instance data. Many programmers use single-instance DBs for this. Others use mult-instance DBs. So the issue of how many DBs you use is entirely controllable even when using FBs. There's no evidence in Appleplc07's post that he is running in to the limits of total numbers of blocks, just the total amount of memory. While the creation of each separate DB has a small overhead associated with it, I don't think this will represent a major saving even if he combines them all.

Moving now to consider the use of FCs as opposed to FBs. This may well be regarded as a way of saving memory, but I'm not convinced. If in your original design you decided to use FB/IDBs as a method of storing code and associated data, where do you store the associated data if you now switch to using FCs? You're going to have to use a DB or DBs for this in any case. If there was never any need for associated data to be stored with the FB code why were FBs designed-in in the first place? This is not just a coding matter, it's a software design matter. It's wrong to think of an FC as a low-memory FB-lite. An FC does one task, and an FB does another. If you need instantiated data use an FB, otherwise use an FC. So the question to ask about these should be during design, not after coding!

Just as an aside, does anyone ever leave the CPU selection & purchase to the end of coding? You can buy all your I/O, racks etc early, write your code, test it using a simulator, and then when you're 90%+ sure you've got the sizing of the code accurate, go and buy you're CPU. I know you need to know costings in order to win a job and the price of the CPU will affect that. But how often do you spend more than the difference in costs between two CPUs in engineering time & effort trying to shoehorn a program in to a limited amount of memory? And how often do you end up upgrading anyway? Just curious.

Regards

Ken

Thanks for remind me the exactly difference of FB and FC. I admit that instant DB has lots of advantages, but think of this: appleplc07 has 100% program LAD, so what's the usage of FB?

And he wants to keep as much LAD as possible. If he needs to exchange some status, he is doing it by global variables which means FB is as same as FC for his application. Is that right?


By the way, if you want to write some IEC standard PLC program which means you can keep the exactly same logic on all kinds of PLCs, you cannot even use STL. So, why not keep all as FC? - It's normal subroutines!

I am actually controlling about 80 plus micromaster drives per PLC.

Click to expand...

I wouldnt waste a second trying to squeze that program into a 315. If there is a problem with the memory or the scan time, get a 317. With 80 Micromasters in the project, I cannot see what justifies the time for trying to shoehorn the code into a 315.
If a 317 is not enough then there is the new 319 with even more memory and processing power.

A Bigger CPU and Smaller Problems, Sometimes I am ready to Pay instead of My boss for better devices instead of insisiting on complicated software or design...

128Lb/80 drives is only about 1.5 Kb per drive. If the parameters are going to be saved in the PLC then they will use the most memory. If the drive uses 32 bit floats or 32 bit longs the memory will be gone in no time.

I don't see why one would convert FBs to FCs. FBs are necessary to save state. Now how are you going to save state using a FC. Sure, you can pass pointers to globals arrays or data but the state must be stored somewhere.

Use STL, not LD. LD code if very inefficient compared to STL because it must always be loading parameters before each block and storing the results of each block. LD must also keep track of the ENO state which uses a lot of code. Finally, array indexing or indirect addressing is almost impossible to do in LD. The code should be very efficient if you can treat the data base of the motion controllers as an array of motion controller UDTs. Then you can index through the drives in a loop instead of repeating code.

We make moton controllers. We won a competition between us and two European motion controller companies because our controller had a FB that was used over and over again by each controller. Only the DB instance changed. All the axes did pretty much the same thing although they did go to different locations. Apparently the S7s were pretty full. The code to run the competitors' motion controller was too big and would not fit in the pre-existing S7 whereas ours could easily. I was told by the customer the difference in code size was at least 2/1. The key is to have re-usable routines as Doug suggested. Another key is making use of the JL instruction to make state machiness. The JL instruction and properly designed state machines can reduce scan time significantly.

What hasn't been made clear is where the motion controller parameters store and how many of these axes can use common code with only the commands and parameters changing?