Octoprint: [Brainstorming]Adding support for Dremel Idea Builder (i.e. FlashForge Dreamer)

[bbatchelder]

I own a Dremel Idea Builder. I'd really like to get OctoPrint to work with it. I am a software developer, but not much Python experience, and the OctoPrint codebase is entirely new to me...so I could use some guidance.

Dremel has provided me with a snippet of C++ code that demonstrates how to push a file to the SD card over USB and initiate printing.

A few things I am noticing at first glance:

• It looks like the Dremel is expecting a tilde (~) as a start character for each command.
• It looks like the Dremel is expecting a \r\n instead of just a \n
• It looks like the M28 command (load file to SD) expects a file size in addition to destination path (the M28 I see in util/comm.py is only sending a filename).
• It looks like the Dremel is expecting an "M601 S0" be sent prior to every command.

I am thinking that as a first step, I'll just pull the latest code and modify util/comm.py to do the above, and see if I get anywhere. If that goes poorly, I'll probably fall back to writing a proof of concept app in C# (the language I am most useful in).

Here is a Dropbox link to the C++ snippet I was given.

Here are some conversations I've found online that add some additional information:

Google Groups thread where some folks sniffed the commands being sent to do various things, including upgrading the firmware.

Simplify3D Forum thread where a user explains how they set up a firmware profile for the Dreamer, and mentions the requirement for M601 S0 and the tilde start delimiter. Though they mention the end delimiter being a single LF (and not the CR/LF I saw in the C++ snippet).

[bbatchelder]

I've got rudimentary communication with the printer working using pyusb/libusb. I'm now writing a plugin modeled after the GPX plugin that provides a serial factory for communication.

I'll keep plugging away at it.

[foosel]

That looks very interesting. I just had a look at the Google group thread you linked and it looks like the commands are sent without checksums and line numbers (which makes sense if the communication transport layer is reliable).

I was recently fiddling with the communication layer in OctoPrint to hunt down some bugs and noticed I was still missing a mechanism in there to disable checksum stuff altogether. Would it help to add something like that? It would be simple to add. An alternative serial implementation then would not have to strip that stuff again.

@markwal would that maybe be also interesting for the gpx plugin? I have to admit, I don't know if that uses line numbers oror not.

[markwal]

Yes, might be helpful since it'd save the time it takes to compute the checksum and for me to strip it back off again. I'd need to change some stuff around about how I figured out when printing has begun, but no problem really.

[bbatchelder]

@foosel I honestly don't know enough right now to know if that would help :-) I'm guessing if it would help @markwal it will help me.

Right now my biggest issue is having to make sure I send a "M601 S0" regularly (perhaps in front of every command) because otherwise the real commands are ignored. Which means I have to strip out the response to the M601, as OctoPrint won't know what to do with it. I have no idea why FlashForge would design it to work this way, to the point where I wonder if I am missing something.

Is there perhaps a better way to handle that (i.e. a way to get OctoPrint to want to send the M601 in front of every legit command, so that it will expect and handle the response)?

Additional issues:

• The M20 command to list SD card contents doesn't seem to actually bring anything back. I'm not sure if I am giving it the correct path, though. It has both onboard SD and a SD slot. Is there a standard for this? I've looked around but not found anything.
• When it comes time to upload a file to SD, it is expecting file size to be given as part of the M28 command. Is there a straightforward way to get that from OctoPrint?

Thanks for the help!

[foosel]

Just to make sure I understand that correctly, working communication looks something like this?

> M601
< ok
> some command
< ok
> M601
< ok
> some other command
< ok

Or rather this:

> M601 some command
< ok
> M601 some other command
< ok

M20 usually takes no parameters in "usual" printers. I'd try something like M20 /. If that works, your plugin could simply swap regular parameter less M20 with path including ones through a gcode queuing phase hook.

Same should work for the M28. If I'm not mistaken, at the time of this command being queued the current file should already be sent in the comm layer, that should have a size property you can access. Take a look at the startFileTransfer method in src/octoprint/util/comm.py. You could then also rewrite that command/add the size parameter with a queuing phase hook.

Take a look at http://docs.octoprint.org/en/master/plugins/hooks.html#octoprint-comm-protocol-gcode-phase

[bbatchelder]

Your first example. Here is a transcript of a session.

> M601 S0
< CMD M601 Received.
< Control Success.
< ok
< 
> M21
< CMD M21 Received.
<
< ok
<
> M601 S0
< CMD M601 Received.
< Control Success.
< ok
<
> M115
< CMD M115 Received.
<
< Machine Type: dremel 3d idea builder
< 
< Machine Name: DREMEL
<
< Firmware: v1.3 20150413
< 
< SN: 2d001a-33334714-37343030
<
< X: 230  Y: 150  Z: 140
<
< Tool Count: 1
< 
< ok
< 

I'll check out that link. Thanks!

[foosel]

Oh my deity, that is awful. That halves reachable transmission speeds. At least you have a full speed usb connection apparently so it shouldn't impact reachable quality, but I honestly have no idea what devil rode them to design that into the protocol O.o

That makes things more complex... Either you send an M601 for each sent line from your serial replacement, but then you'll also need to filter out every second ok that comes back pour stuff will get confused.

Or you turn every sending command into two via a hook (tricky for stuff like the rate limited M105 queries), but for that those first need to support returning multiple commands for one input command, which if I remember correctly is available in the devel branch but not maintenance.

[bbatchelder]

Yeah, it seems so braindead that I want to try and talk to an engineer at Dremel / Flashforge before going too far down this path. So far the Dremel folks have been very cooperative.

[steddyman]

I'm also an experienced developer (not a lot of python experience) with a FlashForge Dreamer and I too would like to get this working. Very happy to help collaborate or help on this one.

[bbatchelder]

Hey Stephen, I'm probably a week and half or so from having something ready to check in.

[steddyman]

Great. I am really look forward to checking it out. I have quite a bit of embedded systems development experience too so give me a shout if you need anything.

[steddyman]

