search

LabVIEW-DCAF / ExecutionInterface

A set of interfaces for code which can configure and operate on the tag bus module interfaces
https://decibel.ni.com/content/projects/reference-designs-for-distributed-control-systems
Apache License 2.0
2 stars 3 forks source link

Need to improve or refactor how timeouts are handled in the API #3

Closed Beazurt closed 9 years ago

Beazurt commented 10 years ago

The engine execution interface functions should support both blocking and non-blocking operation. That is, they each send a command to an engine telling it to change states, and the functions should be able to either wait for the state change for a given timeout period, or simply send the command and continue. Only two of the functions (initialize and get error) have a timeout input. We should either specify the timeout duration for each API function during initialize, or add a timeout input to each function. We also need to document that a 0 timeout means nonblocking and should not return a timeout error.

smithed commented 10 years ago

Could also have a different set of functions -- "request safe state" and "wait for safe state", "request pause", "wait for..." and then your existing API uses those, and you can put both the blocking (current) and nonblocking ("request...") functions on the palette. After all, the requests don't have a timeout.

Beazurt commented 9 years ago

Per our discussion today, I think the best/fastest option would be to simply add a timeout input to each function with -1 as the default value.

smithed commented 9 years ago

Done, I also added an input for "open" even though I would expect it to be synchronous. It might be nice to make the same API be able to support a networked engine (ie hide the AMC/nanomsg/whetever thats under the hood).