feat: TO_<NUM> library functions
#1334
Conversation
volsa
changed the title
There was a problem hiding this comment.
Do we want to keep these generative scripts around? I think they've served their purpose and there is no need to track them via git/keep them in our sources.
There was a problem hiding this comment.
imo it doesn't hurt to track them in case anything changes in the future where we have to regenerate the ST files but I'm also fine with deleting them. Which one do you prefer?
There was a problem hiding this comment.
See comment in the other to_num.py file
libs/stdlib/iec61131-st/to_num.py
Outdated
| types = [ | ||
| "SINT", | ||
| "USINT", | ||
| "INT", | ||
| "UINT", | ||
| "DINT", | ||
| "UDINT", | ||
| "LINT", | ||
| "ULINT", | ||
| "LREAL", | ||
| "REAL", | ||
| ] |
There was a problem hiding this comment.
It seems like we are missing quite a few types here, i.e. TIME, LTIME, LWORD, (STRING?), etc. I've tried converting a TIME variable to USINT, which will just end up calling TO_USINT__USINT, silently truncating the input down to 8 bits, losing most of the information and returning wrong values.
Are these planned for a different commit?
There was a problem hiding this comment.
I'll have to check what CodeSys supports here, but BOOL(?), BYTE, WORD, DWORD and LWORD are (probably) missing here. I forgot about them somehow
volsa
changed the title
TO_<NUM> library functions
REAL and LREAL for bit / byte types seems to be wrong as of now. Maybe we need an external keyword here?
volsa
force-pushed
the
volsa/type-conversion-functions
branch
from
2988383
to
4082459
Compare
This PR introduces the
TO_<NUM>library function. Under the hood anyTO_<NUM>function makes use of the already existing and tested<NUM>_TO_<NUM>functions.Also, I've decided to isolate the
TO_<NUM>functions into a separate file instead of appending them tonum_conversion.st, to make discoverability and readability easier.