Looking at the Machine Control Panel output from Simply3D it does not repeatedly send the M601 command prior to every command. Perhaps this is something unique to the Dremel which does not apply to the Dreamer. Also if I generate a gcode file for the Dreamer and look at it, it does not contain this command.

I am intrigued to know why the people who say that Octoprint doesn't support the Dreamer because it used non-standard protocols actually mean. Do you mean the GCODE is not standard or do you mean there is something different about the USB comms?

[markwal]

@steddyman non-standard means subtly different in many ways and generally undocumented though Dremel looks more cooperative than FlashForge.

To list a few off the top of my head:

1. It isn't using FTDI style serial. This is a good thing generally because it has a faster microcontroller and better pathways with more bandwidth. Problem is, undocumented yet different than all the RepRap printers out there.
2. It is using some g-code definitions that are reminiscent of MakerBot, but... once again unclear in totality which ones plus MakerBot and RepRap divided company some years ago and so things are different.
3. EEPROM settings for things like acceleration which look like they have internally (just going off of forum posts here), are no longer exposed via the protocol because they don't use x3g any more, but they didn't wire up any g-code instead (or if they did, they aren't telling anyone).
4. Other things I'm sure because it doesn't work with OctoPrint, Pronterface, Cura (as host) etc.

Really the burden is on FlashForge to describe the differences, not on the open source community to discover them all. But since they seem unwilling, it's up to people who actually own the devices to do all the reverse engineering because only people who actually have the device in front of them can do the reverse engineering.

[Cyphrz]

I may have a contact with dremel. (My company bought about 1,500 of them from dremel.)
Any questions you guys have that you want me to ask?

[steddyman]

Thanks, but not a lot clearer on this one.

So it isn't an FTDI chip, so what, it is still a serial protocol. It is implemented using the onboard STM microcontroller (which has hardware usb support) which is documented here:

http://www.st.com/web/en/catalog/tools/PF257882

Also, why does the open source community feel that FlashForge are trying to keep information from them? The full GCODE API documentation for the Dreamer is freely available on their website:

http://www.ff3dp.com/media/wysiwyg/Documents/Flashforge_Gcode_protocol_open_.zip

[markwal]

Ok. How about this way. They took open source licensed software changed it to be incompatible (it doesn't work) and in spite of the license requiring that if they redistribute the software in binary form they also have to produce the modified sources. They claim they rewrote the whole thing despite evidence to the contrary.

Plus, that documentation is minimal and just sufficient enough to notice that they've decided to be different for the sake of being different.

But the kicker is, you need a dev to make a shim. And that dev needs to both care (it has wifi already) and own one (so he can test). So if you're that dev, you should be able to answer the question yourself. If it already works, great, they made it compatible, if not, then you have work to do. I suspect you have work to do. Which is the point.

[steddyman]

Hi
Are you making any progress on this conversion?

[gretel]

@markwal i don't think that blaming some vendor will be beneficial for this project. lots of the printers are not-so-opensource but supported by octoprint nonetheless. 💵
@Cyphrz how about talking to marketing at dremel and let them discuss this issue with their engineers? 😏
@steddyman guess the 'partial' in regards to the documentation means that they don't document g-code in general, but the vendor-specific codes. 📚
@bbatchelder you have been working on something, did you commit anything yet? 👀

got a dreamer with firmware 2.4, a simplify3d license, and some engineering skills. so if applicable i'd be glad to help at some starting point. 👷

[markwal]

@gretel I know, I'm the one that did the work to support the FlashForge Creator Pro. I was just answering the question.

[gretel]

@markwal in comparison to the creator the dreamer has it's less open aspects, we can agree on that. btw, thanks for your work!

[jchristman75]

Any progress on this, or a repo where I play with the code, as it is?? thanks.

[foosel]

Just for some update on stuff that changed in OctoPrint that might maybe help:

• checkums/line numbers can be be disabled fully now via config.yaml (feature.neverSendChecksum) and
• 1.3.0+ allows configuration overlays by plugins through __plugin_settings_overlay__, so a plugin like the GPX plugin by @markwal or a FF Dreamer plugin could simply set this setting accordingly.

[slohmaier]

I made a small webapplication for monitoring and sending gcode commands to the Flashforge Dreamer using llibusb1. Although its nothing production ready: https://github.com/Noneus/FlaMo But I'm currently using it to monitor my Dreamer and send M25 if something obvious is going wrong on the webcam :)

With the stuff I learned there I want to make an OctoPrint Plugin: https://github.com/Noneus/Flocto

[KevinCathcart]

So just to clear up a few things.

The way the Dreamer and Idea Builder, and other new FlashForge models (like the Finder, or the Guider) works is as follows:

All gcode commands over usb or wifi must be preceded ~ and must be followed by "\r\n".

When you first start communicating, you use "~M601 S0" This makes the system start to listen to commands on the USB port. (It looks like "S1" is needed when communicating over Wifi) It replies with "Control Success." (and the normal "ok", of course). It is absolutely not necessary to resend this command with every new command. However the connection times out if idle for more than 5-8 seconds. Idle here means that nothing has been sent. That fact that you are waiting on an "ok" does not make you non-idle. A simple wait-to-reach-temperature command will time out under the simplistic precede each command with "~M601 S0" approach.

When you time out you get back "Control Released" followed by "ok" just like you sent a command to close the connection. This means the simplistic approach would wrongly think the temperature was reached when it was just a timeout. The reason for this weird behavior has to due with the printer's unusual command buffering system.

These printers use a command buffer on the printer side. However this command queue is very different than any others. First all all all commands can be buffered except emergency stop and the commands that return information. When you send any command you get back "CMD __ Received." For any bufferable command, once you get the received message you may immediately send the next command. Well except when you get back "buffer full" along with the received command. In that case you must now wait for some of the "ok"s to come back from the buffered commands.

While the buffer is full you can continue to send the unbuffered commands like "M105" or "M114". Obviously you want to parse the outputs of these commands all the way to the "ok" line. That said, I'm pretty sure it is possible that the ok line from one of the buffered commands will appear after you send the "M105" and before you get the result back from M105, so you need to handle that right. I suspect it is guaranteed that the output for these informational commands will immediately follow their "CMD M___ Received." lines so you know to parse from that line through to the "ok".

The fact that you can always send the status query commands at any time (except perhaps during uploading of a file) is why the timeout is so short. The flashprint software will query at least once a second.

These printers are really designed to only use the usb cable for uploading gcode to the sd, monitoring status of prints, and manual jogging etc. The printer will let you start a print from an sd card while printing via usb! So the whole premise of using OctoPrint is certainly not a a designed scenario. If after reading all the above anybody still wants to try to make this work, I've added some additional important things to note below:

Some special notes: "~M23 0:/user/filename.g" selects and starts printing. There is no need to send M24 to start the print (but doing so should be harmless. )

Yes that path does have a numeric drive-letter like syntax, which i guess is intended to allow addressing a plugged in usb stick too, using "1:", but I've not tested that at all, and it may not be implemented. (The command does seem to work fine for the main card if you leave off that "0:"). Also all gcode added to the built-in sd card should be placed in the /user/ folder, so it can be seen in the printer's gui.

Listing files from the sd card does not seem to be possible. Deleting files from the sd card does not appear to be possible.

The wait for hot-ends to reach temperature command is "M6". Command "M7" is the same but for the bed temperature. Both default to a 600 second time limit. It is not immediately clear if M119 is supported. It is certain not used by the flashforge slicer.

Hope somebody finds this useful or at least interesting.

[jchristman75]

Thanks Noneus. I will have to tinker with this. I have a PowerSpec Ultra printer, which is uses the Dreamer firmware. The vendor ID is still FlashForge, but the device ID is 0x00ff, rather then 0x0001.

In any case, I was able to connect to the printer as a preliminary test. I would love to get this working in Octo.. Thanks for the great work. I will see if I can figure this out enough to give you a hand.

[edit - typo]

[robottwo]

Home Depot is selling the Dremel for 50% off to clear their store inventory. I just picked one up, and very excited to see a working version of the plugin, when available.

[jchristman75]

@bbatchelder, did you ever get any code checked in? Can I see what you have? I want to start digging into this, but really have not made any headway yet. Thanks.

[jchristman75]

@foosel, or anyone, Is there any good examples or tutorials of how I could allow connecting to a libusb connected device like this, rather than requiring serial? I tried serial factory with auto, but the factory is never called because it seems to error out before that attempting to find a COM port. Thanks for any assistance.

Really all I need is the starting point.

[foosel]

@jchristman75 A full stack trace of that "error out" part might help us to help you there :) In any case, the serial factory would in fact be the way to go about this. You'd need to create your own serial_obj in case your libusb connection doesn't provide the required interface on its connection objects.

The relevant bits in OctoPrint's comm layer are here. An example of how that can be utilized is the virtual printer and the gpx plugin.

[jchristman75]

Sorry "Error out" was vague. The error is "Error: Failed to autodetect serial port, please set it manually."

I guess the bigger question is how to get a port listed, that my plugin can listen for. The code you sent, shows the problem. Auto, is not the selection to use, because it returns None before it gets to the serial factories, if it can't detect the com port.

The virtual printer, show that the base code of OctoPi is specifically modified to add the virtual printer.
here.
I tried adding "dreamer" to the additional ports, configuration page, without any success. I am certain I am just missing a small step here.

---

I can see Octo register my plugin

| Flashforge Dreamer (0.1.0) = /home/pi/.octoprint/plugins/dreamer

But it never calls my serial factory, when I try to connect; it just throws the auto error. This is corroborated by the code in comm.py

    def serial_factory(self, comm, port, baudrate, timeout, *args, **kwargs):
        self._logger.info("Connecting to dreamer.")

I did register the hook:

        __plugin_hooks__ = {
                "octoprint.comm.transport.serial.factory": plugin.serial_factory
            }   

[foosel]

Ah, of course, that makes sense then. The problem is that you'll only get ports there that are actually existing on the system. The ports don't have to actually be serial device files however - if your printer gets detected as /dev/usb/someid, that should also work as pattern in the additional ports. You could also create a udev rule that takes care of a readable name. But it is necessary for now to actually have a device file to match the potential list of ports against.

The virtual printer was kind of a hack there which I still have to clean up. I guess it's time to allow plugins to also add entries that are not actual device files to that drop down, maybe even directly associating them with potential factories.

[jchristman75]

@foosel, Thank you.. I saw your recent YouTube video, and saw that you have Patreon, So I signed up to help. Thanks for the great work!

[thotil]

Would be willing to give some funds to get Flashforge Dreamer supported.

[jchristman75]

If I have time, perhaps I will mock something up in OctoPrint. I really love the tool, and I think we have just a small gap here. I expect a few more hooks will be all it takes. A hook to add a port to the list, if the device is available, Another hook to handle the com open method, make sure it is happy, and termincate the open method before it attempts to directly open the port. These methods would inform the caller that they handled the request, so it can take the correct action.

You could even limit the calling of these hooks to the plugin that registers a port name. e.g. my plugin can register a port "Flashforge Dreamer". Then when that port is selected, it will either directly call the registered handler of the that port, for all hooks, or it exclude it when that port is not selected; so it will non-interfering.

Then the serial factory may all that is needed after that. Does that make sense?

Personally, at this point, I am ready to hack my install so that it will only work with the Dreamer, but I would rather design it the most flexible and reusable way.

I have a feeling that more and more printers will start showing up with proprietary connections. With a new API for handling this, the vendors would even be able to create an officially supported plugin; but also enthusiasts, like myself, can make it work. I upgraded from an original FF to the Dreamer, and thought I could just plug it into my existing Octo. It was very disappointing when that did not work. I loved my original FF, and a lot of that was OctoPrint.

[markwal]

You can already do all that with the current plugin architecture. You can add a custom port to the list, you can intercept when a connection is made with that port and do something else and you can not take over if you don't see the port you want. There is no hard association from a hook to a port nor a defined priority order for the hook, but presumably a user with this printer will only have at most two serial hook's defined: the dreamer one and the virtual one. The virtual serial hook does exactly what you describe, it adds "VIRTUAL" as a port and if it sees "VIRTUAL" as the port name it takes over.

I think this plugin wouldn't be that hard, I just can't sign up for it because I can't even try it (no Dreamer).

[jchristman75]

Mark, can you show me a quick plugin that will add a port (other than virtual, that doesn't exist in /dev/)?, So basically, this can be tested with no printer. I just want a starter plugin that will get me to the point of loading the serial factory.

If I can get the serial factory to load, I am certain I can make the rest of the plugin, by looking over the wonderful work you have done. Like I said, my first printer was a FF, so I am familiar with your GPX plugin.

[markwal]

Do you want it to exist in /dev? You don't really need to, but you can call your port /dev/dreamer, if you like. You put /dev/dreamer in the additional ports list and since OctoPrint uses that as a glob pattern on the file system, you can just create the file via the command line.

sudo touch /dev/dreamer

Of course, for a plugin, you might actually want the path to be something writable by the plugin so it can make the 0 byte file, but it doesn't actually have to be in dev since you aren't going to use it for anything, just as a token to know when to let your serial hook kick in (when the serial hook gets called with that name). The GPX plugin looks at the port name to avoid trying to do AUTO and VIRTUAL, but you can reverse the sense of the comparisons.

But since you're just using it as a token to check for and all you need is for it to exist in the file system, you could use the actual device that the Dremel shows up as in the tree and look for that. GPX basically assumes that whatever you pass it that isn't AUTO or VIRTUAL is meant for it whether it really is or not. I made that assumption because why else would you install it. :-)

As an aside, the Redeem firmware uses a socat connection to emulate a serial port (there's no serial communication happening since Redeem is just another process on the Pi), so it doesn't even need or use the serial hook. OctoPrint opens up what it thinks is a serial port, but it's just talking to the Redeem process. You might be able to wire socat up from a tty looking thing to a network protocol and talk to the Dreamer via wifi even. But I'm probably being distracting, if the goal is USB printing, the serial_hook will be easier.

[jchristman75]

Mark, thanks for the tip.. I am not that experienced with POSIX. I forgot that everything is a file; duh.

Thank you so much for the tips. You are great help. Thank you

[jchristman75]

@markwal, You are awesome! you got me over my first big hurdle. Added to tmp, for a quick test. I guess I need to write the rest of the plug-in now.. 😄

[thotil]

@jchristman75, really hope you can solve this mate! :D good luck!

[pmwoodward3]

Any updates? I would love to get my Flashforge finder working :)

[jchristman75]

I have been able to make a plugin that will connect the dreamer, monitor, and control it, such as setting temperatures and manual movement.

However, printing is a different beast. It seems like it only wants to print from SD, or really the hard drive. This alone is not a problem, but it also doesn't seem to support listing the contents of the SD/HDD. M20 just returns "ok". Perhaps there is a magic parameter set to make it work, but I haven't found it.

If you send it a command, that it doesn't like, it will just drop the connection and stop talking until you initiate communication again. Also, some commands seem to make it angry, and it will not communicate (or will only partially communicate), until you power-cycle the printer.

The subset of supported gcode is pretty small, however it is larger than the set they publish.

The method that Simply3D takes, is to send the gcode and name it temp.g (M28/M29). Since it knows the path (as it just sent it) can can request a print of that (M23). Then it periodically sends M119 to get the status, M105 for temps, and M27 to determine the progress of the print.

So far this doesn't really fit well with the OctoPrint paradigm, so I have been developing and testing in a separate app, so I can get a better handle on the conversation.

In the end I may have to emulate the SD listing functionality to make Octo happy, and just not allow direct printing. But I think it would be clunky to require uploading to SD everytime, then printing from SD each time.

What would be useful, and I have not investigated, is if I can intercept a local print attempt, get the requested file, abort the local print, send the file to SD, and print from SD, as a single operation.

[thotil]

@jchristman75 Sounds like you have solved a lot. If I understand you correctly you can now monitor your temps, status and time left?

[jchristman75]

Hmm.. Have not tried monitoring a print; guess I should try that. I can monitor it while idle. Like, if I set the temperature, I can watch the temperature rise on the graph. When it failed to fit in the pattern, I left octo for a standalone app, that I am still tinkering with.

[greatjava]

@jchristman75 dittos to what others have said. Thanks for figuring a lot of this out. Anyone using the dreamer based firmware (new Finder, some Qidi, Dremel, and Prospec lines) would all benefit. Happy to brainstorm if need another set of eyes. Been watching how S3D does it and doesn't really fit the Octoprint model because the file is transferred for print, not really controlled realtime like Octoprint would normally do. Even a standalone web application that you could upload a file to (flashprint can mess with them after you load a sliced file) and monitor an attached webcam, and get status of print from a tablet or phone would be really valuable even as standalone app.

[jvpernis]

It seems like it only wants to print from SD, or really the hard drive.

In the end I may have to emulate the SD listing functionality to make Octo happy

How about emulating the SD card entirely using a Raspberry Pi? I think it should be possible to modify the code from this project to work on the Pi.

The project uses FatFs to handle the file structure and SPI to communicate the raw blocks with the SD card host.

I'd figure this solution would be kind of hacky and really only useful for OctoPi, but hey, if it means that we're able to use OctoPrint for the Flashforge Dreamer...

I'd be down with that!

[pmwoodward3]

Any updates?

[jumpingmushroom]

I'm also curious about any updates on this. Using Octoprint for time-lapse and statistics on my flashforge finder would be amazing, to say the least. I've got a bit of technical know-how and I'll gladly help out where I can.

[chrisgwilliams]

Any update on this? I'm considering buying a Dremel DigiLab 3D40 printer, and wanted to make sure I could continue using OctoPrint.

[foosel]

Just for the record: No updates from my side, no such printer, no way to look into this, and admittedly hands way too full already in any case.

But keeping my fingers crossed someone will have a break through here. 🤞

[doublemind]

@Gina: I could provide a 3d20 for testing.

[foosel]

@doublemind that would still leave "and admittedly hands way too full already in any case" ;)

