Total Bytes Dremel 3D20

[jimprince]

While printing I have no estimated time on the printer LCD, which I suspect is related to the denominator of "SD Printing Bytes" as seen in the image above.

I'm running a new installation of Octoprint with a new install of this software done today.

[Mrnt]

Hah yes, thats interesting indeed! What is the actual size of the file?

Can you turn on debugging for the plugin (see Readme for instructions and picture) then take a look at octopi.log - it should be exactly the same, but worth checking.

[Mrnt]

BTW I just pushed a new release that should allow you to upload .3drem files if you want to test that also.

[jimprince]

It looks like when it is passing the file to the printer the size is okay but when it starts printing it's messed up. Log included. octoprint.log

I also tested upload .g3drem, .3drem and *.gdrem (same file, I just changed the extension) and they were grayed out in the selection windows in octoprint. The output from Cura is a g3drem file. I've attached a sample with a .txt extension b/c I don't know how to get you a gcode file through github (sorry, I'm new to this). D_Spacer.txt

Cheers

[Mrnt]

You are right about not recognizing the files. I mistakenly thought I could add file support after the printer was detected, so it would only allow files of the type supported by the connected printer but that will not work. It will have to always allow .g3drem

Are all three of these (.g3drem, .3drem and *.gdrem) valid file extensions? I only saw .g3drem as a an allowed option from the official Dremel software.

Still looking at the file size issue - does it wok correctly for smaller files?

[jimprince]

Doesn't work correctly for any of the smaller files I've printed either, they all just display a jibberish number.

G3drem is the only valid extension I am aware of. I was just checking to see if a typo had been made in the permissible files as your prior message had 3drem instead of g3drem. Wasn't sure where the typo originated.

Larger files cause the printer to crash (8MB). Should I open a separate issue for this? I can record a video once my current print finishes.

[jimprince]

My suspicion is that it has to do with the "estimated time" byte in the g3drem header as found here: https://github.com/timmehtimmeh/Cura-Dremel-3D20-Plugin/blob/master/plugins/Dremel3D20/G3DremHeader.py

Congrats on being added to the official repo, that's super cool!

[Mrnt]

Firstly, thanks for your donation - that was a super nice surprise since I just put the link up!

re the G3DremHeader plugin - I was wondering if it could be related. I was rather hoping that the plugin worked correctly because I was planning on looking at it for clues on how the header is formatted so I can parse the file in the plugin. It looks like the Dremel version of Cura - "Dremel Digilab 3D Slicer" does not allow you to save files with the image header (.g3drem) - it only supports .gcode?

BTW have you tried uploading a .gcode file (instead of a .g3drem) to the printer via the plugin to see if it reports that file print progress correctly?

[jimprince]

People who make useful things should be compensated, and this printer has been driving me crazy not being able to be connected to a network. I'm I student, so I don't have much, but hopefully now that you're on the repo you'll have some more love headed your way. :)

When I use the files exported from cura using the cura dremel plugin and print them from SD card I'm able to see the approximate time and a screenshot on the printer while printing. When I upload the same file via octoprint I don't have either one of them for some reason. Seems like it would be something with the header, but not sure why it wouldn't be sending.

Sorry I'm not more help on the coding side, but I appreciate your help working out the kinks!

[Mrnt]

To make sure I understand - you are able to transfer a file to SD card manually, plug it into the printer and the correct print progress appears on the printer screen but if you upload the same file via OctoPrint it does not display the correct progress in OctoPrint?

Can you try a couple of things:

1) Can you connect OctoPrint to the printer, then manually launch a print on the printer screen of one of the files you >manually< installed to the SD card. OctoPrint should detect that a print started and indicate in the Terminal window the progress in bytes done / total bytes - does it display something valid for the total bytes? If yes then the implication is that he file header is getting munged when it is uploaded via OctoPrint.

2) If (1) does not work - also attached is the file you uploaded without the header (ie just plain gcode) - if you try loading this to the printer via the "Upload to SD" button it should display progress in OctoPrint correctly - this will validate that there is not something strange about how the Dremel provides progress data over the USB connection.

D_Spacer.gcode.zip

[Sidewalkhorse]

Hello there. Managed to get the dreamer connected and printing (via upload to sd card) but as soon as the printer gets going it time-outs??? Is there a command that I need to delete. Though I’d sussed it for a minute 😩 - check attached image.

[Mrnt]

Ugh so close! Did you try to control the led while it was printing? All of the control commands (move, led, temp) will hang if the printer is busy and cause the connection to timeout. If that wasn’t it then can you upload the OctoPrint.log so I can take a look?

[Mrnt]

You should however be able to include led control (M146) into a Cura generated file by putting it in the pre or post print custom g-code sections of Cura’s printer configuration (or adding manually to the print file).

[timmehtimmeh]

@Mrnt - I finally got prompted to look into octoprint for the 3D20 & discovered your plugin. Awesome job! Reverse engineering the communication protocol is no small feat.

If you have any questions about the g3drem file format that isn't clear from the description or the code feel free to reach out.

I've added some instructions to the Cura Plugin 3D20 repo regarding how to modify the printer definition file that my plugin installs to enable printing from Cura using the Cura Dremel 3D20 plugin + the Cura Octoprint Connection plugin wirelessly to the 3D20. Just tested by printing a calibration cube using Octoprint 1.5.3 & FlashForge Plugin 0.2.6 - the print came out great, but I can verify as @ jimprince says that the screen didn't change while printing to show an estimated time or anything else. I'm pretty sure that cura uploaded gcode and not a .g3drem file (see screenshot below)

Again - great job & thanks for all your efforts on this.