ControlLogix Integers

I'm in the middle of a ControlLogix project and I started thinking about integers (dangerous, eh?).
When you specify an INT data type that is not part of an array or structure, how many bits does Logix5000 assign for that data type? From what I've been told the CLX platform is designed around 32-bit data access. So to do 16-bit integer math the CLX would need to do some masking or data shifting (possibly) before using the data it only 16 bits are assigned. If this is true it would be more processor efficient to use double integers wherever possible.

Anybody know how this is done? This is more for curiosity's sake than for any processing benefit I might realize.

Keith

I've read several ControlLogix manuals which say exactly what you said, that double integers are preferred over 16-bit integers. As far as I know, though, if you just declare something as a single integer, you don't need to program in any masks or bit-shifts or anything like that.

As far as I know, though, if you just declare something as a single integer, you don't need to program in any masks or bit-shifts or anything like that.

Click to expand...

Sorry about that. I didn't phrase that statement as well as I should have.
I know the programmer doesn't need to do anything special to access the data. But the CLX processor might.
Let's assume the CLX packs two 16-bit integers into a 32-bit memory space. Let's also assume that when the CLX does a memory access it pulls data 32 bits at a time on a logical 32-bit word boundry. Let's further assume that i want to perform a math function on two 16-bit integers and, just by dumb luck, the two integers we need are packed into a single 32-bit word. As far as i know the CLX processor would need to get the 32-bit value, mask off the top 16 bits and push it, relaod the original 32-bit value, mask off the bottom 16 bits, divide but 65536 or shift right 16 times, then perform the math operation. If the integer was actually just the lower 16 bits of a 32-bit integer the processor could perform math functions on the DWORDs directly.

Like I said, a bit esoteric but I'm the curious sort.

Keith

You could try an experiment to see if there is any difference.

Set up a simple program with some 16-bit math functions. Set up another program the same as the first except that the second one uses 32-bit integers. Then check the scan time difference between the two programs. If it handles 16-bit integers as you suspect, the scan time for the 16-bit integers should be longer than for 32-bit integers.

I only use INT or SINT data types when I need to interface with an external device that doesn't support DINT data.

The ControlLogix uses 32 bits for a SINT or INT or DINT type data element, so you do not save memory by using those data types for ordinary tags in the control program.

There is a performance penalty for math on SINT or INT tags, too; it takes just 28 bytes of memory to access a DINT during an ADD, for example, but 260 bytes to access an INT. The same math instruction will require 0.55 microseconds on a DINT, but 8.53 microseconds on an INT. Using an INT as an array pointer is also a lot slower than using a DINT for that purpose.

I got that info from an old ControlLogix System Design Recommendations powerpoint presentation, I think from AF2002.

The moral of the story ? Use DINT data types wherever you use integer values.

Thanks for the info, Ken. DINTs it is.

Keith

more stew for the pot

Ken's reply caught my interest so I did some experimenting with a program I'm currently working on. I have a subroutine that calculates a couple of position cam profiles in iterative fashion using an INT for the index and also using an INT variable plus a lot of REAL's. The following data is from a V.11 L1 - the working unit is a V.12 L61 which runs about 6 times faster.

initial scan time - 588 msec.
scan time after change index to DINT - 580 msec.
decreased memory usage with index as DINT - 2100 bytes
scan time after change INT var to DINT - 585 msec.
decreased memory usage with DINT var - 1100 bytes

Also of interest (?) the MCCP (365 points) takes 148 msec.

As for the 32-bit discussion - I am convinced that memory access in the CLX is byte-wise. To make a long story short, an output ramping down was shown in one instance to go 267, 11, 248... The output was generated in a periodic task and transferred to profibus in the continuous task using COP. Check the bit patterns of those numbers and it's obvious that the COP was interrupted on a byte boundary and transferred a stale low byte with a fresh high byte. CPS seems to have fixed this little problem.

Just a little update

I had some time to play at work today and decided to take Steve's advice and actually program a test.
I have a CLX 5555 processor and an ENBT in a rack. I started with a fresh project and am only using the default Main Routine the Logix5000 makes for you when it creates a project. I wanted to make sure I minimized the impact of anything other than the math functions on the scan time. In that routine I have 128 rungs; the following pair repeated 64 times:

ADD test_var_1 test_var_2 test_var_1
SUB test_var_1 test_var_2 test_var_1

Yes, I know that I really didn't need the SUB since I could just leave test_var_2 zero. But I was in a hurry and wasn't thinking clearly.

Anyway, I ran the test with test_var_1 and test_var_2 as data types INT, DINT and REAL. The average scan time for the routine for each was:

INT 1.2 milliseconds
DINT 200 microseconds
REAL 1.1 milliseconds

As Ken said DINT math is SIGNIFICANTLY faster than the INT math for basic math operations.

