Reporting that M114 not supported by firmware when it is.

[e3donline]

If this is a feature request describe it here

_REPLACE_THISFEATURE_REQUEST_DESCRIPTION_GOES_HERE

Version of Octolapse

Octolapse Version: 0.4.0

Version of OctoPrint

OctoPrint Version: 1.4.2

When you ran into the problem, did you have diagnostic logging enabled?

Diagnostic Logging was Enabled: YES

What were you doing when the problem occurred

1. pushed the print button.

What should have happened?

Start printing

What happened instead?

Paused, then reported an error saying the firmware did not support the M114 command.

Operating System running OctoPrint and Octolapse

OS Name: OctoPi Os Version: 1.4.2

Printer model & used firmware incl. version

Printer Model: E3D ToolChanger Printer Firmware Version: RRF 3.1.1

Browser and version of browser, operating system running browser

Browser: _REPLACE_THISBROWSER_VERSION_GOES_HERE Browser OS: _REPLACE_THISBROWSER_OS_GOES_HERE

Link to the gcode file you were printing when the problem occurred

Link to Gcode File: _REPLACE_THISGCODE_FILE_LINK_GOES_HERE

Link to settings.json

Link to settings.json with all passwords removed: _REPLACE_THISSETTINGS_JSON_LINK_GOES_HERE

Link to plugin_octolapse.log

Link to plugin_octolapse.log: https://pastebin.com/11eXQh0a

Link to octoprint.log

Link to octoprint.log: https://pastebin.com/GPgR1aGn

Link to contents of Javascript console in the browser

Link to javascript console output: _REPLACE_THISLINK_GOES_HERE

Screenshots and/or videos of the problem:

Screenshot/Video Links: _REPLACE_THISLINKs_GO_HERE

Please consider becoming a patron

If you like this project, please support my work by becoming a patron, and consider adding a 'star' to the repository. It takes a lot of time and effort to maintain the project and respond to issues. The cost of test prints, software, cameras, printer parts, etc. can quickly add up, so every bit helps.

You can find various videos and tutorials by subscribing to my Youtube channel. You can also follow me on Twitter.

[FormerLurker]

Can you send an M114 via the OctoPrint terminal and paste in the response from your printer?

[e3donline]

Send: M114 Recv: X:272.500 Y:140.000 Z:15.000 C:4.600 E:0.000 E0:0.0 Count 66000 21200 24000 7360 Machine 272.500 140.000 15.000 4.600 Bed comp 0.000 Recv: ok

[FormerLurker]

The printer's response is quite unusual, and the matching regex doesn't properly detect this as a valid M114 response. It could be adjusted, but I've never seen anything quite like it before. I doubt Octoprint can parse this return either. There are two values for E returned (which is correct?). What is C? Any info about the response would be appreciated.

I'll see if I can adjust the regex, but I suspect this unusual response from the printer will cause trouble for many more plugins than Octolapse.

[FormerLurker]

FYI, here is the regex pattern Octolapse uses to detect an M114 response:

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*)+))

where {float} = [-+]?[0-9]*\.?[0-9]+

Obviously this could be adjusted to accommodate the m114 response you provided. It is nearly identical to the one OctoPrint uses:

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+:\s*{float}\s*)+))

Both fail to parse this response.

If you have control over M114, I could make some recommendations that would improve compatibility with existing plugins. Let me know.

[e3donline]

I'm not sure what the extra E is for, the C is another axis on the machine.

I just want to trigger a photo at a certain point in my script. I had hoped to be able to do that with Octolapse. I'm not certain why it needs position information to trigger a photo? Can that function be disable or worked around?

This is on a duet 3 electronics and RRF3 firmware.

Thank you for your time in assisting me.

[FormerLurker]

It needs to be able to detect that motion is complete before taking a snapshot. It does this by sending an M400 + M114, and waiting for the M114 response. If neither octoprint nor Octolapse can tell that a response from M114 is delivered, it doesn't know that the stabilization motion is complete. As an added safeguard, Octolapse also checks to see if the current position matches the expected position (some printers incorrectly respond immediately to M114, without waiting for moves to finish). That's why a detectable response to M114 is required.

[e3donline]

Is there an option or way to disable these functions and have it assume everything is good and correct?

[FormerLurker]

