DEV: ST1K4 needs to be used as a veto device

[ghalym]

Description

Made changes to that ST1K4 encoder value of the Y axis is communicated to the arbiter.
Also, the IN position has been modified based on a request from @tongju12

Motivation and Context

TMO needs to Use ST1K4 as a veto devices for it's components.

How Has This Been Tested?

Where Has This Been Documented?

Screenshots (if appropriate):

Pre-merge checklist

• Code works interactively
• Code contains descriptive comments
• Test suite passes locally
• Libraries are set to fixed versions and not Always Newest
• Code committed with pre-commit (alternatively pre-commit run --all-files)

[ghalym]

@ZLLentz This is then implemented the same way we do opitcs on the arbiter. And that uses UDINT instead of ULINT. any thoughts?

[ZLLentz]

UDINT instead of ULINT

I assume we were trying to save space on the EL6695 frame size. UDINT gives you a max encoder value of 2^32-1 ~ 4 billion counts = 4 meters at nanometer scale and very few things have greater than 100cm travel range here, so it's sufficient.

ULINT's 64 bits do match the native type, but we don't need the counts per se.

It's probably fine either way, we're only saving 4 bytes but it's 4 bytes of zeroes 🤷

[ZLLentz]

Looks good to me!

input from the raw enc -> type conversion -> output to the arbiter