News:

  • August 19, 2026, 10:30:28 AM

Login with username, password and session length

Author Topic: User Data Type definitions, Heap-Items and Data-Blocks  (Read 41700 times)

Mike Nash

  • Hero Member
  • *****
  • Posts: 652
Re: User Data Type definitions, Heap-Items and Data-Blocks
« Reply #15 on: October 26, 2017, 02:50:06 PM »
Two steps forward, one step back.

I seem to have misread my test results. COPY N2:D MyStruct.Word2 does not copy N3 into Mystruct.Word3.

So I am stuck with either a qty 2, COPY with 40 items (32 bits and 8 words) or I have to also have fields in the UDT that are DWORDS, for qty 2, COPY with 5 items as I previously thought. My bad.

I'll edit the previous post if I can to point this out.

Controls Guy

  • Internal Dev
  • Hero Member
  • ****
  • Posts: 3626
  • Darth Ladder
Re: User Data Type definitions, Heap-Items and Data-Blocks
« Reply #16 on: October 26, 2017, 03:14:09 PM »
Can we not MEMCOPY in and out of UDT instances to make it type/register-agnostic, just X bits or bytes from location A to location B and let me take care of the mapping?
I retract my earlier statement that half of all politicians are crooks.  Half of all politicians are NOT crooks.  There.

BobO

  • Host Moderator
  • Hero Member
  • *****
  • Posts: 6172
  • Yes Pinky, Do-more will control the world!
Re: User Data Type definitions, Heap-Items and Data-Blocks
« Reply #17 on: October 26, 2017, 03:38:21 PM »
Can we not MEMCOPY in and out of UDT instances to make it type/register-agnostic, just X bits or bytes from location A to location B and let me take care of the mapping?

Yes...and no. He needed half of his struct to be input and half output. There isn't currently a mechanism to do a partial struct or start anywhere but the beginning. The controller can do it now, but we need to do some work on DmD to generate the proper code.
"It has recently come to our attention that users spend 95% of their time using 5% of the available features. That might be relevant." -BobO

Controls Guy

  • Internal Dev
  • Hero Member
  • ****
  • Posts: 3626
  • Darth Ladder
Re: User Data Type definitions, Heap-Items and Data-Blocks
« Reply #18 on: October 26, 2017, 03:52:36 PM »
Ah, OK.  Thanks for the explanation.
I retract my earlier statement that half of all politicians are crooks.  Half of all politicians are NOT crooks.  There.

franji1

  • Bit Weenie
  • Host Moderator
  • Hero Member
  • *****
  • Posts: 3843
    • Host Engineering
Re: User Data Type definitions, Heap-Items and Data-Blocks
« Reply #19 on: October 26, 2017, 11:48:48 PM »
Two steps forward, one step back.

I seem to have misread my test results. COPY N2:D MyStruct.Word2 does not copy N3 into Mystruct.Word3.

So I am stuck with either a qty 2, COPY with 40 items (32 bits and 8 words) or I have to also have fields in the UDT that are DWORDS, for qty 2, COPY with 5 items as I previously thought. My bad.

I'll edit the previous post if I can to point this out.

You need to use a union structure member that occupies the same DWORD as .Word2 and .Word3, (say .Dword23), then use COPY N2:D to .Dword23

Mike Nash

  • Hero Member
  • *****
  • Posts: 652
Re: User Data Type definitions, Heap-Items and Data-Blocks
« Reply #20 on: October 27, 2017, 11:56:52 AM »
franji1,

That is what I was trying to say. I need to add the extra 10 DWORDs to my structure to allow fewer entries in the COPY instructions. The DWORDS simply point to the start of each 32 bit section (and overlap them). Unfortunately, this adds those 10 words to the available elements when I am trying to "build" the element in ladder or data view from the (whatever you call that selection list that opens as you start typing) thingy.

