display values in magic sheets

Within a magic sheet you could expose the sACN channel data itself, which would give you the raw output data. Note that you need to actually be outputting for this to work -- ie on a console in primary/backup or client mode (or offline with visualizer, but regular offline mode will not work).

However, what are you using the "engine" for? Just know that DMX Protocol is not intended for anything that involves life-safety, which includes motor control for set pieces or fly systems. Ask yourself if it moves accidentally, could someone get hurt? If the answer is yes, then any DMX based system is not what you want to use! The biggest reason is because DMX does not have any sort of delivery guarantee or error correction, it is simply best effort.

You will see all the time where someone is reporting a problem where a light is flickering, or something is doing something not intended by the lighting designer. Things like lack of proper cable termination, using the wrong cable, RDM interactions, etc., are just some of the ways where lighting data can become corrupted or cause problems. If someone rolled the grand piano over a lighting data cable and the associated light start to flicker, you just disconnect the light and everything is okay. But when you say motor, what might move erratically left and right, and could that hurt someone.

Within a magic sheet you could expose the sACN channel data itself, which would give you the raw output data. Note that you need to actually be outputting for this to work -- ie on a console in primary/backup or client mode (or offline with visualizer, but regular offline mode will not work).

However, what are you using the "engine" for? Just know that DMX Protocol is not intended for anything that involves life-safety, which includes motor control for set pieces or fly systems. Ask yourself if it moves accidentally, could someone get hurt? If the answer is yes, then any DMX based system is not what you want to use! The biggest reason is because DMX does not have any sort of delivery guarantee or error correction, it is simply best effort.

You will see all the time where someone is reporting a problem where a light is flickering, or something is doing something not intended by the lighting designer. Things like lack of proper cable termination, using the wrong cable, RDM interactions, etc., are just some of the ways where lighting data can become corrupted or cause problems. If someone rolled the grand piano over a lighting data cable and the associated light start to flicker, you just disconnect the light and everything is okay. But when you say motor, what might move erratically left and right, and could that hurt someone.

thanks for your reply and your help.
sACN channel data is a nice idea and i tried it before.
Unfortunately i reduced the output of the channel so it would not be full.
Also ist shows the value is from 0 to 255 and i prefer to have the value in percent.  

The engine is to revolve props stuff. It do not involves life-safety. If it would include it, i would not use it.
It's not my idea to implement the controll of the engine with the console but i am the guy who have to finde a nice and user friendly way to do that.

Another thought might be to just as assign it as a submaster and always control the submaster from cues -- the end result being that you'll always have a visual representation (perhaps even more intuitively) by way of viewing the physical submaster fader...

If you go with a fader you might go with an showcontroll entry that is listening to an sACN address and coupled with a fader.

Than it is automated.