I also ran a few tests with the same operations but the operands being array elements. I used both INT and DINT indices. As expected the DINT[DINT] combination was the fastest with the INT[INT] combination the slowest. However, the difference wasn't as pronounced. The fastest was faster by a factor of 3 as opposed to the factor of 6 seen above.

Take it for what it's worth but I will personally never use an integer again unless absolutely necessary.

As for Gerry's note about the byte access, the fact that the system was a Profibus system caught my eye. Gerry, when you saw the strange data were you looking in the plc or were you looking in the Profibus slave? If you were looking in the slave it sounds to me like a Profibus data consistency problem. I had the same thing happen to me on a non-AB project until I set the GSD file in the slave to use full consistency.
Just a thought.

Keith

heading off on a tangent

Gerry, when you saw the strange data were you looking in the plc or were you looking in the Profibus slave? If you were looking in the slave it sounds to me like a Profibus data consistency problem. I had the same thing happen to me on a non-AB project until I set the GSD file in the slave to use full consistency.

Click to expand...

Well, this particular project is a team effort and I must confess near total ignorance of profibus (it was set up by another). We used a SST card to connect to a number of ABB ACS600 drives. A couple of the drives were intermittently tripping on over current which was traced to sudden setpoint changes (using the drives' built-in logging features). I did ask at one stage if there was any possibility of transferring a partially updated integer within the profibus components. All I got was blank stares and suggestions to add "belts and braces" to 'be sure to be sure' that the setpoint didn't swing wildly. So, that didn't work. When I got a chance to look closely at the log data, the byte problem stuck out prominently. I changed the COP's to CPS's, removed the superfluous limit checks and the trips have not recurred.

So, do I understand correctly that there is some config option in the profibus system to combat this sort of problem?

Tangents are the way of things...

Tangents are a good thing, Gerry. It takes force to keep things going in a circle. A tangent just happens and carries on forever. It's a beautiful thing.

It looks like in your case you were being interrupted in the middle of your data copy in the plc. If you weren't the CPS would not have helped. And I think you are also correct with the data access size. I think it's the processor that is designed for 32-bit math as opposed to the data bus.

Yes, there is such a thing as consistent data transfer with a Profibus device. I haven't seen it on stuff like digital I/O blocks. But I have seen it with drives. I'm not 100% sure it is a Profibus thing but since I had to change it in the drive's .GSD file I assume it is. I think the basic idea is the same as the CPS variant in CLX. However, I was wrong on the byte count. It looks like Profibus does a pretty good job on it's own of keeping up to two data words together (32 bytes). If you need keep more than two words together you might need to use consistent data transfers.

Keith

Dredging up past post...

We converted an exisiting CLX 1756-L63 program to use all DINTs. It is not a true statement that by doing this it will help your scan time. It actually increased ours by 1.2 ms.

Just thought that someone may find this interesting. By the way it is using version 12 firmware.

Darren

Darren-
That is very interesting. My test program was pretty simplistic so it may not be a good representation of real world performance. I was using just straight-up math instructions and was not intermixing data types.
For example, if you converted a program from all REALs to DINTs where you could but you could not convert all the REALs to DINTs, I could see where this would hurt you. Most CLX instructions will do automatic data type promotion, bringing the data type of every value in the instruction up to the data type of the highest data type in the instruction. So if you went from having all similar data types to mixing data types this is going to cost you. Also MOVs (the instruction) do the same thing where possible (if the data will fit in the data type being moved to). I think you can even pass dissimilar data types between a JSR and its associated SUB and the CLX will handle the type conversion (not sure about this one). But the data type conversions will take processor resources.

Does this seem reasonable in your case?
Keith

Actually we went from several different data types (INTs, SINTs, DINTs) to 100% DINTs.

I thought the result was interesting.

Darren-
That really is interesting. It seems to go against the published information from AB. I am definitely at a loss as to why this happened to you.
The only other thought that popped into my mind is if you are copying arrays alot. For example, if you had a 10 element array that you converted from SINT to DINT and you copied that array to another array, you are really transfering a greater number of bytes in that case (by a factor of 4). So in that particular case the performance would take a hit also.
I'm sure there are others. I'm just curious as to what they might be so I can steer around them. And, no, I don't want to calculate out my scan time instruction by instruction every time I write a program

Keith

Interesting thought... The CLx processor prefers 32 bit words, OK try this test, in setting up in the I/O configuration, a 16 bit input or output word say to a PV, the system assigns 32 bits to the darn thing anyway. Well here's the kicker, you may still use the higher order word for temporary bit use! The PV doesn't use them but the system does treat them like they exist!
And in answer to everyones question, when you declare a variable (tag) you have to select a data type. SINT is exactly what it says; an 8 bit word, hint look at the string type! INT a 16 bit word, and of course the good ol' DINT (32bit) which is in the native tounge of the CLx. Since the 32 bit word is it's native tounge then of course it will "react" faster.

Just some info..

Bitmore