Please help me: Area length error when reading

[BoSChoW]

Hi all,
I have a problem, when i try to run my application an error appear on the PLC S-300 CPU 313C. The diagnostic buffer says area lenght error, what does it mean? how do i correct this? anyone had some experiences with this cind of error might help me solve my problem.

Thanks for your help and your time. Regards.

 

[BNA]

Read this thread !


http://www.plctalk.net/qanda/showthread.php?t=12230
Regards
Brian

 

[JesperMP]

The thread that BNA posted a link to, discusses two possible causes for the error.

1. That the HW config is not setup correctly, so that the real HW does not macth the one setup in STEP7.

2. That the HMI tries to access data that does not exist on the PLC.

But the most common cause is this:
3. That the userprogram tries to access data addresses or i/o addrsses that does not exist on the PLC.

To locate the problem exactly, investigate the diagnostics buffer and look for "address being accessed" or something like that. I dont remember the phrasing exactly. The word-number and type (Input, output, merker, DB) will be stated.
Then use the cross reference to find out where in the program the address is being used.
Notice that the address that is used in the program can be of another type than word, it may be a bit, or a byte, or a doubleword. So you have to look for all posible types.

 

[SimonGoldsworthy]

Are you performing any indirect addressing in your program ?

If not, then my most common cause when encountering this error is that the instance data block(s) are out of date and are not the correct size (too small).

 

[BoSChoW]

Hi all and thank you guys, Simon yes i am useing indirect addresing for the inputs. In my application i have 16 steps, each step consists of 16 inputs. The user defines which input is being used... The error accours when the first step is executed...so the cause may be with the indirect addressing or perhaps with the error masseges on the HMI OP7. I will try and locate the error. Again thanks a lot guys.

 

[JesperMP]

1. That the HW config is not setup correctly, so that the real HW does not macth the one setup in STEP7.

I think that I have to explain a little more, otherwise what I wrote before could be misinterpreted.

For normal i/o access ("I" and "Q" addresses), there is a "proces image" of a certain size on the configured CPU.
The "Area lenght error" only appears if the program tries to access i/o outside the proces image. If the program tries to access i/o that is not configured in the hardware setup, but is within the proces image, then there will be an error, but not the "Area length error".

For access to peripherial i/o ("PI" and "PQ" addresses), then the addresses must match the configured hardware exactly in all cases. If not, then you will get the "Area length error".

 

[BoSChoW]

Hey guys,
I have located my error. It happans in the case statement. And i dont know how to correct it. In the first case when all the conditions are solved the application should go to the next case statement but instead the error appears. My case statement looks like this:

CASE setp OF
1: stepping:=2;
2: stepping:=3;
.
.
.
15: stepping:=16;
end_case;

step:=stepping;

 

[SimonGoldsworthy]

I know this doesn't identify the problem, but wouldn't it be a lot simpler to code this as:

step:=setp+1; ?

 

[PeterW]

Can't see it being the case statement itself, probably the step that's processed is causing it. I would presume depending on the value of step, it will jump off somewhere.

Or possibly, you have no 'else' in there, so what value does stepping have if the case variable is not within the 1 to 15 boundaries?

If setp is outside 1 to 15 it will pass over without effecting the variable stepping.

So its either something in one of the steps 2 to 16 or its whatever happens if its setp is outside the expected number.

 

[BoSChoW]

Simon, i made my application like this to avoid repetition. I have avtomatic and stepping mode. And i wanted to use a single CASE for both automatic and stepping, but yes your proposal resolves my problem, but i will have to make the second CASE for the stepping mode. Tommorow i will fix the error hopefully.

Peter i have alll the else conditions, but somehow when the step:=2 the error appears and i dont know why, but i will do as simon has suggested.

Thanks a lot guys for your help and support.

 

[BoSChoW]

Hi. I made the changes as Simon suggested but the error is still present, something is wrong with my addresing. I just tiped step and stepping between the VAR and END_VAR, is something wrong wtih this ? I dont know, can somebody suggest a better way to do CASE statements?

Thank you very much for your time and help.

 

[Gambrinus]

It will be better to fix your problem. If you have possibility to do it, try to comment by // all (this means temporary disabling) from place where execution jumps after CASE. When ERR LED switches off, re-enable step by step your program lines until error occurs.
Second. Organize your pointers content transferring to not used M or DB area to analize it from VAT.
Error may be simple and stupid, my expirience says.

 

[Ken M]

Hi BoSChoW

I'm not convinced your problem is in your CASE statement. This may be where you see the symptom, but it certainly looks correctly constructed.

If SETP wasn't declared as an integer, it wouldn't run (or compile) at all. If STEPPING and STEP weren't declared as integers you couldn't assign values to them as you do. So all clear so far. Even if SETP has a value of 0 or 16, this shouldn't fault the CASE statement: if it doesn't find a match it just carries on without taking any action.

You are controlling the value of STEPPING and STEP from the code so we can predict (to an extent) the outcome of these. What about SETP? How is its value established? Could it be that a non-valid integer value is being created there somehow? Is it set by your HMI?

Regards

Ken

 

[SimonGoldsworthy]

Going back to an earlier post, as follows:

I have located my error. It happans in the case statement. And i dont know how to correct it.

What did you do to establish that the error occurred in the Case statement ?

 

[BoSChoW]

Hi guys, i have finally solved my problem. The error was in the comparison of the words... I had compared a word that existed with one that dosen't thats why the PLC went to RED led. So to solve the problem i just had to correct this.

And yes all of you were right there was nothing wrong with the CASE statement. And i wanna thanks all of you for helping me out on this one. Thank you very much.

Regards.