You are not logged in. Please login or register.
SoliForum - 3D Printing Community → XYZ Printing Hacks & Mods → DaVinci Junior cartridge reset
By chance are there any assembly experts online right now. I just ran a disassembly and have an output file, but I know nothing about assembly language.
The dump I have is from
http://s000.tinyupload.com/index.php?fi … 8177964475
in a previous post.
I also dumped it to ASM but the formatting isn't making sense. If the reset vector is 0x00000000, the first instruction would include the plaintext dv1J00A000+2.2.0 - not exactly a valid branch address or instruction, depending on endianness. Does anyone know the beginning code execution address? If the usual ARM vector tables are just ignored, the next valid code start would be @ 0x00000020 which contained an undefined instruction, a branch instruction to invalid address, or a branch to 0x00000030 which branched to an invalid address depending on which ARM version and endianness. There's also the possibility the reset vector was changed to another ARM alternate standard of 0xFFFF0000 which would be outside of valid addresses. Unless I read the ARM literature wrong which is entirely possible.
I found I was getting very bad prints after about 150 hours of print time. Then I realized you have to clean it periodically. Before the print quality dropped I noticed noises that could be described as scratchy. It sounded to me like a very old HDD doing heavy work like a defrag.
There is an instructional video but cleaning like they did had little effect. The video shows the cleaning needle being inserted about 1/4 inch 3 times and calls it done.
I clean by first wiping the tip. Then, inserting and removing the needle about 3/4 inch, 3 or 4 times, then removing it completely and heating the needle with a lighter until glowing to remove the plastic. Repeat this a few times then progress to doing gentle swirls with the needle at a slight angle to try to clean the sides of the inside. Do that at a few different depths burning the needle clean each time.
I will do this now before every print if the total print length from all of the prints since my last cleaning plus the new print exceeds about 15m.
It's tedious but the noises have stopped and the print quality is good again.
Also, if you find this beneficial but destroy all of the included cleaning like I have, I have found that 28 gauge wire (kanthol in my case) is only slightly smaller than the included cleaning needles and works well to fashion more.
johnboyjr wrote:DocD7 wrote:Won't work quite that way. Was stated that the count was still decremented but it didn't stop the printer when the count got down to and below 0. Still, nice workaround for using up the last of the filament on the spool despite "not having enough" to complete the job.
a spool has 200m using the old software it looks like you can set it to only use 1m per print no matter how big it is. so one the spool really runs out just switch it but keep using the same card. you would get 200 prints per card. if this works i will just buy 3 spools of xyz filament then just buy normal filament of amazon. 600 prints should last me a long time. i am testing it right now i will let you know if it works when the print is done. the printer reads 100% done right from the start but it seems to be working fine.
At the bottom of that thread it was reported that the printer uses GCode for the display but it still decrements the spool count. Seems to have a separate sub-system for tracking usage and writing to the NFC chip.
See http://www.soliforum.com/post/109129/#p109129 - copied below:
cazzer2015-11-07 19:08:57
Newbie
Offline
Registered: 2015-11-07
Posts: 2
Oh well that would have been too easy. It uses the g code for the front panel info but it still decrements the spool.
yeah, just tried that as well before I read your post. same thing. software read 0m usage and printer read 100% 1 minute while printing but the spool was decreasing as i checked in the printer monitor on the software. I got too exited and now I'm disappointed...
Ok.. I have an idea. I tried taking out the chip and after the first layer it said Spool Error. If there is some way to modify the GCode so that the entire print is technically one layer, then it would finish the whole print before checking to see if there is a chip in or not.
I believe someone suggested that but it would require a huge refactoring of the gcode. Not too big a deal with a really small, simple model but a huge undertaking for files with 10's of thousands of lines.
I believe someone suggested that but it would require a huge refactoring of the gcode. Not too big a deal with a really small, simple model but a huge undertaking for files with 10's of thousands of lines.
Ah. Maybe someone can come out with a program that does it automatically? I don't know. I'm just pitching ideas because I don't want to have to buy XYZ's expensive proprietary crap.
DocD7 wrote:I believe someone suggested that but it would require a huge refactoring of the gcode. Not too big a deal with a really small, simple model but a huge undertaking for files with 10's of thousands of lines.
Ah. Maybe someone can come out with a program that does it automatically? I don't know. I'm just pitching ideas because I don't want to have to buy XYZ's expensive proprietary crap.
Neither do I. But, more importantly, I want some more control of my printer. I personally believe breaking into the firmware is the solution to all our problems. We shouldn't have to modify the tools or tool behaviors or reformat standards-based file formats just to "fool" firmware for just a single printer while still having to purchase (at least once) "valid" supplies to get it to work at all. The firmware should be modified to accept existing tools and formats. The only exception to that being adding performance/abilities that greatly changes what can be done with existing hardware.
Just my $.02
jakecrowley wrote:DocD7 wrote:I believe someone suggested that but it would require a huge refactoring of the gcode. Not too big a deal with a really small, simple model but a huge undertaking for files with 10's of thousands of lines.
Ah. Maybe someone can come out with a program that does it automatically? I don't know. I'm just pitching ideas because I don't want to have to buy XYZ's expensive proprietary crap.
Neither do I. But, more importantly, I want some more control of my printer. I personally believe breaking into the firmware is the solution to all our problems. We shouldn't have to modify the tools or tool behaviors or reformat standards-based file formats just to "fool" firmware for just a single printer while still having to purchase (at least once) "valid" supplies to get it to work at all. The firmware should be modified to accept existing tools and formats. The only exception to that being adding performance/abilities that greatly changes what can be done with existing hardware.
Just my $.02
I'm with you, I would much rather just flash some custom firmware and be on my way. The only problem is how would that affect the auto-load/unload as well as auto-bed leveling? Anyway, why can't we just use a program to intercept the firmware download from xyz and replace it with a custom one?
DocD7 wrote:jakecrowley wrote:Ah. Maybe someone can come out with a program that does it automatically? I don't know. I'm just pitching ideas because I don't want to have to buy XYZ's expensive proprietary crap.
Neither do I. But, more importantly, I want some more control of my printer. I personally believe breaking into the firmware is the solution to all our problems. We shouldn't have to modify the tools or tool behaviors or reformat standards-based file formats just to "fool" firmware for just a single printer while still having to purchase (at least once) "valid" supplies to get it to work at all. The firmware should be modified to accept existing tools and formats. The only exception to that being adding performance/abilities that greatly changes what can be done with existing hardware.
Just my $.02
I'm with you, I would much rather just flash some custom firmware and be on my way. The only problem is how would that affect the auto-load/unload as well as auto-bed leveling? Anyway, why can't we just use a program to intercept the firmware download from xyz and replace it with a custom one?
The firmware was intercepted and the bin file was posted. Getting it disassembled and rewritten is the problem especially if the file is encrypted until it is flashed to the board. Further, this isn't just an Arduino on steroids. There's a full Cortex-M4 processor in there so at least some, if not all, of the firmware is likely going to be ARM instead of purely AVR.
Now that I think about it, could a purely AVR firmware replace the current without running amok of the ARM core? If so, tracing the pins and flashing with AVR-based repetier FW or the like might just do the trick! Any thoughts?
jakecrowley wrote:DocD7 wrote:Neither do I. But, more importantly, I want some more control of my printer. I personally believe breaking into the firmware is the solution to all our problems. We shouldn't have to modify the tools or tool behaviors or reformat standards-based file formats just to "fool" firmware for just a single printer while still having to purchase (at least once) "valid" supplies to get it to work at all. The firmware should be modified to accept existing tools and formats. The only exception to that being adding performance/abilities that greatly changes what can be done with existing hardware.
Just my $.02
I'm with you, I would much rather just flash some custom firmware and be on my way. The only problem is how would that affect the auto-load/unload as well as auto-bed leveling? Anyway, why can't we just use a program to intercept the firmware download from xyz and replace it with a custom one?
The firmware was intercepted and the bin file was posted. Getting it disassembled and rewritten is the problem especially if the file is encrypted until it is flashed to the board. Further, this isn't just an Arduino on steroids. There's a full Cortex-M4 processor in there so at least some, if not all, of the firmware is likely going to be ARM instead of purely AVR.
Now that I think about it, could a purely AVR firmware replace the current without running amok of the ARM core? If so, tracing the pins and flashing with AVR-based repetier FW or the like might just do the trick! Any thoughts?
Doesn't XYZWare flash the firmware from the software? I was saying we could replace the firmware with some software, say redirect the firmware URL with a custom repetier so it would flash that file instead of the xyz firmware.
If that doesn't wonk I would for sure go along with tracing the pins and flashing the firmware. Would you need any addition hardware? Say an AVR Programmer? Or can I use my arduino. The only thing I am worried about is bricking my device.
Anyway, I opened up my printer and got the serial number off the chip. Here is the link to the datasheet http://www.atmel.com/Images/Atmel-11157 … asheet.pdf
I found some useful information such as reset and flash pin. You can take a look for yourself to see if you can trace those pins back to the board
DocD7 wrote:johnboyjr wrote:a spool has 200m using the old software it looks like you can set it to only use 1m per print no matter how big it is. so one the spool really runs out just switch it but keep using the same card. you would get 200 prints per card. if this works i will just buy 3 spools of xyz filament then just buy normal filament of amazon. 600 prints should last me a long time. i am testing it right now i will let you know if it works when the print is done. the printer reads 100% done right from the start but it seems to be working fine.
At the bottom of that thread it was reported that the printer uses GCode for the display but it still decrements the spool count. Seems to have a separate sub-system for tracking usage and writing to the NFC chip.
See http://www.soliforum.com/post/109129/#p109129 - copied below:
cazzer2015-11-07 19:08:57
Newbie
Offline
Registered: 2015-11-07
Posts: 2
Oh well that would have been too easy. It uses the g code for the front panel info but it still decrements the spool.yeah, just tried that as well before I read your post. same thing. software read 0m usage and printer read 100% 1 minute while printing but the spool was decreasing as i checked in the printer monitor on the software. I got too exited and now I'm disappointed...
Yeah, that cheat won't work. I still think the NFC is updated on each G92 requests (maybe also in between). What I want to try is to create a gcode where there are no G92's and do a reset mid-print to check if the spool is updated or not
jakecrowley wrote:DocD7 wrote:At the bottom of that thread it was reported that the printer uses GCode for the display but it still decrements the spool count. Seems to have a separate sub-system for tracking usage and writing to the NFC chip.
See http://www.soliforum.com/post/109129/#p109129 - copied below:
cazzer2015-11-07 19:08:57
Newbie
Offline
Registered: 2015-11-07
Posts: 2
Oh well that would have been too easy. It uses the g code for the front panel info but it still decrements the spool.yeah, just tried that as well before I read your post. same thing. software read 0m usage and printer read 100% 1 minute while printing but the spool was decreasing as i checked in the printer monitor on the software. I got too exited and now I'm disappointed...
Yeah, that cheat won't work. I still think the NFC is updated on each G92 requests (maybe also in between). What I want to try is to create a gcode where there are no G92's and do a reset mid-print to check if the spool is updated or not
That's what i mentioned but Doc said that it would take a huge refactoring of the GCode and just wouldnt be practical. The real thing we need to do here is come out with a firmware flash which would solve all of our problems.
Played around with the NFC and was able to intercept the password using a bus pirate. Sent my printer back for an exchange due to loud noises on the extruder and an unlevel z-axis. It was 10 days old so didn't want to play around too much and figure I will take my chances with another. I like the junior because it is small.
Going to try writing the original values back to the card and see if it works. Found an updated library for my nfc writer for the password authentication on ntag2xx nfc tags.
This is not really practical for the average user. I honestly think a repetier flash would solve all the problems. Could even add a small heated bed to print abs there a lots of 150mmx150mm heated silicone mats available. I don't have the guts to experiment with the printer as my wife bought it for me.
I did order a ramps controller with LCD and was thinking about using it instead as i wouldn't have to cut any wires. I also ordered a new hot-end and am in the process of designing a holder that locks in the same way the oem print head locks in.
Not sure why people want to jack up the temps for PLA. Should be 190 for PLA and around 230 for ABS.
Provided we can get this thing licked, is the stock hot end up to the task of ABS? Can it handle the temps? Are there any specs on the hot end at all? Just thinking ahead and out loud as it were.
Played around with the NFC and was able to intercept the password using a bus pirate. Sent my printer back for an exchange due to loud noises on the extruder and an unlevel z-axis. It was 10 days old so didn't want to play around too much and figure I will take my chances with another. I like the junior because it is small.
Going to try writing the original values back to the card and see if it works. Found an updated library for my nfc writer for the password authentication on ntag2xx nfc tags.
This is not really practical for the average user. I honestly think a repetier flash would solve all the problems. Could even add a small heated bed to print abs there a lots of 150mmx150mm heated silicone mats available. I don't have the guts to experiment with the printer as my wife bought it for me.
I did order a ramps controller with LCD and was thinking about using it instead as i wouldn't have to cut any wires. I also ordered a new hot-end and am in the process of designing a holder that locks in the same way the oem print head locks in.
Not sure why people want to jack up the temps for PLA. Should be 190 for PLA and around 230 for ABS.
I was using MakerBot filament (still using the nature filament nfc chip that came with the printer) and in order for it to melt i had to jack up the temp to 230 for pla. What I have heard is that XYZ's filament has a lower melting point than regular pla and same for abs. If writing back the original values works, I might have to order an nfc writer as even if their were a repetier flash I wouldn't have the guts in fear of bricking the printer as well as I am a 3D printing noob (this is my first printer).
I just really want some solution quick before i run out on filament and am forced to buy xyz's proprietary.
Provided we can get this thing licked, is the stock hot end up to the task of ABS? Can it handle the temps? Are there any specs on the hot end at all? Just thinking ahead and out loud as it were.
I can't really find anything on the hot end. I can see if it can get up to the temp abs were to melt at, I already can print fine at 230.
After skimming the data sheet for SAM4E chip, as long as we have a valid FW from XYZ there should be little worry about bricking the printer. There are provisions built into the chip for in-situ flash programming via USB as well as standard serial comms. Not to say everyone will be able to "unbrick" a failed flash all by themselves, but there are definitely options for a bricked machine.
Also found in the data sheet there are options for JTAG programming and even cascaded programming of multiple chips at one time. Not sure the latter would be particularly useful, but just pointing out that even if a flash fails all is not lost. Of course most of the target market for this machine probably won't want to risk it at least until a new firmware flash is proven and somewhat stable, but those of us with at least a little knowhow, some hardware, and a little courage (liquid or otherwise) could quite easily revert back to standard FW and effectively unbrick anything that went wrong.
On a side note, the chip is pretty much a full ARM processor - no AVR. So a modified AVR repetier FW won't work. Has to be ARM FW. Also, there is some great info in the data sheet for the memory-mapped peripherals including the addresses for I2C, USART, and GPIOs. If we can get the XYZ FW decompiled correctly, searching for references to those addresses could lead somewhere useful.
After skimming the data sheet for SAM4E chip, as long as we have a valid FW from XYZ there should be little worry about bricking the printer. There are provisions built into the chip for in-situ flash programming via USB as well as standard serial comms. Not to say everyone will be able to "unbrick" a failed flash all by themselves, but there are definitely options for a bricked machine.
Also found in the data sheet there are options for JTAG programming and even cascaded programming of multiple chips at one time. Not sure the latter would be particularly useful, but just pointing out that even if a flash fails all is not lost. Of course most of the target market for this machine probably won't want to risk it at least until a new firmware flash is proven and somewhat stable, but those of us with at least a little knowhow, some hardware, and a little courage (liquid or otherwise) could quite easily revert back to standard FW and effectively unbrick anything that went wrong.
On a side note, the chip is pretty much a full ARM processor - no AVR. So a modified AVR repetier FW won't work. Has to be ARM FW. Also, there is some great info in the data sheet for the memory-mapped peripherals including the addresses for I2C, USART, and GPIOs. If we can get the XYZ FW decompiled correctly, searching for references to those addresses could lead somewhere useful.
I really wish I could help, but I just don't know how to decompile / program fw for these chips. ;( I really hope there is some workaround soon, either FW Flash or NFC Reset. Please keep me updated on all progress made, I am very anxious! (I come back to this forum every 30 mins to 1 hr checking for new posts lol)
I really don't think an NFC reset scheme will solve the most significant issues. Sure, you could print with whatever PLA you want (to a point), but still couldn't change temps, easily use non-XYZ softwares, or mod the machine at all (ABS with heated bed anyone?). FW is definitely the final solution.
I'm starting to think that an ARM port of repetier or the like along with pin traces of the XYZ mainboard will be the most solid hack. I don't think a complete rewrite of FW is the way to go - no sense in starting from scratch and replicating work already done.
I really don't think an NFC reset scheme will solve the most significant issues. Sure, you could print with whatever PLA you want (to a point), but still couldn't change temps, easily use non-XYZ softwares, or mod the machine at all (ABS with heated bed anyone?). FW is definitely the final solution.
I'm starting to think that an ARM port of repetier or the like along with pin traces of the XYZ mainboard will be the most solid hack. I don't think a complete rewrite of FW is the way to go - no sense in starting from scratch and replicating work already done.
I'm able to change the temp quite easily. I downloaded XYZWare Advanced Mode (you can find it earlier in this thread) and changed the GCode with the inbuilt GCode editor to whatever temp you want. Tested it and was able to get it heated up to 230. Its probably possible to get it heated up to higher temps, i just haven't tried anything else yet.
DocD7 wrote:I really don't think an NFC reset scheme will solve the most significant issues. Sure, you could print with whatever PLA you want (to a point), but still couldn't change temps, easily use non-XYZ softwares, or mod the machine at all (ABS with heated bed anyone?). FW is definitely the final solution.
I'm starting to think that an ARM port of repetier or the like along with pin traces of the XYZ mainboard will be the most solid hack. I don't think a complete rewrite of FW is the way to go - no sense in starting from scratch and replicating work already done.
I'm able to change the temp quite easily. I downloaded XYZWare Advanced Mode (you can find it earlier in this thread) and changed the GCode with the inbuilt GCode editor to whatever temp you want. Tested it and was able to get it heated up to 230. Its probably possible to get it heated up to higher temps, i just haven't tried anything else yet.
I haven't been able to find a Mac port of the Advanced Mode SW. I really don't want to have to fire up my VM just for a print. Not to mention, most "consumers" of this printer probably won't even be aware of it. Would be nice if there were a CLI switch I could use on the Mac to force the stock SW into Advanced Mode - There are .nibs for many of the advanced features in the app package but I haven't found any documentation to enable them.
jakecrowley wrote:DocD7 wrote:I really don't think an NFC reset scheme will solve the most significant issues. Sure, you could print with whatever PLA you want (to a point), but still couldn't change temps, easily use non-XYZ softwares, or mod the machine at all (ABS with heated bed anyone?). FW is definitely the final solution.
I'm starting to think that an ARM port of repetier or the like along with pin traces of the XYZ mainboard will be the most solid hack. I don't think a complete rewrite of FW is the way to go - no sense in starting from scratch and replicating work already done.
I'm able to change the temp quite easily. I downloaded XYZWare Advanced Mode (you can find it earlier in this thread) and changed the GCode with the inbuilt GCode editor to whatever temp you want. Tested it and was able to get it heated up to 230. Its probably possible to get it heated up to higher temps, i just haven't tried anything else yet.
I haven't been able to find a Mac port of the Advanced Mode SW. I really don't want to have to fire up my VM just for a print. Not to mention, most "consumers" of this printer probably won't even be aware of it. Would be nice if there were a CLI switch I could use on the Mac to force the stock SW into Advanced Mode - There are .nibs for many of the advanced features in the app package but I haven't found any documentation to enable them.
Ah Mac user i see. 
There is also a python script that converts any Cura/Slic3r exported GCode into a w3 file. You could change it in the GCode there, then convert it. You have to change 'DaVinciF10' in the GCode to 'DaVinciJR10' (case sensitive, i learned that the hard way lol) in order for XYZWare to print the w3 to the jr. You also have to load the config ini files included into Cura/Slic3r.
Example: daVinciGcodePrep.py test.gcode curaMode=true
(Obviously only use cura mode when you are using cura. If you are using Slic3r just leave out the curaMode=true)
convert2DaVinci: https://drive.google.com/file/d/0B76NYU … sp=sharing
So, I was just wandering around the inter webs and came across Keil MDK-ARM Cortex-M DeVon tools. Includes an IDE, ARM compiler tools, and a tool to convert ELF executables to bin. This suite is made for uC's and flash based FW.
Just in case someone was looking for tools. Doesn't help with disassembly of current firmware but might help with porting repetier.
DocD7 wrote:Provided we can get this thing licked, is the stock hot end up to the task of ABS? Can it handle the temps? Are there any specs on the hot end at all? Just thinking ahead and out loud as it were.
I can't really find anything on the hot end. I can see if it can get up to the temp abs were to melt at, I already can print fine at 230.
There is lots if pla that will melt at 190. Just depends on the brand.
SoliForum - 3D Printing Community → XYZ Printing Hacks & Mods → DaVinci Junior cartridge reset
Powered by PunBB, supported by Informer Technologies, Inc.
