Thanks! I was expecting the code to look something like that. I wasn't sure what to add to the pointer - I had seen a reference to the SIZEOF operator, but wasn't sure how to use it. This helps!
I wish I didn't have to use pointers - the PLC I'm converting the program from (S7-200) like other PLCs in it's class - has a nice easy to use BLKMOV-D command to initialize 150 16-bit registers as 75 32-bit registers.
It then uses the same command to move data from a bunch of source registers to a bunch of destination registers. And the registers are all battery backed, so I needed to use persistent retained variable in the CoDeSys PLC, which don't let you declare physical addresses, which are of course required by the SysMemMove instruction to do block moves blah,blah,blah...
I'll stop venting now . I know the CoDeSys PLCs can be very powerful, so I am surprised by some of the snags I keep walking into
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2016-02-10
Originally created by: scott_cunningham
Yes, persistent retain always creates trouble... Try to avoid defining a persistent retain within a FB - it causes the whole FB to be saved in the persistent retain memory section.
I have often defined my persistent vars and then in my FBs I define a local var that is a REFERENCE TO (BYTE or DINT, etc) and then I link the local var to the persistent. Maybe you could use the REFERENCE TO concept to reduce the number of data copies....
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'll check it out. I had heard from others that using any sort of global variable (persistent or otherwise) was something of a "no-no". So I wasn't sure how to build a function block that would work with persistent data. I will check out the REFERENCE TO suggestion. Thanks for the tip
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2016-02-11
Originally created by: scott_cunningham
Yes I know, globals are evil... I hear that too, but we are working with machines and last time I checked, there is only one drive for conveyor #1 and it's kind of a global... so I just avoid globals where it makes sense and then use one program to link local vars to fieldbus I/O (digital I/O, drives, etc) to have a write once solution. Good luck!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If I am executing a declaration and command like this to set a pointer to and address
tag1 AT %MD0: DWORD;
tag2 AT %MD2: DWORD;
PtrToPLCData := ADR(%MD0);
How would I then index the pointer to look at %MD2, then %MD4, etc??
I need to take a constant (300 in this case) and write it 75 different DWORD tags. I think I need to do this with a loop.
I tried to use the SysMemSet command, but it seems to write the data to every byte
Thanks!
Originally created by: scott_cunningham
Something like this if you must use pointers:
I manually typed this up, so may have typos... I am sure there are other ways.
Thanks! I was expecting the code to look something like that. I wasn't sure what to add to the pointer - I had seen a reference to the SIZEOF operator, but wasn't sure how to use it. This helps!
I wish I didn't have to use pointers - the PLC I'm converting the program from (S7-200) like other PLCs in it's class - has a nice easy to use BLKMOV-D command to initialize 150 16-bit registers as 75 32-bit registers.
It then uses the same command to move data from a bunch of source registers to a bunch of destination registers. And the registers are all battery backed, so I needed to use persistent retained variable in the CoDeSys PLC, which don't let you declare physical addresses, which are of course required by the SysMemMove instruction to do block moves blah,blah,blah...
I'll stop venting now . I know the CoDeSys PLCs can be very powerful, so I am surprised by some of the snags I keep walking into
Originally created by: scott_cunningham
Yes, persistent retain always creates trouble... Try to avoid defining a persistent retain within a FB - it causes the whole FB to be saved in the persistent retain memory section.
I have often defined my persistent vars and then in my FBs I define a local var that is a REFERENCE TO (BYTE or DINT, etc) and then I link the local var to the persistent. Maybe you could use the REFERENCE TO concept to reduce the number of data copies....
I'll check it out. I had heard from others that using any sort of global variable (persistent or otherwise) was something of a "no-no". So I wasn't sure how to build a function block that would work with persistent data. I will check out the REFERENCE TO suggestion. Thanks for the tip
Originally created by: scott_cunningham
Yes I know, globals are evil... I hear that too, but we are working with machines and last time I checked, there is only one drive for conveyor #1 and it's kind of a global... so I just avoid globals where it makes sense and then use one program to link local vars to fieldbus I/O (digital I/O, drives, etc) to have a write once solution. Good luck!