ControlLogix 5000: AOI Bitword Input?

I'm not a PLC programmer, so bear with me here ...

I was making an AOI with a bunch of BOOL inputs and realized some of them were actually Options, so I thought it would be better to pack them into a bitword called "Options" that was a UDT with each bit clearly labeled with its own name.

But then I tried to add this UDT to the AOI and it told me I couldn't do it because the type wasn't one of the system integral types (ie: BOOL, INT, DINT, etc.). Huh?

So ... does this mean I'd have to use an INT instead (with the system-assigned generic names ??) or would I have to use aliases somehow to make it clearer? Is that how I'd do this?

But a bunch of bool inputs can be converted to a DINT...

You can use User Defined tag in AOI as In/Out parameter that is defined by reference. This is similar to “pointer” in other languages.

Yeah ... I guess I'm just doing this because it's what I'd normally do elsewhere for "code tidiness"? To me, a bunch of related bit flags should be stored in a single data word, not as individual variables (or tags), but maybe I'm just being too anal.

So a UDT *can* be used ... as long as it is defined as an "In/Out" parameter? But if it's like a pointer, does that change the way I reference it in the PLC logic (syntax-wise), or is this handled implicitly by the PLC "compiler"?

Originally posted by Colt Hero:

So a UDT *can* be used ... as long as it is defined as an "In/Out" parameter? But if it's like a pointer, does that change the way I reference it in the PLC logic (syntax-wise), or is this handled implicitly by the PLC "compiler"?

Click to expand...

Aside from selecting the use as In/Out there are no syntax implications to this. You use the In/Out tag the same way you would any other tag. The Logix processors don't have any explicit "pointer" operations. That is all taken care of under the hood when it happens.

I know, I know. Some are going to get all excited and say "What about accessing arrays?". That really isn't a pointer access. It is a base+offset (or index) access.


Keith

kamenges said:

Aside from selecting the use as In/Out there are no syntax implications to this. You use the In/Out tag the same way you would any other tag. The Logix processors don't have any explicit "pointer" operations. That is all taken care of under the hood when it happens.

I know, I know. Some are going to get all excited and say "What about accessing arrays?". That really isn't a pointer access. It is a base+offset (or index) access.


Keith

Click to expand...

So the PLC "compiler" just knows to generate the proper instructions to reference by address instead of by value whenever it sees "In/Out" as the Parameter type?

But you cannot programmatically put an address into a variable in a PLC and then use it to reference something, correct? That's how you'd get into trouble without any "data protection" ... which these PLCs don't have, right?

But you can programmatically crash a PLC, though ... right ... simply by overrunning an array with a bad index value? Isn't that true? And does that mean every PLC program should always have an exception handler to gracefully recover from such things ... and then what exactly would that handler do?

Lots of questions with these things. Every now and then I have to touch one and it's such a strange universe for me.

The answers to your questions are platform specific. The plcs based on the Codesys runtime, for example, do have true pointer access. I think this is instruction specific but I'm not sure of that. I just know some instructions require what would be a true address pointer.
The Siemens plcs have a designator to indicate a pointer is being used but that is again instruction specific. I don't think you can use pointers wherever you want to.
Having said that I will limit my responses to the Rockwell Logix platform of PLCs since I know just enough about those to be dangerous.

Originally posted by Colt Hero:

So the PLC "compiler" just knows to generate the proper instructions to reference by address instead of by value whenever it sees "In/Out" as the Parameter type?

Click to expand...

That is correct.

Originally posted by Colt Hero:

But you cannot programmatically put an address into a variable in a PLC and then use it to reference something, correct? That's how you'd get into trouble without any "data protection" ... which these PLCs don't have, right?

Click to expand...

Correct in application. I'm not sure about the rationale, though. I think it is just as likely that you are dealing with a hardware platform and a software development environment that are in lock step with each other. This means that the development environment has intimate knowledge of the memory allocation and usage in the hardware. Specific instructions with predefined access can be provided to reach addresses that are not part of the normal user data area. This greatly decreases the amount of information a user needs to access in a more generic way.

Originally posted by Colt Hero:

But you can programmatically crash a PLC, though ... right ... simply by overrunning an array with a bad index value? Isn't that true? And does that mean every PLC program should always have an exception handler to gracefully recover from such things ... and then what exactly would that handler do?

Click to expand...

Yes, that is true. The Logix plcs will make a pre-pass through a program to make sure array indexes are not over their bounds and will not let the processor start if this is detected (immediate fault). After that, if an index is set past an array bound and is subsequently used in an array access instruction it will result in a fault. It is up to the user to make sure the index stays inside the array bounds. There is a SIZEOF instruction that can be used to make this a little more dynamic. But you can't dynamically allocate memory anyway so it just helps by making sure a decrease in array size offline doesn't cause issues after a download.


It may help to keep the historical target audience and applications of PLCs in mind. The target audience was historically not degreed software engineers. The target audience was plant electricians and manufacturing engineers. The target application was not large-scale data management and evaluation. It was mid-speed machine control. So "higher level" software development concepts were generally not required.
Also, hardware, runtime and development environment come from a single source. You don't have a user application compiled with a Borland compiler (I just aged myself) running in a Microsoft operating system on a Motorola microprocessor...today. The need for flexibility in accessing information when operating in multiple environments doesn't exist with classical plcs.
As the user and applications set continue to evolve things will continue to change. You can do stuff even in the Logix environment that you couldn't do 15 years ago in any "plc" environment. And then there are the Codesys platforms, which can do even more. So things are changing.

Keith