Automatically incrementing serial numbers
-
It’s an interesting concept!
Given that the serial number should be supplied by a server, wouldn’t it be easier to request a new GCODE for each print? Adding serial number plates in a slicer world be much more flexible than adding it via RFF. -
@pakue That is a very interesting idea. The network-acquired serial number was an afterthought I included when typing up the message. Originally, I had only thought that the individual g-code file would self-increment. But your idea leads to a magnificent world of g-code streaming servers. Kinda like the way the world is inching towards binary-streaming servers: no installing software, run it remotely and stream the input/output.
-
@sonderzug Those are some great thoughts. I'll have to come back and read again to fully absorb them, but I like it a lot. I actually have been always thinking about this in 3D -- not X/Y planar. The "regions" could be any arbitrary orientation. To achieve the 3D version, we would just have to keep track of the separate layers of the digit, rather than have one layer that could be replicated for all layers of the digit. It certainly adds a bit of complexity, but I think it's manageable.
The idea of instancing g-code is a very good one. PrusaSlicer already instances the models (when requested, with the instance command). So, it shouldn't be too much of a stretch to implement that into g-code as well. In PS, you can either copy/paste an object, which makes two separate objects, but an instance is truly an instance -- any changes made to one, are transferred to the other and sliced. The g-code is all one thing, though, but with the ability to robustly handle relative positioning/instancing, this could all work together nicely.
-
@bot Ok, it will be interesting to see how this would work across non-XY-coplanar surfaces. to illustrate, I whipped up a quick demonstrator...
easiest case: text lines printed on planar surface (this should be the first goal IMO since this is basically what we discussed until now)
more difficult, since it is basically just an arrangement of bumps/path offsets in the perimeters* (outermost perimeter might suffice):
also more difficult than the first, since it involves more perimeters and cutting out of the infill: negative extrusion
to me, the preferred version for text on vertical or non-horizontal surfaces: slightly inward extruded text, this looks the best, but is basically a copy of #2 but with more perimeters affected
*thinking more about this description of how the text is displayed, this might actually be the way to add text (or texture, for that matter) afterwards - offsetting the perimeter by x for certain areas over y amount of layers... doesn't Ideamaker allow to apply textures to STL files? How do they do it?
food for thought...
-
@sonderzug Yes, part of the problem that arises, especially in the "3D placement" case, like you mention and illustrate with your photos, is that the numbers become "merged" with the part, and the perimeter of the serial numbers is one and the same as the rest of the model.
This is where we could make the "engineering compromise." The slicer would actually produce a separate 3D region, which contains the digit. It would have its own infill and perimeters.
Imagine if that region is a single digit of the serial number. Each digit gets its own region. That is what makes this possible. The reserved region remains the same volume, so the toolpaths of the main part don't change.
*not actually a robot
-
@bot Here is an example with the spaces for 3 digits reserbed. (These would be HUUUGE digits. This is just an example.)
-
instead of a digit, could it be a QR code or bar code? Perhaps more space efficient at the expense of human readability?
-
@bot Why not do it via a displacement map on the actual STL/3MF/mesh? That makes it very flexible to add other things instead of characters and is independent of the part surface.
-
@phaedrux Barcode would be more practival than QR code. I don't know how we could encode every possible serial number in QR codes in an efficient manner. Even if we separate the code into chunks, it's still a lot of chunks to generate and store as toolpaths. But, I don't know the specs -- maybe it turns out to be fewer toolpaths than with all digit combinations? The barcode would be a direct replacement for numerical digits, afaik.
@Pakue from what I can envision, I don't see a way to make the numbers dynamically change for each print if we emboss the numbers directly into the main print. We need discrete regions that can be sliced, printed, and stored separately.
-
@bot I'd imagine it is easier (and more flexible) to reslice with a different parameter (serial number or similar), than it is to dynamically replace portions of existing gcode and handling it on the µC. Especially if the printer is running via an SBC that has more than enough compute power for slicing.
