I created a sequence using Pro features such as Forms and now also CustomFunction (thanks again for the advanced user training!). But it looks like a variable generated in a Forms module cannot be used within the value field of an argument of the CustomFunction module, even though the Forms module is placed before the CustomFunction module in the sequence. Within the custom function, I can see that the variable of the argument isn’t substituted by its value but handed over “as is”, including curly brackets. Is this a limitation or am I doing something wrong here?
Nevermind. To solve my own case: I missed the difference between the point of execution of the “Class Main” and the “Function main” as mentioned in the Wiki
I’ll add the execution property so that it gets processed at the very beginning as this will sort my debugging printout better.
It looks like I missed the real issue: the CustomFunction does not generate the value before the SweepBox content is evaluated. I tried all three execution properties and the CustomFunction is several steps above the SweepBox. Stil, debug view tells me that the output value of the CustomFunction is not generated and this is why the SweepBox generates an error, complaining about trying to run “replace” on “NoneType”.
you can handover values from Form to CustomFunction (CF) in two ways:
You can define an argument in your CF script with default value being a tuple (). This leads to a Dropdown box in the User interface of the CF module where you can select a variable. The value dedicated to this variable are handed over as array to the ‘main’ function of the CF script. So, typically it is needed to extract the value e.g. using my_values[-1]
A second option is to request a String by using this data type as the default value for your argument. Then, the user can type in either a text or use the parameter syntax to handover information to the CustomFunction.
The SweepBox has already a parameter syntax replacement implemented. However, the Sweep Box is only readout once very much at the beginning of your measurement. It is related to my answer in this issue:
We basically plan to add a creation of sweep value on runtime. The realization of this feature is part of our backlog but also depends on upcoming customer projects as they have high priority to us and we often try to fit such backlog items to our customer projects.
Instead of creating a list of values with SweepBox, it is also possible to create a list directly with CustomFunction and return it. However, same problem: The list cannot be used as the source for a sweep right now.
There are still some tricks and workarounds to dynamically change sweeps during a run. One option is use a “subtractive” creation of the final sweep. For example, you can create a sweep that spans the largest possible/thinkable range. Then, use a Condition to skip points that are not needed, e.g. all values larger than the start value and smaller than the stop value.
Also feel free to contact us via direct message, and maybe we can also support you with the creation of your routine.
Thanks for the extensive explaination, as usual. I have currently implemented the argument handover via predefining them as strings, this works well. For the moment, we can do fine with selecting the output variable of the CustomFunction as a direct source for the sweep values instead of taking the detour via the SweepBox. This seems to work fine.
I guess the issue you mentioned is also the reason why I cannot have a Forms variable processed by the Calc module before using it as Start and Stop values in a sweep. But the workaround using subtractive ranges should be feasable.
That’s right. So far, SweepMe! has a phase (even before ‘connect’) where all modules are allowed to define their sweep values. Once this is done, there is no more chance to alter them.
We use this mechanism to calculate the run progress and the time it takes until the measurement is finished as all sweep values and repetitions are well known, except Loop module runs in nonstop.
Once the measurement starts, i.e. the first ‘connect’ of the first module is called, it is already too late to define further sweep values.
We plan to work on the dynamic sweep values this and next quarter.
The subtractive method works flawless. We set the sweep values for the SMU via a seperate Sweep Module, but run them trough a Calc module afterwards, together with values from a Forms module, to calculate whether they should be handed over to the SMU afterwards or skipped. This essentially allows us to move a lower and upper limit dynamically within the total range that’s preset in the Sweep Module, depending on choices being made in the Forms module.