Bug in OpenXilEnv test library

[NikiWelik]

The RPC interface doesn't work reliable when using the OpenXilEnv test library. The writing of the signals does not always work.

The issue occurs only when the XIL was disconnected via the RPC interface and opened again. If it was not disconnected, the writing operations are working reliable when starting a new automation script.

@eb1234x do you have an idea what the problem could be here? If you want to reproduce the issue, you can execute this Python file: Samples/Automation/Python/OpenXilEnv/automationExample.py

[NikiWelik]

Update:
I investigated the issue a bit and I found out that the function __waitUntilApplicationIsReady causes it. It waits for 5 seconds after the XiL process was launched. I added this because sometimes it can take a while until the process was started with the GUI and the connection might not be successful.

But waiting a few seconds after starting the process shouldn't matter. When I start the XiL manually by launching the executable, there is also an elapsed time until I start my automation script. The script can connect with the XiL but the write operation does not work as I would expect.
I got the following output from my script:

Python has been successfully connected to XilEnv
Remaining cycles: 97
FireUp: 1.0
Remaining cycles: 0
FireUp: 1.0

However, the write operation works reliable in these cases:

• Waiting for 30 seconds up to 1 minute after a manual launch
• Waiting for 1 seconds in the function __waitUntilApplicationIsReady
• Disabling the RT factor switch (running faster than real time)

Then I receive the expected output:

Python has been successfully connected to XilEnv
Remaining cycles: 98
FireUp: 1.0
Remaining cycles: 98
FireUp: 0.0

@eb1234x maybe you can also try it out.

[eb1234x]

Maybe it would be better to implement a timeout logic to avoid a fixed delay.
Replace:

self.__waitUntilApplicationIsReady()
connectionStatus = self.__xilEnv.ConnectTo("")

With:

while (timeout):
    connectionStatus = self.__xilEnv.ConnectTo("")
    if ((connectionStatus == 0) or (timeout == 0)):
        break
    timeout = timeout - 1
    time.sleep(1)

And add the timeout as constructor Parameter with a default value:
def __init__(self, xilEnvPath, timeout=5):

[NikiWelik]

Unfortunately your solution leads to another problem:

It seems like the XiL is not ready to attach variables, because the process is started and the connection works immediately, so connectionStatus = 0. Everything is happening very fast.

When the script tries to attach variables, it will not work. self.__xilEnv.AttachVari(variableName) returns not a valid ID.

    def attachVariables(self, signalNames):
        for variableName in signalNames:
            variableId = self.__xilEnv.AttachVari(variableName)
            if variableId > 0:
                self.__attachedVar[variableName] = variableId
            else:
                print(f"Could not attach variable {variableName}")

Output:

Python has been successfully connected to XilEnv
Could not attach variable XilEnv.Version.Patch
Could not attach variable FireUp
Could not attach variable PlugIn

That means even if we are connected tho XiL, we have to wait for a specific time until the XiL is "really" ready. After the connection was successful I'm waiting for 1 second. And it seems like it also solved the initial write operation issue.
However, I have taken over the timeout solution from you because it makes the script more stable.

            while timeout:
                connectionStatus = self.__xilEnv.ConnectTo("")
                if connectionStatus == 0 or timeout == 0:
                    break
                timeout -= 1
                time.sleep(1)

            if connectionStatus == 0:
                print("Python has been successfully connected to XilEnv")
                self.__waitUntilApplicationIsReady()
                self.__attachDefaultXilEnvVariables()
                return

    def __waitUntilApplicationIsReady(self):
        time.sleep(1)

Output:

Python has been successfully connected to XilEnv
Remaining cycles: 98
FireUp: 1.0
Remaining cycles: 98
FireUp: 0.0

@eb1234x shall we investigate this issue more, or do you think it's OK now with these changes?