Post has attachment

Just wondering what the latest status of the UFIS is? I found this info today and its looks like there is no further updates/progress since June. I have the ear of major filament manufacturer and wondering how I can help or get more involved.

It's been a couple of months since this been posted to and it's not quite Halloween but I'm necromancing this.

+OctoPrint​ 1.2.0 just came out and +BotQueue​ is also going through stuffs right now, plus +Gina Häußge​ (since you weren't already tagged in this post before) is doing some great stuff with wanting to standardise crap. Point being, good time to find where everyone is at on this project.

Post has attachment
Looks like we have everything that I need to get the new tab to hook it all up in the UI. I'm working on a conference submission right now (distributed physics calcs in #golang) so I've got to get that in a good state before I can turn to getting our plugin in place. We'll have to duplicate the webcam URL settings so that we can pull out the snapshot to run the QR recognition through unless we can grab them from the other settings? I'll do some more digging as I get closer.

This seems very interesting. I am interested in making a stand-alone extruder/hot-end controller.  It would use a USB based barcode scanner to identify spools and a memory card to store information about the various attributes to optimize printing (temps, print speeds, etc).  It would use i2c to communicate with the main control board of the 3d printer.  What is the status of this project?

I wanted to update everyone with why I have not posted. After reading through my NDA for my day job, I had some concerns with the wording. I am have one more meeting I need to schedule to finalize my exemption of UFID from my NDA (making the company aware that I am taking about these things publicly, and they agree that it is not a conflict of interest for me). This took longer than I thought it would, it will be a bit longer before I can continue to publish things.

I have not forgotten, but wanted to insure everything was on the up and up legally.

Feedback before I start real coding, everything looks like it should workout ok. I do need to know what Mcode to send things to / which branch of Marlin I should use on my local machine to work against

Post has attachment
A discussion popped up and has been going through a couple of threads in the 3d printing community about a developing a standard for using ribbon cables to wire everything together. I've taken over and dictated that pins on the cable to the extruder need to be set aside for a data protocol (probably I2C, but RS485 and a few others are under discussion) for use with UFID and other peripherals. I just realized that I should cross-post here for feedback.

I'm currently trying to find the best way to arrange the the data and thermistor pins to avoid crosstalk, and I'm thinking of interleaving those with each other to get them away from the FET-driven pins that are switching significant current. +Camerin hahn, this sounds like it's related to what you do, right?

+Whosa whatsis, +Ross Hendrickson, and myself had a meeting recently. We decided that what we need to focus on is a proof of concept build. So here is a summary.

Where we are today:
We have a standard
We have a web interpreter. This will read tags and make slicer profiles.
We have a code generator.
Volumetric extrusion has been implemented in marlin and smoothieware

What we need to do a proof of concept:
M-Codes to write a code to EE-Prom (+Whosa whatsis )
Internal workings to adjust some print parameter based upon the EEprom data(+Whosa whatsis ??)
Program for scanning QR codes and translating them to M-Codes (Me)
JavaScript M-Code generator (Me, but after whosa writes the programer)
Grab a frame from octoprint and pass it to the code interpetter (+Ross Hendrickson )

That is the plan right now. If we have other ideas that people want to implement and work on we should discuss them here in the computer. I saw +Richard Horne had some things he wanted to discuss. My finding is meetings are good for organizing resources, but the community is great for sourcing and discussing ideas.

Post has attachment
As discussed in the hangout, I've been shopping for i2c eeprom chips. I've decided to order this one to try:

This appears to be a pretty common and inexpensive part, and it has a page size large enough to fit the entire UFID code. We could have gone with an eeprom as small as 265 bits, but that would have been broken up into 8 pages of 32 bits (4 bytes), which would probably make the reading/writing a bit more complicated.

We also might want to consider moving the 2-byte spool volume block forward a byte (switching places with mixture ID) so that it doesn't cross the 128-bit boundary, which is another common page size. BTW, color would also be split across two 32-bit pages, if we went with one that small.
Wait while more posts are being loaded