[greatjava]

@bbatchelder Do you still have that C++ example, the link isn't working. In Python I was able to connect via wifi and send it code one line at a time to do some simple extrusions without sending a file (basically the start code in S3D) but would like to see their example. As mentioned above the buffering is odd and sometimes just stops talking back.

[jchristman75]

Yeah.. I gave up on the Dreamer. I am actually in the middle of a brain transplant to replace the dreamer Mobo with a RAMPs board. I do a little each day. That is how much I miss octo. Octo is now a prerequisite of any printer. It should be listed on the spec sheet.

[greatjava]

Can't disagree and thought same... But I'd be happy if I could just export from S3D to a folder and have it kick off the print over wifi. I think I can pretty easily do that in Python but for some reason my code to send a file isn't working right (I setup a proxy to see PowerSpec send a file and not sure what I'm doing differently). Have any code you completed for an upload you could share?

[richardofortune]

I'm in the same boat - I wasn't looking for another hardware project - but octo is too useful at this stage...

[greatjava]

I’ve been able to upload/print, and monitor from python code - any partial plugin work anyone has they could post? I don’t think a real time print from OctoPrint would be an option but potentially depending on the plugin model we could still launch and monitor the print.

[Ryan12439]

Is anybody still working on this?

[Jack-Dark]

