[NOTICE] Removal of BitString PlcValue types and update to using PlcBYTE etc.

[Christofer Dutz <ch...@c-ware.de>]

Hi all,

while doing the pre-release grooming of our codebase and testing the drivers agains the hardware that I have here. I noticed painfully that it seems every single diver handled the BYTE, WORD, DWORD and LWORD types differently.
I reached out to colleagues of mine from the Automation department and reached out to people on LinkedIn.

Together with previous input on discussions here on the list, I decided to remove the BitString types completely and updated all drivers to now use the PlcBYTE, PlcWORD, PlcDWORD and PlcLWORD datatypes, which currently seem to be clones of the unsigned integer types.

Even if I think it’s a bit of a step back, it doesn’t help if the rest of the world sems to be using the datatypes this way. Also does it make implementation a lot easier (Actually the main reason I ended up liking this option).
Cause now the users have to deal with stuff like “bit-order” etc. Before this switch I was really trying to find a sensible way how we define the order of the bits as soon as more than one Byte is involved.

I really hope this cleans up a lot of things in the drivers and makes things simpler for our users.

Chris

Re: [NOTICE] Removal of BitString PlcValue types and update to using PlcBYTE etc.

[Lukas Ott <ot...@gmail.com>]

+1

On Wed, 28 Sep 2022 at 16.31, Christofer Dutz <ch...@c-ware.de>
wrote:

> Hi all,
>
> while doing the pre-release grooming of our codebase and testing the
> drivers agains the hardware that I have here. I noticed painfully that it
> seems every single diver handled the BYTE, WORD, DWORD and LWORD types
> differently.
> I reached out to colleagues of mine from the Automation department and
> reached out to people on LinkedIn.
>
> Together with previous input on discussions here on the list, I decided to
> remove the BitString types completely and updated all drivers to now use
> the PlcBYTE, PlcWORD, PlcDWORD and PlcLWORD datatypes, which currently seem
> to be clones of the unsigned integer types.
>
> Even if I think it’s a bit of a step back, it doesn’t help if the rest of
> the world sems to be using the datatypes this way. Also does it make
> implementation a lot easier (Actually the main reason I ended up liking
> this option).
> Cause now the users have to deal with stuff like “bit-order” etc. Before
> this switch I was really trying to find a sensible way how we define the
> order of the bits as soon as more than one Byte is involved.
>
> I really hope this cleans up a lot of things in the drivers and makes
> things simpler for our users.
>
> Chris
>