Closed simonschmeisser closed 1 year ago
"1" is a string, isn't it ? Does this work:
symbols.Write("MAIN.boolVar", 1);
No, there is no such function signature ...
"1" is a string, isn't it ? Does this work:
symbols.Write("MAIN.boolVar", 1);
Yeah, thats a bug because we handle uint8_t just like the other integer types but stringstream interprets it as ascii. I have a fix ready will release soon together with the string handling issue #194
Good catch! I switched to using AdsVariable
for those types but I wonder if there should not be more overloads like Write(string, bool)
to avoid the string conversion all together?
Is there actually a technical difference between those two APIs? Do they result in different data being send to the PLC?
Yes, there is a huge difference AdsVariable with handle is much safer! Accessing PLC variables "directly" by index group and offset is pretty dangerous, because you can silently corrupt the memory when the PLC did an online change for example. SymbolAccess was meant to demonstrate how access PLC variables in a generic way. A better version of SymbolAccess::Read/Write would generate a handle and use the handle when accessing the variable on the PLC.
However, the bug about ASCII instead of integer for BOOL values should be fixed with https://github.com/Beckhoff/ADS/commit/d7ada1228c68a7c4b2b86d357720ed8f6e76662c
If I use". If I read it then it will be sometimes values like 48 (false) or 49 (true) instead of 0 and 1 as I would expect.
SymbolAccess
to write aBOOL
variable, the TwinCat Life view turns to "I write by using
symbols.Write("MAIN.boolVar", "1");
and read using(int)readBuffer.data()[0]
(copy pasted fromSymbolAccess
)