Programming with Concept IEC


Thread Starter


Okay, I've had people tell me that the Concept IEC programs are memory hogs, but this is ridiculous.

I have several different projects where I used Quantum CPU113-03 processors with LL984 logic with around 400 networks of fairly dense DX logic to control several hundred motors without any problem. So now I've decided, reluctantly, to modernize and use IEC on my current project. I developed a few motor control DFB's (derived function blocks) to do what I once did with DX logic blocks in LL984. I used these in a program to control 40 motors (same 113-03 CPU) and I'm out of memory after getting 8 motors programmed. I have another 30 or so motors to go and no memory left in the CPU. Am I missing something very obvious here?

I'm also interested in your general comments and experiences using Concept 2.5. I can't say that I'm terribly impressed with it so far.

Charlie Hiatt

Are you useing the stripped executive in the quantum 11303. This will increase your memory from 130k of IEC to 368k of IEC.

Select the 140CPU11303S from the PLC selection. The PLC executive must be Q1SV230D.bin for 2.5 SR2.

This should help memory problems.

Robert Willis

What Concept Exec do you have loaded into the 140CPU11303 controller? If you will do a search on CPU Selection from the Concept Help file you will get a table, which will detail the max amount of IEC memory that is available when using a particular Exec.

It sounds like you have the exec that allows for both the 984LL and IEC which will limit your IEC memory to 136K. If you switch to the "Stripped Exec" you will then have 379K available for IEC programming however you will no longer be able to have a 984LL section.

Do you have any of the Concept Version 2.5 IEC Upload features turned ON??

Concept is a powerful IEC61131-3 compliant programming package and will use more mempory that the 984LL editor.

Robert Willis
Square D Company
Houston, Texas
E-Mail: [email protected]

Nucciarone, Joe

concept is the only software i've ever seen that won't let you upload from the plc unless you have the project on your pc. makes me mental!!

Gavin Maclean

When I used Concept there was place to configure how much memory is set aside for IEC code, and one for data. If you set the IEC to max, you can't do any 784. Also check that it is only download IEC blocks that you require.

My view on Concept. I love the DFB's, but you can keep the rest.
Joe you need to get a current version of concept. This is one of the only plc software packages that allows you to upload the plc program, complete with all documentation onto a pc without anything other that the concept software itself loaded, IE no user program on the pc what-so-ever. As for the memory issue that was initially asked about, you are obviously missing something, 100 motor starter circuits should be no problem.

Check that you are using the stripped exec for this low end processor, verify that you have increased the iec memory space in the processor selection area, verify that you have not made huge amounts of unneeded register space that you are not going to use.

You can also disable the upload capability to increase space signifigantly, especially if you add alot of comments which is not a bad thing. Follow general good optimized programming techniques and contact your local distributor or modicon application engineer if still having problems.


I haven't put the stripped exec in yet, although I'm aware that it will save memory. My concern is that if this gives me 2.5 times more memory than I have now, that will allow me to program about 20 motors before running out of memory (assuming a linear relationship). Maybe I shouldn't assume this since the memory used by the DFB's is only used once. I'm mainly concerned about the order of magnitude of memory usage here. So, I was wondering if there are some other optimization techniques that I'm somehow missing. I tried reading the Konzept manual on this, but I'm not very good a reading bad German to English translations (more comments about Schneider's horrid manuals follows below).

Bob Peterson

I don't know for sure about earlier versions but version 2.5 allows you to do so providing the original programmer included "download" information as one of the code generation options. It does eat a substantial amount of memory to do this.

I suspect that the people that came up with the IEC stuff in the first place would not understand why you would want to do this anyway.

Bob Peterson
We find that DFBs are a memory hog. You may want to try converting your DFB to a MACRO, which places a pre-connected set of EFBs on a concept

Also, you can check your memory allocation. There is a setting (slider) somewhere to allocate memory to either programs or registers.

You probably will get a more technical answer from one of the modicon guys on this list.

S. Landau
I agree with all of the other suggestions (use stripped exec, use DFB's for some things but not all, disable the upload feature etc.) One other note though, are you actually downloading code into a 11303 controller or using the memory prediction function?

I know that as of two weeks ago there was still a bug using memory prediction for IEC code on a 11302 or 11303. In my case, memory prediction reported 85% used and when downloaded to the controller, memory statistics showed only 40% used. This was reported to and verified by Schneider and was not fixed with the Concept 2.5SR2A service release. They told me that it should be resolved with the next service release.

One other note, you can save memory when using constants in place of duplicate literals. Probably not enough to matter in your case but I have seen people use a literal in a hundred places they needed the value of "10". They could have saved 99 pieces of memory by defining one constant with a value of "10" and referring to it.


I was actually downloading the program. The memory predictor came up with very similar numbers to the actual download.


I've created about 5 DFB's, one for each specific type of equipment to be controlled. They contain on average about 60 FFB's each. If I create macros instead, and use them in the 45 instances for equipment being controlled (45x60=2700 FFB's), I would be very surprised if they used less memory than DFB's, unless DFB references have phenomenally high memory overhead, but I've been surprised before. I assume (at least I would hope) there must be a point of complexity where DFB's would be more memory efficient than macros.
I am working in automation business during of 3 years. The used programs is Concept 2.5 and EFB Toolkit. I programme Modicon TSX Quantum with IEC HSBY for automation of oil pump station.

My EFB library is allow the:
- process the 2000 discrete inputs;
- process the 500 analog inputs;
- process the any number outputs;
- the new signal can describe with HMI without stopping and downloading project in CPU;
- the new equipment can describe with HMI without stopping and downloading project in CPU;

I have one instance DFB for alike equipment.
The free data memory about 50% with HSBY!
Timescan is 150ms with HSBY!