I hope so. 3D Printer OS managed to get the Flashforge Dreamer working: https://www.3dprinteros.com/supported-3d-printers/

Unfortunately, it doesn't yet support the PowerSpec Ultra clone (which I have). I'm still watching this intently though. Would be very happy to use this in the future.

[Ryan12439]

Yes, It works with my Dremel 3d20 too, which I was watching this forum for.

[Jack-Dark]

Good news! 3DPrinterOS managed to support the PowerSpec Ultra too! It's not currently on their list of supported printers, but it works!

Long overdue edit: I’ve used it a bit now and it works pretty well, but there’s a bug that multiple people have reported both with the PowerSpec Ultra printer and others where the print will fail, but the entire printer will lock up and maintain temperature directly on the print. This is obviously a pretty significant safety hazard, so I’ve stopped using it.

[dontcrash]

Any updates? I have a FlashForge Finder, I'm quite familiar with AVR chips, serial communication etc.
I can test things out if you need help

[dontcrash]

3DPrinterOS Support the Finder/Dreamer fully now, it's open source also, not familiar with OctoPrint but now we know it's feasible

[pmwoodward3]

Any link to that? I couldn't find anything in a quick search about it being
open source now.

On Thu, Sep 20, 2018, 7:36 AM Nick [e-mail] wrote:

