Rework of Driver APIs

[dbeuchler]

Things for MORYX 10:

• Replace Driver-callback mechanism by async-Tasks
• Make StateClassification extensible for other drivers
• Rework IMarkingLaserDriver and remove unused stuff (Warning/Error-events+requests)
• IAxesController should accept arrays of instructions, for moving multiple axes at once

Points for discussion

• Do we really need a driver for a weight scale? Couldn't this be represented as IInputDriver
• Do we need a scanner driver or could they be reduced to IInputDriver or at least be combined with RfidAntenna?
• Merge with Simplify driver APIs #628 - won't do!

[dbeuchler]

Consens after discussion with @1nf0rmagician

• We keep IWeightScaleDriver but inherit from IInputDriver<T>
• We keep IRfidDriver but inherit from IInputDriver<T>
• We keep typed inputs and outputs
• We keep typed IMessageDriver<T>

[dbeuchler]

@1nf0rmagician I have not used the FunctionResult for the DriverResponse because it cannot be inherited and must be used as it is. Different thought: Do we need a response base for drivers? We write the error inside a class, but the TPL uses exceptions for that. We should throw exceptions when a call is not possible, then all TPL APIs are also working.

• The async/await pattern in C# is designed to work seamlessly with exceptions.
• When an exception occurs in an async method, it is captured and re-thrown when you await the task.
• This means you can use try/catch blocks naturally, without reinventing error handling logic.
• Compatible with Task.WhenAll(), ConfigureAwait() and Cancellation tokens

Using custom result objects breaks this natural flow and requires extra boilerplate. Developers might forget to check Success, leading to subtle bugs. Exceptions force attention because unhandled exceptions bubble up and fail fast.

I will change that for all driver APIs.

[dbeuchler]

@1nf0rmagician TODOs but not part of this Pull-Request #784 #785 #786

[Toxantron]

@dbeuchler and @1nf0rmagician sorry for not being aus involved recently as I planned to. Could you eloborate why you keep the generic interfaces? Given the little benefit and the import regarding proxies, I don't fully understand your decision.

[dbeuchler]

@dbeuchler and @1nf0rmagician sorry for not being aus involved recently as I planned to. Could you eloborate why you keep the generic interfaces? Given the little benefit and the import regarding proxies, I don't fully understand your decision.

We inherited the IWeightScaleDriver, IRfidDriver from IInputDriver to use it in a more generic way but with typed payloads. Removing the type from the payload would lead to more and more casting and abstraction to the lowest level. At the moment we do not need this level of abstraction and keep the typed interfaces. Do you have additional arguments why to remove the type? Do we overlook something?