iTNC 530 get_error_messages inconsistent?

[npalmerDNX]

Exercising get_error_messages on a iTNC 530 the logging/logic implies that getting to the "no next error" case is a negative and not a complete walk of the active error messages. This also seems like it is causing some unexpected behavior when run against the same machine when there are no errors.

getErrorMessages - Found an error message. Number: -2130706422, Text: 010 Machine guard is open !, Class: 3, Group: 3
2023-09-26 20:32:55 - LSV2 Client - INFO - edge1:3912516:client._send_recive - an error was received after the last transmission, Error Type: 1, Error Code: 57 'no next error available'
2023-09-26 20:32:55 - LSV2 Client - WARNING - edge1:3912516:client.get_error_messages - an error occurred while querying error information.

Case 2 log:
2023-09-26 20:32:56 - LSV2 Client - INFO - edge1:3912516:client._send_recive - an error was received after the last transmission, Error Type: 1, Error Code: 57 'no next error available'
2023-09-26 20:32:56 - LSV2 Client - WARNING - edge1:3912516:client.get_error_messages - an error occurred while querying error information.
.....
Skipping repeat logs
.....
2023-09-26 21:56:48 - LSV2 Client - WARNING - edge1:3912516:client.get_error_messages - an error occurred while querying error information. This does not work for all control types

Is the expected behavior for calling this method that we treat all "no next error available" errors as success message and if so, shouldn't the last_error be cleared instead of kept?

pyLSV2/pyLSV2/client.py

Line 187 in cfa4f46

if self._llcom.last_response is lc.RSP.T_ER:

[npalmerDNX]

I ran through some test logic to see what was happening. I noted that you are using 'is' based checks for the last_error but comparing that against a different class (

pyLSV2/pyLSV2/client.py

Line 1681 in cfa4f46

if self.last_error is lc.LSV2StatusCode.T_ER_NO_NEXT_ERROR:

):

'if self.last_error is lc.LSV2StatusCode.T_ER_NO_NEXT_ERROR:'

`>>> from pyLSV2.dat_cls import LSV2Error, LSV2StatusCode

tError = LSV2Error()
tError.e_type = 1
tError.e_code = LSV2StatusCode.T_ER_NO_NEXT_ERROR

str(tError)
'Error Type: 1, Error Code: 57'

tError is LSV2StatusCode.T_ER_NO_NEXT_ERROR
False

`
In this case, I believe the expectation is that the if statement would result in true, but I believe to achieve that you would need to do a check for self.last_error.e_code is ..... or add a comparator function to the LSV2Error class to perform this check for you. I notice that there's a large number of similar is based checks throughout the codebase which may warrant investigation to make sure they are behaving as expected.

[drunsinn]

Hello @npalmerDNX
thank you for the testing you did. To be honest, most of the testing I did was with a programming station and not a real machine. I expect that with the number of messages generated by a real machine the current design is insufficient.

Regarding your first post: I am not sure if I understand your question correctly. The check for RSP.T_ER is not related to the error messages you get via get_error_messages(). The former is used to check if a transmission or protocol error occurred during the communication phase. The later returns the messages the control displays on the screen for the machinist. As far as I know, protocol errors are never communicated via the control screen.

What you noticed in your second post is definitely correct! This most likely happened during the work from pre 1.0 to 1.0. Pre 1.0 the error I hope to finde some time during this or next week to fix this. Going forward I will investigate using some kind of type checker for python to identify similar problems.

As a side note: which python version are you using? Currently I am trying to keep pyLSV2 compatible with 3.6 but I would like to drop the support for deprecated versions if possible.

[npalmerDNX]

@drunsinn , we are using python 3.8.10 right now. The first part was probably a bit preliminary as I think it was just purely tied to log messages and behavior I drilled into more in the second post.

[npalmerDNX]

@drunsinn I was running the latest release and noticed that my calls to get_error_messages was still logging info errors whenever we finished reading the alarms (or if no alarms were found)
https://github.com/drunsinn/pyLSV2/blob/master/pyLSV2/client.py#L182
Looks like even though the message expects the T_ER_NO_NEXT_ERROR as a valid/positive result this still hits this block to trigger the info log. Would you consider changing the log level here to be conditional based of if it's this specific error result?

[drunsinn]

Sounds reasonable. Taking into account issue #55 a rework of the logging concept might be in order. Either by reducing most/all logging levels or by adding a debug mode that is more verbose.