-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
iTNC 530 get_error_messages inconsistent? #52
Comments
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 ( Line 1681 in cfa4f46
'if self.last_error is lc.LSV2StatusCode.T_ER_NO_NEXT_ERROR:' `>>> from pyLSV2.dat_cls import LSV2Error, LSV2StatusCode
` |
Hello @npalmerDNX 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. |
@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. |
@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) |
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. |
this will suppress the false positiv while reviving a negativ response on querying for more error messages
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
The text was updated successfully, but these errors were encountered: