search

Mrnt / OctoPrint-FlashForge

OctoPrint plugin to support closed source printers from FlashForge, PowerSpec, Dremel
GNU General Public License v3.0
86 stars 12 forks source link

Add Dremel Digilab 3D45 support #9

Open powpingdone opened 4 years ago

powpingdone commented 4 years ago

Dremel Digilab 3D45 has a different printer ID than the "Dremel IdeaBuilder," add it in.

powpingdone commented 4 years ago

Do not pull yet, there is a issue with connection timing out.

Mrnt commented 4 years ago

Thanks for your help!

Where are the timeouts happening - connecting, while idle or while printing from SD? If you are doing this from the desktop and your computer goes to sleep I think that might kill the connection.

On the last rev I made some changes to the default settings to try and make it connect more reliably out the gate. But I think you need to have the two settings for "Temperature interval" be set to 2 or 3 (under "serial Connection">"Intervals & timeouts")

I am also working on a change to support direct printing (directly from OctoPrint instead only via upload to SD card and kicking off a print). While doing that I noticed that on long operations the printer needs to be polled even when the print queue is full or it drops the connection.

powpingdone commented 4 years ago

Tried to reconnect, and I got a Kernel Panic. Whoops. Upgrading the pi....

powpingdone commented 4 years ago

I do have the settings set to 2.

Mrnt commented 4 years ago

Which pi are you using? You may need to turn on debugging for the plugin and take a look at the log if you are not seeing anything useful in the Terminal tab

powpingdone commented 4 years ago

Yeah got another kernel panic. Pi 3. Sorry but I won't be able to debug it until Monday.

Mrnt commented 4 years ago

Maybe a damaged card? Try wiping and doing a clean install?

powpingdone commented 4 years ago

Kernel panic. Switched pis and sd cards. Something about Linux being unable to page memory? It does this every time I connect. Very strange error.

Mrnt commented 4 years ago

Are you using OctoPi or OctoPrint installed on top of something like Raspbian? If not OctoPi do you have other things installed (touch display, etc)? Any other OctoPrint plugins installed, enabled? Debugging enabled or disabled?

powpingdone commented 4 years ago

Using the octopi image with no other peripherals and nothing other than your plugin. Debugging disabled.

Mrnt commented 4 years ago

And no camera?

powpingdone commented 4 years ago

No camera.

Mrnt commented 4 years ago

Is it possible it is a corrupted/incomplete octopi download?

powpingdone commented 4 years ago

No, I used the same image on 2 other Pi's with regular Marlin printers attached

Mrnt commented 4 years ago

OK. Im a bit mystified. I just:

For you is it failing right when you tell it to connect to the printer? Are you using all default settings? Did you turn on debugging for the plugin? - if so can you get a clean octopi.log and upload it as a zip file?

powpingdone commented 4 years ago

I am using all default settings, with your suggestions. It fails after communicating with the printer. It will be giving me the timeout message, and then a kernel oops happens. Debugging hasn't been tried in depth, will be tried tomorrow.

powpingdone commented 4 years ago

Heres the logs. Also I checked the md5 hash on the zip, and everything was ok. dremellogs.zip

powpingdone commented 4 years ago

Upload to SD worked, and then it crashed the pi. The printer stopped shortly after.

powpingdone commented 4 years ago

Is there anything I could do to help debug?

Mrnt commented 4 years ago

Sorry for the delay and thanks for posting the logs. I'm taking a look at them and have a couple of ideas. Give me a day or two - I think I might make a special version for you to test with if that is ok with you.

Mrnt commented 4 years ago

