ABS_S Not Working

[bmalcheski]

I have generated a new binary for ABS_S and filled the rest of the binary with 0's to complete the 512 bytes. When I try using this eeprom in my machine I get "Support not valid" error. I am able to refill the regular ABS fine. I have tried incrementing the support serial number twice now. Any ideas why this isn't working? Is there anyone who can confirm that it does work?

[bvanheu]

On Tue, Jun 10, 2014 at 9:52 PM, Ben notifications@github.com wrote:

I have generated a new binary for ABS_S and filled the rest of the binary with 0's to complete the 512 bytes. When I try using this eeprom in my machine I get "Support not valid" error. I am able to refill the regular ABS fine. I have tried incrementing the support serial number twice now. Any ideas why this isn't working? Is there anyone who can confirm that it does work?

I guess your printer doesn't support ABS_S, i think it has to do with the serial number?

Benjamin Vanheuverzwijn

[bmalcheski]

Prior to rewriting the eeprom I believe it said ABS_S was on it though... So what material name should I use to refill support cartridges?

[HaveBlueXST]

Did you use all the same values for the other fields like manufacturing date, initial material amount, etc.?

[bmalcheski]

Yes and after it did not work initially, I tried changing them. The eeprom is from a 3rd party supplier, not Stratasys. The lot number was actually "Empty". I'm not sure if any of that would make a difference...

[HaveBlueXST]

I've only ever seen 'EMPTY' lot numbers anyhow, so that shouldn't matter... So all that you modified was incrementing the serial number?

[bmalcheski]

I made a couple of attempts. Incrementing the serial number once. Then incrementing the serial again and changing the manufacturing\use dates. I also went to 55 and 55 instead of the original 56.3 on the material values On Jun 11, 2014 9:22 AM, "HaveBlueXST" notifications@github.com wrote:

I've only ever seen 'EMPTY' lot numbers anyhow, so that shouldn't matter... So all that you modified was incrementing the serial number?

— Reply to this email directly or view it on GitHub https://github.com/bvanheu/stratasys/issues/5#issuecomment-45747687.

[Bald888Eagle]

I've been poking at this for a while, and I'm not sure why it doesn't work. I've rewritten several ABS cartridges, restored cartridges to their original state, and even took data from one cartridge, incremented the serial number, and wrote to another EEPROM using the new 23 serial number to encrypt the data for that chip. It all seemed to work smooth as butter. Then I tried rewriting an ABS_S cartridge and all hell broke loose.
Have you used the stratasys parse_binary.py file to look at the newly encrypted data in your neweeprom.bin file?
I'd also like to get an idea of the OS and Python versions people are using.

[bmalcheski]

Parsing the new data that I wrote results in what I would expect based on my new parameters. I'm using Linux Mint and I believe python 2.7.4 my machine is a Dimension BST768 768. On Jun 11, 2014 9:33 AM, "Bald888Eagle" notifications@github.com wrote:

I've been poking at this for a while, and I'm not sure why it doesn't work. I've rewritten several ABS cartridges, restored cartridges to their original state, and even took data from one cartridge, incremented the serial number, and wrote to another EEPROM using the new 23 serial number to encrypt the data for that chip. It all seemed to work smooth as butter. Then I tried rewriting an ABS_S cartridge and all hell broke loose.

Have you used the stratasys parse_binary.py file to look at the newly encrypted data in your neweeprom.bin file?

I'd also like to get an idea of the OS and Python versions people are using.

— Reply to this email directly or view it on GitHub https://github.com/bvanheu/stratasys/issues/5#issuecomment-45749372.

[bvanheu]

I don't understand how a different material would break the crypto, are-you sure you used a ABS_S cartridge before in your printer?

If so, and you have a valid one, can you provide me (by email) the cartridge raw dump?

[bmalcheski]

