[Request] Auto detection of Malyan M200/MP Select Mini firmware and its peculiarities

[foosel]

According to this reddit thread the M200/MP Select Mini runs some customized version of GRBL for which there are (currently) no sources available.

While it claims to be compatible to the Marlin instruction set, it appears to behave differently enough that issues arise, especially when handling SD cards.

The firmware identifies as NAME: Malyan VER: 2.9 MODEL: M200 HW: HA02 via M115. Following up a discussion originating in #1737 it needs at least feature.sdAlwaysAvailable set to true to function correctly. A possible further candidate is feature.alwaysSendChecksum set to true (since the firmware seems to hiccup on combined checksummed and checksum-less lines).

Identified TODOs:

• Add detection of NAME: Malyan and MODEL: M200 to the firmware auto detection code.
• If detected, set the following flags:
  • feature.sdAlwaysAvailable
  • feature.alwaysSendChecksum
  • feature.blockWhileDwelling (as determined in Time out after G4 #1941)

@amd989 and @nokemono42, would you be available to test further and report back to figure out if those are the only two flags that are needed for issuefree operation between the printer and OctoPrint?

[amd989]

Sure I'm down for testing!

@amd989 try checking "send all lines with checksums" please, see if that helps.

I will try this as soon as I get home.

Also, does regular printing (not via the printers sd) work?

Yes, printing through OctoPrint works fine. I had a couple of hiccups tho:

• twice it happened that in the middle of a print of a big gcode file (~20mb+) the printer would stop and then keep extruding plastic in the same spot. It could happen at any time of the print. If I printed the same file through the SD card it will finish fine. I then read somewhere that it might be related to the GCODE viewer. So I disabled it and it hasn't had any issues since. Also worth mentioning I was using a raspberry pi 1 so maybe it was too much for it. I have since upgraded to a rpi3 and everything has been fine.
• When the print starts, the printer detects its in "printing" mode and shows printing screen, however the percentage is not updated. Not sure if this is the same for all printers. Also, updating values from the printer (bed and hot-end temp) while printing reflects in OctoPrint successfully.
• When printing finishes, the printer stays in printing mode. While OctoPrint finished successfully. You can start another print from OctoPrint, and it will print fine. However, you can never get out of printing mode unless you hit the cancel button in the printer. At this point, the printer gets back to the main menu and a couple of seconds later, resets itself losing the connection with Octoprint. I have yet to test if the same occurs if you print and cancel from the SD directly. Printing directly from SD will show a "finished" screen when done, after that going back to home doesn't reset the printer.

Link to the current firmware if it helps
https://drive.google.com/open?id=0BxyFI3iDaicLQXRhNi1IZkd4WU0

[foosel]

The two last points are due to how that printer's firmware works. There might be some commands OctoPrint could send it via serial to update the displayed progress and/or switch from printing to not printing mode and vice versa, but those are certainly not part of the standard instruction set and since unless someone with one of those printers finds them by accident or Maylan publishes the source of their variant (the bin files are already compiled) there's no way to make this work.

The first point sounds more like a crash of the printer ("keep extruding plastic"). OctoPrint sends it commands line by line from your uploaded files, it's the firmware's responsibility to acknowledge them ("ok") so that new commands can be sent and execute them as necessary.

[joeycortez42]

A little late, but I'll post my results as well. Thanks @foosel for the responses.

[joeycortez42]

Uploaded a gcode file to the SD card after turning on "alwaysSendChecksum". It seemed to work fine. Here is the response:

Send: N322015 M106 S1*81
Recv: ok
Send: N322016 M104 S0*81
Recv: ok
Send: N322017 M29*45
Changing monitoring state from 'Printing' to 'Operational'
Recv: Done saving file.
Send: N322018 M20*43
Recv: Begin file list
Recv: swords~1.gco
Recv: End file list
Recv: ok N322018 P15 B15

Printing the file now to see if there are any issues.

[amd989]

In my case it did not work, I loops differently now

Send: N11 M20*33
Recv: Begin file list
Recv: wifi-setup.gcode
Recv: pid-bed.gcode
Recv: pid-heater.gcode
Recv: End file list
Recv: ok N11 P15 B15
Send: N12 M110 N0*78
Recv: ok N0 P15 B15
Send: N13 M28 /cable_~1.gco*24
Recv: Error:Line Number is not Last Line Number+1, Last Line: 0
Recv: Resend: 1
Recv: ok N0 P15 B16
Send: N1 M21*17
Recv: ok N1 P15 B15
Send: N2 M20*19
Recv: Begin file list
Recv: wifi-setup.gcode
Recv: pid-bed.gcode
Recv: pid-heater.gcode
Recv: End file list
Recv: ok N2 P15 B15
[...]
Send: N11 M20*33
Recv: Begin file list
Recv: wifi-setup.gcode
Recv: pid-bed.gcode
Recv: pid-heater.gcode
Recv: End file list
Recv: ok N11 P15 B15
Send: N12 M110 N0*78
Recv: ok N0 P15 B15
Send: N13 M28 /cable_~1.gco*24
Recv: Error:Line Number is not Last Line Number+1, Last Line: 0
Recv: Resend: 1
Recv: ok N0 P15 B16
Send: N1 M21*17
Recv: ok N1 P15 B15
Send: N2 M20*19
Recv: Begin file list
Recv: wifi-setup.gcode
Recv: pid-bed.gcode
Recv: pid-heater.gcode
Recv: End file list
Recv: ok N2 P15 B15
[...]

It keeps refreshing the SD's file list. With no checksum it will create the file in the SD, with 0 bytes, with checksum enabled it will not create the file.

[foosel]

Something is weird there because it resets the line number but then continues with the old one:

Send: N12 M110 N0*78 
Recv: ok N0 P15 B15 
Send: N13 M28 /cable_~1.gco*24

That looks more like an actual bug that I've never seen before. What feature flags did you have set and what was configured on the serial settings tab with regards to the advanced options? Just to make sure there's no collisions there of any kind.

[amd989]

Feature flags.
firmwareDetection: false
sdAlwaysAvailable: true

• Always Send checksums. (when testing)

For serial tab options I have.

Basic

Advanced

[foosel]

Just a quick ping, I haven't forgotten about this, I just have way too much stuff going on all at once again.

[foosel]

@amd989 for the life of me I can't figure out how the issue you are seeing can even happen. I looked through the code in question again, this:

Send: N12 M110 N0*78 
Recv: ok N0 P15 B15 
Send: N13 M28 /cable_~1.gco*24

should never happen. In fact, the comm layer in OctoPrint should rewrite the M110 command here to be sent with the same N0 in front it also has as parameter (so N0 M110 N0*<checksum>) and reset the internal line number counter so the next command would be sent with N1. In a nutshell, based on the implementation it should actually look like this:

Send: N0 M110 N0*<checksum1>
Recv: ok N0 P15 B15 
Send: N1 M28 /cable_~1.gco*<checksum2>

The fact that it doesn't means something must have happened here earlier in the communication that somehow managed to get around this, and I have no idea right now how that would be even possible.

So, could you please provide a full serial.log of a reproduction of this issue? I need to the full log, from the initial connection right until and including the reproduction of the problem. Also please provide a list of the plugins you have installed (that should usually be logged right after server startup to octoprint.log).

[amd989]

Hi! I'll get this done as soon as I get home!
Thank you for your support!

[amd989]

Ok here is the octoprint.log.txt

And here is a failure serial-failure.log.txt

After that failure, I started testing multiple gcode files that I had. Until I got a success. I tried checking what was different between these files, It seems that anything below 2MB would not upload to the SD. While anything higher would. I tried various files ranging from 2050KB to 7000KB and they would upload correctly.

Here is the success serial-success.log.txt

Couple files used (one fails, one works): gcode.zip

[foosel]

This is so weird. I poked at it from a lot of sides and am stumped. It shouldn't have anything to do with the file size, because the error arises when it doesn't reset its line number when sending its M110 to the printer. Which it should ALWAYS do.

@nokemono42 can you reproduce this issue that @amd989 is seeing too?

@amd989 I don't see any plugin configured there that I'd suspect of causing this, but just to be on the safe side, would you be able to disable your third party plugins (just disable should be enough) / restarting in safe-mode (octoprint serve --safe) to make sure no plugin is at fault here? It's a far stretch, because the only way a plugin could cause this would be by overwriting a specific function in OctoPrint, but I don't see how else the code I have in place there couldn't be executed correctly here.

Another thing to try would be connecting to the printer and manually sending a M110 via the terminal. Just to see what it does then.

[joeycortez42]

@foosel No I have not had any issues with failed uploads.

[foosel]

@amd989 Good news, I think I finally found the reason for your issue. Race condition, see #1882. Should be fixed in 1.3.3

Also, auto detection support for the Malyan M200 will also be part of 1.3.3, pushed that a while ago to maintenance and devel but apparently forgot to mention that here 😳

[foosel]

It looks like there is still an issue with G4 (dwell) commands and this firmware, see #1941, apparently they need to be handled identically to the way they are handled in Repetier firmware.

[foosel]

Auto closed by 844494a even though we are still waiting for #1941 m)

[foosel]

The "block while dwelling" feature flag will now also be set for Malyan printers.

Patch is already live on maintenance and devel and will be released with 1.3.5.

[foosel]

1.3.5 was released yesterday.