3DPrinterOS Support the Finder/Dreamer fully now, it's OpenSource, not
familiar with OctoPrint but now we know it's feasible

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/foosel/OctoPrint/issues/1263#issuecomment-423151020,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABbE2UmYQEPc8jwzyVRjnj3xrtDc7alMks5uc33bgaJpZM4HrLAf
.

[dontcrash]

https://www.3dprinteros.com/open-source-cloud-client-for-3d-printers/

[dontcrash]

Works for my Finder perfectly

[foosel]

Quoting that page:

The cloud client is available now on Github.

Clicking the link though yields a 404. And looking at their github profile I sadly also don't see anything that might match (I did spot an OctoPrint plugin though and had to chuckle). So - not open source after all from the looks of it. Too bad, the source of an existing implementation could have really helped the people in this thread here.

[dontcrash]

They do offer a raspberry pi image, I’m sure it would be possible to extract code from it:

https://builds.3dprinteros.com/3DPrinterOSdev_new.zip

[dontcrash]

It appears to by Python

https://client-cdn-3dprinteros.azureedge.net/releases/3DPrinterOS_Client_6.0.15.104_dev.zip

[pmwoodward3]

Would it be legal to use code pulled from the image? What's their license?

On Thu, Sep 20, 2018, 8:33 AM Nick [e-mail] wrote:

They do offer a raspberry pi image, I’m sure it would be possible to
extract code from it:

https://builds.3dprinteros.com/3DPrinterOSdev_new.zip

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/foosel/OctoPrint/issues/1263#issuecomment-423165777,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABbE2brRhFJ4QovdRxDRpIT24g-bcQ0oks5uc4sNgaJpZM4HrLAf
.

[dontcrash]

GNU AFFERO GENERAL PUBLIC LICENSE

Is what they state on their site

[pmwoodward3]

Perfect, that should mean it's all good to pull the code out right?

On Thu, Sep 20, 2018, 8:36 AM Nick [e-mail] wrote:

GNU AFFERO GENERAL PUBLIC LICENSE

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/foosel/OctoPrint/issues/1263#issuecomment-423166521,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABbE2SOaMSxnklBpp7PhvIRx18EQ-ooXks5uc4u1gaJpZM4HrLAf
.

[dontcrash]

I don’t see it as an issue, plus it’s not like you’d just copy paste it all, you’d just look at how they’re doing it and understand and write your own implementation.

If I wrote some basic C code co calculate 10+10 (let’s assume you didn’t know how to get the sum) and you wrote it in Python based on my code, there’s nothing illegal about that?
At least that’s the rudimentary way I understand the matter.

[foosel]

This is getting a bit off topic but...

If I wrote some basic C code co calculate 10+10 (let’s assume you didn’t know how to get the sum) and you wrote it in Python based on my code, there’s nothing illegal about that?
At least that’s the rudimentary way I understand the matter.

Actually, that's a bit of a grey area and not fully agreed upon, which is why in such a case it is usually preferable to find someone who looks at the implementation in question and who then verbally explains what was being done to another person who then reimplements it. That way only the idea is transferred, no way to compromise the new implementation with detailed knowledge about the old one.

