0.2.4 can't process simplify3d gcode file when printing from SD Card #55
Comments
|
Please upload the file so I can test with it, thanks! |
|
it wouldn't let me upload a plain gcode file. |
|
If you upload to the address card using “Upload to SD” the file should go straight to the SD card and you should just see printing progress type messages in the log which looks like what you have. The plugin does not parse the uploaded file and alter it. It is a bit of a red flag that it says the total bytes it is/was printing is 1000. If you look further back in the log you should see the actual upload happening with progress in %. Make sure that got to 100%. There will be an M29 command at the end of the upload which should get a non error response. |
|
If you can upload a fresh OctoPrint.log captured during an SD upload that doesn’t print it would be helpful. |
|
I see the files completing and M29 looks ok |
|
every time I see this in the log, it's completes |
|
I should note, the printer never actually does anything - the hot end doesn't heat up, nothing. Just sits there. |
|
mo' log |
|
This might be a silly question, but is this the internal SD card? The finder has two usb ports, so I can only assume that this SD card is internal to the unit... |
|
Yes there's an sd card embedded on the control board of most of these printers so when you connect using FlashPrint and upload a file it goes onto that internal SD card. On the display on the printer you can print files off the internal SD card or select the USB drive (if you have one plugged in). |
|
xyzCalibration_cube.gcode.txt here are files from this morning. log file is freshly new and shows the same behavior. |
|
Great, thanks for that. The file upload appears to be successful and the printer responds correctly to the M29 command which makes it look like it saved the file: Have you added any plugins besides the FlashForge one? |
|
And you have not filled up the memory on the SD card in the printer? |
|
Looking again at the log it appears you have several plugins installed. Perhaps try disabling all of the ones you added except the FlashForge one and then try uploading to SD again. Depending on the function of the plugin, some plugins will manipulate the file before it is uploaded to the SD card (I believe DisplayLayer does this) so it would be good to eliminate any of them as a possible cause. |
|
The FF memory is certainly not full. however, it does not show the 'xyz.gcode' file at all. I do have a number of plugins installed. I will report back. |
|
as an aside, if I try to stream the gcode to the finder directly, the printer responds, but makes horrible grinding noises and grossly over-extrudes. |
|
seems to be working, although not sure which plugin it might be having issues with. I think the one that presents a 'preheat' button might be it, but that's total conjecture. |
|
I was able to do one print, but after I cancelled it, it didn't seem to work again. Power cycling, and trying again edit: I tried with the xyz.gcode, then tried with one that had a much longer filename (And that did not seem to work, going to try with a shorter name) |
|
Ok, strange - xyz.gcode prints, but xy.gcode (a tile holder, much larger file) does not. I tried re-slicing the same model with what I thought were the same factory settings in S3D, and it .. doesn't seem to work. I do see the xyz.gcode on the onboard flash now. So this is weird. Let me play with it a little bit and see if I can get something repeatable for you to chew on. Thanks for working with me! |
|
...aaand now it's not working at all. :/ |
|
not sure if this matters, but the port on the connection seems to be changing - when it connected before, it said 1:3, then 1:7 now 1:8... |
|
I think I figured it out - if the file is in a folder in octoprint, it doesn't load correctly. If I "Upload to SD" from the root, it works. If I try from a folder (in this case, "finder_test", it does not work. I think before I was changing directories unwittingly: this print did work: ...likely because there is no folder on the SD card called "finder_gcode" ? |
|
...also, it seems that if you get the file to the printer, then the folder doesn't matter - although it is not clear if it transfers in a new file, or just uses the existing file. Anyway, I think I understand the problem. I went and deleted the xyz.gcode from the printer directly, and tried to load from the finder_tests folder in octoprint, and it did not print, as expected. what's interesting is that the printer display indicates that it has a job, and has the right name - but just never goes anywhere. It does 'home', but then that's it. in short: if the file does not exist on the SD card, I have to Upload to SD from the root of octoprint. If the file name already exists, it appears to not matter what folder in octoprint I 'upload to SD' card, although I am not sure if it actually does file transfer or it just thinks it does - and runs whatever it has that has the same file name (old file). |
|
my most recent log if it is helpful. this does not have a faulty load, but a successful one. |
|
Oh yes the file path is totally screwed up. On my printers the upload path should always be |
|
Not sure whether it is relevant - but what web browser are you using for the 'Upload to SD'? |
This will happen if you reboot the printer which you sometimes have to do if the connection isn't closed properly - eg for some reason the plugin did not get all of the response from the printer before the connection was closed. It reconnects on the Pi/computer and ends up taking a new port number (I'm guessing the USB stack is not sure if the previous port is still in use). |
|
I think I will do a special version for you to try, but please tell me how you are able to get a subfolder name into the filename when using 'Upload to SD' because I cannot reproduce it using Safari, Chrome or Firefox (I don't have access to a Window box right now). |
|
Shoot, I'm sorry - I should have shown those steps. I'm just making a folder in Octoprint here in the GUI - just hitting 'create folder', and that is where the finder_gcode comes from... and what I mean when I say 'root' vs in the folder. (see next comment). |
|
2020-10-01 07:22:29,344 - octoprint.filemanager.analysis - INFO - Starting analysis of local:finder_gcode/xyz.gcode |
|
I don't think it likes the /data bit. |
|
connection details: I noticed it has a timeout up front, which seems weird. Timeouts are all specified as in the config page (5,2,2 etc) |
|
re M21 - I just looked again log file you uploaded and it seems the printer never responded to the M21 command at connect. That would cause the OctoPrint to wait for a response and eventually generate a timeout at which point it sends an M105 (get temperature) command to see if the printer is still there. I cannot tell if the command does anything on any of the FlashForge printers so maybe the answer is to just stop OctoPrint from sending it. Probably likewise for the M20 command which the printer is supposed to reply with the list of files on the SD card. The older printers at least respond to the command (even though they don't provide a list of files), so no timeout occurs. re SD card uploads - with the dev version does it never start the upload process? Does the printer not respond to the sendcommand() M28 250929 0:/data/xyz.gcode? |
|
I just pushed an update to the dev branch to eliminate the M20, M21 commands. Please reinstall from the dev URL (as described above) - that should eliminate the communication timeout messages immediately after connecting. Can't tell yet whether that has an impact on the SD Upload issue. |
|
Ok, that seemed to resolve the timeouts (m20/21), but the streaming still isn't working. It has 'broken' between the 'stable' 2.4 and the dev 2.4... so I can't print anything at all at least Upload from SD-wise |
|
Here is what the log says: |
|
Not sure what is going on there - did some of the log not paste in correctly? We should at least see the M28 command being issued. |
|
more log: |
|
the shmutz at the end might not be your plugin |
|
Just changed it back to using /user/ as the upload path if you want to try reinstalling dev |
|
ok, doing so. |
|
ok, that fixed the Upload to SD thing. and the timeouts are gone. Let's see if the print carries through.. it usually stops reporting/auto reporting about 24 'bytes' in.. and it never reports the actual number of bytes.. it's always x/1000 |
|
any tinkering with timeouts? the auto reports seem to work fine if there is no print job going, but once the print job gets going, the reports seem ... slow. |
|
Do you mean the print status when printing from the SD card? That looks to be set at a default of 1s using the "SD status interval (polling)" setting. |
|
Yes, I'm just saying that it stops auto updating after a while. In the case of the print I am running right now, the update stopped happening before the temp even got to 200C (the print is well under way at this point) |
|
|
|
I hit the 'print' button after it appeared to have stalled out to see if it would unstick, but to no avail |
|
Did the printer actually stop or is it OctoPrint no longer getting updates? |
|
Octoprint is no longer getting updates. The printer goes along happily once I do the Upload to SD card (with your latest refactor of the directory) |
|
Can you upload the complete log that you have right now so I can see the whole context? |
|
The printer seems to stop responding but the weird thing is the plugin does not generate a timeout waiting for a response from the printer. |
|
I did see this: which may or may not be relevant |
|
Aye - I've seen that. I'm not sure if it is significant or not. I had no issues with my Creality that took commands right from the unit. I can't imagine octoprint being a hard-hidding application. |
|
One thing is that the icon only blinks when there is an ongoing issue. It is not blinking - so for a temp issue (vs undervoltage issue), I am not seeing this when printing. That notification is from 7am in the morning, not now. |
|
ok, I will admit that since I power cycled the Pi, and turned it a little so that natural convection works a little better, so far no hang ups. So you might be onto something with your notification of the warning. I never said I was a Good User! edit - it quit around 125/1000. The screen saver/lock screen had also come up, not sure if that matters (I can't imagine it would, it shouldn't stop sending queries...) |
|
Can we change the M27 polling frequency to something more reasonable like once every 30 seconds? 1/s seems excessive for something that takes hours... |
|
Sure - you can change M27 polling to whatever you want. The plugin is not setting those - they are the default for OctoPrint and certainly if your prints are typically hours long then an update every 30s makes more sense. I don't think it will affect the issue you are seeing where the connection between OctoPrint and the printer is effectively stalling. Do you have the pi running a Linux desktop connected to a monitor? I know if I run OctoPrint on my Mac it tries to put the USB connections to sleep when the Mac tries to go to sleep causing the connection to the printer to drop, though it is pretty obvious in the log when that happens. So yes, if you have it running a desktop OS with power saving enabled I think there is a chance it will try to put the USB connections to sleep if it is trying to go into a low power or sleep state. |
Hi,
I used Upload to SD card, then printed from that - I get these kinds of messages in the log
2020-09-25 14:43:37,492 - octoprint.plugins.flashforge - DEBUG - rewrite_gcode(): dropping command
2020-09-25 14:43:37,493 - octoprint.plugins.flashforge - DEBUG - rewrite_gcode(): gcode:G1, cmd:G1 X1.482 Y-9.400 E1.5032
The extruder sounds like it's grinding or skipping steps or something. I also see this:
2020-09-25 16:23:46,385 - octoprint.plugins.flashforge - DEBUG - readraw() returns: CMD M119 Received. | Endstop: X-max:0 Y-max:0 Z-max:0 | MachineStatus: READY | MoveMode: READY | Status: S:1 L:0 J:0 F:0 | ok |
2020-09-25 16:23:46,387 - octoprint.plugins.flashforge - DEBUG - readline() called by thread comm._monitor
2020-09-25 16:23:46,389 - octoprint.plugins.flashforge - DEBUG - readraw() called by thread: comm._monitor, timeout: 2000
2020-09-25 16:23:46,391 - octoprint.plugins.flashforge - DEBUG - readraw() returns: CMD M27 Received. | SD printing byte 0/1000 | ok |
2020-09-25 16:23:46,392 - octoprint.plugins.flashforge - DEBUG - buffering: CMD M27 Received.
2020-09-25 16:23:46,394 - octoprint.plugins.flashforge - DEBUG - buffering: Not SD printing
2020-09-25 16:23:46,395 - octoprint.plugins.flashforge - DEBUG - buffering: ok
2020-09-25 16:23:46,398 - octoprint.plugins.flashforge - DEBUG - readline() called by thread comm._monitor
2020-09-25 16:23:46,400 - octoprint.plugins.flashforge - DEBUG - readline() called by thread comm._monitor
2020-09-25 16:23:46,402 - octoprint.plugins.flashforge - DEBUG - readline() called by thread comm._monitor
2020-09-25 16:23:46,403 - octoprint.plugins.flashforge - DEBUG - readraw() called by thread: comm._monitor, timeout: 2000
2020-09-25 16:23:47,364 - octoprint.plugins.flashforge - DEBUG - rewrite_gcode(): gcode:M27, cmd:M27
2020-09-25 16:23:47,364 - octoprint.plugins.flashforge - DEBUG - is_sd_printing()
2020-09-25 16:23:47,366 - octoprint.plugins.flashforge - DEBUG - write() called by thread comm.sending_thread
2020-09-25 16:23:47,367 - octoprint.plugins.flashforge - DEBUG - write() M119
~M27
2020-09-25 16:23:47,376 - octoprint.plugins.flashforge - DEBUG - readraw() returns: CMD M119 Received. | Endstop: X-max:0 Y-max:0 Z-max:0 | MachineStatus: READY | MoveMode: READY | Status: S:1 L:0 J:0 F:0 | ok |
2020-09-25 16:23:47,377 - octoprint.plugins.flashforge - DEBUG - readline() called by thread comm._monitor
2020-09-25 16:23:47,380 - octoprint.plugins.flashforge - DEBUG - readraw() called by thread: comm._monitor, timeout: 2000
2020-09-25 16:23:47,382 - octoprint.plugins.flashforge - DEBUG - readraw() returns: CMD M27 Received. | SD printing byte 0/1000 | ok |
2020-09-25 16:23:47,383 - octoprint.plugins.flashforge - DEBUG - buffering: CMD M27 Received.
2020-09-25 16:23:47,384 - octoprint.plugins.flashforge - DEBUG - buffering: Not SD printing
2020-09-25 16:23:47,384 - octoprint.plugins.flashforge - DEBUG - buffering: ok
2020-09-25 16:23:47,386 - octoprint.plugins.flashforge - DEBUG - readline() called by thread comm._monitor
2020-09-25 16:23:47,387 - octoprint.plugins.flashforge - DEBUG - readline() called by thread comm._monitor
2020-09-25 16:23:47,388 - octoprint.plugins.flashforge - DEBUG - readline() called by thread comm._monitor
2020-09-25 16:23:47,388 - octoprint.plugins.flashforge - DEBUG - readraw() called by thread: comm._monitor, timeout: 2000
2020-09-25 16:23:48,359 - octoprint.plugins.flashforge - DEBUG - rewrite_gcode(): gcode:M105, cmd:M105
2020-09-25 16:23:48,360 - octoprint.plugins.flashforge - DEBUG - is_sd_printing()
2020-09-25 16:23:48,363 - octoprint.plugins.flashforge - DEBUG - write() called by thread comm.sending_thread
2020-09-25 16:23:48,364 - octoprint.plugins.flashforge - DEBUG - write() M105
2020-09-25 16:23:48,367 - octoprint.plugins.flashforge - DEBUG - rewrite_gcode(): gcode:M27, cmd:M27
2020-09-25 16:23:48,369 - octoprint.plugins.flashforge - DEBUG - is_sd_printing()
2020-09-25 16:23:48,374 - octoprint.plugins.flashforge - DEBUG - readraw() returns: CMD M105 Received. | T0:28 /0 B:0/0 | ok |
2020-09-25 16:23:48,374 - octoprint.plugins.flashforge - DEBUG - buffering: CMD M105 Received.
2020-09-25 16:23:48,376 - octoprint.plugins.flashforge - DEBUG - buffering: T0:28 /0 B:0/0
2020-09-25 16:23:48,377 - octoprint.plugins.flashforge - DEBUG - buffering: ok
2020-09-25 16:23:48,380 - octoprint.plugins.flashforge - DEBUG - readline() called by thread comm._monitor
2020-09-25 16:23:48,383 - octoprint.util.comm - INFO - Externally triggered heatup detected
2020-09-25 16:23:48,395 - octoprint.plugins.flashforge - DEBUG - readline() called by thread comm._monitor
2020-09-25 16:23:48,397 - octoprint.plugins.flashforge - DEBUG - readline() called by thread comm._monitor
2020-09-25 16:23:48,399 - octoprint.plugins.flashforge - DEBUG - write() called by thread comm.sending_thread
2020-09-25 16:23:48,400 - octoprint.plugins.flashforge - DEBUG - readraw() called by thread: comm._monitor, timeout: 2000
2020-09-25 16:23:48,401 - octoprint.plugins.flashforge - DEBUG - write() M119
~M27
2020-09-25 16:23:48,411 - octoprint.plugins.flashforge - DEBUG - readraw() returns: CMD M119 Received. | Endstop: X-max:0 Y-max:0 Z-max:0 | MachineStatus: READY | MoveMode: READY | Status: S:1 L:0 J:0 F:0 | ok |
2020-09-25 16:23:48,412 - octoprint.plugins.flashforge - DEBUG - readline() called by thread comm._monitor
2020-09-25 16:23:48,414 - octoprint.plugins.flashforge - DEBUG - readraw() called by thread: comm._monitor, timeout: 2000
2020-09-25 16:23:48,417 - octoprint.plugins.flashforge - DEBUG - readraw() returns: CMD M27 Received. | SD printing byte 0/1000 | ok |
2020-09-25 16:23:48,418 - octoprint.plugins.flashforge - DEBUG - buffering: CMD M27 Received.
2020-09-25 16:23:48,420 - octoprint.plugins.flashforge - DEBUG - buffering: Not SD printing
2020-09-25 16:23:48,421 - octoprint.plugins.flashforge - DEBUG - buffering: ok
2020-09-25 16:23:48,423 - octoprint.plugins.flashforge - DEBUG - readline() called by thread comm._monitor
2020-09-25 16:23:48,426 - octoprint.plugins.flashforge - DEBUG - readline() called by thread comm._monitor
2020-09-25 16:23:48,429 - octoprint.plugins.flashforge - DEBUG - readline() called by thread comm._monitor
2020-09-25 16:23:48,430 - octoprint.plugins.flashforge - DEBUG - readraw() called by thread: comm._monitor, timeout: 2000
2020-09-25 16:23:49,371 - octoprint.plugins.flashforge - DEBUG - rewrite_gcode(): gcode:M27, cmd:M27
2020-09-25 16:23:49,373 - octoprint.plugins.flashforge - DEBUG - is_sd_printing()
2020-09-25 16:23:49,376 - octoprint.plugins.flashforge - DEBUG - write() called by thread comm.sending_thread
2020-09-25 16:23:49,378 - octoprint.plugins.flashforge - DEBUG - write() M119
~M27
2020-09-25 16:23:49,386 - octoprint.plugins.flashforge - DEBUG - readraw() returns: CMD M119 Received. | Endstop: X-max:0 Y-max:0 Z-max:0 | MachineStatus: READY | MoveMode: READY | Status: S:1 L:0 J:0 F:0 | ok |
2020-09-25 16:23:49,388 - octoprint.plugins.flashforge - DEBUG - readline() called by thread comm._monitor
2020-09-25 16:23:49,389 - octoprint.plugins.flashforge - DEBUG - readraw() called by thread: comm._monitor, timeout: 2000
2020-09-25 16:23:49,392 - octoprint.plugins.flashforge - DEBUG - readraw() returns: CMD M27 Received. | SD printing byte 0/1000 | ok |
2020-09-25 16:23:49,393 - octoprint.plugins.flashforge - DEBUG - buffering: CMD M27 Received.
2020-09-25 16:23:49,394 - octoprint.plugins.flashforge - DEBUG - buffering: Not SD printing
2020-09-25 16:23:49,396 - octoprint.plugins.flashforge - DEBUG - buffering: ok
2020-09-25 16:23:49,402 - octoprint.plugins.flashforge - DEBUG - readline() called by thread comm._monitor
2020-09-25 16:23:49,408 - octoprint.plugins.flashforge - DEBUG - readline() called by thread comm._monitor
2020-09-25 16:23:49,411 - octoprint.plugins.flashforge - DEBUG - readline() called by thread comm._monitor
2020-09-25 16:23:49,413 - octoprint.plugins.flashforge - DEBUG - readraw() called by thread: comm._monitor, timeout: 2000
2020-09-25 16:23:50,375 - octoprint.plugins.flashforge - DEBUG - rewrite_gcode(): gcode:M27, cmd:M27
2020-09-25 16:23:50,376 - octoprint.plugins.flashforge - DEBUG - is_sd_printing()
2020-09-25 16:23:50,378 - octoprint.plugins.flashforge - DEBUG - write() called by thread comm.sending_thread
2020-09-25 16:23:50,380 - octoprint.plugins.flashforge - DEBUG - write() M119
~M27
2020-09-25 16:23:50,389 - octoprint.plugins.flashforge - DEBUG - readraw() returns: CMD M119 Received. | Endstop: X-max:0 Y-max:0 Z-max:0 | MachineStatus: READY | MoveMode: READY | Status: S:1 L:0 J:0 F:0 | ok |
2020-09-25 16:23:50,390 - octoprint.plugins.flashforge - DEBUG - readline() called by thread comm._monitor
2020-09-25 16:23:50,392 - octoprint.plugins.flashforge - DEBUG - readraw() called by thread: comm._monitor, timeout: 2000
2020-09-25 16:23:50,395 - octoprint.plugins.flashforge - DEBUG - readraw() returns: CMD M27 Received. | SD printing byte 0/1000 | ok |
2020-09-25 16:23:50,396 - octoprint.plugins.flashforge - DEBUG - buffering: CMD M27 Received.
2020-09-25 16:23:50,398 - octoprint.plugins.flashforge - DEBUG - buffering: Not SD printing
2020-09-25 16:23:50,399 - octoprint.plugins.flashforge - DEBUG - buffering: ok
2020-09-25 16:23:50,402 - octoprint.plugins.flashforge - DEBUG - readline() called by thread comm._monitor
2020-09-25 16:23:50,404 - octoprint.plugins.flashforge - DEBUG - readline() called by thread comm._monitor
2020-09-25 16:23:50,407 - octoprint.plugins.flashforge - DEBUG - readline() called by thread comm._monitor
2020-09-25 16:23:50,407 - octoprint.plugins.flashforge - DEBUG - readraw() called by thread: comm._monitor, timeout: 2000
2020-09-25 16:23:51,378 - octoprint.plugins.flashforge - DEBUG - rewrite_gcode(): gcode:M27, cmd:M27
2020-09-25 16:23:51,379 - octoprint.plugins.flashforge - DEBUG - is_sd_printing()
2020-09-25 16:23:51,382 - octoprint.plugins.flashforge - DEBUG - write() called by thread comm.sending_thread
2020-09-25 16:23:51,387 - octoprint.plugins.flashforge - DEBUG - write() M119
I use Simplify 3D to slice, and the gcode files directly out of that always work if I load them via a usb flash drive at the unit directly.
The text was updated successfully, but these errors were encountered: