Different behavior of read_area on windows and linux. read_area throws ValueError about python-snap7 HOT 18 CLOSED

Hi OldFellow,
Thanks for reporting this issue.

The second issue is a separate issue, can you open a new issue for that?

from python-snap7.

It looks like a signed vs unsigned issue to me @spreeker , what do you think? It is quite weird though, I think read_area is one of the most used functions in python-snap7, so it should have shown up before?

from python-snap7.

try to work with the "db_read" function! does it also happen there?

I will add to the util.py file.

try:
    # try with the standard library
    from collections import OrderedDict
except ImportError:
    # fallback to Python 2.6-2.4 back-port
    from ordereddict import OrderedDict

from python-snap7.

Please keep the python2.6 discussion here #44

from python-snap7.

@oldfellow please teast the "db_read" and an older snap7 to rule out all options. snap7 1.3 came with some endian awareness..

Snap7 1.3.0 is out !!!
(Platform and comfort release)

Snap7 now is runtime endian-aware.
(Runtime = No compilers switches are needed to work with Big-Endian CPUs)

from python-snap7.

i've updated the package in the launchpad PPA (Ubuntu) and homebrew (OS X)

from python-snap7.

db_read has the same behavior like read_area.
Which snap7 should I give a try?

from python-snap7.

Any lower than 1.3 I find the whole issue really weird.

What kind of values are you trying to read? Are only some values wrong and
others good?
On Apr 1, 2015 8:12 AM, "oldfellow" [email protected] wrote:

db_read has the same behavior like read_area.
Which snap7 should I give a try?

—
Reply to this email directly or view it on GitHub
#42 (comment)
.

from python-snap7.

did the signature of the function change to unsigned or something since 1.3.0? I can't check this now, in conference

from python-snap7.

With snap7-1.2.1 I have exactly the same behavior.

I guess this must be related to the python wrapper. Using the same snap7.so ( from Version 1.3.0 or 1.2.1 ) with cpp or plain-c works fine.

from python-snap7.

this is the the content of the plc:
DB2:
Byte 0 - 3 Real: 12.34
Byte 4 - 5 WORD: 0xABCD
Byte 6 - 7 INT: 4537
Byte 8 - 9 WORD: 0xFF00

( I use this funtion to print the raw data in client.py line 109 )
print "".join("0x%02x " % b for b in data)

In Windows Environment the result of db_read and read_area is equal:
0x41 0x45 0x70 0xa4 0xab 0xcd 0x11 0xb9 0xff 0x00
On Linux the result look like this:
0x41 0x45 0x70 0x-5c 0x-55 0x-33 0x11 0x-47 0x-1 0x00

As you can see in the last WORD, the 0xff is "translated" into 0x-1.
I agree, that this seems to be a signed / unsigned error. But at what point?

from python-snap7.

When I add the following lines to client.py I can resolve this issue:

1. To client.py I add:
   import binascii
2. Before the return of the function db_read, I add the following:
   hex_data = binascii.hexlify( data )
   data = binascii.unhexlify( hex_data )
   return bytearray(data)

I don't really understand, why converting two times solves this issue.
Any idea?

from python-snap7.

it could be a bug in snap7, where the type of the byte is not defined as signed and the compiler functions differently on the two platforms.

from python-snap7.

ah right, it works correctly if you write a C program

from python-snap7.

@oldfellow Could you find out if and what the difference is of the data1 before and the data2 after the
hexilfy steps?

hex_data = binascii.hexlify( data1 )
data2 = binascii.unhexlify( hex_data )
return bytearray(data)

from python-snap7.

Could you try to replace the python2.6 ctypes extension with a newer version?
Googling python2.6 ctypes gives a lot of bug results.

from python-snap7.

Sorry, because I'm working in a blackbox environment I can't change any python evironment.
How can I find out a difference bevore and after the hexlify? What PyCode should I use?

from python-snap7.

hi @oldfellow this is quite an old issue now, sorry about that. Are you still experiencing these problems? Did you manage in the end?

from python-snap7.