Closed johanfforsberg closed 9 years ago
Hi, Johan; Thanks for the report.
How were you doing the REAL Tag writes and reads? If you use the cpppo.server.enip and cpppo.server.enip.client modules, it seems to work:
$ python -m cpppo.server.enip --print -v SCADA=REAL[100]
(in another window): $ python3 -m cpppo.server.enip.client -p 'SCADA[0]=(REAL)1.234' SCADA[0] SCADA[ 0-0 ] <= [1.234]: 'OK' SCADA[ 0-0 ] == [1.2339999675750732]: 'OK'
Since the value contains decimal points, the cpppo.server.enip.client will automatically deduce that it should write REAL values (otherwise, if all the values are integer, it will default to INT).
Can you tell me more details about the failure?
Thanks!
In that case it works fine, but try the same thing with a length 1 array, e.g.:
$ python -m cpppo.server.enip --print -v SCADA=REAL[1]
$ python3 -m cpppo.server.enip.client -p 'SCADA[0]=(REAL)1.234' SCADA[0] SCADA[ 0-0 ] <= [1.234]: 'OK' SCADA[ 0-0 ] == [1.0]: 'OK'
Confirmed; working on a fix now. I am treating "scalar" values different than "vectors" (because assignment to vectors can be intercepted with getitem/setitem, to support remote access in the PLC back-end). I incorrectly used the Python type of the default value to cast the incoming value -- and provided an integer default for REAL scalars. I'm re-engineering the handling of data types now, to ensure that it correctly handles current (SINT/INT/DINT/REAL) and future EtherNet/IP data types correctly. Should have a fix later today.
Great! BTW, is there a reason there is no BOOL type? It seems to be present in the EtherNet/IP standard. (A different issue, perhaps...)
There are a multitude of data types in the EtherNet/IP standard that are not (yet) supported. No particular reason -- just have not had a client use-case for them, yet.
Fixed in version 3.4.1
Writing a value to a REAL tag works, but reading it back returns the value rounded down to the nearest integer.