Interesting thing about the wood!!! Neat! Any pics of the finished piece? Re slicing, yeah, cubify is crap. Try simplify 3d and export to cube Bfb then convert back to cube. And oh btw I measured the filament neon green I got with my cube 3 and it's 1.77 all over, nothing about 1.65! Not even 1.75 lol
I didn't say the address was wrong. I was talking about the physical location of that row in the hex file. It needs to come before any of the other rows in that section. Also, the debug setting does nothing. The IPE will notice that debug is turned on and turn it off. You only need to turn off the WDT to make it work. Have you got a PICkit3? The only way you can use the debugger is with one of those, and you need to physically connect it to the ISP pins on the controller board. If you have all that stuff set up already, you can just go read out the flash of your own chip. The IPE will let you export it to a hex file once you've read it. Then you can diff it with the hex from the toolkit and see what I'm talking about.
I see, thank you! Can you send me the correct string for the configuration bits? I do have the Pickit 3 already. Trying to make it work with this utility: GitHub - sergev/ejtagproxy: GDB interface utility for MIPS processors, including PIC32 I really want to make GDB work, it would so much easier to debug directly from IDA. I do not need the firmware hex downloaded from the printer, I already have it disassembled with the XC32 compiler signatures applied.
Has anyone ever tried putting CubePro firmware on a Cube3? I read in the other thread that they both use the same controller board. I would assume the differences are mainly in the cfg files on the sd card. Has anyone posted the sd card files from a CubePro? I'd like to diff them with the Cube3 files.
Does the edit at the first message of this thread mean that I should back-flash my v1.1 machine to v1.0 for best results? I have toolbox 1.0 and 1.1 but never pulled 1.11 from the thread/resource. I was about to implement v1.1 on another machine operated by someone not as technically capable as I, and would not wish to complicate her life.
V1.0 has been working wonders for me. 1st reload today. Ever try joining leftovers end to end? It can be done
Get yourself a PTFE / TeflonTube in your filament diameter. Push filament to the middle from one side and the leftover from the other side. Get yourself a lighter and head up the middle where both filaments meet. Just as much that you can push both filaments together. Let it cool a few seconds. You are done. @Tom Dirriwachter sorry for stealing your post
@fred_dot_u Use the Toolbox v1 please. The Version v1 only patched the write routine of the chip and nothing else. AND Thank YOU for the donation!
Guys, do you by chance have configuration for either KISSlicer or Simplify3D for Cube 3? The ones that work good for you. Could you share if you have ones?
Hi, I am a little late to the party, but maybe I come with good things to digest. My daughter bought me a cube 3 for x-mas, and I after some playing around with printing I got fixated at breaking the chip as well. I am a HW guy, so my solution was different and I just got it running last weekend. Talk about timing. I used an FPGA Spartan 6 development kit from Avnet and I communicated to the chip through the FPGA. I could then block the write message by knowing the serial code like you guys had found out. The one thing I can do which you cannot yet is deal with full cartridges. I can tell when the cartridge is less than full and block the messages dynamically based upon filament remaining instead of all of the time. Anyway, in my work I have deciphered some of the two messages/memories which go to the chip. I am also quite fluent in the 1W protocol right now. There are two messages/memories used. The chip has 4 pages, and only two of these pages are used by the cube - page 0 and page 1. Each page is 32 byes little endian. Page 0 is used for the filament remaining count soley and page 2 is used to hold the filament type PLA/ABS, color and serial number of the cartridge. I have not fully decoded page 1, but I have a fair amount of info for that page. The filament remaining number at 100% full is BA A0 01 00, or roughly 9.3738x10^-4 counts/percent full. One can easily key off this full number after the read page 0 routine to determine when to block the write. I do not have the code which determines PLA versus ABS because I have no ABS cartridges to test with. If someone were to send me a used chip for ABS, I could find the code in a few minutes. I could also buy a full ABS cartridge as well if the data I gather would be used. Cheers Doug
I should have a zero percent ABS laying around somewhere. I just need to find it among the PLA's. Would that work?
Absolutely. The percentage full is in a different page of memory. I shall give you a few bucks for it along with the post charges. I am totally new to this site, and I do not know how to PM. Please PM me and I will give you my details. Doug
I've done quite a bit of work on this, as well. I've gathered dumps from 6 or 8 different carts, including 2 ABS ones. I used a BusPirate, which I think costs $30, so it's quite accessible if anyone wants to give it a try. I've decoded almost all of the bytes, I think. There is one 4-byte section that seems to be unique to each cart. I recently figured out how to decode the xml header of the cube3 files, and that contains the filament type/color code, which matched the bytes I thought they were, although it includes 1 more byte for type. I captured a bunch of 1-wire traffic back and forth using a Saleae Logic, and it looks like most of the traffic operates at Overdrive speed. My original plan was to have an external MCU act as a 1-wire slave and simply fake all the responses, but I could only find one software library that supported Overdrive. If you want to fake the traffic you have to figure out how to calculate the SHA-1 hash that the controller uses to authenticate, and how it picks which key its going to use. I would think it uses the EEPROM's serial number, and maybe that 4-byte unique key, but maybe I'm making it more complicated than it is. (Everything else I've expected to be complicated with this thing ended up being quite easy... this is probably the same.) Back to specifics... Don't key off a specific value for 100% full. It can vary a bit with each cart. The first page of the EEPROM contains the 100% value, and the second page contains the remaining value. All of my PLA carts have a full value of 0xB8 0xA0 0x01 0x00, but my ABS carts are 0x10 0xF4 0x01 0x00. The key to easily reading the data is to ignore the "0x3" part for all but one byte until you get to the 100% full value. I don't know if the 3 is for bit-stuffing, or the numbers are just in ASCII. Here's the dump of the EEPROM contents of a white PLA cart: 00: 0x36 0x30 0x38 0x36 0x34 0x32 0x33 0x36 08: 0x35 0x30 0x33 0x40 0x31 0x31 0x30 0x36 10: 0x32 0x33 0x31 0x35 0xB8 0xA0 0x01 0x00 18: 0xE3 0xE9 0x00 0x44 0x00 0x00 0x00 0x00 20: 0x2E 0x9C 0x01 0x00 0x00 0x00 0x00 0x00 Decoder ring: 0x36 - always 6 on every cart 0x30 38 36 - 086 - type/color code - 0 for PLA, 1 for ABS, 86 for white 0x34 0x32 - 42 - not sure what this is for, but it's 42 on all my carts but 1, my pale-yellow ABS has 41 here. 0x33 - 3 - not sure, but it's 1,2, or 3 on all my carts 0x36 0x35 0x30 0x33 - 6503 - don't know, changes from cart to cart 0x40 - I think this is extruder temp, inverted. All PLA carts have 0x40 here. ^0x40 is 0xBF, which is 191. ABS carts have 0x00, which is 255 inverted. 0x31 0x31 0x30 0x36 - lot #, date code - 1,1,06 - first 2 are enumerated, 1 for X, 1 for 12, 06 for week or month (this matches the code from the label of the cart) 0x32 0x33 0x31 0x35 - lot #, second half - 2315 0xB8 0xA0 0x01 0x00 - starting filament length (100% full) 0xE3 0xE9 0x00 0x44 - don't know, unique per EEPROM, isn't ASCII like the rest of the data 0x2E 0x9C 0x01 0x00 - filament remaining The type/color codes have some kind of mask applied, but it doesn't really matter. You can just view them as 3 unique bytes: 086 - PLA white 091 - PLA neon green 082 - PLA red 133 - ABS green 083 - PLA green 109 - ABS pale yellow
My bad Razor, I got my pages swapped. Yes, the filament left is the first long word on page 1 not page 0. I now know what bit indicates ABS, so I do not need to snoop a chip. Thanks The color for PLA is 40 + the color code in ASCII from what I could tell. Here are the dumps of page 0 for two of my cartridges. I am unclear on the last word as well. It is not a CRC from what I have tried so far White reg data 36 30 38 36 34 32 33 31 31 32 58 40 31 31 30 34 33 30 31 35 B8 A0 01 00 81 A9 51 DA 00 00 00 00 Black reg data 36 30 38 37 34 32 34 31 34 31 5A 40 31 31 30 38 31 31 31 35 B8 A0 01 00 92 FC F6 05 00 00 00 00 Doug
There must be an incidental hook to the rest of the software that the reading of the chip is on the right or left. I know it has unique names so you can have many in a chain on the same wire. But how does the rest of the software differentiate sides for where the chip is installed? I only mention as an awareness so that the remain algorithm isn't cut off from important data. PS, there is also the Infinity Rinse "type". It could be defaulting to ABS or PLA for that. I only have one of those and it is at 100%.
Doug, what's the chances of someday writing a common percentage value to all chips, 100%, 0%, or intermediate. If 100, write 99, loop If 0, write 99, loop else, write 99, resume
I knew as soon as I said that the first byte was the filament type code that I didn't have enough samples to say that. So I generated some cube3 files with the same color but different type, and opened them in a hex editor and looked at the code. As I expected, I spoke too soon: White: PLA - 86, ABS - 136 ... difference of 0xB0 Green: PLA - 83, ABS - 133 ... difference of 0xB0 Oh look, that proves it, right? And then... Pale Yellow: PLA - 102, ABS - 109 ... difference of 0x07 <sadtrombone/> So I wouldn't use the first byte for filament type. If you're looking for a simple flag, I'm pretty sure the byte I marked as being filament temp is a better indicator.
I do believe that the code is related to the last two digits of the part number. Memory Code Function PLA add 40 (for PLA 42 to 51) PLA add ?? (for PLA 52 to 57) PLA add 24 (for PLA 75 to 81) ABS add 74 (for ABS 58 to 67) ABS add ?? (for ABS 36 to 41) ABS add 38 (for ABS 88 to 74) Part Number Color Part Number Function 391136 ABS Teal PLA = ABS + 16 (for ABS 36 to 41) 391137 ABS Purple ABS = PLA – 16 (for PLA 52 to 57) 391138 ABS Brown 391139 ABS Silver 391140 ABS Glow green 391141 ABS Glow blue 391142 PLA Red PLA = ABS – 16 (for ABS 58 to 67) 391143 PLA Green ABS = PLA + 16 (for PLA 42 to 51) 391144 PLA Blue 391145 PLA Yellow 391146 PLA White 391147 PLA Black 391148 PLA Tan 391149 PLA Magenta 391150 PLA Neon orange 391151 PLA Neon green 391152 PLA Teal 391153 PLA Purple 391154 PLA Brown 391155 PLA Silver 391156 PLA Glow green 391157 PLA Glow blue 391158 ABS Red 391159 ABS Green 391160 ABS Blue 391161 ABS Yellow 391162 ABS White 391163 ABS Black 391164 ABS Tan 391165 ABS Magenta 391166 ABS Neon orange 391167 ABS Neon green 391168 ABS Forest green PLA = ABS + 07 (for ABS 68 to 74) 391169 ABS Navy blue ABS = PLA – 07 (for PLA 75 to 81) 391170 ABS Coral 391171 ABS Pale yellow 391172 ABS Dark grey 391173 ABS Gold 391174 ABS Bronze 391175 PLA Forest green Memory Code Function 391176 PLA Navy blue PLA add 40 (for PLA 42 to 51) 391177 PLA Coral PLA add ?? (for PLA 52 to 57) 391178 PLA Pale yellow PLA add 24 (for PLA 75 to 81) 391179 PLA Dark grey ABS add 74 (for ABS 58 to 67) 391180 PLA Gold ABS add ?? (for ABS 36 to 41) 391181 PLA Bronze ABS add 38 (for ABS 88 to 74) 391602 Rinse away Doug
I think that if we use the cube code, then the code can write these as we like once we know how. Doug
I just flashed my printer with the 1.11 firmware and the printer now thinks I am printing in ABS and I have never had any ABS in the printer. The cube print software is set up to use PLA, and the file should be using PLA to print, It cancels the print with error 0x120008 ABS not present.
