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.

Sign up for GitHub

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

Jump to bottom

Marlin 2.0.6 autostart not working properly #19296

Closed
3dseawa opened this issue Sep 7, 2020 · 28 comments
Closed

Marlin 2.0.6 autostart not working properly #19296

3dseawa opened this issue Sep 7, 2020 · 28 comments
Labels
F: SD Card / Media S: Solved

Comments

@3dseawa
Copy link

3dseawa commented Sep 7, 2020

Bug Description

Marlin 2.0.6 autostart not working properly.
I have three files sliced in Simply3D and renamed to auto0.g, auto1.g, auto2.g. When each file is named auto0.g and is the only file on the SD card each will autostart upon power boot-up. When auto0.g and auto1.g is on the card the auto1.g will autostart and print but not auto0.g. When auto0.g, auto1.g, auto2.g are on the SD card nothing happens. I have tried each of the files in different combinations with the same results.
When the same three files are on one SD card and put into my Ender3 Pro the auto0.g will execute but the other two do not.

The above leads me to believe this is a bug. If it is a configuration or file setting issue, please let me know the proper configuration or file settings.

I am do not have a LCD connected, nor is the USB connected to a computer – just the motherboard so printing directly from the micro-SD card reader on the mother board.

I have a custom-built machine using Marlin 2.0.6, download on 9/6/2020, on a BigTree Tech SKR 1.4 Turbo with TMC2209 drivers and sensorless homing. These are the setting in Configuration_adv.h folder: (lines 1145 and 1147)
#define SD_MENU_CONFIRM_START // Confirm the selected SD file before printing
#define MENU_ADDAUTOSTART // Add a menu option to run auto#.g files
No changes have been made to any .cpp files.
I have read others are having the same issue with auto1.g executing but not auto0.g.
Thank you in advance for helping identifying and resolving this issue for myself and other.

My Configurations

Required: Please include a ZIP file containing your Configuration.h and Configuration_adv.h files.

Attached are the configuration.h and configuration_adv.h zipped files:
Configuration.zip
Configuration_adv.zip

Steps to Reproduce

  1. save three sliced .gcobe files and rename as auto0.g, auto1.g, auto2.g,
  2. load onto sd card reader on motherboard while disconnected from LCD and computer
  3. power on machine and note what happens.

Expected behavior: [What you expect to happen]
upon power bootup auto0.g should print, then auto1.g should print automatically, then auto2.g should print - up to auto9.g.

Attached are the configuration.h and configuration_adv.h zipped files:
Configuration.zip
Configuration_adv.zip

Actual behavior: [What actually happens]
See above for what happens and what has been tried.

Additional Information

  • Provide pictures or links to videos that clearly demonstrate the issue.
  • See How Can I Contribute for additional guidelines.
@thomas374b
Copy link

Enable SDCARD_SORT_ALPHA in Configuration_adv.h and tried to play with optional defines around there.

This may solve your problem with starting auto1.g instead of auto0.g since files are usually unsorted written to the card

@thomas374b
Copy link

thomas374b commented Sep 9, 2020 •
edited
Loading

If you have defined SD_MENU_CONFIRM_START

you must press a button on the LCD in order to start printing. If you have no LCD this code will never be reached.

@3dseawa
Copy link
Author

3dseawa commented Sep 9, 2020

