Working with URSim version 126.96.36.1996 (Sep 05):
During the course of debugging a script I want to confirm correct interaction with the xmlrpc server. To do this I have interspersed a series of popups between the server calls to indicate what variable values should be present after each call.
The problem is that the popups seem to be out of sync with the server calls. All of the latter are being executed and values returned while the first popup is still being displayed.
Is there any way to keep the popups in sync with the server calls and other code?
What kind of popups are you executing?
Do you have a snipped of example code that can elaborate what you are aiming to do?
What timing-frame are we looking for?
In the debugging code snippet below the objective is to:
- Make sure the vision system has been started.
- Pause URSim at each popup in order to observe the state of the vision system, the xmlrpc server log and/or the URSim variables.
As shown in the image below, the first popup is being displayed, but the variables field shows that we are at the “3rd blob should be loaded” state (3.0 in the 2nd to last field). All the calls to the xmlrpc server have already been made and the last target data is now in memory. There was no opportunity to observe the intermediate behavior.
In actual production operation, if the operator had seen that the vision system had not been started, there would have been no opportunity to correct the situation. Instead the robot would have tried to go ahead anyhow -with unpredictable results.
I’m not sure whether this answers your timing-frame question.
You could you try to add
blocking=True to the popup calls.
popup("Make sure WAY-2C is started", title="Message", warning=False, error=False, blocking=True)
I would imagine that this is your issue.
This parameter defines if the programm execution is suspended until the user clicks OK or not (the unlucky default).
@jbm why is this parameter not documented in the script manual an why does it default to False?
Thanks, that was indeed the problem.
I have reported the missing documentation of the
blocking=True to R&D.