And in the case of this image zip, it would only be legal if the GNU AGPL license file was actually also attached to the actual files on there. You can't rely on these being sources licensed under this license just because a post somewhere on the internet from the vendor says so about undisclosed sources since you can't test that they are in fact the same code base. And checking the README in the zip in fact shows this:

License

Copyright 3D Control Systems, Inc. All Rights Reserved 2017-2019. Built in San Francisco.

This software is distributed under commercial non-GPL license for personal, educational,
corporate or any other use. The software as a whole or any parts of that are prohibited
for distribution and/or use without obtaining license from 3D Control Systems, Inc.

If you do not have the license to use this software, please delete all software files
immediately and contact sales to obtain the license: [email protected].
If you are unsure about the licensing please contact directly our sales: [email protected].

which isn't even remotely the AGPL and probably also GPL incompatible.

So better tread carefully here.

[Jack-Dark]

I should have edited my original post about 3DPrinterOs months ago (done now). I used it for a while, and it works pretty well, there’s a bug that multiple people have reported both with the PowerSpec Ultra printer (Flashforge Dreamer clone) and others where the print will fail, but the entire printer will lock up and maintain temperature directly on the print. This is obviously a pretty significant safety hazard, so I’ve stopped using it.

I'm looking forward to when OctoPrint hopefully supports this printer.

[pmwoodward3]

I also have had that happen on my finder using stock firmware and software
if it makes any difference. Recently it just fails and turns off, which I
guess is a little better.

On Thu, Sep 20, 2018, 9:58 AM Jack-Dark [e-mail] wrote:

I should have edited my original post about 3DPrinterOs months ago (done
now). I used it for a while, and it works pretty well, there’s a bug that
multiple people have reported both with the PowerSpec Ultra printer
(Flashforge Dreamer clone) and others where the print will fail, but the
entire printer will lock up and maintain temperature directly on the print.
This is obviously a pretty significant safety hazard, so I’ve stopped using
it.

I'm looking forward to when OctoPrint hopefully supports this printer.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/foosel/OctoPrint/issues/1263#issuecomment-423193575,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABbE2ZCzQp0Pf9JhyVD6n6rvFO7dXdRHks5uc58TgaJpZM4HrLAf
.

[unk1nd]

Have a Flashforce Finder that I want to use with octoprint.
Can contribute to the code base and test stuff out on my printer if needed.

[jameskf99]

Hello! Just checking in to see if any one has any progress on getting Octoprint to work on a Dremel Idea Builder 3D20.

[GeirFrimann]

Any news? I really need actoprint working on a Flashforge Dreamer..

[princeofgonville]

Yes please, any news would be welcome, either on Octoprint for 3D20, or brain-transplainting a 3D20, or anything else that makes slicing easier. Thanks.

[RobWinnie]

Would love an update, would love to connect my Finder to Octoprint.

[Ryan12439]

It's been over three years since this thread was opened, has any progress been made lately? @foosel Is this built in or can we expect support anytime soon?

[foosel]

To quote myself:

Just for the record: No updates from my side, no such printer, no way to look into this, and admittedly hands way too full already in any case.

But keeping my fingers crossed someone will have a break through here. 🤞

[jchristman75]

When I was investigating this, I was able to issue simple commands, like moves, but it doesn't seem to like tethered printing. The best (or perhaps only) way to print is to send the file to the printers storage, request a print, then loop monitoring the progress. This is the method that Simply3D takes, and works. The Catch-22, is that the printer's storage is a black-hole and doesn't act like SD; I think it may be write-only via the interface. I found this method didn't really fit the printing model of OctoPrint, so I gave up.

[bbatchelder]

Hey folks. Not too long after my last comment here, I had some things come up in life that took away most of my free time and completely away from 3d printing.

I actually just dusted off my 3D20 for the first time in over 2 years. Happy to say it still works really well.

Anyways, given the above, I have no made any progress, though I see others have. I did see a request for the files that Dremel/Bosch sent me, and have attached them here.

Dremel 3d printer code.zip

[johnpdowling]

@jchristman75 Do you have a repo or notes of your octo plugin work done so far? Right now the manual upload -> request print -> monitor workflow would be a great starting point.

[Mrnt]

Thanks to the work by @Noneus and notes from @bbatchelder along with studying Wireshark, I made a plugin that supports basic communication with FlashForge printers https://github.com/Mrnt/OctoPrint-FlashForge
It's just a start but I have been able to use it to connect to a Dreamer and a Powerspec Ultra and control temps, position, etc. I started implementing upload to SD card using the new hook from @foosel but I'm struggling a bit with how to do it, in part because I'm new to OctoPrint but also a Python noob.
Hoping to get some feedback on SD upload and/or make this a starting point for someone else.

[bbatchelder]

Very cool! I suspect you will find some of what you need to upload to SD and print in the dremel_sender.py file from the 3DPrinterOS client zip file @dontcrash attached above.

I wish I had the time to play with this code. I will try and get an instance of OctoPrint up and running attached to my Dremel 3D20 so I can at least assist in testing.

[dontcrash]

I heard my name and have been summoned.

I possess a FlashForge Finder if you need someone to test.

[slohmaier]

I will try @bbatchelder 's plugin. For SD Upload I bought a Flashair Card and I use a forked python script to upload gcode files after slicing in Simplify3D: https://github.com/Noneus/s3d-to-flashair

[thomazff]

Anyone got this to monitor prints? I can't connect octoprint to the my flashforge finder. I aim to start prints from flashprint or another windows slicer and monitor my prints away from home with webcam, so I can shutdown the printer if anything goes wrong.
Tried the Octoprint-Flashforge plugin, but can't make this connection work.

Terminal inside octoprint gives this error
Changing monitoring state from "Offline" to "Error: Connection error, see Terminal tab"
Unexpected error while connecting to serial port: AUTO ImportError: 'No FlashForge Printer found (0)' @ comm.py:_openSerial:2611 (hook flashforge)

Edit: I got most of what I want from polar cloud. Pluged webcam directly to the Finder, and I can monitor and give commands to the printer, but the web interface is crap on mobile. If they had an app, all would be good.

Edit 2: After successfully installing LIBUSB1, the message changed from "No module named usb1" to "No FlashForge Printer found (0)". Updated this info in to the original message.

[marcboivin]

You can’t start from one program and monitor from another. The usb
connection is exclusive. You would need to slice, export gcode, upload to
Octoprint and start print from octoprint. Otherwise you won’t be able to
send command to stop/pause the print in case of failiure.

On Sat, Jul 20, 2019 at 10:19 AM thomazff [e-mail] wrote:

Anyone got this to monitor prints? I can't connect octoprint to the my
flashforge finder. I aim to start prints from flashprint or another windows
slicer and monitor my prints away from home with webcam, so I can shutdown
the printer if anything goes wrong.
Tried the Octoprint-Flashforge plugin, but can't make this connection work.

Terminal inside octoprint gives this error
Changing monitoring state from "Offline" to "Error: Connection error, see
Terminal tab"
Unexpected error while connecting to serial port: AUTO ImportError: 'No
module named usb1' @ comm.py:_openSerial:2611 (hook flashforge)

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/foosel/OctoPrint/issues/1263?email_source=notifications&email_token=AABRL54U5O2KYO37EV2ZS2LQAMNHRA5CNFSM4B5MWAP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2NPH2Q#issuecomment-513471466,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABRL56OGJQNRCF4JCWFA6LQAMNHRANCNFSM4B5MWAPQ
.

[Mrnt]

@marcboivin I am not sure that is completely true. Flashprint uploads to the sd card then triggers a print. You can disconnect Flashprint and reconnect so I believe you could connect with Octoprint after launching a print from Flashprint and then disconnecting it.

[thomazff]

I am able to send commands after print started from Flashprint + WIFI and from files inside de Finder internal memory. Commands were sent from 3dprinteros website (when RPi3 connected to Finder), from Polar Cloud website (Finder has Polar functionality from inside the printer). I believe this is not a problem in this case. My maind goal is just to have an app (web versions are plenty but cumbersome) to check on live view of the printing and the ability to stop if a problem happens. Octoprint would be the best option for this. All I need now is to connect to the printer, something that has been done by others.

[Mrnt]

@thomazff you are just using a flash forge finder?

[thomazff]

@thomazff you are just using a flash forge finder?

Yes

[unk1nd]

Great work guys!

Have a finder as well and I will be testing out and see if there is something I can contribute with since I have programming background.

[thomazff]

@Mrnt how can I add, or change, another deviceID

Finder has a deviceID 0x0007

[Mrnt]

@thomazff I've been making some changes (upload to SD card and kick off a print, autodetect printer model) but have not committed them yet. Meanwhile if you want to try and talk to the Finder, then in octoprint_flashforge/flashforge.py change:
self.deviceid = 0x0001 # Dreamer # self.deviceid = 0x00ff # PowerSpec Ultra
to
#self.deviceid = 0x0001 # Dreamer self.deviceid = 0x0007 #Finder # self.deviceid = 0x00ff # PowerSpec Ultra

[thomazff]

@thomazff I've been making some changes (upload to SD card and kick off a print, autodetect printer model) but have not committed them yet. Meanwhile if you want to try and talk to the Finder, then in octoprint_flashforge/flashforge.py change:
self.deviceid = 0x0001 # Dreamer # self.deviceid = 0x00ff # PowerSpec Ultra
to
#self.deviceid = 0x0001 # Dreamer self.deviceid = 0x0007 #Finder # self.deviceid = 0x00ff # PowerSpec Ultra

Had just made almost that. I replaced the Dreamer for the Finder. But I just get this

With GPX
Unexpected error while connecting to serial port: AUTO IOError: 'GPX plugin not able to discover AUTO port and/or baudrate. Please choose specific values for them.' @ comm.py:_openSerial:2611 (hook GPX)

Without GPX
Changing monitoring state from "Offline" to "Detecting serial port"
Serial port list: []
Changing monitoring state from "Detecting serial port" to "Error: Failed to autodetect serial port, please set it manually."
Failed to autodetect serial port, please set it manually.

[Mrnt]

Try turning the GPX plugin off in the Settings/Plugin Manager - I was testing with it off.

[Mrnt]

@thomazff Sorry, I see you tried that. Did you make sure the FlashForge plugin was enabled, does not have a typo after your change causing a syntax error, etc? There are a bunch of log messages in the code so if you turn on debugging (Settings/Logging) for octoprint.plugins.flashforge and set to "DEBUG" it might help.

[Mrnt]

@thomazff I've uploaded a new version that should support the Finder if you want to take a look.

[thomazff]

@thomazff I've uploaded a new version that should support the Finder if you want to take a look.

Thanks for the support.

Now gives the following error

Unexpected error while connecting to serial port: AUTO USBErrorAccess: 'LIBUSB_ERROR_ACCESS [-3]' @ comm.py:_openSerial:2611 (hook flashforge)

[Mrnt]

@thomazff sorry for the delay been a bit busy but should hopefully have more time now. It looks like a permission issue - are you running Octoprint on a Linux? I saw this which may be relevant: https://github.com/vpelletier/python-libusb1/issues/34

[Mrnt]

@thomazff I finally set up OctoPi (which is painfully slow for me on a Pi B 1 or 2), previously I was using my desktop as I was in "proof of concept" mode. It looks like OctoPi/Octoprint on Linux does not automatically have permission to access the USB interface of the printer, which caused the connection to fail with LIBUSB_ERROR_ACCESS and before getting any useful feedback about the device in the logs.
As of 0.1.3 it should now throw an error when trying to connect in the case of a permissions problem and indicate that a udev rule needs to be created with instructions on what the rule should be and where it should be created.

[unk1nd]

Is there a repo for the current work for the plugin I can contribute to?

[Mrnt]

