Studio 5000, DINT vs INT for HMI controls.

[AutomationTechBrian]

Just something I think about when choosing data types in Studio 5000. It seems logical, but I've never looked deeply into the question.

When creating tags in Studio 5000, the default is DINT. It's very tempting to just accept that choice whenever the value is appropriate. But, when I'm working with the HMI controls, I think about bandwidth (Ethernet IP), and it seems logical not to use a DINT if an INT is acceptable. Before I log that into my brain as a "rule", any thoughts on the topic?

 

[cardosocea]

PLCs (and processors in general) do some quirky things when it comes to memory that aren't quite expected or normal.



Try creating an array of 32 BOOLs and check if it's 32 bits, for example. I reckon this will be very similar.

 

[AutomationTechBrian]

That's why I even bother to bring it up. It 'seems' logical, but that's without knowing the underlying properties.

The question is basically, "if an HMI is reading and writing to 100 INTs, is it faster than if it were 100 DINTs?" I usually use one of the two Ethernet ports on the PLC for direct connection to the HMI (Ignition Edge on a PC, in this case), and the other port for remote IO, VFDs, etc. There is a separate safety processor, and DLR for the safety components.

I don't think this is a critical piece of info. The bandwidth these days is pretty huge. But I'm curious if the extra effort changing the DINT default to INT is warranted.

 

[plvlce]

Non-array INT and DINT tags reserve the same amount of memory in Studio 5000 -- 4 bytes.

Does the HMI pull just the actually used memory, or the entire space reserved for the tag? If the latter, there is no benefit to going smaller than a DINT on an individual tag.

This changes when using arrays and UDTs though.

cf Logix 5000 Controllers Design Considerations, Chapter 8

 

[rupej]

Just to keep things more consistent, I always use DINTs even when an INT would do, unless I'm messaging a Logix 500 controller or something like that. Consistency is probably worth more than any possible bandwidth savings IMO.

 

[AutomationTechBrian]

Non-array INT and DINT tags reserve the same amount of memory in Studio 5000 -- 4 bytes.

Does the HMI pull just the actually used memory, or the entire space reserved for the tag? If the latter, there is no benefit to going smaller than a DINT on an individual tag.

This changes when using arrays and UDTs though.

cf Logix 5000 Controllers Design Considerations, Chapter 8

Nice reply. Picked up a few things to think about.

 

[JeremyM]

The same code used on an INT will consume more memory than a DINT would in Logix.

 

[kamenges]

Originally posted by JeremyM:

The same code used on an INT will consume more memory than a DINT would in Logix.

Flesh that out, JeremyM. I suspect you know what that is. Inquiring minds and all.

Keith

 

[JeremyM]

Flesh that out, JeremyM. I suspect you know what that is. Inquiring minds and all.

Keith

On any 5x80...

Creating a:
- DINT, INT, SINT, or LINT costs 88 blocks.

Assigning any number to:
- DINT costs 36 blocks.
- INT costs 88 blocks.
- SINT costs 88 blocks.
- LINT costs 36 blocks.

 

[ASF]

There's also a penalty for scan time in your PLC using INTs I believe. Because Logix processors are 32 bit processors, if you force them to do math on two 16-bit integers, they convert them to 32-bit integers, perform the math, and then convert them back. That's probably oversimplifying it, but that's my general understanding.

If you only use INTs for data transfer blocks you could potentially minimise this, but worth remembering.

 

[AutomationTechBrian]

Ok, then... DINTs it is! I did not expect that.

 

[TheWaterboy]

If you are MSGing to older procs like SLC and PLC5 with 16 bit registers or storing modbus data, you have to use the INT, but otherwise DINT is the way

 

[cardosocea]

If you are MSGing to older procs like SLC and PLC5 with 16 bit registers or storing modbus data, you have to use the INT, but otherwise DINT is the way

So much this!!! I inherited quite a few applications in my old job where the developer didn't understood data sizes and was wasting a fair bit to line up 32 bits to 16.