Skip to content
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

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

Closed
foosel opened this issue Feb 10, 2017 · 18 comments

Comments

Projects
None yet
3 participants
@foosel
Copy link
Owner

commented Feb 10, 2017

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 #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

This comment has been minimized.

Copy link

commented Feb 10, 2017

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

This comment has been minimized.

Copy link
Owner Author

commented Feb 10, 2017

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.

@nokemono42

This comment has been minimized.

Copy link

commented Feb 10, 2017

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

@nokemono42

This comment has been minimized.

Copy link

commented Feb 10, 2017

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

This comment has been minimized.

Copy link

commented Feb 10, 2017

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

This comment has been minimized.

Copy link
Owner Author

commented Feb 10, 2017

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

This comment has been minimized.

Copy link

commented Feb 13, 2017

Feature flags.
firmwareDetection: false
sdAlwaysAvailable: true

  • Always Send checksums. (when testing)

For serial tab options I have.

Basic
basic

Advanced
advanced

@foosel

This comment has been minimized.

Copy link
Owner Author

commented Feb 22, 2017

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

@foosel

This comment has been minimized.

Copy link
Owner Author

commented Feb 23, 2017

@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

This comment has been minimized.

Copy link

commented Feb 23, 2017

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

@amd989

This comment has been minimized.

Copy link

commented Feb 27, 2017

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 comment has been minimized.

Copy link
Owner Author

commented Mar 9, 2017

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.

@nokemono42

This comment has been minimized.

Copy link

commented Mar 13, 2017

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

foosel added a commit that referenced this issue May 3, 2017

Only prevent command processing if streaming AND printing
Otherwise we might run into a rare race condition where the M110 sent
on start of a SD card upload gets prepared for sending after the
source file is already opened. That would then lead to the M110 not
getting processed anymore by OctoPrint and hence the line number
counter not resetting accordingly, leading to one line number
mismatch after the next from the firmware.

Testing if our "isPrinting" flag is ALSO set to true here ensures
that we'll only stop processing commands internally once the state
has actually switched to printing, which only happens after the
firmware responds to the M28 sent after the M110.

Fixes #1882 and probably also the issue encountered by @amd989 in
#1762 (which looks like exactly the same problem)
@foosel

This comment has been minimized.

Copy link
Owner Author

commented May 3, 2017

@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 foosel added the status:solved label May 3, 2017

@foosel foosel added this to the 1.3.3 milestone May 3, 2017

@foosel

This comment has been minimized.

Copy link
Owner Author

commented May 31, 2017

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 foosel removed the status:solved label May 31, 2017

@foosel foosel modified the milestones: 1.3.4, 1.3.3 May 31, 2017

@foosel foosel closed this in 517fd6f May 31, 2017

@foosel

This comment has been minimized.

Copy link
Owner Author

commented May 31, 2017

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

@foosel foosel reopened this May 31, 2017

foosel added a commit that referenced this issue Jun 1, 2017

@foosel

This comment has been minimized.

Copy link
Owner Author

commented Jun 2, 2017

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 foosel added the status:solved label Jun 2, 2017

@foosel

This comment has been minimized.

Copy link
Owner Author

commented Oct 17, 2017

1.3.5 was released yesterday.

@foosel foosel closed this Oct 17, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.