The maybe in this case becomes more likely to (appear to) work because he's doing all this from the Vision Client, which means you have to factor client <-> gateway comms into the timing uncertainty.
Regardless, it's certainly not advisable.
2 Likes
Ah; I see. This is the root cause of his professed latency and the resultant need for an asynchronous call.
I see nothing in the code sample provided that is related to changing the position field.
That's because that textbox is bound to a tag that is not directly touched by this script -- when a move command is sent and exectued by the PLC, the motor controller itself will emit a different position value (once it moves). The point was that it was not allowing the text field to update with the correct value, as it was being attached to the active cursor which evidently has higher edit priority than the binding (which makes sense, I just didn't know why it was being selected).
Oh I am sure it works, but it is quite slow -- hence the original reason I needed to move all of this to an async function (something I will use more of in the future by default). I agree that the slow comms are why it works, and I will be improving the PLC interfacing in the future to ensure that it functions correctly even if we get a faster controller.
I see; the binding is not responding as expected to this unusual approach. You can always refresh a binding using system.db.refresh. Until you can develop a more efficient way to go about this, you can probably at least get the textfield to update by adding this to the end of your asynchronous function:
def updateTextfield():
component = # Put relative path to textfield here
propertyName = 'text'
system.db.refresh(component, propertyName)
system.util.invokeLater(updateTextfield)
Thank you, the force update code will be helpful. Hopefully I don't need it in this particular case once the gui traversal is fixed but I know I'll need it elsewhere.