I am conflicted about trying to use the User Structures until they can be slightly more transparent, simply because going back and trying to understand what is happening later might be a chore. Obviously I am wanting to get to the point they function more like built-in structures and the hanging point is the need to move data in and out of the structure for the MRX and MWX or EIPMSG needs. Now if I could simply put structure elements as a pointer into those instructions and how many of what size elements (ignoring the 32 bit field issue by the instruction handling it for me) it would be simply wonderful.

I like it and it does work and it is a work in progress still, but it isn't quite graceful enough for my particular needs just yet. Also, I don't get to pick the form of the structure I need as that is defined by the device data being transferred and the manufacturer chose that already.

BobO

  • Host Moderator
  • Hero Member
  • *****
  • Posts: 6172
  • Yes Pinky, Do-more will control the world!
Re: User Data Type definitions, Heap-Items and Data-Blocks
« Reply #21 on: October 27, 2017, 02:22:27 PM »
They can't function any more like built-in structures than they do, because there is literally zero difference. Maybe this is semantics.

You can do everything you are wanting right now (MEMCOPY from array data to/from structure), except split a single structure into input and output sections. Maybe you could just use two different structures?

We will definitely look at what it takes to copy to/from a subset of structure, and we can also look at what it would take to make structures a source and destination for comm instructions.
"It has recently come to our attention that users spend 95% of their time using 5% of the available features. That might be relevant." -BobO

Mike Nash

  • Hero Member
  • *****
  • Posts: 652
Re: User Data Type definitions, Heap-Items and Data-Blocks
« Reply #22 on: October 27, 2017, 02:39:38 PM »
They can't function any more like built-in structures than they do, because there is literally zero difference. Maybe this is semantics.

Quite possibly. Terminology isn't my strong suit.

Quote
You can do everything you are wanting right now (MEMCOPY from array data to/from structure), except split a single structure into input and output sections. Maybe you could just use two different structures?

I considered it, and might again, but then there are those elements that ought to be included but would break the model again. For example, some type of value associated with the structure, but not part of either the in or out world, for a Modbus device, such as a status word, or bit. So now there are three structures, which is probably OK anyway, but feels kinda loose.  :-\

Quote
We will definitely look at what it takes to copy to/from a subset of structure, and we can also look at what it would take to make structures a source and destination for comm instructions.

Now these would really make me smile!  :)        Bigger! I mean smile bigger! ;D

Bolt

  • Hero Member
  • *****
  • Posts: 598
Re: User Data Type definitions, Heap-Items and Data-Blocks
« Reply #23 on: December 11, 2017, 03:19:08 PM »
I'm trying to use some User Data Types for some TCP communications.

I would like to have my structure somewhat as follows:

.Command - unsigned word
.Response - unsigned word
.ACKResp - unsigned word
.NAKResp - unsigned word
.Success - bit
.Fail - bit
.SuccDate1...9 - signed d words
.FailDate1...9 - signed d words


I can set it all up like I think it should work, but cannot use the .Command and .Response as strings for my STREAMOUT/IN.

Also, is there an easy way to block copy the .SuccDate1-8 to .SuccDate2-9 and then $Now to .SuccDate1

Am I missing something or are both of these the nature of the beast?



franji1

  • Bit Weenie
  • Host Moderator
  • Hero Member
  • *****
  • Posts: 3843
    • Host Engineering
Re: User Data Type definitions, Heap-Items and Data-Blocks
« Reply #24 on: December 11, 2017, 03:45:27 PM »
I can set it all up like I think it should work, but cannot use the .Command and .Response as strings for my STREAMOUT/IN.

It has to be from a data-block of a numeric type.  Sorry.  You will have to do a MOVE or COPY to/from the data-block element to the structure members.

Quote
Also, is there an easy way to block copy the .SuccDate1-8 to .SuccDate2-9 and then $Now to .SuccDate1

No.  But you can do it in the new COPY instruction pretty easily (see attached - I only did the first 3 and the last two, using DST22, the local time 1970 epoch value in a DST)

Bolt

  • Hero Member
  • *****
  • Posts: 598
Re: User Data Type definitions, Heap-Items and Data-Blocks
« Reply #25 on: December 12, 2017, 12:58:18 PM »
It has to be from a data-block of a numeric type.  Sorry.  You will have to do a MOVE or COPY to/from the data-block element to the structure members.

