SLC 5/04 and PV decimal handling

Hi all-

I have an application where a part is being measured using stroke reading cylinders and a HSCE2 card. Basically I'm using the high-speed counter to count the pulses from the cylinder, and then using a calibrated offset, determine the part dimensions. One pulse is equal to 1/10 of a mm. This is done for both length and width.

The customer needs to be able to input 4 parameters from the PV600 for each of 255 different part types- length, length +/-, width, and width +/-. I will calculate a min and max for both length and width, then loop through with the measured values to determine the part type.

The setpoints need to be entered from the PV in mm with one decimal place (xxx.x mm). Obviously, I can use floating point files for this in the PLC, but then I'll end up with 8 floating point files of 255 elements each. Would it be better to store the values in the PLC in integer files in tenths of a mm (104.2 entered on PV writes 1042 to the PLC register)? I think I could use scaling in the PV to do this. This way all of my PLC registers that I need to scan through and compare are integer files. I know this would save memory, but possibly scan time as well.

Any thoughts?

what's the highest number that you'll EVER need to handle? ... hopefully it's 3276.7 or lower ... we'll need to know the answer to that question before we go much further ...

The stroke of the measuring cylinders is only 250mm, so the highest number I would need to handle would be 250.0 (2500 in the PLC for N files), so that is not an issue.

If you are comfortable working in counts instead of decimal mm then that might be easiest. That way you don't have to convert the HSCE value.

There is the memory issue. The 255 * 4 floats will take up 2040 words and the ints will only take up 1020 words.

You can see how many words you have free by double clicking controller properties in the project tree.

Actually, there would need to be 8 floats at 255 each. I'll need to add and subtract the '+/-' to both the length and width and store it in files to use as the max and min values of my LIM instructions. When the measured value is between the min and max of both lenght and width, then I know which part type I have.

I am leaning towards using N files instead of F, and using scaling in the PV to do my conversion to whole numbers. I just have never done this before and don't have the PV available to test. I can have the operator enter a number with one decimal point, set the scale value to .1, and the PV will write a whole number to an N file, correct?

You can do it with integers and it will work just fine. The PV can do the scaling for you no problem. It is a common practice. You will need to set the scale factor in the PV tag database and set the decimal point display correctly in the display objects. I can't be more specific since I don't have the tools in front of me to check further or the memory to recall all the details

Are you tolerances uniform or varied? What I mean is are the limit checks going to all be plus or minus the same amount? If so, you could reduce your memory usage further by calculating the limits just before the check and only store the tolerance instead of storing the upper and lower limits for each product. It's a less flexible solution, but if you are running out of memory it could help.

OkiePC- The tolerances are all uniform. The width, width tolerance, length, and length tolerance are entered from the PV for each of 255 data types. In order to do the LIM instruction I would need to create files of min and max values based on the input setpoints and tolerances, right? Actually, since I'm looping through the same logic over and over I don't need to store the min and max separately for each part. I can keep one min and one max register that gets updated with the appropriate data each scan. I see what you mean now. Thanks for the idea.

The rest of the application is fairly small, so I'm not all that worried abot memory. This is just more of a best practice question. The main thing I hoped to save would be scan time since I have to loop through a maximum of 255 times searching for the data type match. If my instructions reference N files instead of F files, they might execute slightly faster.

If you have to loop up to 255 times during a single program scan, then definitely use integers and avoid any unecessary math. Precalculate the limit values in advance as they are entered, so they are all ready to go before the search begins. Trim the logic within the loop down to the bare minimum.

You should also do some worst case testing to make sure a big hit on the scan time doensn't cause other problems elsewhere in the program.

I would have suggested sorting the entries as they are stored, but would you sort them by length or width? Probably won't help, huh?

Another thing that may come into play is breaking up the search into multiple PLC scans. If the application can tolerate it, you may want to limit your looping to 16 loops per scan for 16 scans for example.

If I were you, I would start out with the simplest method and only get more complex with it as necessary.

From reading your post, it seems that you only need to look up the values when the operator changes the values from the PanelView. If this is true I would put your lookups in their own subroutine and only call it when the data changes from the PanelView.

Are you crunched for memory in this SLC5/04?

Eight tables of 255 floating point numbers will occupy 4K words of memory. 5/04s come with 16, 32, and 64 K words of memory, so unless you have thousands of rungs in your program or you have lots of other huge data tables, you really shouldn't have a problem with memory. If you are not pressed for memory, then any unused memory is money you already spent that you aren't using, so you may as well use it and make life easy on yourself.

Right click on "Project" in the project tree (top of left panel) and select statistics. You will need to verify the project first to get a current stat. It will show you how much memory you have used and how much is left. Chances are, you'll be pleasantly surprised.



This screen shot is from a project that has 339 rungs and a whole bunch of data files. I added 8 floating point files of 255 elements. The PLC is a SLC5/04 with 16K of memory. Even with eight files of 255 elements, there is still plenty of memory left over.

I don't know how big your project is, but my recommendation would be to take the easiest approach if you have the memory available instead of spending hours coding to conserve memory that you already paid for.