comm.regex_position does not allow spaces after a ':' character

[FormerLurker]

I've been debugging an issue from a user that caused a lockup (due to signal wait) whenever Octolapse requests a position via M114. After some digging I discovered that the response for M114 from this printer (AlfaWise U20) was not being recognized by the comm.regex_position regex search because there are spaces after the colon. I have adjusted the regex to account for this:

regex_position = re.compile("X:\s*(?P<x>{float})\s*Y:\s*(?P<y>{float})\s*Z:\s*(?P<z>{float})\s*((E:\s*(?P<e>{float}))|(?P<es>(E\d+:{float}\s*)+))".format(float=regex_float_pattern))

Here is a sample of the position response from the printer:

ok X:150.0 Y:150.0 Z:  0.7 E:  0.0

I believe it's using a fixed width format for the parameters here, which is why the original regex doesn't work. I've tested this pattern, but there could be some situations I didn't take into account (though I can't think of any). Basically I just added a \s* after each colon, but NOT to the es named capture group because there is some stuff going on there that I don't understand.

I hope this helps!

[GitIssueBot]

Hi @FormerLurker,

It looks like there is some information missing from your bug report that will be needed in order to solve the problem. Read the Contribution Guidelines which will provide you with a template to fill out here so that your bug report is ready to be investigated (I promise I'll go away then too!).

If you did not intend to report a bug but wanted to request a feature or brain storm about some kind of development, please take special note of the title format to use as described in the Contribution Guidelines.

Please do not abuse the bug tracker as a support forum - that can be found at discourse.octoprint.org. Go there for any kind of issues with network connectivity, webcam functionality, printer detection or any other kind of such support requests or general questions.

Also make sure you are at the right place - this is the bug tracker of the official version of OctoPrint, not the Raspberry Pi image OctoPi nor any unbundled third party OctoPrint plugins or unofficial versions. Make sure too that you have read through the Frequently Asked Questions and searched the existing tickets for your problem - try multiple search terms please.

I'm marking this one now as needing some more information. Please understand that if you do not provide that information within the next two weeks (until 2018-10-23 17:50 UTC) I'll close this ticket so it doesn't clutter the bug tracker. This is nothing personal, so please just be considerate and help the maintainers solve this problem quickly by following the guidelines linked above. Remember, the less time the devs have to spend running after information on tickets, the more time they have to actually solve problems and add awesome new features. Thank you!

Best regards,
~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being, so don't expect any replies from me :) Your ticket is read by humans too, I'm just not one of them.

[DC43star]

Thanks again for the help!

[FormerLurker]

@foosel, let me know if you need any additional information when you are available. I don't want the bot to delete this issue, and I believe I've supplied everything necessary, but I could be wrong :)

[foosel]

@FormerLurker in this case all's fine. Just need to look into it a bit more closely, but on first glance it looks like allowing whitespace there should hopefully not break anything. Just really wish firmware vendors would stop doing their own thing all the time and divert from established defaults 🙄

[FormerLurker]

Tell me about it! We need to form a standards committee :)

FYI, I've bypassed the on_event Events.POSITION_UPDATE event and have been using the regex I posted (as well as some modified versions of the comm.py code) within the octoprint.comm.protocol.gcode.received hook to detect position responses myself, and haven't had any issues so far. I'll let you know immediately if I find any issues with the regex.

[foosel]

Adjusted by the above commit, already available on maintenance, soon devel and to be pushed out as part of 1.3.10.

I also took the opportunity to add a unit test for it referring to this ticket so I won't wonder down the road ;)

[FormerLurker]

Excellent, thank you! I'll remove my own position update and will go back to using Events.POSITION_UPDATE. Good idea regarding the unit test. If I see any other odd position responses, I'll let you know.

Closed!