Tag Write falsely reports Success
cstrutton opened this issue · 7 comments
Preflight checks
Before you post an issue, ensure you have tried the minimal examples within the repo, or tried the pylogix-tester.
- [x ] Have you tried the examples?
- Have you tried pylogix-tester?
- [x ] Have you read previous issues?
Type of issue
- [x ] Bug
- Feature Request
- Question
- Other
Delete items that do not apply below.
Description of issue
I have a brand new machine that I am trying to read and write tags with. It has a 5069 Compact GaurdLogix 5380 running version 33.012
My code simply polls a bool tag every .2 seconds. When the tag goes High, I read a 2 strings (multiread) and make a good/bad judgment. In response, I set one of two Bool Tags True. If I log the status of the write it tells me Success but the value never changes in the PLC. If I read the tag value after writing and loop over until it reads what it should, it takes from 4 to 95 read-write cycles until it reads what it should.
The PLC only has one destructive UNLatch command but it doesn't happen until the tag goes high (which it never seems to do).
Expected behavior
I expect the tag to contain the written value if Success is reported, or an error if it fails.
Actual behavior
Code
with PLC() as comm:
comm.IPAddress = '192.168.1.3'
read = True
while read:
try:
result=comm.Read(CHECK_TAG)
if result.Value:
tags = comm.Read([CODE_TAG, LASER_JOB])
mark = tags[0].Value
job = tags[1].Value
status = check_barcode(mark, job)
attempt = 0
if status:
rewrite = True
while rewrite:
attempt += 1
result = comm.Write(GOOD_TAG, True)
result = comm.Read(GOOD_TAG)
if result.Value == True:
rewrite = False
else:
rewrite = True
while rewrite:
attempt += 1
result = comm.Write(BAD_TAG, True)
result = comm.Read(BAD_TAG)
if result.Value == True:
rewrite = False
waiting = True
print('Passes:', attempt)
while waiting:
waiting = comm.Read(CHECK_TAG).Value
time.sleep(.2)
else:
time.sleep(.2)
except KeyboardInterrupt:
print('exiting')
read = False
except Exception as e:
print('Unhandled Exception', e)
Screenshots
Stacktrace
Versions
Include versions to
- pylogix: 0.8.6
- python:3.8.10
- OS: Ubuntu 20.04
I have my money on the guardlogix not letting you write to the plc. Can you record the packets with Wireshark? can give us a better idea what's going on.
Guardlogix isn't in the supported plc's in the readme as well. @dmroeder has anyone actually used it before on this model? I know for sure these plc's have tons of safety features.
Can you please try this scenario in a non guardlogix plc?
Can you change this bool tag from say an ignition opc server?
GuardLogix isn't an issue. It is not pylogix that determines if the write was successful, the PLC returns that code, I pass it on to you. The fact that the PLC says it was successful and the value doesn't change suggests that there is something overwriting the value in the PLC. You can try to write to a BOOL that is used in am OTE, for example, the PLC will consider it successful, but the rung it is used on controls the value in the tag
Yeah I didn't even think about something overriding the value. I was thinking maybe OP already had that covered.
I did look for anything that might override the value. The tag is only referenced three times in the whole program. There is one UNLATCH further down the stepper but the sequence never gets there. One of the tags I am trying to write needs to go True before it does.
I will try to get Wireshark working next week when I get back to the shop.
I have about 25 units polling PLCs (Gaurdlogix included) without an issue. I rarely write to PLCs for obvious reasons so I haven't run into this before. Was hoping someone else might have seen this.
I suspect a firmware issue with the PLC but how do I get AllenBradley to help when I tell them I am writing to their PLC with your library? Might have to use some relays to talk to the PLC. Frustrating.
I think my next test will be to write to a completely new tag.
Highly doubt firmware issue unless the same scenario worked with previous firmware versions.
One obvious question, are these tags you're trying to write writeable? because there's one property to make them read only.
I would make a test with a tag that isn't referenced anywhere and I would also try to change it from an opc server, ignition edge is free 2hr runtime and easy to setup opcua, then use opcua matrikon or alike to change it.
I don't think that wireshark is really going to help at all because I don't think anything is going wrong. You write to the PLC, it says, yeah, that was successful.
I also think it is very unlikely that this is a firmware issue. Possible, but not probable. More than likely, exactly what is supposed to happen is actually happening. Maybe there is some sort of scan/race condition in your program that is not obvious. Maybe there are two of the same tag by accident, one being controller scope, one being program scope, so the one being written to is not the one you are using in logic. Or the tag is aliased to another tag. There is almost certainly something logical to explain this.
I think you are on the right track, create a new tag to write to, have no logic controlling it, I think you'll find that everything is working properly. When you create the tag, pay attention to scope and external access properties.
You would have a hard time convincing Rockwell to pay attention to something like this, especially some library unknown to them. You would have to come at them with some very clear evidence that their controller is at fault, I don't think you're there yet. You're blaming them a little too early.
I'm closing this. Reopen if there is evidence of an issue.