The library guidelines say that pointers should not be passed as function block parameters. Fair enough, but, the OSCAT library offered in the codesys store uses this technique to implement function blocks that operate on arbitrarily sized arrays. Has OSCAT been granted some kind of special exception to the rule or is there some other technique that should be used? The only other solution I can see is to create separate function blocks for each possible array size, which is not at all practical.
Also I have seen on the PLCOpen website that future versions of the IEC-61131-3 standard do don't include pointer data types. They claim that pointers are no longer necessary but of course this is not true. While the REFERENCE data type is roughly equivalent it has a number of limitations with regard to arrays of reference, indirection, type conversion, etc.
I am currently developing libraries that depend heavily on these techniques so I am open to any input or advice you may be able to give with regard to alternatives.
Also, what will be the future disposition of the SUPER and THIS pointers?
What of legacy code? It will all have to be written just because of an arbitrary decision? Seems to be a very shortsighted decision.
I do understand that the problems with pointer arithmetic in that the assumed memory allocation may or may not be correct. For this reason I never use this technique. I also understand the possibility of pointers becoming invalid due to online changes and take care to implement the proper precautions.
Any insight to this situation and alternative solutions will be greatly appreciated. Thankls
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I had the same opinion until I tried this:
It could also make your program more portable between x86 and ARM processors. byte aligned memory vs 2 or 4 byte aligned memory.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2016-06-04
Originally created by: scott_cunningham
The guidelines are just that, guidelines. I 100% agree that no pointers should be used at the user level of machine code. But, this should not apply to the manufacturer's device library level. In many cases, pointers are the fastest, no matter how "evil" they are. Yes, a full PC is fast, but many times PLCopen is used on lower performance, embedded devices. If one is making a hardware unspecific library, then be very, very careful! The target could be Intel or Motorola byte order OR even worse, 16 or 32 or 64 bit based!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@yannickasselin1: Thanks for the tip. I've been looking for that (Array [*], LOWER_BOUND, UPPER_BOUND) for years. I suppose it doesn't with input and output parameters, I'll have to check. Thanks.
@scott_cunningham: Thanks for your input. I'm aware of the portability issues you and yannickasselin1 mention. Consequently, I only use pointers to pass or store object references and make it a point to never do pointer arithmetic. I also take care that stored pointers are refreshed when online changes occur. I learned long time ago that being extra clever isn't clever at all.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2016-06-20
Originally created by: scott_cunningham
@yannickasselin1: Which version of CoDeSys is this allowed in? My OEM tools use CoDeSys 3.5.6.30, which does not like ARRAY[*] and LOWER_BOUND and UPPER_BOUND are not found in the help.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The library guidelines say that pointers should not be passed as function block parameters. Fair enough, but, the OSCAT library offered in the codesys store uses this technique to implement function blocks that operate on arbitrarily sized arrays. Has OSCAT been granted some kind of special exception to the rule or is there some other technique that should be used? The only other solution I can see is to create separate function blocks for each possible array size, which is not at all practical.
Also I have seen on the PLCOpen website that future versions of the IEC-61131-3 standard do don't include pointer data types. They claim that pointers are no longer necessary but of course this is not true. While the REFERENCE data type is roughly equivalent it has a number of limitations with regard to arrays of reference, indirection, type conversion, etc.
I am currently developing libraries that depend heavily on these techniques so I am open to any input or advice you may be able to give with regard to alternatives.
Also, what will be the future disposition of the SUPER and THIS pointers?
What of legacy code? It will all have to be written just because of an arbitrary decision? Seems to be a very shortsighted decision.
I do understand that the problems with pointer arithmetic in that the assumed memory allocation may or may not be correct. For this reason I never use this technique. I also understand the possibility of pointers becoming invalid due to online changes and take care to implement the proper precautions.
Any insight to this situation and alternative solutions will be greatly appreciated. Thankls
I had the same opinion until I tried this:
It could also make your program more portable between x86 and ARM processors. byte aligned memory vs 2 or 4 byte aligned memory.
Originally created by: scott_cunningham
The guidelines are just that, guidelines. I 100% agree that no pointers should be used at the user level of machine code. But, this should not apply to the manufacturer's device library level. In many cases, pointers are the fastest, no matter how "evil" they are. Yes, a full PC is fast, but many times PLCopen is used on lower performance, embedded devices. If one is making a hardware unspecific library, then be very, very careful! The target could be Intel or Motorola byte order OR even worse, 16 or 32 or 64 bit based!
@yannickasselin1: Thanks for the tip. I've been looking for that (Array [*], LOWER_BOUND, UPPER_BOUND) for years. I suppose it doesn't with input and output parameters, I'll have to check. Thanks.
@scott_cunningham: Thanks for your input. I'm aware of the portability issues you and yannickasselin1 mention. Consequently, I only use pointers to pass or store object references and make it a point to never do pointer arithmetic. I also take care that stored pointers are refreshed when online changes occur. I learned long time ago that being extra clever isn't clever at all.
Originally created by: scott_cunningham
@yannickasselin1: Which version of CoDeSys is this allowed in? My OEM tools use CoDeSys 3.5.6.30, which does not like ARRAY[*] and LOWER_BOUND and UPPER_BOUND are not found in the help.
Not sure on which version this started to be supported.
I know that on TwinCAT 3, it is supported from 3.1.4020.
I would say 3.5 SP7 or SP8 on Codesys?
Maybe Edwin could tell?
Arrays with variable lengths are supported from SP8.
Hehe, Well that explains why I couldn't find it until now.