A couple of things off the bat that may not be helping: 1) It looks like you are sending a file to print and connecting to the printer at the same time, you may need to let the connection establish first. 2) At the moment the plugin does not support printing except via uploading the file to the printer's SD card because the printer takes so long to respond when waiting for the extruders/bed to warm up or homing that either Octoprint considers the connection dead or the printer thinks the USB connection is no longer active because the host (ie Octoprint) hasn't sent anything (because Octoprint is blocked on sending print commands until it receives a response to the commands already sent, which won't happen until the printer starts printing when it reaches temp).

I almost have a solution for 2 but I am still in the process of testing/bug fixing.

powpingdone commented 4 years ago

Ah ok. How long does it usually take to connect? Because with your settings the pi times out when connecting. I'm ok with using a custom build and/or custom src.

Mrnt commented 4 years ago

Just to connect is typically instantaneous, but I think there is an issue right at that point for your printer where it fetches the status as part of completing the connection, returns something mangled to Octoprint which leads to Octoprint thinking it is still waiting for a response from the printer, triggering the timeout, etc.

powpingdone commented 4 years ago

Yeah I do remember it being very delayed when fetching temperatures.

Mrnt commented 4 years ago

After looking more closely at the libusb docs, it looks like I needed a bigger read buffer. Just pushed a new release to master with that fix and I think that may be causing at least some of your troubles. Please do an update on the plugin and let me know how it goes.

Mrnt commented 4 years ago

You will need to add your Dremel USB ID since I did not merge that yet

powpingdone commented 4 years ago

Gotcha. Will do that tomorrow as I don't have access to the printer right now.

powpingdone commented 4 years ago

octoprint.zip It connects properly, but times out during heating when attempting to print.

Mrnt commented 4 years ago

ok well thats progress! Are you uploading the file to the sd card via Octoprint and printing or printing from within Octoprint? Right now printing from Octoprint directly ie load file into Octoprint and printing will have timeout issues because the printer will just sit there saying nothing if the wait for heat up command (M109) has been sent until it heats up (likewise for homing), so Octoprint assumes the connection is dead and will timeout depending on the timeout settings. You could try increasing the "Communication timeout" under Settings>Serial Connection>Intervals and Timeouts and fiddling with the "Max. consecutive timeouts while printing" under the "Advanced" section on the same settings page. Like I mentioned above I am working on supporting this but I have no docs and its all based on reverse engineering by trial and error so it takes time...

powpingdone commented 4 years ago

Uploading from SD gives timeout issues, and the Pi is doing kernel panics and oops.

Mrnt commented 4 years ago

Oh. Can you send me a log of that, zipped up like before?

powpingdone commented 4 years ago

octoprintlog.zip

Mrnt commented 4 years ago

it looks like you are still using version 0.1.9 of the FlashForge plugin? 2020-02-11 00:08:42,883 - octoprint.plugin.core - INFO - 16 plugin(s) registered with the system: | Action Command Prompt Support (bundled) = /home/pi/oprint/lib/python2.7/site-packages/octoprint/plugins/action_command_prompt | Announcement Plugin (bundled) = /home/pi/oprint/lib/python2.7/site-packages/octoprint/plugins/announcements | !Anonymous Usage Tracking (bundled) = /home/pi/oprint/lib/python2.7/site-packages/octoprint/plugins/tracking | Application Keys Plugin (bundled) = /home/pi/oprint/lib/python2.7/site-packages/octoprint/plugins/appkeys | Backup & Restore (bundled) = /home/pi/oprint/lib/python2.7/site-packages/octoprint/plugins/backup | Core Wizard (bundled) = /home/pi/oprint/lib/python2.7/site-packages/octoprint/plugins/corewizard | Discovery (bundled) = /home/pi/oprint/lib/python2.7/site-packages/octoprint/plugins/discovery | Error Tracking (bundled) = /home/pi/oprint/lib/python2.7/site-packages/octoprint/plugins/errortracking | FlashForge Plugin (0.1.9) = /home/pi/oprint/local/lib/python2.7/site-packages/octoprint_flashforge

After updating the plugin you may need to restart OctoPrint

powpingdone commented 4 years ago

Well updating it seems to have stopped the kernel oops and panics, but it still isn't fully uploading via the print to sd. octologandgcode.zip

Mrnt commented 4 years ago

OK now it is connecting properly! If you did not do the SD upload you should be able to use the Temperature and Control tabs in Octoprint to control the printer. So it might be worth doing that just to verify they work. As far as the SD upload goes, the printer appears to not realize that the upload is complete (which is signaled by Octoprint sending the M29 command). Give me a little time to see if I can figure out why.

powpingdone commented 4 years ago

https://www.simplify3d.com/support/hardware-setup-guides/dremel/ something interesting I found on Simplify3D's site. I do have Simplify3D, but I don't and I know how to sniff usb.

Mrnt commented 4 years ago

It was possible to sniff USB traffic on OS X using the built in virtual USB port and capture/view the traffic using WireShark: https://www.umpah.net/how-to-sniff-usb-traffic-reverse-engineer-usb-device-interactions/ However, on the most recent updates to OS X they tightened security to the point where it becomes rather arduous to use the virtual port. I believe that you can capture USB traffic on the Raspberry (and Windows?) by using WireShark.

Re the last log you sent - did you slice that Benchy file using the Dremel Digilab or something else? I'm wondering whether there is something about the file that the printer does not like. I tried uploading it to my FlashForge printer and it also hung...

powpingdone commented 4 years ago

I use Linux on my laptop (specifically Manjaro if you're interested) so sniffing is pretty easy. I also use PrusaSlicer with a custom profile. It uses the start and end gcode straight from the program. It has these strange commands (M132, M907, G162) that I honestly have no idea what they do. I can try a Dremel Digilab sliced file tomorrow. It might also be the "semi-proprietary" .g3drem file format that it could need even though it can read and print GCode from USB. Heck, there is a setting for Prioritize GCode Settings which I don't understand yet or maybe a USB drive has to be plugged in.

Mrnt commented 4 years ago

On the FlashForge branded slicer it defaults to .gx files which are g-code but with a thumbnail image embedded in the top of the file. Needless to say OctoPrint does not like parsing those. However it also gives the option to save as a .g file which is just the g-code. Either format will usually upload directly to the SD card just fine (except if the SD card is full or corrupt). So take a look at the Dremel Digilab and see what file endings (.g, etc) it uses for the files and what is actually in them. It may just be the file ending is causing an issue.

Note - you may have to reformat the SD card if the printer has left a file on there that is unreadable - I had to do that. Also make sure there is sufficient room on the card...

If you are interested in looking at the log for yourself - in the case of the 3DBenchy.gcode SD upload you did it appeared to finish uploading, at which point the plugin sends the M29 command to indicate upload is complete:

2020-02-11 22:37:27,139 - octoprint.plugins.flashforge - DEBUG - FlashForge.writeraw() called by thread SD Uploader
2020-02-11 22:37:27,141 - octoprint.plugins.flashforge - DEBUG - Sent: 100.00% 4392546/4392546
2020-02-11 22:37:27,142 - octoprint.plugins.flashforge - DEBUG - FlashForge.sendcommand() M29
2020-02-11 22:37:27,143 - octoprint.plugins.flashforge - DEBUG - FlashForge.writeraw() called by thread SD Uploader
2020-02-11 22:37:27,144 - octoprint.plugins.flashforge - DEBUG - FlashForge.readraw() called by thread: SD Uploader, timeout: 10000
2020-02-11 22:37:29,762 - octoprint.plugins.flashforge - DEBUG - rewrite_gcode(): gcode:M105, cmd:M105
2020-02-11 22:37:32,764 - octoprint.plugins.flashforge - DEBUG - rewrite_gcode(): gcode:M105, cmd:M105
2020-02-11 22:37:35,768 - octoprint.plugins.flashforge - DEBUG - rewrite_gcode(): gcode:M105, cmd:M105
2020-02-11 22:37:37,146 - octoprint.plugins.flashforge - DEBUG - FlashForge.readraw() error: LIBUSB_ERROR_TIMEOUT [-7]

and the printer is supposed to respond with an OK, but instead the USB connection timed out, so the printer has apparently gone AWOL and the only thing I can think of is it is something about the file.

It should look something like this, with the M23 command being queued up to select the file and start a print:

2020-02-13 17:37:00,920 - octoprint.plugins.flashforge - DEBUG - FlashForge.sendcommand() M29
2020-02-13 17:37:00,920 - octoprint.plugins.flashforge - DEBUG - FlashForge.writeraw() called by thread SD Uploader
2020-02-13 17:37:00,933 - octoprint.plugins.flashforge - DEBUG - FlashForge.readraw() called by thread: SD Uploader, timeout: 10000
2020-02-13 17:37:00,977 - octoprint.plugins.flashforge - DEBUG - FlashForge.readraw() CMD M29 Received. | Done saving file. | ok | 
2020-02-13 17:37:00,977 - octoprint.plugins.flashforge - DEBUG - FlashForge.sendcommand() got an ok
2020-02-13 17:37:00,978 - octoprint.plugins.flashforge - DEBUG - rewrite_gcode(): gcode:M23, cmd:M23 1:/LatchDustbox.gx

I'm attaching a trivial g-code file generated by the FlashPrint slicer which I'm guessing might work for you. Square Sheet Test-4_FP_Drmr.g.zip

Mrnt commented 4 years ago

I've been meaning to document the g-code commands that I have identified so far since they do not all match up with the Marlin "standard". I'll try to do that when I get a chance.

powpingdone commented 4 years ago

That does make sense if it is timing out. It might mean that the printer needs a USB drive in it to "Upload To SD" even though it has internal storage. Also those .gx sound pretty similar to .g3drem.

Mrnt commented 4 years ago

It should be uploading to the internal microSD card by default. I can’t tell if there is also a separate external SD card slot on the 3D45 like some of the other printers - if so then, like a usb drive, that would be a different upload path, so it won't upload to a usb drive right now.

powpingdone commented 4 years ago

Discoveries: Simplify3D does not work with USB printing on the 3D45 on both Linux and Windows. Your sliced file did work from reading from the USB drive, but the Print to SD option failed just the same. The Dremel Digilab sliced file didn't work. Prioritize GCode settings doesn't work, and plugging in a USB doesn't seem to matter. Attempting to regularly upload and spam Fake Acknowledgement seems to work. Using 

M132 X Y Z A
M907 X100 Y100 Z50 A100
G1 Z50.00 F400
G92 E0
G1 F200 E3
G92 E0

as a starting GCode header "seems" to work after it has homed, but the LCD doesn't update with print status, and you still need to spam the fake acknow. Setting the temperature in the print header doesn't seem to work either.

Mrnt commented 4 years ago

Thats annoying. As a sanity check - are you able to upload a file direct to the internal SD card from the Dremel Digilab and have it start printing successfully?

powpingdone commented 4 years ago

From the software? No. Dremel Digilab is just a reskinned Cura. However you can "Copy To Printer" from a USB.

Mrnt commented 4 years ago

Oh thats interesting because FlashPrint (which FlashForge supplies for their printers) was also supposed to be a re-skinned Cura and does allow files to be uploaded direct to internal SD card (and immediate print).

The Dremel 3D45 manual contains this:

BUILD FROM COMPUTER Dremel 3D45 is compatible with Print Studio from Autodesk, Dremel's cloud-based platform, and will included plug-ins for Cura and Simplified 3D. Follow the instructions that came with this software to complete a Build from your computer.

Which is really ambiguous - not sure if that means it can only send prints direct to the machine via the cloud/network interface, though it does sort of sound like they are only supporting direct uploads/printing via the cloud/network interface and not USB.

powpingdone commented 4 years ago

*not via usb port but from USB flash drive. Also checking out print studio only lists support for the 3D20 and the 3D40, strangely. Just for clarification btw, yeah they support only cloud printing, or from a USB Flash Drive (not how I said "Copy To Printer", thats also from a flash drive.)

powpingdone commented 4 years ago

Looking at how the 3D45 sends back the M28/M29 cycle it actually sends back CMD M29. Still doesn't fix timeout, but maybe I implemented wrong.

Mrnt commented 4 years ago

So you were able to see a FlashForge.readraw() CMD M29 Received.? In the last log you uploaded it timed out waiting for that response.

powpingdone commented 4 years ago

I used the terminal and just gave it M28 with no filename or byte lengths. and then sent over G0 X0 Y0 and finally M29, to which it then replied not with "CMD_M28 sent" but "CMD_M29 sent".