Any datatype on rockwell

[HVN]

If you take the build in function "FLL", the in/out put leg called "Destination" can accept the following data types:

• SINT
• INT
• DINT
• REAL
• structure

How do I create an AOI with a in/out leg with the same properties?

As far as I have understood, in/out works more like an address pointer, witch is also why they do not show in the TAG call.

I whould have liked to selete data types as "Any" or something like this.

 

[Olly]

I think you are going to have to get creative, or find a different solution to your original problem. To my knowledge, there is no equivalent in Rockwell PLC software of a "Variant" in VBA, which I think is what you are looking for.

The IN/Out parameters are created like tags and show up in the "Parameters and Local Tags" of the AOI, therefore must be assigned a data type. I don't think it is possible to create a variable of type = "Any".

If you must have a single AOI that handles all of those data types as IN/OUT parameters, I think you will have to create a different IN/OUT parameter for each data type you would like to handle and get creative with your logic about when you use each one. However, in my experience, you generally know which data type you are working with (what you are putting into and getting out of your AOI) but if you give a bit more context to your problem, that might help us to help you find a solution.

 

[HVN]

Thanks for your thoughts on the problem.

What annoys me is that Rockwells function blocks can do this, so the PLC is clearly able to handle it. The question is, am I as the user allowed to do the same somehow. Or is it just yet another stupid thing users aren't allowed to do when using Rockwell?

 

[cardosocea]

The IN/Out parameters are created like tags and show up in the "Parameters and Local Tags" of the AOI, therefore must be assigned a data type. I don't think it is possible to create a variable of type = "Any".

Not really... Rockwell has the ability to do it, but doesn't trust anyone else to. They even have a name for it. It's "Competitive Advantage.".

 

[tlf30]

Behind the scenes built-in instructions are handled completely different than user defined instructions. You will notice that built-in instructions like FLL do not require a UDT.

These are implemented as C functions in firmware, and the header files that expose the signatures can even be found in the Studio 5000 installation directory.

While there is 1 feature that I know of that only Rockwell allows their developers to use for PlantPax that we cannot, having variants is not it.
For PlantPax they have the ability to make a parameter with the flag CanBeNull, and there are two additional instructions which can check if a parameter is null or not. These are dangerous as accessing a null parameter with any other instruction will fault the controller. But you CAN actually use these. You just have to export the AOI and make the correct changes to the XML. The downside is that you will no longer be able to edit the AOI in Studio 5000 as you do not have a license to do so.

I have actually met someone outside of Rockwell with the required license to use this feature. I've also asked the firmware product manager at Rockwell if this feature could be improved and opened up to the pro license for studio 5000. They were going to look into it. (Better than them saying no)

 

[cardosocea]

For PlantPax they have the ability to make a parameter with the flag CanBeNull, and there are two additional instructions which can check if a parameter is null or not.

Used in PDose... but never noticed other instance where this is used in PlantPAX. Though I haven't used it extensively.

 

[HVN]

Thanks for the great inside tlf30.

I still however dislike the fact though. Just like the fact that all functions they provide doesn't work on all available languages. Like e.g. mentioned FLL that only works in LAD, or the move function MVMT that works on FB and STL but not LAD.

It's so infuriating.

 

[cardosocea]

It's so infuriating.

This isn't what's infuriating... the infuriating bit is really the people that defend them despite all of this ****.

 

[HVN]

This isn't what's infuriating... the infuriating bit is really the people that defend them despite all of this ****.

Can't argue