data file size

beanpole_ecc

Member
Join Date
Mar 2011
Location
Ohio
Posts
48
Using an SLC 5/05 L551C as an example:

Is it better to program with a large single data file (i.e. integer data type with 255 elements) or break it up into smaller data types (i.e. 4 integer data files each with 50 elements)?

This is just a preference question unless this has an effect on processor efficiency.

Thanks in advance.
 
I prefer to break them into Task specific files for ease of documentation and troubleshooting etc. i.e. and Integer File for a PanelView Read/Write.

Stu....
 
My personal preference is to make data file that pertain to certain funtions of the machine. I think 50 elements would be a rather large file myself and I would only create a file that large if I was doing data logging or something along those lines.

Example:

Motor Speeds: 1 integer file
Faults/Alarms: 1 bit file
Auto Functions: 1 bit file
Manual Functions: 1 bit file
Status: 1 integer file

Like Ladder files I think it is much easier for next guy if things are broken into small chuncks and grouped together based on what the machine does.
 
That's cool. I've done it both ways (breaking up and large file). I'm currently doing one of the largest programs i've ever done and trying to make it easier for the next guy. For small programs I have tended to lump everything into one data file. This program has 4 modes of control, data logging, alarms, etc and I just wanted to see how other people did the separation. Always learning you know.
 
That's cool. I've done it both ways (breaking up and large file). I'm currently doing one of the largest programs i've ever done and trying to make it easier for the next guy. For small programs I have tended to lump everything into one data file. This program has 4 modes of control, data logging, alarms, etc and I just wanted to see how other people did the separation. Always learning you know.

One way to look at it.

What do you want to see when your troubleshooting. Do you need to look at several integers at the same time? Well if you do, wouldn't it be handy if they were in file together without abunch of other data that was not related?

Also your outputs may be used by several deffferent modes (or functions) wouldn't it be real cool if you could see those seperatly instead of all bunched together?

It is about preference but an easy test is have someone else look at your program and file structor and see if they can figure it out.
 
Thanks everyone for responding. I'm breaking up the program even more now. I can see the advantages more and more since the program is large (only 10 routines but a lot of math and calculations). So there are a bunch of user changeable setpoints that have to be available. So that's a main separation i've found that is working. Setpoint integer elements (grouped with other hmi integer elements), calculation integer elements, etc. All of those used to be grouped together. So when i had to make a small change, then another small change, the data file got messy pretty quick.
 
In addition to others comments, let me say: "Add Spares." There is nothing wrong with only using the first five elements of several different files who are filled out with 256 elements available.

There is something wrong with connecting to a running process and needing to add four integers to a SLC program and being unable to do so.

I try to fill up as much memory as I safely can with spare data tables and a few spare ladder files, so I can do online programming and keep it neat.

I try to leave a couple kbytes free for adding logic later, and the rest gets allocated to all shapes and sizes of data tables that I might need one day.

There might be a minuscule cost in CPU speed when you are using more of the available memory, but I would be surprised if it's measurable.
 
Last edited:
I agree with OkiePC - add spares beyond your assessment of future needs.

Also, if you need a file greater than 256 elements (0-255), then there is a facility that allows you to "Index across file boundaries". It needs a bit set in the status file, but once set, the processor suspends file boundary testing, allowing you to have, for example, an indexible "structure" of 2560 integers, made up of 10 consecutive Integer files of 256 words each. The processor will allow you to index to any element of the block of files, up to element number 2559.

Of course the processor doesn't know which files you want to apply this setting to, so it applies to them all. So in the example above, indexing to element number 3000 would be a no-no, but the processor won't fault out or even warn you !!

It is wise therefore to put index limit checks on all indexed file access, otherwise "unpredictable" behavior can occur.
 
Like Stu and Clay mention, break them up into function. It helps with readability and debug.

On that topic, I agree. You can also change the name of the files also....

C5 - COUNTER could be renamed C5 - TOTALISERS (10 character limit)

And don't forget that you can also add a description to the data-file, to help others understand its usage...
 

Similar Topics

I stumbled onto this behavior the other day, then went looking for old forum posts with the assumption that "there is nothing new under the...
Replies
0
Views
770
Hello guys Thank you all for your support. I have completed re-writing a program as it was lost and no back up file found. Now the three PLCs...
Replies
7
Views
1,372
Hello everyone, Does anybody know if it is possible to read the Free Memory words of a PLC5 from a status register? I have a feeling it may not...
Replies
1
Views
1,008
Hello All, I am working on converting a program written in RSLogix 500 to Connected Components Workbench. The MicroLogix to Micro800 converter...
Replies
1
Views
1,171
I am looking for a profile sensor that I can get access to the raw data. I looked a Keyence, Cognex and can probably get what I need but they are...
Replies
14
Views
7,175
Back
Top Bottom