AB processors that support LINT?

[theColonel26]

I am updating some of my code that I give customers to put on their plant PLC to communicate with our PLCs.

I would like to use an LINT in my code but I am worried that some older processors and or firmware will not support it. I don't think I am concerned with any firmware older than v28, but what processors (both compact and control) support this type?

Is there a comprehensive list somewhere?

 

[Engineerj22]

I gotta ask, what are you using the LINT for?

 

[drbitboy]

Cf. https://www.reddit.com/r/PLC/comments/fac46e/just_venting_that_compactlogix_5370_on_v32/

See final comment by dmroeder.

This is not a complete answer to OP's query, but it's something; maybe @dmroeder can eloborate here.

Also note there is a difference between having LINT available to store (what? bits, I guess), and being able to do math on LINTs.

 

[baref00t25]

Unfortunately datatypes like LINT aren't always just based on firmware, it can be based on the processor itself. I have some code that uses the ULINT datatype that will not work in a 1769-L30ER that is firmware ver 33.00. The error message is below.

 

[theColonel26]

I gotta ask, what are you using the LINT for?

I am just using it at the bit level for bool flags.

so I can can say "tag > 0" for any, "tag < 1" for none, and or "tag = -9223372036854775807" for All

So I am not doing math but does that mean I can't do comparisons either?

Is this limitation only limited to the 5370 or is it true for the 5570 as well?


I supposed I could do a special AOI that reads a bool[64] and loops though it in one scan to create the same result, but then I am adding another dependency to their code.

 

[widelto]

see attached file

Hope this will help

 

[theColonel26]

Unfortunately datatypes like LINT aren't always just based on firmware, it can be based on the processor itself. I have some code that uses the ULINT datatype that will not work in a 1769-L30ER that is firmware ver 33.00. The error message is below.

Yes I am aware of the unsigned datetype problem I have had to alter a lot of my customer side code after I discovered that non sense.

 

[drbitboy]

So I am not doing math but does that mean I can't do comparisons either?

1756 rm003, November 2020 revision, on page 3:

Compare (CMP) on page 266: Added support for LINT, ... and ULINT data types.
​

So, by implication, before that such support did not exist.

 

[drbitboy]

Apparently there are AOIs on the R-A website to make DINT[2] tags act like LINTS. Ugly to be sure, but probably more portable.

 

[dmroeder]

I am just using it at the bit level for bool flags.

so I can can say "tag > 0" for any, "tag < 1" for none, and or "tag = -9223372036854775807" for All

So I am not doing math but does that mean I can't do comparisons either?

Is this limitation only limited to the 5370 or is it true for the 5570 as well?


I supposed I could do a special AOI that reads a bool[64] and loops though it in one scan to create the same result, but then I am adding another dependency to their code.

You can only use LINT at the bit level in 5380/5580 and v32 firmware. I think the implementation of LINT in the 5370/5570 was mainly to handle time stamps. You can't use them in very many instructions.

Edit: or you could use a Micro820, they'll happily let you access LINT's at the bit level. ULINT's too.

 

[JeremyM]

Arbitrary ******** limitations like this make me want to throw things at AB.

Unsigned support makes lots of other things - namely CIP interactions - a lot better than having to do something especially dumb, like fudge with a DINT to represent a UINT.

It's even dumber if you think for more than a second on 5370s being CIP-aware devices. Or maybe a bit dumber than that when you realize unsigned support of atomics dates back to, I suppose, the earliest assembly languages and adders?! So we know the internal hardware supports the types.

Subsets of the PowerFlex 525's 16-bit parameters are even unsigned! A 755 supports 32-bit fully. But hey, on a 5370 and earlier you've gotta fudge, fudge, fudge.

That said, we've basically eaten this and have written our code with unsigned types baked in. Yes - 5370 and earlier won't be supported, but 5380 and future platforms should maintain support. Code runs faster, more predictably, smaller, without the caveat.

You can make compact timer and/or pulse generator AOIs using LINT and a single GSV(WallClockTime, , CurrentValue, LINT), so it's certainly handy. Especially when AB ships 600KB processors in 2021.

 

[theColonel26]

You can only use LINT at the bit level in 5380/5580 and v32 firmware. I think the implementation of LINT in the 5370/5570 was mainly to handle time stamps. You can't use them in very many instructions.

Edit: or you could use a Micro820, they'll happily let you access LINT's at the bit level. ULINT's too.

Good to know.

Arbitrary ******** limitations like this make me want to throw things at AB.

Unsigned support makes lots of other things - namely CIP interactions - a lot better than having to do something especially dumb, like fudge with a DINT to represent a UINT.

It's even dumber if you think for more than a second on 5370s being CIP-aware devices. Or maybe a bit dumber than that when you realize unsigned support of atomics dates back to, I suppose, the earliest assembly languages and adders?! So we know the internal hardware supports the types.

Subsets of the PowerFlex 525's 16-bit parameters are even unsigned! A 755 supports 32-bit fully. But hey, on a 5370 and earlier you've gotta fudge, fudge, fudge.

That said, we've basically eaten this and have written our code with unsigned types baked in. Yes - 5370 and earlier won't be supported, but 5380 and future platforms should maintain support. Code runs faster, more predictably, smaller, without the caveat.

You can make compact timer and/or pulse generator AOIs using LINT and a single GSV(WallClockTime, , CurrentValue, LINT), so it's certainly handy. Especially when AB ships 600KB processors in 2021.

Along those same lines have you ever wondered why you can't view the status of an AOI instance if it is executed in a loop????? I am not talking the same instance being executed multiple times, I am talking about each iteration executing a different instances. Doesn't make any sense, they are different Tags, in memory.

NOW, if you execute the same AOI instance MULTIPLE times by Copy/Pasting it (hard coding repeats) then you can see the status of each execution....... it is mind boggling. WTF

But oh hey "Rockwell is great"!!!, says all the Plant Support guys, "We only use Allen Bradley here, it's the Best!". I want to them.

 

[JeremyM]

Not sure about your first part.

You ever accidentally put an infinite loop in a prescan routine? Try seeing if an unsuspecting engineer or programmer can figure that one out.

 

[Peter Nachtwey]

Unfortunately datatypes like LINT aren't always just based on firmware, it can be based on the processor itself. I have some code that uses the ULINT datatype that will not work in a 1769-L30ER that is firmware ver 33.00. The error message is below.

The ability to support ULINTS and LINTS is a matter of software.

An 8 bit CPU can support LINTS or ULINTS. It would be slow.