I am quite sure that the eeprom I am trying to write said ABS_S. The last time I used it, when it went to empty, was a couple of days ago. However, I do recall seeing that the last use date was the same as the manufacturing date which was listed as some time in 2013...

On Wed, Jun 11, 2014 at 11:22 AM, Benjamin Vanheuverzwijn < notifications@github.com> wrote:

I don't understand how a different material would break the crypto, are-you sure you used a ABS_S cartridge before in your printer?

If so, and you have a valid one, can you provide me (by email) the cartridge raw dump?

— Reply to this email directly or view it on GitHub https://github.com/bvanheu/stratasys/issues/5#issuecomment-45764514.

[Bald888Eagle]

I don't get why ABS_S is causing problems either. The lot is always EMPTY, and the two dates are always (and may have to be) the same (that's why the ends of the first 2 lines of hex are always identical). I'm going to have to see if I can install the correct version of Python, sine 3.4.0 doesn't seem to like the way these scripts are written.

[sn34ks]

Did you ever get the ABS_SS issue resolved? I am having the same exact issue.

[sn34ks]

I solved the issue for my machine. In the material.py file, ABS_S and ABS_SS are listed twice. In my case my machine used ABS_SS (40) but kept getting written with ABS_SS (170). I simply changed material_id_to_name[0xaa] = "ABS_SS" to material_id_to_name[0xaa] = "DONOTUSE_ABS_SS" and everything worked perfectly.

[bvanheu]

Good catch, thanks!

I'll replace it by ABS_SS_2 until we know what's the material. Maybe it's ABS_SS for another printer but i'm not sure why they would use two different material list.

[bvanheu]

Please reopen this issue if ABS_S or ABS_SS creates any problem.

[Bald888Eagle]

sn34ks : Can you tell me what the hax dump of your new binary file is? I'm trying to get this to work on a Prodigy, which doesn't use ABS_SS, and even with the new "fix", I'm still having problems getting a valid binary file, as judged by the mismatch of the first two lines of hex, and the fact the machine rejects it. Strangely, the stratasys-cli.py script seems to read it back as OK, even though it's not. Something must be getting messed up in the packing of the cartridge byte array that gets undone when it gets unpacked from it again, or in the crypto .... Just wanted to see if your output was the same as mine.

[sn34ks]

I think there still may be an issue with the ABS_SS/ABS_S. While it works perfectly for my machine (40), I fear that other dimension machines need the second value that is now disabled(170). I have a buddy whose machine is a bit older I was going to test it on next week. I'm going to write him couple Support chips, one with the ABS_SS(40) Support and the now disabled ABS_SS(170). While mine uses the (40) I suspect his uses the (170). If that is the case, I'm not sure how to differentiate a (40) and (170) ABS_SS when reading the original chips.

BaldEagle:

Try changing these lines: 47: id_to_name[0x0f] = "ABS_S" -TO- id_to_name[0x0f] = "ABS_S_2" 72: id_to_name[0x28] = "ABS_SS" -TO- id_to_name[0x28] = "ABS_SS_2"
118: id_to_name[0xa0] = "ABS_S_2" -TO- id_to_name[0xa0] = "ABS_S" 119: id_to_name[0xaa] = "ABS_SS_2" -TO- id_to_name[0xaa] = "ABS_SS"

Maybe your machine uses the currently disabled (170)

[Bald888Eagle]

Thanks a lot Sn34ks, But if you look in my ISSUE #6, I think it's probably more complicated than that.
With regard to determining which material is on the original chip, I would think that when you run your hex dump through the stratasys-cli.py script, it should tell you the number in the materials list as well as the Hex Value, and the material name. Could you post the first 32 hex values of a few of your newly generated files, Please? At this point that would help me more than anything else.

[sn34ks]

I'm out of town for the Holiday, but when I return I will get that for you. You may want to try my suggestion above. When I had the incorrect material value it threw all kinds of weird errors for me. It would only take a couple of seconds to rule it out.