M600 - Changing filament without using LCD and encoder #11281
Comments
|
Start with looking up how pingpong (ok) protocol works. Sorry. Currently you are far away from a working concept. |
|
@AnHardt |
|
Hello! Sorry for the long wait. It took us a little more to figure out how the host was also working and to test the solution a bit. To change the filament using a host exclusively, one could follow these steps:
// Added support for M601 & M602 (changing filament related)
#define EMERGENCY_PARSER
#if ENABLED(EMERGENCY_PARSER)
enum e_parser_state {
state_RESET,
state_N,
state_M,
state_M1,
state_M10,
state_M108,
state_M11,
state_M112,
state_M4,
state_M41,
state_M410,
state_M6,
state_M60,
state_M601,
state_M602,
state_IGNORE // to '\n'
};
#endif
// Currently looking for: M108, M112, M410, M601, M602b. in the switch(state), modify case state_M like this: case state_M:
switch (c) {
case ' ': break;
case '1': state = state_M1; break;
case '4': state = state_M4; break;
case '6': state = state_M6; break;
default: state = state_IGNORE;
}
break;c. in the switch(state), add these cases before case state_IGNORE: case state_M6:
state = (c == '0') ? state_M60 : state_IGNORE;
break;
case state_M60:
switch (c) {
case '1': state = state_M601; break;
case '2': state = state_M602; break;
default: state = state_IGNORE;
}
break;d. in the switch(state), in the default case, there is another switch(state) case, add these cases before the inner default case: case state_M601:
advanced_pause_menu_response = ADVANCED_PAUSE_RESPONSE_RESUME_PRINT;
SERIAL_PROTOCOL("M601 reached");
SERIAL_EOL();
break;
case state_M602:
advanced_pause_menu_response = ADVANCED_PAUSE_RESPONSE_EXTRUDE_MORE;
SERIAL_PROTOCOL("M602 reached");
SERIAL_EOL();
break;After just these steps, M601 and M602 should work in such a way you don't need an encoder to change the filament any more.
In OctoPrint, the host waits for an "ok" before sending the next command, and because M600 only sends this "ok" when the whole procedure is finished, "Fake Acknowledgement" is required. When having M600 inside a file, we noticed 2 "Fake Acknowledgement" is needed after each of the commands (M108, M601, M602), and only 1 "Fake Acknowledgement" was sufficient when M600 was explicitly sent by us. For instance:
I hope this helps someone! If you have any questions, please do ask. |
|
Hello good morning, I can't make it work, only the m108 works but the M601 and the M602 don't |
|
Hello is for Marlin 1.1.9 or 2.0.x. Thanks |
|
I've done it. |
|
This is rather ancient, host prompt support does this with M876 to choose actions as well. |
|
Except the emergency parser does not work for M876. |
|
Yes it does, I coded it myself. |
|
Then it has a bug. It doesn't work when in a busy state waiting for user during an M600 event. I had to overrride all occurrences of #if (DISABLED(EMERGENCY_PARSER) to get it to work in the context of this post. So if you could make a permanent change to the code so we don't have to modify it that would be greatly appreciated! I have an Artillery Sidewinder and our TFT does not have an encoder. I had to jump through hoops to get the runout script working with the TFT and Octoprint. // Enable an emergency-command parser to intercept certain commands as they Notice how these commands are all disabled #if emergency parser is enabled. Is it possible this is supposed to say enabled instead of disabled??? I added the EMERGENCY_OVERRIDE parameter: /*gcode.cpp/ /*gcode.h/ /*queue.cpp/ /*M108_M112_M410.cpp/ #include "../gcode.h"
/**
/**
#endif // !EMERGENCY_PARSER |
|
What platform are you on? That code makes it run in the normal parser, not the emergency parser. If its getting there at all then the emergency parser is not active at all. Im just getting things caught back up to date, most of my branches are 2-3mo old right now, after all the pandemic mayhem so its possible it was broken again in the interim. The TFT on that machine is a serial streamer and can interfere with octoprint. It has no direct interface to Marlin and talks on the same serial channel as USB. It can at times cause random issues when one of its commands injects in the middle of what octoprint is sending. |
|
I'm running 2.0.5.3 on an MKS Gen L board with an Mkstft_28 clone. I have no encoder and the same serial port is used for both the TFT and the USB cable that plugs into the computer to run octoprint. So having to share the serial port has been a challenge but host actions have saved the day so far. They allow me to remotely remotely parse runout events from the TFT. I had to enable an LCD to be able to activate the family of features associated with advanced pause, so I chose reprap discount smart controller but I'm not using any of the encoder pins. I'm using LCD support as a Trojan horse to activate the M600 features. |
|
Shouldnt need an LCD enabled if emergency parser is enabled. I have a few machines with no LCD enabled but M600 is on just based on host prompt and emergency parser. Ive got the same machine, ill update the code and test a few configurations over the next day or two. In the meantime, post youre config files and ill glance for anything obvious. |
|
Awesome I appreciate the help. Maybe the lcd support is actually causing me the problem in the first place! I will upload the configuration files momentarily. |
This comment has been minimized.
This comment has been minimized.
|
My branch FWIW - https://github.com/InsanityAutomation/Marlin/tree/ArtilleryX1_2.0_Devel Can try this and see if it works as-is if youd like before I get a chance to run some tests myself. Rebased it so its current. Day job is calling so I wont be back to this till late tonight. |
|
I see that you don't have the default configuration set up for the Sidewinder, but I did notice your description for EMERGENCY_PARSER now lists M876, PROMISING!
OK, I have tried this version of Marlin and disabled LCD support instead of adding EMERGENCY_OVERRIDE and the behavior is definitely different, which could be from disabling LCD support, or it could be from differences in the backend code. I did notice changes to the syntax of some expressions but nothing caught my attention offhand that would be functionally different for this behavior. For example, this new way to implement conditionals: TERN_(O,A). I don't like it personally, and I wonder what it accomplishes. Action notifications no longer occur at the start of a print "//action:notification Printing..." or the end "//action:notification Artillery Sidewinder X1 Ready". I need these notifications to tell the TFT when to switch modes for an Octoprint session! And under this configuration, when I respond to the "//action:prompt_begin Nozzle Parked" dialog, it does not stay paused for the Purge More/Continue Dialog, it just continues printing after acknowledging the Nozzle Parked dialog. (And a side note about that dialog: it calls for M108 but M108 was kicking me out of the M600 script in the 2.0.5.3 I was running before. I experimented to find that an M876 S0 did the trick and got me, functionally, to the Purge More dialog, but that doesn't work here.) The strange thing is that it displays the Purge More/Continue Dialog, but it just continues with the print like the dialog doesn't exist and doesn't take the appropriate actions upon acknowledging the M876 S0 or M876 S1. /THESE RESPONSES RESULT IN NO ACTION!!! THERE IS NO FURTHER PURGING ON M876 S0 AND IF A PRINT IS IN SESSION IT WILL ALREADY HAVE RESUMED BY THE TIME THESE DIALOGS APPEAR/ It appears that part of Marlin thinks the M600 script is complete as soon as it receives the Nozzle Parked response, and the main gcode execution thread resumes, but another function is still handling the dialogs as if the print is still paused because it is supposed to be. I am thinking it has to do with this configuration failing to hold a BUSY state to stop the host from sending new gcode. That, of course, doesn't necessarily solve the fact that Purge More doesn't work, but it would be half of a solution. Here are my current configuration files, this should make it relatively easy to test later on. I am using the X+ position for #define FIL_RUNOUT_PIN 2, otherwise it is configured for a stock setup. If you want in depth details about how I got it working properly I couldn't say everything I need to say here, it's too much information. But if you have 12min to watch my video I think you'll understand where I am coming from. https://www.youtube.com/watch?v=HJpfO8XifqI I would very much like a permanent solution to this so no modification of Marlin is necessary on the backend! Whether that be help configuring something differently or changes to the repository! |
|
Here are the changes that I found necessary to the previous build of Marlin: //=============================================================================
//================================ Configuration.h ===============================
//=============================================================================
#define FILAMENT_RUNOUT_SENSOR
/*Self-explanatory. This is the foundation for everything we are doing.*/
#define FIL_RUNOUT_PIN 2 //MKS GEN L 1.0 X_MAX PIN
/*This assigns the FILAMENT_RUNOUT_SENSOR to the X+ pin (D2) of the MKS GEN L board. We will have to move the runout sensor from the TFT to this location in order to use it from both the TFT and Octoprint*/
/**Print Job Timer
* Automatically start and stop the print job timer on M104/M109/M190.
* M104 (hotend, no wait) - high temp = none, low temp = stop timer
* M109 (hotend, wait) - high temp = start timer, low temp = stop timer
* M190 (bed, wait) - high temp = start timer, low temp = none
* The timer can also be controlled with the following commands:
* M75 - Start the print job timer
* M76 - Pause the print job timer
* M77 - Stop the print job timer*/
#define PRINTJOB_TIMER_AUTOSTART
/*This is important because Marlin will not monitor the runout sensor unless the print timer is running, so enabling this feature will allow us to activate the print timer while printing from the TFT.*/
/////////////////////////NOT USED FOR THIS TEST#define REPRAP_DISCOUNT_SMART_CONTROLLER
/*This allows us to enable the family of features necessary to activate the M600 scripts*/
//=============================================================================
//============================== Configuration_adv.h =============================
//=============================================================================
// Enable an emergency-command parser to intercept certain commands as they
// enter the serial receive buffer, so they cannot be blocked.
// Currently handles M108, M112, M410
// Does not work on boards using AT90USB (USBCON) processors!
#define EMERGENCY_PARSER
/*Note that this feature does not handle M876 in this description*/
/**
* Host Action Commands
*
* Define host streamer action commands in compliance with the standard.
*
* See https://reprap.org/wiki/G-code#Action_commands
* Common commands ........ poweroff, pause, paused, resume, resumed, cancel
* G29_RETRY_AND_RECOVER .. probe_rewipe, probe_failed
*
* Some features add reason codes to extend these commands.
*
* Host Prompt Support enables Marlin to use the host for user prompts so
* filament runout and other processes can be managed from the host side.
*/
#define HOST_ACTION_COMMANDS
#if ENABLED(HOST_ACTION_COMMANDS)
#define HOST_PROMPT_SUPPORT
#endif
/*Both if these would probably work wonderfully if we were using a different serial port for the TFT*/ |
|
UPDATE FROM PRELIMINARY TESTING: After enabling LCD support, behavior went back to normal, even without the EMERGENCY_OVERRIDE, so this is definitely an improvement over the previous version! No more backend modification necessary, just some Trojan horse action on the LCD support. It's not as elegant as I'd like, but it does work! (I also enabled #define LCD_SET_PROGRESS_MANUALLY for later use. I want to display Octoprint progress on the TFT in the future.) |
|
This behavior is also new, but the print did resume successfully afterwards: |
|
FYI, I noticed when rebasing my configs got blown out, so you may have seen a default config there. Its up correctly now. They were sitting in my offline changes not pushed. As the error suggests, have you increased the octoprint communication timeout, and set the checkbox that it is not the exclusive host? I just flashed my machine and ill be testing shortly. |
|
I wasn't that concerned about the timeout at the moment. It may just be that the M600 is a long command process when the user is not present to handle the dialogs. If that's the case I couldn't avoid that error unless I completely disabled timeout error management. I'll look for the exclusive host checkbox now. Let me know how testing goes. I'm particularly interested in whether or not you can get the PurgeMore dialog to work without enabling LCD support. |
|
Ive confirmed the issue is related to the Octoprint queue not Marlin. Ive forwarded some details to @foosel over discord. Once M876 is actually sent by the host, its processed however something is causing it to not jump the queue (maybe something in the capability report?) So we may need some info from that side. |
|
Awesome! I'm assuming he's an Octoprint guy? If so, could you ask if he could update the parser for Host Prompt support so that Dialogs are automatically cleared when ack_seen("//action:prompt_end")? When I clear a dialog from the TFT I'd like it to clear from Octoprint at the same time. Unless that's what "the checkbox that it is not the exclusive host" does (I haven't gotten around to that yet). |
|
NOTE: there was an error in my configuration_adv.h where the extruder fan was not defined. |
Thanks, but I'll also need an
Note that I have that still default to Also note that your way of setting it as a emergency command here:
works just fine on my end as well: Important for this is that the firmware reports
She. |
|
To clarify the issue, it is independent of Octoprint and happens any time the M600 script is run. If I do not define an LCD controller, PurgeMore/Continue selections do nothing at all. Print immediately resumes after the Nozzle Parked dialog. If I define an LCD controller, all operates as expected. To be honest, knowing that I would not have access to M73 without defining an LCD controller sort of makes me glad this is an issue. I do plan to incorporate the option for the TFT to display a print percentage, even from Octoprint. So at this point I just thought you should be aware that it is not functioning the way you said it is supposed to earlier in the thread. And on another note, while printing from Octoprint it would be nice to know what z height the printer is at. I have modified M155 to autoreport XYZE just like an M114 and it seems to work well but maybe you have a better idea. Ultimately, it would be more elegant to autoreport M114 and release M73 for use without LCD support, in addition to negating the need for defining an LCD for our setups, but I do have it running to my satisfaction so no harm no foul if that doesn't happen. I'm just glad the new branched don't require backend mods to run M600! Or maybe I can convince foosel to add an option to echo XYZ coordinates and print progress % while printing! That would limit the functionality to Octoprint, but that's all people talk about using anyway. |
OctoPrint has a complete library of plugins to add extra behaviors.
See if it helps to make this change in - #if ANY(EXTENSIBLE_UI, NEWPANEL, EMERGENCY_PARSER, HAS_ADC_BUTTONS)
+ #if ANY(EXTENSIBLE_UI, NEWPANEL, EMERGENCY_PARSER, HAS_ADC_BUTTONS, HOST_PROMPT_SUPPORT)
#define HAS_RESUME_CONTINUE 1
#endif |
|
No joy, behavior the same: Send: M109 S180 Send: M600 echo:Insert filament and send M108 <-----M108 doesn't work. M876 S0 does. Send: M876 S0 Send: M876 S0 ok <----expected: "M876 Responding PROMPT_FILAMENT_RUNOUT\nok\n", got: "ok\nok\n" <--------------------STILL NO FILAMENT ON PURGE MORE Send: M876 S1 |
|
This issue is stale because it has been open 30 days with no activity. Remove stale label / comment or this will be closed in 5 days. |
Bad assumption. |
Thanks I'm sure that was necessary. I've already spoken to her about it. |
|
Found this thread - strongly believe it will answer the problems I have with my recently installed run-out sensor. Hopefully the thread will stay in place till I get project completed. Lowell |
|
|
Sweet! |
One thing I considered doing was allowing the user to specify an endstop switch to substitute as a click of the LCD Panel's encoder wheel. That way, people without an LCD can still give the system a 'click' to indicate they are past a particular phase of the filament change sequence. It really should not be much code or complexity to do that. But the thing that has kept it from happening is so few printers are missing an LCD Panel now days. |
|
Host prompt support is more than capable of handling the situation. It would just be nice if it could be fully operational without defining an LCD controller. the entire artillery 3D printer line is lacking an encoder and they just released version 5 of The Sidewinder exactly the same |
|
For the sake of discussion - I have an LCD on my MakerGear M2 Dual Rev E. The challenge has been incorporating the Run-Out switch into the code. I've looked but a code modification/installation thread eludes me. I am currently close - but not close enough. |
|
Can you put the sensor on the main board? The next best option is to have the lcd send an M600 when the filament runs out |
|
Yes, the sensor is on the mainboard - the RAMBo board and the board supports the function, I have narrowed down the issue to the version of Marlin loaded on the system The last piece is enabling the Advanced Pause Feature - which I cannot find in V1.0.2 All that said I would love to upgrade to a newer version of Marlin - but am skeptical I can get all the settings correct, and MakerGear has no path forward for that upgrade at this time - to my knowledge. |
|
I am unfamiliar with that system or it's limitations. You may want to keep an eye on free memory if it running Marlin 1.0 though |
You might try doing a M503 and see how complete of a dump of all the settings you get. Because if you get a fairly complete dump of all the magic numbers... Turning on or off what ever other features you want should be fairly tame. |
|
Thanks for that advice - nice to see folks still want to share their madd
skillsets.
I'll do some more digging and kick the idea around some more. I'm going to
touch base with the technical team that makes the printer and see what
information I can drag out of them.
Take Care - be safe...
(my results)
SENT: M503
READ: echo:Steps per unit:
Steps per unit:
READ: echo: M92 X88.88 Y88.88 Z1007.70 E471.50
M92 X88.88 Y88.88 Z1007.70 E471.50
READ: echo:Maximum feedrates (mm/s):
Maximum feedrates (mm/s):
READ: echo: M203 X200.00 Y200.00 Z10.30 E25.00
M203 X200.00 Y200.00 Z10.30 E25.00
READ: echo:Maximum Acceleration (mm/s2):
Maximum Acceleration (mm/s2):
READ: echo: M201 X1000 Y1000 Z50 E2000
M201 X1000 Y1000 Z50 E2000
READ: echo:Acceleration: S=acceleration, T=retract acceleration
Acceleration: S=acceleration, T=retract acceleration
READ: echo: M204 S2000.00 T3000.00
M204 S2000.00 T3000.00
READ: echo:Advanced variables: S=Min feedrate (mm/s), T=Min travel feedrate (mm/s), B=minimum segment time (ms), X=maximum XY jerk (mm/s), Z=maximum Z jerk (mm/s), E=maximum E jerk (mm/s)
Advanced variables: S=Min feedrate (mm/s), T=Min travel feedrate (mm/s), B=minimum segment time (ms), X=maximum XY jerk (mm/s), Z=maximum Z jerk (mm/s), E=maximum E jerk (mm/s)
READ: echo: M205 S0.00 T0.00 B20000 X4.00 Z0.40 E1.00
M205 S0.00 T0.00 B20000 X4.00 Z0.40 E1.00
READ: echo:Home offset (mm):
Home offset (mm):
READ: echo: M206 X11.11 Y0.00 Z10.97
M206 X11.11 Y0.00 Z10.97
READ: echo:PID settings:
PID settings:
READ: echo: M301 P25.89 I1.94 D86.53
M301 P25.89 I1.94 D86.53
READ: ok
|
|
This issue is stale because it has been open 30 days with no activity. Remove stale label / comment or this will be closed in 5 days. |
|
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Hello!
I am trying to change the filament using the M600 command without an LCD screen and an encoder. The way I want to do it, is calling other M commands when the printer asks for input.
I have done some modifications to Marlin in an attempt to achieve this (which I will describe further below), but I have failed to achieve my goal. However, in doing so, I have discovered something which I would call a bug, but could possibly be an expected behavior. At some point during the M600, Marlin doesn't accept any command, not even M112 Emergency Stop, which could be dangerous, because I guess anyone could use this command when operating the printer from a very big distance if they notice a danger.
The way M600 works right now is:
The way I want M600 to work is to let the user make the choice proposed at points 4 and 5, by using either the encoder, or by issuing M601 Resume Print or M602 Extrude More.
In the following I will describes the steps I took into adding M601 and M602 commands.
Add these lines to Configuration_adv.h:
#if ENABLED(ADVANCED_PAUSE_FEATURE)
#define FILAMENT_CHANGE_HOST_EXCLUSIVE // Enables M601 and M602
#endif
In the Marlin_main.cpp, add the following lines of code before the definition of "process_parsed_command()":
#ifdef FILAMENT_CHANGE_HOST_EXCLUSIVE
/**
*/
inline void gcode_M601() {
advanced_pause_menu_response = ADVANCED_PAUSE_RESPONSE_RESUME_PRINT;
}
inline void gcode_M602() {
advanced_pause_menu_response = ADVANCED_PAUSE_RESPONSE_EXTRUDE_MORE;
}
#endif
In the Marlin_main.cpp, in the "process_parsed_command()" function, in the "case: 'M'" of the main switch statement, add the following lines of code at the end:
#if ENABLED(FILAMENT_CHANGE_HOST_EXCLUSIVE)
case 601:
gcode_M601();
break;
case 602:
gcode_M602();
break;
#endif
In the Marlin_main.cpp, in the "get_serial_commands()" function, after the "#endif#" of the "#if DISABLED(EMERGENCY_PARSER)", add these lines:
if (strcmp(command, "M601") == 0) { advanced_pause_menu_response = ADVANCED_PAUSE_RESPONSE_RESUME_PRINT; }
if (strcmp(command, "M602") == 0) { advanced_pause_menu_response = ADVANCED_PAUSE_RESPONSE_EXTRUDE_MORE; }
After implementing M601 and M602, the expected behavior is that I could change the filament without using the LCD and the encoder. I can now issue these commands when the printer says "busy: processing", but when the printer says "busy: paused for user" (which it does right when it asks to continue printing or extrude more) I cannot issue any command.
I have tracked down where I think it makes the printer pause for user, and it's in Marlin_main.cpp, in the "static void resume_print(...)" function, this block:
// Show "Extrude More" / "Resume" menu and wait for reply
KEEPALIVE_STATE(PAUSED_FOR_USER);
wait_for_user = false;
lcd_advanced_pause_show_message(ADVANCED_PAUSE_MESSAGE_OPTION);
while (advanced_pause_menu_response == ADVANCED_PAUSE_RESPONSE_WAIT_FOR) idle(true);
KEEPALIVE_STATE(IN_HANDLER);
I have tried to make "wait_for_user" true, but it does not seem to solve the issue.
Is there any way to make Marlin not enter the "busy: paused for user" state, and instead to only stay in the "busy: processing" state while it asks to continue printing or extrude more? (this way I could call those M601 and M602 commands, and probably it would solve the issue).
Also, is it an expected behavior for Marlin not to accept any commands at some points? Not even those from the EMERGENCY_PARSER section?
Any input on this is greatly appreciated. Thanks!
The text was updated successfully, but these errors were encountered: