-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reading PLC memory via memory address returns different values than reading via data path #48
Comments
Oh, that seems to be a bug that was introduced with #40. I will look into it and get back to you. |
Can you please check if there are any warnings or errors in the log? |
I'm not getting any warnings or errors. The output for addresses 356, 364, 368 and 360 doesn't change, it's always [4210752250] when reading via |
Ok, this seems to be more of a problem with the documentation than with th e code. To get the same results with Example:
|
WHEN im trying this print("## double word: {}".format(con.read_plc_memory(8016, MemoryType.DWORD, 50))), return only 0 values i dont know why,this is the value in the cnc +66977274 |
I am seeing this same problem just with WORD as well, both calls worked and returned the same non-zero value in 0.7.7 but the latest versions are hitting this.
|
@npalmerDNX In earlier versions of pyLSV2 the calculation of the correct memory address of the read_plc_memory function was wrong which lead to an offset. This meant that bigger chunks of memory returned broken values. |
This is very strange. If you look at Line 112 in dc06e43
range(0, 500) for all three tests still does not fail.
I think you also have a bit of a problem in your code. The modulo comparison basically skips every second element which results in an offset. Take a look at this and its output:
As I see it, by multiplying the address for the data path with two I get the same result as with 'read_plc_memory'. The approach of skipping every other address gives an offset. |
I ran your test script and I see that the values of PLC and DP2 are the same, but they are not the representation of what the W# is. Address 0: PLC 0 - DP*1 0 - DP*2 0
Address 1: PLC 0 - DP*1 skipp - DP*2 0
Address 2: PLC 0 - DP*1 0 - DP*2 0
Address 3: PLC 0 - DP*1 skipp - DP*2 0
Address 4: PLC 0 - DP*1 0 - DP*2 0
Address 5: PLC 0 - DP*1 skipp - DP*2 0
Address 6: PLC -21487 - DP*1 0 - DP*2 -21487
Address 7: PLC 25901 - DP*1 skipp - DP*2 25901
Address 8: PLC 0 - DP*1 0 - DP*2 0
Address 9: PLC 0 - DP*1 skipp - DP*2 0
Address 10: PLC 0 - DP*1 0 - DP*2 0
Address 11: PLC 0 - DP*1 skipp - DP*2 0
Address 12: PLC 0 - DP*1 -21487 - DP*2 0
Address 13: PLC 0 - DP*1 skipp - DP*2 0
Address 14: PLC 0 - DP*1 25901 - DP*2 0
Address 15: PLC 0 - DP*1 skipp - DP*2 0
Address 16: PLC 2 - DP*1 0 - DP*2 2
Address 17: PLC 0 - DP*1 skipp - DP*2 0
Address 18: PLC 0 - DP*1 0 - DP*2 0
Address 19: PLC 10 - DP*1 skipp - DP*2 10
Address 20: PLC 10 - DP*1 0 - DP*2 10
Address 21: PLC 0 - DP*1 skipp - DP*2 0
Address 22: PLC 0 - DP*1 0 - DP*2 0
Address 23: PLC 32767 - DP*1 skipp - DP*2 32767
Address 24: PLC 0 - DP*1 0 - DP*2 0
Address 25: PLC 0 - DP*1 skipp - DP*2 0
Address 26: PLC 0 - DP*1 0 - DP*2 0
Address 27: PLC 0 - DP*1 skipp - DP*2 0
Address 28: PLC 0 - DP*1 0 - DP*2 0
Address 29: PLC 0 - DP*1 skipp - DP*2 0
Address 30: PLC 0 - DP*1 0 - DP*2 0
Address 31: PLC 0 - DP*1 skipp - DP*2 0
Address 32: PLC 0 - DP*1 2 - DP*2 0
Address 33: PLC 0 - DP*1 skipp - DP*2 0
Address 34: PLC 0 - DP*1 0 - DP*2 0
Address 35: PLC 0 - DP*1 skipp - DP*2 0
Address 36: PLC 0 - DP*1 0 - DP*2 0
Address 37: PLC 0 - DP*1 skipp - DP*2 0
Address 38: PLC 0 - DP*1 10 - DP*2 0
Address 39: PLC 0 - DP*1 skipp - DP*2 0
Address 40: PLC 0 - DP*1 10 - DP*2 0
Address 41: PLC 0 - DP*1 skipp - DP*2 0 |
I still quite follow your reasoning. According to the memory tables on the control the address values are correct. If you check the screenshot I posted here, word 11 is the same as via the library as on the control. If you are not happy with the current state you are more than welcome to create pull request for a new function that use another addressing scheme. Please note that since the current implementation works as far as I can see, and some other application might already use it the way it is now, I don't want to break compatibility. |
I interpreted the blue column numbers a bit differently. Since I have no manual I assume that these numbers count the number of bytes from the start of memory. The increments change when switching between byte, word and double from 1 to 2 to 4 but the line numbers only change when switching from byte to word or double. This lead me to believe that they count the number of bytes instead of the address of the memory value. |
Reading PLC memory via memory address like
con.read_plc_memory(356, pyLSV2.MemoryType.DWORD, 1)
returns the following:
when accessing the same addresses via data path at the same time it returns the following:
con.read_data_path("/PLC/memory/D/356")
I'm not sure if I've missed anything, but up to pyLSV2 version 0.7.7 the values were the same.
I've discovered this on an iTNC530 / 606420 04 SP20. Help would be much appreciated.
The text was updated successfully, but these errors were encountered: