print gcode files to miniMaker (Page 3 of 16)

What printer are you trying to use? 

Is it still on stock firmware?

Would you mind if I sent you a special version that logged out all the communication for me to analyze?

miniMover is the utility linked in the first post of this thread, it lets you encrypt/decrypt .3w files and send them on to a da Vinci printer.

Sorry for my idiocy and forgetting to post what counts for you.

I am using a Da Vinci Mini Maker with stock firmware. And no, I do not mind you collecting data on this printer if it can help you bypass the authenticity check for the filament.

Mehigh and Carl, can you run this version of mini mover and send me the output? You can capture a screen shot, or copy the text out of the dos box.  To copy the text right click on the box and select 'mark', then highlight the text with your mouse and hit enter to copy it to the clipboard.

Actually I would be happy to have anyone run this, as long as your still on the stock firmware.  I don't know that it will do anything with a da Vinci 1.0 but I'd still be curious to see what happens.

Version 8 cleans up the debug logging a lot.  Now if you create a debug.txt file in the same directory that you put the miniMover exe I will log all low level communications between the printer and miniMover.  That way if you are getting some sort of an error you can pass me along all the communication without me needing to make a special build.

I also made an initial pass at decoding the error number, although I'm not very confident that I'm doing it right.  And I cleaned up the print logging a bit

Thanks Mehigh, I will take a look at that.

I downloaded all the firmwares I could and inspecting them in a hex editor. Most of them follow the v3 format of a small header followed by what I assume is an encrypted body, however the older 1.0 and 2.0 models are not encrypted.

I spent a bit of time looking through one and interestingly enough the rom has strings for all the commands used in all three versions of the communications protocol. That is the DAVxxx format of version 1, the XYZ_@3D:x format of version 2, and the XYZv3/xxx version 3 format. I doubt it supports all three protocols but the command parser still can gracefully accept all three without choking.

So I'm getting to the end of what I can do here without some help form others.  I have this working quite well for the miniMaker, and in theory it works ok on all the v3 protocol machines, but I have almost zero testing on that.

I still could support configuring and talking over wifi, but I only have one example of what the wifi settings look like from a 1.0 pro machine, I need to see the settings on the mini w, jr w and 1.0w machines as well.  And I would need someone interested in working with me as I developed this who could run tests for me.

I could support the older 1.0 and 2.0 machines but again I would need someone willing to test the code out for me.  I have only a single very limited example of how to talk to a 1.0 machine from a firmware that is 4 years old.  I would need a lot more data to implement this properly.

And finally I need at least minimal testing on all the machines to verify they work at all.

So if anyone has an interest in seeing this move forward, and has an xyz printer other than the miniMaker then let me know.  I have been racking my brains for how to get my hands on another machine, short of dropping many hundreds of dollars on the project and can't work it out.

I am not sure you system will work with older machines. They do not use RFID and instead use a three wire serial connection directly to an EEPROM that is on the bottom of each cartridge. In addition the machine has to go online to validate each cartridge serial number and if it see a serial number that has been seen before as empty ro it see one that has not been made , it will reject them. This has been an issue with some as for some reason they by new filament but it somehow was never added to XYZ's database so it fails when the machine calls home to validate it.

This is the main reason most have said screw it and gutted the machine and installed a RAMPS or other open source controller.

Interesting, I saw the code to register filament, I wondered what it was good for.  Supporting the 1.0 machines is not super high on my to do list but I would like to support them enough that I can auto detect the machine and convert the file format from gcode to .3w automatically.  I may have all I need to pull that off already, but it would be nice to have someone lined up to test it before I put in the effort to support it.

I have a conundrum I can't work around.  I found a big gcode file (60 MB) and sent it to the printer in about 500 seconds.  That works out to a data rate of around 126,000 Bytes per second, or 10x faster than the requested 115,200 bits per second transfer rate of the serial connection.

I keep going over the documentation and I can't see anything that would make 115,200 bps act like bytes per second.  All I can think of is that the serial to usb converter is speeding up the transfer rate, but why only 10x faster.  It all feels too coincidental...

The way all the XYZ printers work is you send the whole gcode file down to there internal sd card (even if the SD card is not removable) and then they print from the card directly.  I have no way to tell you what line they are printing on, or really any way to control the print.

However Cura has all that built into it and more, you can decrypt your .3w file, load it into cura, and use one of there many scripts to change parameters on a layer by layer basis.