You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is driven by an MTConnect use case but may be applicable beyond that. My proposal is to allow fanuc_driver to act as a singular (MTConnect) SHDR Adapter rather than spawn an SHDR adapter per machine connection.
The idea is to collect data from multiple sources and publish it to an SHDR stream, making use of the optional device name prefix. This allows the Agent to make a connection to a single adapter.
Allow me to offer a few thoughts on implementation:
I would consider a design based around methods like .RegisterSource() and .RegisterSink(). This would break apart the current "machine" definition seen in YAML. A source would include connection details and collectors at minimum, possibly handlers and veneers too (I'm making assumptions about those last two based on class name alone). A sink may include additional handlers, veneers, etc and an egress.
The driver would then orchestrate flow from source(s) to sink(s). Sources should be able to be run in parallel (like with an .ExecuteAsync() method). When that comes to completion, the return is passed to each sink in parallel.
The benefits I see are [a] simplified configuration and [b] maybe some performance improvement in cases where you eliminate the overhead of multiple outputs, [c] ability to mix and match sources and sinks. This will always be limited by necessary coupling between source and sink so "mix and match" may be overselling it a bit. Depends how complicated (abstract) you want to make the sink I suppose.
The text was updated successfully, but these errors were encountered:
Conceptually related to #73.
This is driven by an MTConnect use case but may be applicable beyond that. My proposal is to allow fanuc_driver to act as a singular (MTConnect) SHDR Adapter rather than spawn an SHDR adapter per machine connection.
The idea is to collect data from multiple sources and publish it to an SHDR stream, making use of the optional device name prefix. This allows the Agent to make a connection to a single adapter.
Allow me to offer a few thoughts on implementation:
I would consider a design based around methods like
.RegisterSource()
and.RegisterSink()
. This would break apart the current "machine" definition seen in YAML. A source would include connection details and collectors at minimum, possibly handlers and veneers too (I'm making assumptions about those last two based on class name alone). A sink may include additional handlers, veneers, etc and an egress.The driver would then orchestrate flow from source(s) to sink(s). Sources should be able to be run in parallel (like with an
.ExecuteAsync()
method). When that comes to completion, the return is passed to each sink in parallel.The benefits I see are [a] simplified configuration and [b] maybe some performance improvement in cases where you eliminate the overhead of multiple outputs, [c] ability to mix and match sources and sinks. This will always be limited by necessary coupling between source and sink so "mix and match" may be overselling it a bit. Depends how complicated (abstract) you want to make the sink I suppose.
The text was updated successfully, but these errors were encountered: