Auto part marking scripts?

Derek_Van_Allen_BD · February 11

A common request from my team is the want for a script that automatically generates part names or numbers and etches / engraves the text into the surface of the part somewhere so that our fabrication team gets easier puzzles to put together and the drafting team gets to spend less time writing puzzle solving instructions. The text generation side of featurescript has plenty of examples to work from, as well as property and attribute handling if I wanted to label things based on part names or variables, but the automatic placement of that text onto valid locations of a part's face without dropping the text into the infinite void of the boomerang shaped splines we like to draw is a lot less trivial. I know this can be solved with a largest inscribed circle or pole of inaccessibility calculation to find the biggest candidate spot to drop a label but I'm looking for something more performant than an iterative solver method to apply to part studios that have 100+ parts that all need their own labels. I could do a net of possible grid locations with some search resolution but I've got long skinny bendy parts that will for sure miss every grid point unless the resolution is set needlessly high.

Anyone else ever make an attempt at tackling this problem or a similar one that has an example to share?

Konst_Sh · February 11

Well, what if just put the text on the largest face, optionally planar, in the point with internal coordinates of (0.5, 0.5)? Or aligned along largest edge in its center on the side of largest face?

Derek_Van_Allen_BD · February 11

@Konst_Sh (0.5, 0.5) ends up being in the void on horseshoe shaped parts. Searching along the largest edge could be a viable strategy for some parts but the middle of that edge is likely to end up corresponding to other important geometry on the opposite side of the perimeter like slots in a cross bracing piece.

I guess I could choose longest edge and search a couple of samples on that, which would be faster than a full grid approach.

martin_kopplow · February 11

I would be interested in such a feature. There are two main scenarios for me:

In early stage, we print or cut samples. It'd be nice if we could imprint the version, so everybody knows what and how current the part is.
Later in the project, we might need to produce a truckload of possibly similar looking parts. It would be good if they could all have a number engraved that is identical with their part number or name in the BOM.
If numbers on all/most of the parts could be readable from approximately the same direction, that would probably help with identification.

I could imagine the number to be placed by specifying a mate connector. Rules like "centroid of largest face" appear problematic, because they might then get in the way of other features or adjacent parts. The lower face could be a cood guess in most situations, but not always. I think it would be good to identify a deliberate corner and an edge on a large-enough face and put the number close to that corner and about parallel to that edge. Target font size to be set by the user as a general setting.

jnewth · February 11

One of the challenges with this is that FS can't read properties (it can set, but not read, nor overwrite). It can read/write attributes. Part numbers are properties. So if you want to create geometry that is driven by part number, you would probably have to manually enter it in to a "part number writing script".

We ended up creating a numbering convention for our printed studs (we are automating wood framing for housing). These studs are all programmatically generated, so the part number can be written to the property and also as an attribute, where I can later retrieve it in FS. The net effect (along with some funky-not-recommended decal trickery) gets us this:

So: Maybe write the script to apply an identifying number in series ("1", "2", …) but this will be hard to force it to match the part number property without manual modeling intervention. If other people have figured out how to get around this limitation I'd love to know about it.

S1mon · February 11

Depending on what your goals are, I would also recommend implementing QR code or Datamatrix for machine readability.

@jnewth I really wish this kind of thing with part attributes was easier.

Derek_Van_Allen_BD · February 11

@jnewth I've got a handful of scripts that retrieve part properties like material or names for operations based on the examples set by @MichaelPascoe in his get property feature, though admittedly never used it for attempting to pull "part numbers" as in the genuine part numbers property from the part numbers region of Onshape. Our company kind of doesn't use release management or version control in that way. You should try out his feature though and see how it does for you.

The nut I'm more interested in cracking is how to place those labels without placing them off into hammerspace or lighting a server cluster on fire with iterative methods or expensive evaluation commands or requiring a user to manually click hundreds of faces.

EvanReese · February 11

@jnewth love the decal trickery. I've played a bit with decals in FS and it's a bit odd, but there's more possible there than is currently implemented.

I understand that it isn't possible to get the part properties with FS (outside of a table or computed property), but do you know if the reason is fundamentally insurmountable? I'd like to believe this might change in the future as it would make SO MANY THINGS EASIER. I also imagine it gives people a lot more opportunities for shooting themselves in the foot too.

Derek_Van_Allen_BD · February 11

@EvanReese my understanding is that properties live outside of runtime and can be edited by the user before or after other features in the tree so they can't be quantified in normal logic. Tables are something of a collector of this information that for UI reasons also exists outside of logic runtime because they interact with parts of the product that aren't featurescript related.

Why this is the case? Not entirely sure. I'm sure there are good architectural reasons to do so for things like BOM reporting or integrations with PLM software or something not directly related to part generation that necessitates the separation.

EvanReese · February 11

Yeah I get the gist of how it happens now. There's an order in which the info is processed, and properties happen after features which is why features can set them, but only if they don't get overwritten later when the properties run. Tables run after the properties do, so it can access them.

I'm just wondering if there's a fundamental reason why it could never change. For example if I have a solid body with an ID of 123xyz, the properties for that part exists somewhere in the database at all times. I imagine the limitation is probably something to do with a priority on repeatable regeneration or something rather than a technical impossibility (sort of like why date/time isn't available in featurescript). You want all features to work the same way every time they run. I'm not sure if that's the reason here or something more fundamental.

@ilya_baran care to enlighten us? Is there a chance custom features will ever be able to read properties (not just in editing/manip logic)?

Auto part marking scripts?

Comments

Howdy, Stranger!

Quick Links

Categories