You are not logged in. Please login or register.
SoliForum - 3D Printing Community → XYZ Printing Hacks & Mods → XYZ Printing Da Vinci Jr (w) / Da Vinci Mini (w) Hacking
PM sent.
So if I understand this correctly, when a genuine spool is used, the colour information is stored in the chip and also the required extruder temp? This is handled automatically by the printer, but how does it work when your using the EMUTAG and 3rd party filament?
Texy
PM sent.
So if I understand this correctly, when a genuine spool is used, the colour information is stored in the chip and also the required extruder temp? This is handled automatically by the printer, but how does it work when your using the EMUTAG and 3rd party filament?
Texy
I print everything at 210 deg - never 190 deg as all of the filament I use adheres better at this temp.
The app I provide for the emutag has a temp option (210 or 190) - basically it is just a pre-determined colour that is set in the XYZ firmware to be 190 deg or 210 deg.
It really doesn't matter what colour the printer thinks the spool is.
If you haven't see the thread explaining the important bits..
http://www.soliforum.com/topic/16357/em … fc-phones/
Another question - as I will be going the EMUTAG route, do I still need to edit my hosts file to block the xyz website?
This means that I will not be able to update the firmware, or the application software directly?
I understand that if the firmware works then it shouldn't need ever changing, however the software may add bug fixes or new features....
thanks again,
Texy
Another question - as I will be going the EMUTAG route, do I still need to edit my hosts file to block the xyz website?
This means that I will not be able to update the firmware, or the application software directly?
I understand that if the firmware works then it shouldn't need ever changing, however the software may add bug fixes or new features....
thanks again,
Texy
That is correct. Block the XYZ sites as you never know when they may push out a firmware that will make these gains no longer work. If your printer works now, and it does, no need for newer firmware.
Just my humble opinion.
pm sent
So I am trying to understand how to change the value of page 20 (remaining meters). Can some one link me to or describe to me how one would go about converting the decimal form (say 90) to the form that would need to go into page 20?
If I am understanding things correctly (which I dont think I am). 90 would be something like this:
[20] 90 5F 01 00
[21] d8 4d 33 54
So I am trying to understand how to change the value of page 20 (remaining meters). Can some one link me to or describe to me how one would go about converting the decimal form (say 90) to the form that would need to go into page 20?
If I am understanding things correctly (which I dont think I am). 90 would be something like this:
[20] 90 5F 01 00
[21] d8 4d 33 54
It depends on what you're using to set the data.
Basically each page (decimal value of 20 or 21) consists of 4 bytes (think of it as a number from 0 to 255) - they are shown in hex normally (as yours are).
Depending on the method of setting the data you may need to convert the hex byte values into decimal (probably if you're using your own arduino solution)
If you have purchased software then read the data first and see if hex or dec values are shown...
Charlie
woogerboy21 wrote:So I am trying to understand how to change the value of page 20 (remaining meters). Can some one link me to or describe to me how one would go about converting the decimal form (say 90) to the form that would need to go into page 20?
If I am understanding things correctly (which I dont think I am). 90 would be something like this:
[20] 90 5F 01 00
[21] d8 4d 33 54It depends on what you're using to set the data.
Basically each page (decimal value of 20 or 21) consists of 4 bytes (think of it as a number from 0 to 255) - they are shown in hex normally (as yours are).
Depending on the method of setting the data you may need to convert the hex byte values into decimal (probably if you're using your own arduino solution)
If you have purchased software then read the data first and see if hex or dec values are shown...Charlie
I guess im not explaining things very clearly (prob my fault sorry). I'll try explaining it differently. In the example that was given earlier in the thread there is a calculation for 144 meters and if you convert the hex values to decimal it comes out to be something like 144099 which is divided by 1000 to come up with 144 meters. If I wanted to say set it to something like 90 meters is the starting decimal value to begin the process going to be 090000 (which you then convert into hex form of xx xx xx xx or 00 01 5F 90) or would it be something else (since on the example the 144 meters has a 099 at the end)?
I decided to buy a creality CR-10 instead of the mini w, so I have EMUTAG, etc for sale here :
http://www.soliforum.com/post/136718/#p136718
Cheers,
Texy
I guess im not explaining things very clearly (prob my fault sorry). I'll try explaining it differently. In the example that was given earlier in the thread there is a calculation for 144 meters and if you convert the hex values to decimal it comes out to be something like 144099 which is divided by 1000 to come up with 144 meters. If I wanted to say set it to something like 90 meters is the starting decimal value to begin the process going to be 090000 (which you then convert into hex form of xx xx xx xx or 00 01 5F 90) or would it be something else (since on the example the 144 meters has a 099 at the end)?
90 meters will be encoded 90 5F 01 00. The 'byte order' is reversed. See the first message in this thread. Paragraph 2.3.2 explains this.
I guess this is the simple part. Now we need to learn how to calculate the checksum that shall go into the three following pages...
BR,
woogerboy21 wrote:I guess im not explaining things very clearly (prob my fault sorry). I'll try explaining it differently. In the example that was given earlier in the thread there is a calculation for 144 meters and if you convert the hex values to decimal it comes out to be something like 144099 which is divided by 1000 to come up with 144 meters. If I wanted to say set it to something like 90 meters is the starting decimal value to begin the process going to be 090000 (which you then convert into hex form of xx xx xx xx or 00 01 5F 90) or would it be something else (since on the example the 144 meters has a 099 at the end)?
90 meters will be encoded 90 5F 01 00. The 'byte order' is reversed. See the first message in this thread. Paragraph 2.3.2 explains this.
I guess this is the simple part. Now we need to learn how to calculate the checksum that shall go into the three following pages...
BR,
Thank You, and the checksums are always XOR'd by the value
0x54321248 (as given in the post earliet) or is that value pulled from some other place in the spools ntag data?
If it's always so I believe my values listed above should be correct for page 20,21
I think you need to calculate values for page 21, 22, 23 to be able to set the length. I have no idea on how to do this.
But I I would like to know why you want to set it to any other value than 300 meters.
Edit: removed (0x) that was wrong
I think you need to calculate values for page (0x)21, 22, 23 to be able to set the length. I have no idea on how to do this.
But I I would like to know why you want to set it to any other value than 300 meters.
Simple. I have 2 emutags that were running on batteries and the batteries died prior to running the spool out (yup i made a whoops). And rather than just move onto the next tag I want to set the remaining spool size lower than the printer last knew about so it can keep printing. I look at the spool info prior to removing the tag and if its some non 100 based number (100,200,300) it would be nice to understand how to set the spool length to some other arbitrary number in the event this situation comes up again 
Teddyz wrote:I think you need to calculate values for page (0x)21, 22, 23 to be able to set the length. I have no idea on how to do this.
But I I would like to know why you want to set it to any other value than 300 meters.
Simple. I have 2 emutags that were running on batteries and the batteries died prior to running the spool out (yup i made a whoops). And rather than just move onto the next tag I want to set the remaining spool size lower than the printer last knew about so it can keep printing. I look at the spool info prior to removing the tag and if its some non 100 based number (100,200,300) it would be nice to understand how to set the spool length to some other arbitrary number in the event this situation comes up again
Ok, if you know what value you want you can do it online by converting the decimal values to hex, but will will not be able to get the values for pages 21, 22 and 23 but I would be glad to help you with these values. You have to enter the values for pages 10, 11 and 29 and the JR will populate the other two.
Ah, I see your problem. I have modified my printer to not be so picky about what spools to use, so I could theoretically set it to any length and after some printing give you a set of data for the remaining length on my card. I think the numbers for 200m are published, but it would take me some time for me to print down to 90m.
I agree with you that it is nice to know how to do things like this. Or even better, find out how to do.
Ah, I see your problem. I have modified my printer to not be so picky about what spools to use, so I could theoretically set it to any length and after some printing give you a set of data for the remaining length on my card. I think the numbers for 200m are published, but it would take me some time for me to print down to 90m.
I agree with you that it is nice to know how to do things like this. Or even better, find out how to do.
If you have a JR you just set the EMU to 90m the start a print and turn the printer off prior to the print starting. The printer will update the EMU tag with all of the check sum digits and there you go.
Teddyz wrote:I think you need to calculate values for page (0x)21, 22, 23 to be able to set the length. I have no idea on how to do this.
But I I would like to know why you want to set it to any other value than 300 meters.
Simple. I have 2 emutags that were running on batteries and the batteries died prior to running the spool out (yup i made a whoops). And rather than just move onto the next tag I want to set the remaining spool size lower than the printer last knew about so it can keep printing. I look at the spool info prior to removing the tag and if its some non 100 based number (100,200,300) it would be nice to understand how to set the spool length to some other arbitrary number in the event this situation comes up again
I believe these are the values for 90m
80 4A 5D 05
Also, I have not confirmed this yet, but I read on another thread that the printers can only store so many tags ID's and after a certain amount they will be to roll off. I do not have a printer I test test this with as I have an old firmware version of a JR. If this is true you will not have to worry about running out of UID's.
Teddyz wrote:Ah, I see your problem. I have modified my printer to not be so picky about what spools to use, so I could theoretically set it to any length and after some printing give you a set of data for the remaining length on my card. I think the numbers for 200m are published, but it would take me some time for me to print down to 90m.
I agree with you that it is nice to know how to do things like this. Or even better, find out how to do.
If you have a JR you just set the EMU to 90m the start a print and turn the printer off prior to the print starting. The printer will update the EMU tag with all of the check sum digits and there you go.
I have a Mini. It seems to skip validating the checksum.
I entered this:
20 90 5F 01 00
21 00 00 00 00
22 00 00 00 00
23 00 00 00 00
Then I printed a spool-clip and could read this:
20 4A 5E 01 00
21 02 4C 33 54
22 5A 62 E1 CE
23 5C 50 48 76
Just mine, or same for all minions?
If you have a JR you just set the EMU to 90m the start a print and turn the printer off prior to the print starting. The printer will update the EMU tag with all of the check sum digits and there you go.
And there I realize I didn't read what you wrote... Sorry for that!
Bozotclown1970 wrote:Teddyz wrote:Ah, I see your problem. I have modified my printer to not be so picky about what spools to use, so I could theoretically set it to any length and after some printing give you a set of data for the remaining length on my card. I think the numbers for 200m are published, but it would take me some time for me to print down to 90m.
I agree with you that it is nice to know how to do things like this. Or even better, find out how to do.
If you have a JR you just set the EMU to 90m the start a print and turn the printer off prior to the print starting. The printer will update the EMU tag with all of the check sum digits and there you go.
I have a Mini. It seems to skip validating the checksum.
I entered this:
20 90 5F 01 00
21 00 00 00 00
22 00 00 00 00
23 00 00 00 00Then I printed a spool-clip and could read this:
20 4A 5E 01 00
21 02 4C 33 54
22 5A 62 E1 CE
23 5C 50 48 76Just mine, or same for all minions?
So on my JR-w I did someting similar to this one time and it worked. I had killed the batteries before and simply updated field page 20 with the values for 100 meters (not changing 21-23) and the printer fired up and started printing no problem. But when I try and go back and do it again for the 90 meter value on my plain JR it just tells me unidentified spool.... very odd.
So on my JR-w I did someting similar to this one time and it worked. I had killed the batteries before and simply updated field page 20 with the values for 100 meters (not changing 21-23) and the printer fired up and started printing no problem. But when I try and go back and do it again for the 90 meter value on my plain JR it just tells me unidentified spool.... very odd.
I too have had issues with truing to re program the emutag with saved data from the prior run. It seems to know the exact numbers and off it is off, spool error. However, it may have been my error in either saving or writing the data.
Right now, if I get an error, I just use a new UID. There are over 400 valid UIDs, PW and PACK on this thread. 400*300M = 120000 meters. Thats a lotta filament to use.
Also, I have not confirmed this yet, but I read on another thread that the printers can only store so many tags ID's and after a certain amount they will be to roll off. I do not have a printer I test test this with as I have an old firmware version of a JR. If this is true you will not have to worry about running out of UID's.
To support Mr Clowns post about remembering a limited number of tags, which make sense, I'll have to start saving the data I start a UID and then try to re-use the earliest every so often to tract this done.
UID inventory management. FIFO, FILO, FISH. umm....
If my Jr's were not running almost constantly I would probably take the time to run down the IC's on the boards and track down which could potentially store the spool data. Has anyone ever attempted to track down which potential IC's in the printer may house this data?
If you have a JR you just set the EMU to 90m the start a print and turn the printer off prior to the print starting. The printer will update the EMU tag with all of the check sum digits and there you go.
Is this the only function of the printer that would perform this operation or would something like a "clean nozzle" function also work?
Maybe a change spool cycle even?
Is this the only function of the printer that would perform this operation or would something like a "clean nozzle" function also work?
Maybe a change spool cycle even?
That is an interesting question, I don't know if changing spools updates the tag or not.
If my Jr's were not running almost constantly I would probably take the time to run down the IC's on the boards and track down which could potentially store the spool data. Has anyone ever attempted to track down which potential IC's in the printer may house this data?
I have no JR, but I guess it should be possible. I made changes to my mini so I can use the same serial number over and over again. If you succeed, keep it as a secret so they don't increase the protection on next FW or model.
woogerboy21 wrote:If my Jr's were not running almost constantly I would probably take the time to run down the IC's on the boards and track down which could potentially store the spool data. Has anyone ever attempted to track down which potential IC's in the printer may house this data?
I have no JR, but I guess it should be possible. I made changes to my mini so I can use the same serial number over and over again. If you succeed, keep it as a secret so they don't increase the protection on next FW or model.
I was thinking more towards the idea of taking and reading the content of the IC and then after how ever long rewriting that same content back to the IC effectively "resetting" the memory state. It's been a little while since I've had to read/write IC's but in theory even if they have some type of protection to prevent the IC chip's content from being tampered with you can still do a raw dump of the IC's content and write the raw dump back to the chip and never really tinker with the secured data. It's not that I would be trying to tinker with it anyway. I just want the IC to develop long term memory loss
SoliForum - 3D Printing Community → XYZ Printing Hacks & Mods → XYZ Printing Da Vinci Jr (w) / Da Vinci Mini (w) Hacking
Powered by PunBB, supported by Informer Technologies, Inc.
