standard engine should automatically decide when to make a module asynchronous

[smithed]

No description provided.

[pollockm]

@smithed - is this still a thing?

[Beazurt]

We have the hooks needed from the modules to do this now, but it hasn't been implemented yet. I think it would be pretty easy, but we'd have to go back and make sure each module set their property properly. I also think we should only use this information to set the default behavior in the editor, but still allow users to specify what they want.

[smithed]

^^what he said

[becega]

THis would be really usefull with Modbus. Modbus master should be async

[Beazurt]

I looked into this some more today. It would be extremely easy to do if we made a simple change. This would have a small chance of breaking existing scripting code though and therefore could be a terrible idea. The engine configuration class 'Add Module to Engine' method current takes in module ID as an input. If we changed this to to take that module's configuration class instead then we would have all of the information we need to add the module with the correct default settings. Again changing the type of this input would break other code. Alternatively we could add the config class as a second and optional input, but then the API just feels odd.

A more complicated approach might be a UI method or checkbox to 'use recommended execution settings'. If a user clicks this box, then we enforce the 'Async' option and don't let a user change it. A third option may simply be to display whether or not each module is deterministic and rely on users to look at that information and make a decision.

At this point, any of these approaches will be pretty fast to implement.

[smithed]

With your first suggestion, is that edit-time or run-time? In either case I'd suggest keeping this an edit-time option and use some button to convert the run mode to the recommended settings, but don't lock it. Just put in an obvious big green button that says "what do you think is right?" to the machine. Maybe pop-up a dialog to explain why each mode was autoselected (this module is deterministic, this one isnt).

Also, when adding a module for the first time can't you use the cef add child callback to read out the module cfg and determine a good default setting for each? Or is that where you are saying the engine only gets access to the ID?

[Beazurt]

A button for a onetime change would make sense to. I was thinking a user could say they want it to run deterministically, and we automatically run things async that aren't. Then it is more of a set and forget so people don't have to reclick the button.

I tried to put this code when a module gets run for the first time using the callback. That is where the issue comes that the 'add' method only has access to the module's ID, not its config. I don't see a way to solve the problem there without changing the 'add' method, which will break anyone's scripting code that happens to use it. Once in the engine's editor UI, the refresh method can no longer easily tell which modules happen to be new (they are already added by the callback), and so it isn't easy to do it there either.

From what I can tell, we either make a breaking change to the config API to get the desired default behavior, or we make a user specify what they want. If a user is going to specify, we can either make a recommendation, or give them an option for the engine to decide for them based on their desired level of performance. I think I still prefer deciding before them, because someone can always just turn that back off and do it manually after seeing what was decided.

[smithed]

Unless you guys have updated it from the tools network version, it looks like standard engine editor node doesn't implement AddChildToNode.vi. Since only the standard engine (not the parent) cares about the async/nonasync nature, you could implement it as a second step to the add function:

The first call being to the engine parent UI class. Not in the picture, but obviously it should also not do anything if an error occurs. Magic wand reads out the module config and uses the engine cfg api to set that module as async.

[Beazurt]

Thanks! Yep that would do it. I gave this a try and it worked well...except that none of the modules implement their execution timing property yet. Adding this had the effect of essentially making everything Async by default, which is annoying. Before adding this feature, I think we would have to audit that property for every module, and in doing so actually verify their determinism. I'm not sure it makes sense to add this feature until that happens. Here is the VI that does the job (renamed to .txt) for when we want to support this. It is exactly the same as what you have above (assuming your subVI does the same thing).
AddChildtoNode.txt