If I did this, the resulting time lapse would look pretty much exactly like the stock time lapse plugin. Im not sure that is what you want. This combo of commands (m400+M114) is the magic sauce that lets octolapse produce smooth timelapses.

I will try to adjust the regex. In the meantime you can try the stock time lapse functionality built into octoprint.

Are you affiliated with E3D? Just curious.

[e3donline]

I'm not using the stock timelapse function as i can't get it to trigger a photo when i need it to, it only has the functions for timed, or on z height change. I have to move the printhead to a particular position before i can take a photo. If the inbult timelapse has a command function i would consider falling back to that.

Yes I work for E3D, my name is Greg. A pleasure to talk to you, and again, thank you for your time and assistance :)

[FormerLurker]

Pleased to meet you!

If you want the timelapse stabilized (print head in a predictable location), and you want it automated (octolapse) the M114 response is crucial. You could manually produce a timelapse by generating custom gcode on a layer change within the slicer to move to the desired position, including an M400 after the movement. Then you'll need to use something like the system command plugin + a custom gcode that runs a script to grab your snapshot + an appropriately long wait command that will give your camera enough time to take a snapshot. I did exactly this a long time ago, which prompted me to create Octolapse. It takes quite a bit of effort, but it can be made to work. The delays are necessarily longer than what Octolapse produces, which leads to more stringing/oozing.

I could help you restructure the M114 response. If you change this:

X:272.500 Y:140.000 Z:15.000 C:4.600 E:0.000 E0:0.0 Count 66000 21200 24000 7360 Machine 272.500 140.000 15.000 4.600 Bed comp 0.000

To this:

X:272.500 Y:140.000 Z:15.000 E:0.000 E0:0.0 C:4.600 Count 66000 21200 24000 7360 Machine 272.500 140.000 15.000 4.600 Bed comp 0.000

It should work properly for both OctoPrint and Octolapse (and numerous other plugins). I know it's strange that the order of the response params matter, but nearly all other printers use this order, and it's much more efficient to rely on this. Otherwise regex can't be used, or one regex per parameter is required.

[FormerLurker]

Also, fyi, I may very well redo the M114 response detection so that order doesn't matter for the X, Y, Z and E parameters at least, but that won't fix the problem for OctoPrint itself.

[e3donline]

I'm not able to change the M114 response as I don't have a part in writting the firmware for the duet. I can maybe forward messages onto Duet though.

I'm not fussed about ooze, that's not an issue with what i am doing at this stage. Would it be possible to just function with the XYZ position and ignore the E if that is what is throwing things out?

[FormerLurker]

It looks like that is non-standard Duet behavior. I looked in their changelog and they specifically mention compatibility for OctoPrint. Do you have a link to the source of the firmware you are using? Is it a customized version of Duet?

[e3donline]

It is an unmodified release | https://github.com/Duet3D/RepRapFirmware/releases/tag/3.1.1

[FormerLurker]

OK, thanks. I'll look through it. Maybe I can do a pull request. It is likely much easier to alter this in the firmware rather than creating a new regex that must also work with all other printers and firmwares out there.

[FormerLurker]

Well, the issue is somewhere here:

https://github.com/Duet3D/RepRapFirmware/blob/4426e0a8cda63032e6aa72fe4db1c27f2d4264d8/src/GCodes/GCodes.cpp#L3642-L3686

I believe the extra C axis is causing a problem in the for loop. I'm guessing the C axis is for the tool changer, no? I would need more time to figure out a pattern that would work for all possible configurations (more than 3 axes).

[e3donline]

Yes, the C is for an additional axis. There maybe even more added in the future too.....

Anything you can do to make Octolapse work with our system would be greatly appreciated :)

[FormerLurker]

It would be easier to test if I had one of your machines 🤣. Anyway, i will see if my solution can be extended to OctoPrint as well.

[e3donline]

We can all dream :)

Thanks for your help :)

[T3P3]

The M114 response from RRF needs to be able to report the positions for machines with up to 9 axis (XYZ ABC UVW) and with multiple extruders (for example a hot end with 5 extruders feeding one tool). It also needs to distinguish between machine co-ordinates and user coordinate

The reason for the multiple E values:

"The first E value (without an extruder number) is the current virtual extruder position, and is included for the benefit of GCode senders that don't understand multiple extruders. The E0, E1 etc. values are for each individual extruder."