@unk1nd Yes! Please feel free to help/contribute/report issues: https://github.com/Mrnt/OctoPrint-FlashForge

[jimprince]

@Mrnt Just as an FYI, your link as typed is correct but clicking on it takes you somewhere else. the corrected hyperlink is: https://github.com/Mrnt/OctoPrint-FlashForge. Thanks for posting the link, it led me where I needed to go. :)

[Mrnt]

@jimprince Thanks for that!

Most recent release OctoPrint-FlashForge (v0.1.15) addresses an issue with not being able to connect to printer after it is recognized (or not uploading to SD card after connecting to the printer), due to the USB endpoints being hard coded which I think may have been an issue for someone on this thread.

Plugin should be able to connect and upload SD on FlashForge Dreamer, Finder V1 & V2 and PowerSpec Ultra but I need testers for Dremel and newer FlashForge printers.

[jimprince]

I’ve got a Dremel 3D20 and am just getting stuff setup today, I’ll report what I find.

[jimprince]

Dremel 3D20 is able to connect and upload normal Gcode to SD, after which the print starts itself. The estimated time remaining shows something non-sensical, but this is very functional for me. I did not need to install the Dremel 3D20 software in Cura or export to *gdrem format which is my process when I save to SD locally and then walk the card to the printer. I was unable to upload gdrem files, which is just as well as I'll probably stop using the SD to transport now. I did try the normal "upload" button the first time because, well I don't really know why. I guess just to see what happened. The printer and octoprint hung pretty bad and both required restarts to get going again. The printer is currently finishing it's first remote print and I'll be grateful not to have to run up and down the stairs as many times.

Thanks for putting this together!

[Mrnt]

I might be able to get the *gdrem format to be accepted if that is helpful? Is that the format that includes the image in the file?

Yep normal OctoPrint upload button will not work yet, but I think Im close - looking for volunteers to test that.

I think you should be able to upload direct to SD card from Cura (via OctoPrint) if you point Cura at the OctoPrint server in the Cura printer settings.

[jimprince]

I'm not super fussed about being able to use gdrem files and tbh it cuts out a step I've been doing for so long I've forgotten that I'm doing it. I believe that format does have the image in the file, but I'm uncertain how it goes about that.

Happy to be a guinea pig when you need to test the upload button. :) Online print status would be incredibly helpful.

I'll have to give the upload directly to SD from Cura a shot, waiting for this print to finish.

[jimprince]

I am getting this in response while printing, which is probably why the time to finish looks so weird on the printer itself.

Printing directly from Cura does work, but it does not work with the Dremel profile that I installed from the marketplace (it won't let me connect to octoprint with that machine profile). I just created a custom machine and then was able to get octoprint to connect. I had to remove the start and end Gcode from the profile as I was getting communication timeouts when they ran. After removing the start and end gcode it looks like it's working like a champ.

I'll put any issues I find in the actual repository you've linked to.

Edited for clarity

[jokedu]

i just installed it on a raspberry pi 3 yesterday.
i also bought the night vision camera for the raspberry and 3d printed a case and a mount, i currently own a dremel idea builder / 3d20 and have been getting problem connecting it to octoprint but i am later going to try manually selecting the usb port with this:Connect to your OctoPi/Octoprint device using ssh
2) Type the following to open a text editor:
sudo nano /etc/udev/rules.d/99-octoprint.rules
3) Add the following line:
SUBSYSTEM=="usb", ATTR{idVendor}=="2a89", MODE="0666"
4) Save the file and close the editor
5) Verify the file permissions are set to "rw-r--r--" by typing:
ls /etc/udev/rules.d/99-octoprint.rules
6) Reboot your system for the rule to take effect.

This is a copied text of the terminal in octoprint's website, i managed to get this text by connecting my printer and installing the pluggin of flashforge and dremel.
Does anyone has a better solution or how did you managed to get it running and connected?

[jokedu]

and all of you with a dremel 3d20 how do you get prints to stick?

would be kinda cool to know what different people use

[Mrnt]

i just installed it on a raspberry pi 3 yesterday.
i also bought the night vision camera for the raspberry and 3d printed a case and a mount, i currently own a dremel idea builder / 3d20 and have been getting problem connecting it to octoprint but i am later going to try manually selecting the usb port with this:Connect to your OctoPi/Octoprint device using ssh
2) Type the following to open a text editor:
sudo nano /etc/udev/rules.d/99-octoprint.rules
3) Add the following line:
SUBSYSTEM=="usb", ATTR{idVendor}=="2a89", MODE="0666"
4) Save the file and close the editor
5) Verify the file permissions are set to "rw-r--r--" by typing:
ls /etc/udev/rules.d/99-octoprint.rules
6) Reboot your system for the rule to take effect.

This is a copied text of the terminal in octoprint's website, i managed to get this text by connecting my printer and installing the pluggin of flashforge and dremel.
Does anyone has a better solution or how did you managed to get it running and connected?

@jokedu I know it is a bit frustrating, but you only have to do it once to enable USB access. I suppose it may be possible to get the plugin to create/modify the file automatically, but right now it seems like the development effort would be better spent extending the plugin functionality/printer support.

[eduncan911]

and all of you with a dremel 3d20 how do you get prints to stick?

would be kinda cool to know what different people use

OT, but...

We don't have any issues with prints sticking and just finished the first roll of filament.

Using the stock sticker pad it comes with for now, though I've been eyeballing a PEI pad replacement. Still got the 2nd pad on the bag. So will use that first.

All we do is manual bed level during each print. Insert the orange paper thing and adjust the bed to where it barely scraps that orange pad.

[eduncan911]

@Mrnt

I might be able to get the *gdrem format to be accepted if that is helpful? Is that the format that includes the image in the file?

Yep normal OctoPrint upload button will not work yet, but I think Im close - looking for volunteers to test that.

I think you should be able to upload direct to SD card from Cura (via OctoPrint) if you point Cura at the OctoPrint server in the Cura printer settings.

Count me in as a tester as well. Just ping me here on GitHub with @eduncan911