@Addidis_no I guess, noone of us will. But to be serous, I like the idea. We need more machines that can be handled by everyone, not just Nerds. Just the prices do not match.
The plan, at this point, is for the EEPROM to be a 1K (that’s kilobit, not kilobyte) EEPROM chip with a 1-wire protocol interface, but I want to keep the option open to replace it with a very small, very cheap microcontroller like an attiny85. Delimiting data in bytes whenever practical makes it easier to read and write, because that’s how the EEPROM’s addressing is set up.
I wonder if a qr that downloads the data is not more efficient . Rather than make tons of hw, just do it entirely in sw in the slic3r. BAsically each filament would get an id. MFG sets up the data , put that number in slicer and it does it all for you.
The whole point is to take the slicer out of the loop. The printer should adjust for things like material temperature and diameter autonomously at run time.
I see what you mean, potentially leading to being able to pass gcodes instead of stl. I assume you are avoiding the onboard eeprom because of things like repetier making use of them? (on ramps)
No, we’re avoiding the onboard eeprom because the eeprom in question will be physically attached to the filament (presumably as part of a cartridge containing it). When you change filaments, the eeprom chip is changed too, so the settings come along with the filament. You could potentially change cartridges mid-print, and the machine would adjust to the properties of the new filament.
Ah I see, I misunderstood the “reusable cartridge” part. This stands to put pressure on filament mfg too to produce uniform product since if they did not their settings would produce bad results. Nice work.
Quick question @Whosa_whatsis , why do we need to make the eeprom store human readable characters. The qr should be readable because if someone is scanning with say a phone they want to see what is up. Why couldn’t we use a say qr10 sized code and parse the data.
By the way I think the qr should be 100% human readable for the purpose of configuring the slicer in the interm be for cartridges are adopted
I want a human-readable ID string (probably 20 characters) on the EEPROM to display on an LCD control panel when it is loaded.
Making the QR all human-readable would mean making it all text WITH field identifiers, which means a huge QR code. Better to include a URI for a human-readable form of the data. Maybe we could make the whole QR code readable as a URL, and throw all of the non-human-readable data into a GET variable that would be ignored by the server, and thus doesn’t have to encode as valid text? We don’t need the URL in the EEPROM version. This way you don’t necessarily need special software to read the QR, but you also don’t need an internet connection to load the QR data into the EEPROM.
Okay so what if all of the data was held in the url? Basically when you scan the code it would be something like http://version.sitename.org/index.php?(all of the data)
The site would parse the data, local programs could be written to parse it as well. All variables would be in binary form and Names compressed as much as possible
Putting text names for each field is still going to give you at least 5-10x as much data. I’m thinking the QR code would be http://example.com/red3mmpla?[binary blob for eeprom]
Now I am starting to get out of my web formatting comfort zone. Can we pass the binary blob through the url to be parsed nicely? It would be handy if there was a method that we could use outside of hosting all of the data in one central location. My brief Google glance didn’t answer my question.
You don’t need to. Put a short manufacturer identification string in front of the question mark and you will go to that page. The binary blob will be passed as the name of an empty GET variable, which the page will just ignore. Example.com would be the filament manufacturer/distributer’s site, and it wouldn’t even have to support scripting. The URL could also belong to a URL shortening service to make a smaller QR code, and the query string would be ignored and stripped during URL expansion. The only restriction is that the actual URL couldn’t include a real query string (which you can get around with htaccess scripting).
Except that this method would provide no benefit to those who do not have the currently hypothetical cartridge. Without the per spool data being easily readable, there would be limited immediate benefit. Long term I think it would be nice, and I realize we are penny pinching to make this code a reasonable size, but the original goal should remain intact.
Now if we stored the binary blob in a used get variable then interpreted the data, the data was then displayed in a human readable fashion, it would be a simple scan then type today, and a simple scan an flash tomorrow.
But you don’t need all that binary data to do a lookup. All you need is the manufacturer/distributer’s domain name and their unique identifier for that SKU, and they they can display a page with all of the other data on it. If you’re making a web query, that’s all the data you need to provide in order to get the full set of data and more back. If your slicer is the program requesting it, it can even replace the query (which it knows is just a binary blob) with its own name, and the server could respond by feeding the data back in the form of a pre-configured profile for that filament in the slicer’s own native format.
If that is the case, you are also requiring the manufacturer to host this data for every spool. For how long should this be hosted? I know that web storage is cheap, but that is a lot of effort for the distributor:
Make the QR code.
Host all of the data for every spool I ever sell
Manage the web traffic for all customers when ever they need to pull down spool data.
I know it is easy to say that this negligible, but we are not only asking the vendor to do more work, but we are asking them to do more work, and do it in 2 technologies, and keep track of it for us forever.
the other problem would be, it would make updating the versions hell. if the data is scatters all around the web on many different servers. getting someone at each company to update there website… best of luck with that.
My brain is turning off for the night, but as far as I can tell, it would be possible to pass the binary blob in the URL, and parse it using JS. The beauty of this sort of application would be that we could make a page dedicated to reading codes of any version, and if incompatibilities arise, we could ping the user when they scan the code saying that this code is out of date, and offer to repackage the binaries for the latest version. the QR would be a vessel to pass the firmware version to a JS engine that would manage version control. (also we could allow roll back for persons that do not want to update their firmware, but purchased a spool with incompatible binaries) just a though
here is a link to an article I was half way through when my brain gave up on me.
If we have persons willing to maintain the JS and if having a centralized website would be beneficial I would be willing to host the site. (I have plenty of space and add on domains left in my current hosting service).
@Whosa_whatsis I actually think that if you have free time and are interested we could get this hashed out by Monday, you have done almost all of the leg work, but I would be willing to help where ever I can. If we do then @Jonathan_Buford could ship some of the first spools on Monday. What do you think?