I have tried that, but it tells me they don't match, one is numeric, the other structure.  Is there a way to setup my .Command, etc as a string structure type?

franji1

  • Bit Weenie
  • Host Moderator
  • Hero Member
  • *****
  • Posts: 3843
    • Host Engineering
Re: User Data Type definitions, Heap-Items and Data-Blocks
« Reply #26 on: December 12, 2017, 05:16:42 PM »
At the bottom is the clip I stubbed out, but it's basically a PROGRAM code-block called DoTransaction that moves the .Command and .Response members into/out of an OutBuff and InBuff data blocks before it does the STREAMOUT and STREAMIN.

Look at the attachment for the .PDF of the Ladder Logic where the STREAMOUT and STREAMIN are done.  Note how in Rung #2 I move the structure's .Command WORD to OutBuff0:UW, then I use 2 BYTES of OutBuff0 in my STREAMOUT.  Similarly, in the corresponding STREAMIN instruction I use 2 BYTEs of InBuff0, then in rung #44 I move those 2 BYTEs of OutBuff0:UW to the structure's .Response WORD.  InBuff and OutBuff are both BYTE blocks, each 8 bytes long, and that is what I use in the STREAMIN and STREAMOUT instructions (since I can't use the structure members).

From $Main, just RUN DoTransaction, then look for DoTransaction.Done then check MyTCP.Success vs. MyTCP.Fail.

Code: [Select]
// Ver(103) PCU(4) Do-more Designer Clip   Source Project: C:\Do-more\Designer2_1\Projects\TCPProtoStruct1    Format: Do-more Designer 2.00+  DO-MORE Ladder
PLC BX-DM1E-18ED13


$PRGRM DoTransaction

SG DoTransaction.S0

RST MyTCP.Success
RST MyTCP.Fail
MOVE MyTCP.Command OutBuff0:W
OPENTCP @MyTCPClient -1062666239 12345 0x101 DoTransaction.S1 DoTransaction.S99

SG DoTransaction.S1

STREAMOUT @MyTCPClient 0x1 SS0 OutBuff0 2 0x100 0x101 DoTransaction.S2 DoTransaction.S99

SG DoTransaction.S2

STREAMIN @MyTCPClient 2 0x0 1000 0x1 SS0 InBuff0 2 D100 0x0 0x101 DoTransaction.S3 DoTransaction.S99

SG DoTransaction.S3

MOVE InBuff0:W MyTCP.Response
SET MyTCP.Success
EXIT

SG DoTransaction.S99

SET MyTCP.Fail
EXIT

$PGMEND DoTransaction

#BEGIN DEVICE
 @MyTCPClient, 32769, 8
#END

#BEGIN UDT_CONFIG
TCPProtoStruct
// Field Name, Data Type, Memory Layout, Read/Write, Display Format, Data View Detail
Command, UWORD, 0:0, Read-Write, Native, Short
Response, UWORD, 0:1, Read-Write, Native, Short
ACKResp, UWORD, 1:0, Read-Write, Native, Short
NAKResp, UWORD, 1:1, Read-Write, Native, Short
Success, BIT, 2:0, Read-Write, Native, Short
Fail, BIT, 2:1, Read-Write, Native, Short
#END

#BEGIN MEM_CONFIG
 InBuff UBYTE decimal 8
 OutBuff UBYTE decimal 8
 MyTCP TCPProtoStruct  0
 DoTransaction PROGRAM  0 -1
#END

Bolt

  • Hero Member
  • *****
  • Posts: 598
Re: User Data Type definitions, Heap-Items and Data-Blocks
« Reply #27 on: December 14, 2017, 03:21:28 PM »
Thank you, franji1.  I haven't had much time to play with that, but it seems like something I can make work with this newfound knowledge.  I can really clean up multiple programs that do similar stream out and in commands, while still maintaining some structure to all the element involved.  Thanks again for pointing me in the right direction.