Thank you thomas374b for you input.
I commented with // for SD_MENU_CONFIRM_START
I also uncommented (deleted the //) SDCARD_SORT_ALPHA
Sadly after trying several tests , I got the same results as before - auto1.g executes but not auto0.g when those two files are on the SD card. When auto0.g, auto1.g and auto2.g are all on the SD card then nothing executes. auto0.g will execute when it is the only file on the card.

@AnHardt
Copy link
Contributor

AnHardt commented Sep 9, 2020 •
edited
Loading

The riddle has likely to be solved here or in the initialization of autostart_index.
At the moment i can't find a obvious problem - but i currently don't understand every part of the code properly.

@boelle
Copy link
Contributor

boelle commented Sep 10, 2020

@3dseawa please check what @AnHardt said about

Marlin/Marlin/src/sd/cardreader.cpp

Lines 676 to 699 in 9ade72a

void CardReader::checkautostart() {
if (autostart_index < 0 || flag.sdprinting) return;
if (!isMounted()) mount();
TERN_(SDCARD_EEPROM_EMULATION, else settings.first_load());
// Don't run auto#.g when a PLR file exists
if (isMounted() && TERN1(POWER_LOSS_RECOVERY, !recovery.valid())) {
char autoname[8];
sprintf_P(autoname, PSTR("auto%c.g"), autostart_index + '0');
dir_t p;
root.rewind();
while (root.readDir(&p, nullptr) > 0) {
for (int8_t i = (int8_t)strlen((char*)p.name); i--;) p.name[i] = tolower(p.name[i]);
if (p.name[9] != '~' && strncmp((char*)p.name, autoname, 5) == 0) {
openAndPrintFile(autoname);
autostart_index++;
return;
}
}
}
autostart_index = -1;
}

also Please test the bugfix-2.0.x branch to see where it stands.

@3dseawa
Copy link
Author

3dseawa commented Sep 11, 2020 via email

@3dseawa
Copy link
Author

3dseawa commented Sep 11, 2020 via email

@qwewer0
Copy link
Contributor

qwewer0 commented Sep 11, 2020

Here is what is happens for me:

  • auto0.g: Printer starts -> (LCD shows AUTO0.G) auto0.g runs -> Steppers gets disabled -> Other print jobs can be started
  • auto0.g and auto1.g: Printer starts -> (LCD shows AUTO1.G) auto0.g runs -> Steppers gets disabled -> auto1.g runs -> Steppers gets disabled -> Other print jobs can be started
  • auto0.g, auto1.g and auto2.g: Printer starts -> (LCD shows AUTO0.G) -> No gcode is executed, and the printer stucks in printing mode
    After print is aborted, no other print (.gcode, .g etc.) can be started, I mean by that the printer won't accept the selected "Print" menu item in the print confirmation menu, can only clicked on "Cancel", and no Auto Home or M48 Probe Test can be run from the LCD. While it is in the printing mode or aborted it, wasn't able to connect it to a PC. Restore Defaults, Store Settings doesn't helps.
auto0.g content 
G28
auto1.g content 
G28
M300 S2000 P5
auto2.g content 
G28
M300 S2000 P5
G4 P50
M300 S2000 P15

Here are the files:
auto.zip

Using the latest Bugfix-2.0.x
Configuration.zip

@github-actions
Copy link

This issue has had no activity in the last 30 days. Please add a reply if you want to keep this issue active, otherwise it will be automatically closed within 7 days.

@qwewer0
Copy link
Contributor

qwewer0 commented Oct 12, 2020

Tested #19296 (comment) on the latest Bugfix-2.0.x, and the results are still the same.

@3dseawa
Copy link
Author

3dseawa commented Oct 16, 2020

It looks like there is a bug with the Autostart feature and it is beyond my knowledge and skill set to fix.
I did find a workaround by only having auto0.g on my SD card (no other auto1.g, auto2.g, et.c. files) then using g-code M32 as the last line of the auto0.g g-code file and naming the next file to start within the M32 command. Then using M32 command in the second file by putting the M32 command as the last g-code line in that file's g-code and naming it the third file to start, and so on up to seven additional file. My setup will only allow for a total of 8 files on the SD card for the auot0.g to execute. More than 8 files and auot0.g does not execute. Not sure why it is limited to 8 files for the auto0.g to execute.

A few key points about the M32 command:

  1. the file name can be a maximum of 8 characters and the file type can only be 3 letters long -'filename.gco'.
  2. the character ! has to directly precede the file name and # must end the file name
    e.g. M32 !filename.gco#
  3. if you want to create a loop where the auto0.g will start after the last file then use the M32 command in the last line of the last file and name it: M32 !auto0.g# and it will execute the auto0.g file again and restart the series of files.
    https://marlinfw.org/docs/gcode/M032.html
    Thanks you to all who contributed to this issue. I appreciate your efforts.

@Zumili
Copy link

Zumili commented Nov 7, 2020 •
edited
Loading

Hey guys, just found some possible solution.
Just change this line: https://github.com/MarlinFirmware/Marlin/blob/2.0.x/Marlin/src/sd/cardreader.cpp#L708
from
if (autostart_index < 0 || flag.sdprinting) return;
to
if (autostart_index < 0 || flag.sdprinting || queue.has_commands_queued()) return;
on line 708 in cardreader.cpp

Why the problem occurs:
In MarlinCore.cpp card.checkautostart(); gets called very often in the main loop.
In checkautostart(); flag.sdprinting is used to check if printing is active. The filename is created and openAndPrintFile(autoname); gets called with that filename.
In openAndPrintFile(); gcode commands M23 and M24 will be created and added to the queue.
Now the loop repeats but the parser may or may not ( and here is the problem ) has parsed the data from the queue. So the flag.sdprinting is probably still false. With queue.has_commands_queued() it will ensure that the next M23 M24 commands only added to queue when it is empty after the print is finished.

@qwewer0
Copy link
Contributor

qwewer0 commented Nov 7, 2020

Tested #19296 (comment) on the latest Bugfix-2.0.x with @Zumili fix #19296 (comment), and it seems to fixed the issue.
Here is what is happens for me:

  • auto0.g: Printer starts -> (LCD shows AUTO0.G) auto0.g runs -> Steppers gets disabled -> Other print jobs can be started
  • auto0.g and auto1.g: Printer starts -> (LCD shows AUTO0.G) auto0.g runs -> Steppers gets disabled -> (LCD shows AUTO1.G) auto1.g runs -> Steppers gets disabled -> Other print jobs can be started
  • auto0.g, auto1.g and auto2.g: Printer starts -> (LCD shows AUTO0.G) auto0.g runs -> Steppers gets disabled -> (LCD shows AUTO1.G) auto1.g runs -> Steppers gets disabled -> (LCD shows AUTO2.G) auto2.g runs -> Steppers gets disabled -> Other print jobs can be started

So it works, and now it shows the right *.g file that is running.

@Zumili You should create a PR with that fix, or you could let me do it.

@Zumili
Copy link

Zumili commented Nov 7, 2020

qwewer0 I am not very familiar with github and I don't want to break the universe :) , so it will be nice if you can do it.

@qwewer0 qwewer0 mentioned this issue Nov 7, 2020
Closed
@boelle
Copy link
Contributor

boelle commented Nov 7, 2020

@3dseawa remember to close this one when the above PR is merged (it goes purple color)

@thinkyhead thinkyhead mentioned this issue Nov 8, 2020
Merged
@thinkyhead
Copy link
Member

I've put together a comprehensive patch at #20071. Please test to confirm that those changes work for you.

@3dseawa
Copy link
Author

3dseawa commented Nov 8, 2020 via email

@boelle
Copy link
Contributor

boelle commented Nov 22, 2020

@3dseawa did you get time to test?

@3dseawa
Copy link
Author

3dseawa commented Nov 22, 2020 via email

@3dseawa
Copy link
Author

3dseawa commented Nov 22, 2020 via email

@qwewer0
Copy link
Contributor

qwewer0 commented Dec 7, 2020 •
edited
Loading

@thinkyhead Thank you for the AutoStart refractory!

On the latest bugfix-2.0.x (with #20071) Configuration.zip

Here is what is happens:

  • auto0.g: Printer starts -> (LCD shows AUTO0.G) auto0.g runs -> Steppers stays engaged -> Printer is stuck in printing mode -> After print is aborted other print jobs can be started
  • auto0.g and auto1.g: Printer starts -> (LCD shows AUTO0.G) auto0.g runs -> Steppers gets disabled -> (LCD shows AUTO1.G) auto1.g runs -> Steppers stays engaged -> Printer is stuck in printing mode -> After print is aborted other print jobs can be started
  • auto0.g, auto1.g and auto2.g: Printer starts -> (LCD shows AUTO0.G) auto0.g runs -> Steppers gets disabled -> (LCD shows AUTO1.G) auto1.g runs ->Steppers gets disabled -> (LCD shows AUTO2.G) auto2.g runs -> Steppers stays engaged -> Printer is stuck in printing mode -> After print is aborted other print jobs can be started

With or without auto#.g files, a started print job stays in printing mode.
With NO_SD_AUTOSTART enabled, there is no print job issue.

@3dseawa
Copy link
Author

3dseawa commented Dec 7, 2020 via email

@qwewer0
Copy link
Contributor

qwewer0 commented Dec 8, 2020

@3dseawa Were you able to try it?

@3dseawa
Copy link
Author

3dseawa commented Dec 8, 2020 via email

@kisslorand kisslorand mentioned this issue Dec 13, 2020
Merged
@3dseawa
Copy link
Author

3dseawa commented Dec 27, 2020 via email

@HarpoDog
Copy link

I am please to confirm that the autostart feature is now working as designed.
Thank you to the entire team that resolved this issue.
You are truly appreciated!

@3dseawa
Copy link
Author

3dseawa commented Feb 11, 2021 via email

@github-actions
Copy link

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.

@github-actions github-actions bot locked and limited conversation to collaborators Apr 12, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
F: SD Card / Media S: Solved
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
8 participants
@AnHardt @thinkyhead @Zumili @boelle @thomas374b @qwewer0 @3dseawa @HarpoDog