Hi there, developer of OctoPrint here. I had a user report that they are seeing replies to the M114 command (to retrieve the print head position) like this:
I cannot confirm this myself since I do not own a K8200, but I had another user who owns one check and they confirmed the behaviour as well on both firmware version v1 and v2.
The output to M114 is actually supposed to look like this, with spaces between the coordinate segments:
Changes like this cause enormous compatibility issues with host software (like OctoPrint) that depend on firmware sticking to the agreed upon standard. In this case, position reporting via feedback controls and also for pause resuming in the upcoming OctoPrint version will not work with K8200 printers, unless the users fix the firmware themselves.
Is this an accidental change that can be fixed or are there particular pressing reasons for this incompatible output format change?
As an update to that, after digging a bit further it looks like you based your firmware versions off of some old-ish Marlin variant that in fact did skip the whitespace between the coordinates (or at least that’s the guess after having heard from another such a case with a non-K8200 firmware). So the question now is no longer “why did you do this” but rather “is there a chance you would fix this”.
Considering that the issue appears to be wider spread than originally anticipated though (who knows how many private forks with that wrong output exist), I guess I’ll just add yet another compatibility workaround in OctoPrint.
Consider this problem solved then. Admittedly in a somewhat unsatisfactory way for a host maintainer, but that’s not your fault but a more general issue with the 3d printer firmware landscape.
Thank you for your incredible work creating OctoPrint. It is a great resource for the RepRap community.
Unfortunately, there are many people who have built this printer, so even if a new firmware version was provided that fixed this problem on the K8200, it would still present a burden to the users to incorporate the fix into their firmware versions and re-flash their controllers. You would also have to field a lot of inquiries about why this doesn’t work and how to find and apply the printer firmware patch.
The G-Code spec page that you linked doesn’t appear to specify whether the whitespace is required. In fact, near the top of that same page I found the following statement:
So this would indicate that any spaces (or tabs) in the G-Code stream are optional.
It is always a good idea when parsing human-readable formats to be very flexible about ignoring whitespace. No whitespace, or extra whitespace, should be expected and handled for the best interoperability with all systems. This will reduce headaches for your users and for you.
I should mention that I am a happy K8200 owner, but I do not work for Velleman. In the interest of eliminating potential problems at every point, I will take a look at the Velleman firmware to see if there is an easy fix for this. But even if such a fix can be provided, I would still expect that many printers out in the wild will continue to exhibit this behavior for a long time.
I hope this perspective is useful to you. Again, thank you for your wonderful contributions to the community.
First let me say that you have developed an incredible software package.
I have been using Octoprint on my K8200 and a Raspberry Pi for over a year now.
As far as I can see there have been no issues with it.
I also have a webcam attached to keep an eye on the printer.
This has save me from a lot of clean up when the print fails.
I can pause the print to change colors and then resume with out any problem.
I think the version I have is 14.0 or something like that.
If you would like me to test anything please let me know.