DaVinci Junior cartridge reset (Page 11 of 58)

crgpgh wrote:

When I tried writing to the length page, the printer did not recognize the spool. However, when I wrote everything back to the known state, the printer again accepted it. So the state of the art at this point is to dump your chips on a new spool, print, then write that known good state back and use it for an off brand spool. I am going to test that all the way through this week, but it seems to work as I was able to take a chip that was no good and write a known state to it and have it work again.

Another option I am going to try is booting the printer up with a generic NTAG213 card, grab what the printer thinks the password should be, write all the known state information from another chip and then password protect the chip with the password the printer tried to pass.

So if I've understood everything correctly, I can save the state of the chip, then write back the info to the 'full' state every time the chip gets low or runs out?

jakecrowley wrote:

crgpgh wrote:

When I tried writing to the length page, the printer did not recognize the spool. However, when I wrote everything back to the known state, the printer again accepted it. So the state of the art at this point is to dump your chips on a new spool, print, then write that known good state back and use it for an off brand spool. I am going to test that all the way through this week, but it seems to work as I was able to take a chip that was no good and write a known state to it and have it work again.

Another option I am going to try is booting the printer up with a generic NTAG213 card, grab what the printer thinks the password should be, write all the known state information from another chip and then password protect the chip with the password the printer tried to pass.

So if I've understood everything correctly, I can save the state of the chip, then write back the info to the 'full' state every time the chip gets low or runs out?

Right. I am going to do exactly that this week with actual filament. What I did as a test was write some values that ended up being bad to a chip. I tried to run that in the printer and it would not accept it. I wrote the original values back and it worked again.

I am going to do another test today or tomorrow but please replicate my results. The more people who try it the better the odds are we will keep making progress on this!

crgpgh wrote:

jakecrowley wrote:

So if I've understood everything correctly, I can save the state of the chip, then write back the info to the 'full' state every time the chip gets low or runs out?

Right. I am going to do exactly that this week with actual filament. What I did as a test was write some values that ended up being bad to a chip. I tried to run that in the printer and it would not accept it. I wrote the original values back and it worked again.

I am going to do another test today or tomorrow but please replicate my results. The more people who try it the better the odds are we will keep making progress on this!

I am just wondering how you were connecting the NFC reader/writer from inside the printer. I do not have an NFC shield so I was wondering if I could do this without buying an NFC shield. I know you said that you couldn't get it to work, but if you still have code I could possibly take a look at that would be great!

crgpgh wrote:

crcasey wrote:

I have a bus pirate and would like to get the information on how you are reading the password for the chip.

I believe once you have this password you should be able to read out all of the unlocked data with the android nfc app, is that correct?

TIA

-Cecil

I tried it with the Android apps but could not get them to read the password protected areas. Only using the Arduino to dump the contents.

I have not done this with the bus pirate yet but that is on my list to try. I am going to use Open Logic Sniffer for this.

I tried today several times today with the bus pirate, and at the 400KHz rate I2C the bus pirate's 4k ring buffer interface just can not keep up with the printer.  I think a faster/deeper chip will be needed, or we will have to use a logic sniffer that streams to the PC like yours.

I do have another question though for you.  When are you seeing the password key handshake between the printer and the NFC?  Is it right at power on, or do you see it later when you tell the printer to start a print?

Thanks!

-Cecil

Oh, I can also verify that the GCode,

M109 S195.000000 ; wait for temperature to be reached

Does seem to work correctly.  At least the display during the printout is now reading 196C instead of the default 191c that is normally reads.

Please note that I didn't probe the hot end to see if the software is just lying to me.  YMMV.

-C

Jake,

I have placed an order for one of the $16.00 China made logic sniffer's.  They use a 24MHz clocked FPGA to grab 8 channels directly to USB.  This is MUCH faster than the Bus Pirate and should be able to grab the I2C clock and data with no problem.

While cheaper than the Scaele logic analyser and having no buffering or pull ups on the lines I am going to gamble the money that it will do the business.

Since it will come China post I am going to be out of the direct hack for a week or better.  But that will give Adafruit plenty of time to get me a PN532 shield in like the one Chris is using.

I will send an update when the slow boat from China gets here.

-Cecil

All of my issues with my Jr, sans "filament freedom" were solved after switching over to the advanced mode program file linked earlier. I can now set my travel speed, retract length and rate, hotend temp and it enables a gcode editor.
I support all efforts to free this piece of hardware from its software cage, but it seems like, if all we're really after is full diy-like control plus ability to use any material we please, the easiest route would be to find the cheapest hardware capable of writing a functioning 200/200 nfc state to the cheapest compatible nfc chip, then buying one of those plus many many blank chips, sell them at cost to any and all. Then just enable the advanced mode features, which for all I can tell, just unhides what they hid from slic3r by default. The only precaution I would take here would be to make sure xyzware is blocked from all network traffic, or control your printer from a network-isolated system to prevent multiple systems from reporting the same serial number all with full states back to xyz. My coding knowledge goes as far as gcode and some basic arduino sketches I made for servo control a few years ago, but I'm always up for a new challenge. The spool I received with my printer arrived reading 0/100m, and the xyz rep reccomended I call amazon instead of dealing with their warranty, and Amazon ended up giving me a 20% refund, which was sufficient for two more spools. I'd also oredered a spool of black pla at the time of purcahse of the Jr.
Each filament that I've used so far has had a different stock heat setting and each has been uniquely tolerant to said setting.
The clear is set to 190, and works well on "excellent" preset, but to get good, cosistent results I had to bump it to 197 (temp seems to sag by 2deg during the print, meaning it was holding 195.)
Black is set 195 by default. Oddly, it printed well for the first few days in the printer, then started to jam about 80m into the spool. After raising the temperature to 205, it's been printing very well.
Neon Green is the worst so far. It has a different texture on the raw spool, if the others could be called shiny, this is matte, almost  rough. The temp preset is 210, and the extruder motor clicked until I brought it almost to 230. To me, this negates the SOLE reason that justifies the nfc system, because they can't even mix plastic right to keep it within their own spec. Another thing about 230 Celsius, it seems like that's it's upper threshold. I've set it to 230, 232, 235, and 240 and it stays reading a max of 229 during the job.