COP Sanity Check (solved)

[JeremyM]

Hi,

I'm just trying to clear data for any type of String.

The following results in only the first character being zeroed:

tSINT := 0;
COP(tSINT, tStr.DATA[0], 82);

This works:

SIZE(tStr.DATA, 0, Size);

i := 0;
while i < Size do
   tStr.DATA[i] := 0;
i := i + 1;
end_while;

Figured it out. COP stops at the end of source data.

 

[Contr_Conn]

COP checks boundaries of source and destination for simple data types. It dies not do it for members of structures.

But try FLL(string_tag, 0, 1)- ladder, not sure about ST

 

[JeremyM]

ST doesn’t implement FLL (unfortunately).

 

[Contr_Conn]

Create AOI in Ladder, call it in ST

 

[JeremyM]

Passing in varying types is the challenge.

Give me a pointer-to-void, Rockwell.

 

[Contr_Conn]

Find a way to do a job instead of finding a reason not to do it.
Tools are never perfect and you have to use what is available in your toolbox today.

 

[JeremyM]

This wasn’t a complaint-oriented thread, but we do pay through the nose for somewhat lackluster tools.

 

[Contr_Conn]

In reality, in most of cases you need only set .LEN=0; No need to fill the DATA fields.
STRING.LEN:=0;

 

[JeremyM]

Unless, of course, an HMI looks for a null rather than length-prefix.

 

[Contr_Conn]

It should not, this is not C++, HMI should look for the LEN field if they want to follow Logix rules, but I recall that old FTView did the same long time ago.
But even in this case, all you need to do is to place 0 into DATA[0]

 

[bernie_carlton]

My go to for zeroing any structure was to keep an appropriately named zeroed copy of the structure and COPying it in to the target.

 

[drbitboy]

my go to for zeroing any structure was to keep an appropriately named zeroed copy of the structure and copying it in to the target.

+1

 

[JeremyM]

It should not, this is not C++, HMI should look for the LEN field if they want to follow Logix rules, but I recall that old FTView did the same long time ago.
But even in this case, all you need to do is to place 0 into DATA[0]

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].

My go to for zeroing any structure was to keep an appropriately named zeroed copy of the structure and COPying it in to the target.

- 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?

 

[Contr_Conn]

FLL fills whole structure, if this is UDT or String or Array of UDTs.
I use FFL all the time.

If you are using 5580/5380 PLCs, then you can simply do this:
MyString:='';

Overall, I know you want ST code. But from my experience, Ladder gives you much more flexible instruction set that allows better functionality.
Over the last few years I was trying to convert existent Ladder AOIs into the ST and had to stop because of luck of functions. FFL is just one of these.

This clarifies my statement - use tools that you have in your toolbox today instead of struggling with limited tools.

 

[JeremyM]

ST or LAD doesn't necessarily matter on their own - it's just that the remainder of the code written in some of our modules are vastly better suited for ST.