Beckhoff / ADS

Beckhoff protocol to communicate with TwinCAT devices.
MIT License
519 stars 197 forks source link

SymbolAccess for Bool #213

Closed simonschmeisser closed 1 year ago

simonschmeisser commented 1 year ago

If I use SymbolAccess to write a BOOL variable, the TwinCat Life view turns to "". 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.

I write by using symbols.Write("MAIN.boolVar", "1"); and read using (int)readBuffer.data()[0] (copy pasted from SymbolAccess)

tboegi commented 1 year ago

"1" is a string, isn't it ? Does this work:

symbols.Write("MAIN.boolVar", 1);

simonschmeisser commented 1 year ago

No, there is no such function signature ...

pbruenn commented 1 year ago

"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

simonschmeisser commented 1 year ago

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?

pbruenn commented 1 year ago

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