COP Sanity Check (solved)

JeremyM said:

---- In that vein, one curious thing is that with some UDTs and when they could be passed by reference into a Rockwell-defined AOI, a simple value of 0 can be substituted if you don't reference an instance of the type.
---- In the picture, Bus[1] is actually optional and 0 can be substituted.
---- How can we pull off the same thing with our own AOIs?

Click to expand...

Would anyone else like to join me in exploring this?

Where's your sense of adventure?

JeremyM said:

Where's your sense of adventure?

Click to expand...

it’s Friday night, take a break…
Seriously, I am not sure that I understood your question, not familiar with this specific AOI, and have no time to figure this out now.

No worries, Contr_Conn, it’s an open discussion anyone can pile on.

When you refer to Bus in this PlanPAx instruction, can you show an example substituting Bus[1] with 0? Even better if you post your file?

I opened version 5.0.02 and it looks like required In/Out parameter that must have a tag of the correct data type.

Contr_Conn, I've attached a link to the .ACD in question. It's a Rockwell sample project.

https://www.dropbox.com/s/65attblvlz7n0xf/PlantPAx_R5_00_Demo.ACD?dl=0

- You can find the AOI call under the A1100_Storage_EM program's 'Dispatch' FBD subroutine.
- If it needs conversion to ladder, let me know.

I've also attached another screenshot showing the call with a '0' substitution. This compiles without issue.

- I've attempted to create another AOI accepting the same UDT in, as far as I can tell, the same way as the raP_Opr_EMGen, but it will not accept a '0' substitution in the same way without compilation error.
- From that, I think I've narrowed this down to something about the original AOI that permits this to happen.
- I'm wondering if they've done some overlay work (or something) to a Local instance of that UDT that the In/Out parameter is ultimately mapped to.

The AOI in your project is ver 5.0.00
If you try to import 5.0.02 and open collision details for Bus parameter, then you will see “Can be Null” set to Yes in older version but not in v5.0.02 where it left blank
This is only that I see, don’t know any details.

JeremyM said:

That's actually a fair point.

I've found in a few instances where the String type is used as a buffer space for comms, particularly ModbusTCP and Message paths.

My overall goal would be to prevent any mishap in those instances when simply zeroing .LEN and .DATA[0].

- The issue eventually faced is tracking down mismatched zero-structures when the original changes. With UDTs, not such a big deal, but Strings are evil in this regard.

-- I've almost scratched an itch lately to simply create a one-size String type from an AOI that has a variable length and fixed backing capacity of perhaps 256 bytes and bundles all the code operations you would typically perform upon it.
-- You could even use aliasing techniques to assign the contents to a Logix String type when needed.

--- How does FLL work, anyway?
--- How is it able to ascertain the number of bytes in which to populate zeros into any structure thrown at it, for example?
--- It appears to also generally accept any blob of bytes thrown at it - is there a way to pass-by-generic-reference (pointer-to-void) that I've missed all this time? Or cast the passed object as something else entirely?

---- In that vein, one curious thing is that with some UDTs and when they could be passed by reference into a Rockwell-defined AOI, a simple value of 0 can be substituted if you don't reference an instance of the type.
---- In the picture, Bus[1] is actually optional and 0 can be substituted.
---- How can we pull off the same thing with our own AOIs?
Answer: OEM license / RA Library builder feature only at this time.

Click to expand...

The underlying FLL operation would be my biggest remaining question. Is there way in Logix to interrogate the size of UDTs?

Is there way in Logix to interrogate the size of UDTs?

Click to expand...

I am not aware of any way to check UDT size.

SIZE works on Arrays only and it does not work on BOOL Arrays or UDTs.

FFL does its magic, it will fill any container you referenced, but this container is hardcoded, can't be dynamic.

Sure, absolutely. But FLL has to know a stopping point of a container thrown its way.

Probably a non-starter, but I suppose I could try hacking it by making an overlay of array of DINT in the UDT definition itself?

UDTs and Strings are aligned on 32-bit boundaries, after all (try making a String of .DATA sized for anything but a multiple of 4).

Here is my guess:
The size of UDT is a constant, UDTs created offline, so FLL will know the the size in Bytes or DINTs at the time of compile.
FLL with size of 1 will fill the whole UDT structure.