Internal Error When Creating Variable From Attributes

Alex_Kempen

Hello,
Last night, I had the idea to make an improved FeatureScript variable library FeatureScript by using attributes to store variable parameters on an arbitrary part. The benefit of this implementation is that it allows for a very user-friendly approach to creating variable libraries, since variables can be easily created through the Create Variable Library UI, which includes options to make variables from an imported CSV file as well as through an array parameter. Each library is stored in a part studio in the form of "library cubes", and users can thus pick and choose which specific variable libraries they want when running Use Variable Library for the first time.

These features seemed very useful to me, so I spent the day throwing together a two part FeatureScript which could accomplish this; one to create libraries, and one to import them. Unfortunately, I ran into some errors when using lamda functions as variables, such as this example:

function(teeth1, teeth2) { return (teeth1 / 20 / 2 + teeth2 / 20 / 2) * in; }

The issue appears to be that functions as variables are unreliable in a way in which regular, non function variables are not. For example, I can consistently create an Onshape internal error through the following procedure:
1. Create a Use Variable Library function targeting the entire Variable Library Studio (importing 21 variables, including several functions)
2. Using a variable function in the part studio
3. Changing the Use Variable Library function to target only the specific variable library containing the variable function used in the part studio
This procedure results in the following Internal Error:

Unexpected null module pushing procedure (lambda)

Furthermore, it appears that using functions in two or more part studios at once is impossible; Once a variable library containing functions has been called in one part studio, attempting to use the same variable library prevents functions (but not other non function variables) from being used in the second part studio. Obviously, this behavior is very strange, and I'm curious as to whether there are ways I can get this to work, as it would be very handy to be able to easily import variables with common values and functions into all of my Onshape projects.

Here's a link to the document:
https://cad.onshape.com/documents/9cffa92db8b62219498f89af/w/06b332ccabc9d2e0aa0abf88/e/65bb32016e4ed5452638807d

ilya_baran

Thanks for reporting this and sorry it's not working right.  I filed a bug against myself to take a look at the internal error.

ilya_baran

Hi @Alex_Kempen,

I've looked into the issue and given how our caching works, unfortunately there's no way to allow calling lambdas attached to the context of one part studio in another part studio without sacrificing a lot of performance or adding a lot of complexity.  My working plan is to block this usage (in derived part studios, editing logic, manipulator change functions, and FeatureScript tables) and make sure that a clear error message is returned to avoid confusion.

At the same time, I do want to make sure that I'm not missing a really good use case.  I think that if you want to have functions available within the part studio, the easiest way to get them is by making a custom feature that sets them (and if you want them in a derived part studio, add that custom feature there too).  Someone comfortable writing a lambda would presumably be comfortable putting it in a feature studio instead of a custom feature (which is harder to edit due to the small text field).  What's the main goal behind attaching lambdas to the context?

Thanks,

Ilya

Alex_Kempen

Hi @ilya_baran,
Thanks for looking into this!

To elaborate more on my previous post, I had the idea a week or so ago to improve on the basic variable library concept. You can find the current WIP version in my FeatureScript document here.

Traditionally, users who wanted to make a set of common variables for use in various part studios would do so by writing their variables inside a basic FeatureScript in a feature studio. This was undesirable to me for a few reasons. The primary issue is that feature studios are inherently difficult to understand; users have to go through the hurdles of copying a document, writing in their variables, figuring out values with units, renaming and adding their library to their toolbar, committing their changes, etc. Additionally, the traditional approach makes large libraries less practical since the feature studio method is an all or nothing type of deal, and it also updating variables relatively annoying for the same aforementioned reasons.

The idea I had to improve on this was to use attributes to store variables in individual parts rather than a feature studio. These variables can then be read in by another feature built for that later. The major benefit of this approach is that it allowed me to create user friendly FeatureScripts for both setting and retrieving variables; accordingly, the create variable library FS is very similar to using Onshape's variable FS inside a part studio (except it's an array parameter), and it also has additional options not possible before, such as allowing users to upload variables from a CSV file, which is obviously a big improvement over manually writing variables in inside a feature studio.

Another major benefit of this implementation is that it makes creating and using multiple libraries much more practical. As you can see in the document, the Use Variable Library FeatureScript allows users to pick and choose individual libraries by choosing the parts corresponding to the libraries they wish to use. I was hoping this behavior would be extendable to lamdas, so users could create lamda function libraries (like a gear CTC calculator library) and import them like other variable libraries. Unfortunately, this is impossible due to the discoveries you and me both have made, so you can see that the current implementation imports lamda functions from a feature studio using an internal feature studio import instead. Although slightly clunkier than the variable library implementation due to the fact that you can't pick and choose individual lamda libraries, and have to do it as an all or nothing type of deal, it still works, and as you mentioned, users who are in the business of writing lamdas are also more likely to be able to figure out how to change the import themselves. The other issue is that users might be surprised by their lamda functions refusing to work properly, but if you add error messages, then I think that should mitigate that issue.

I plan on finishing the variable library FS as soon as my exams wrap up next week. I still want to add an option to import variable libraries from other part studios (attributes aren't carried over by the derive tool) to make borrowing others' libraries easier, and I want to go over my CSV import code again to make sure it's up to par. I also need to flesh out the standard function library, and I suppose I might want to make a variant for general users, and for the robotics community specifically. I'll also need to revise the documentation I've created for it, and then I can release it to the FIRST robotics community as well as to the broader Onshape community. With any luck, people will get some use out of it!

ilya_baran

Hi Alex,

Ok, thanks for elaborating -- I like the idea of variable libraries.  Attaching variables to parts is an interesting hack and without lambdas, there's no problem with it (there is currently a bug that prevents attributes from being derived, but that is being addressed).  With lambdas, the internal error you're seeing is a symptom of us not supporting using them across part studios changes to make that more clear are in the pipeline.  So lambdas will have to be defined in a feature studio and inserted into every part studio that needs them.

One more thing: we are in the early design stages of some sort of global variables solution that should make reusing variables across multiple part studios and assemblies easier -- basically your FS is a workaround for us not yet doing something I feel we should do well out of the box.

Alex_Kempen

To clarify, are attributes supposed to get carried over by things like the derive tool and the instantiator? That was an issue I ran into pretty hard while writing the get variable library FS; eventually I got it to work by running the build function, but it still felt like more work than it should have been. Will I be able to simply use the instantiator for that in the future?

ilya_baran

Yes, that's correct.  The only thing is you probably don't want the cubes themselves carrying over, so for what you're doing, the current approach is probably better than the instantiator.