StringPlcMapper does not null out full string

One of my co-workers discovered this and it’s a bit annoying.

The way we implemented the StringPlcMapper if you write a string like “12345” it will write a value of 5 to the string.len tag and then it will write 5 bytes into the actual byte array for the string.

The issue comes about if you then write a shorter string, “abc”. The string.len will get updated to 3 and the first three bytes will be overwritten. BUT the value for the string array in the PLC will now be [a,b,c,4,5,\0,\0…] and this confuses some PLC functions and external programs.

StringPlcMapper.cs

I fixed this locally by creating a new, local mapper in my project that always writes the full max string length - padding it out with zeros. But it raises some questions:

1. Are there any performance implications to writing extra bytes for strings?
2. Should we do this for the different PLC types or only CLgx?
3. Should this be optional functionality or default?

@kyle-github and @timyhac - What do you guys think?

[IanRobo75]

I’m not sure what you are getting at. I wrote \0 because the string “ian” would be stored in a LogixPCCC PLC as \61 \69 \00 \6E. It makes sense to keep adding \00 from the next byte (5th byte here) until the end of the string (82nd byte), assuming the string is less than 82 bytes. Seems pretty safe to me, for all the PLCs I know, and extra time should be negligible.

From: timyhac [e-mail] Sent: Saturday, 31 October 2020 2:40 PM To: libplctag/libplctag.NET [e-mail] Cc: IanRobo75 [e-mail]; Mention [e-mail] Subject: Re: [libplctag/libplctag.NET] StringPlcMapper does not null out full string (#101)

@kyle-githubhttps://github.com/kyle-github - fantastic!

@IanRobo75https://github.com/IanRobo75 - after looking at this a little bit closer, I’m 51% sure that we can simplify the LogixPcccEncodehttps://github.com/libplctag/libplctag.NET/blob/master/src/libplctag/DataTypes/StringPlcMapper.cs#L138 logic.

What its doing at the moment is padding a \0 character only when the string length is odd, to guarantee an even string length.

I would find it a little strange if always padding the entire structure with \0s would break other cases. What do you think about this approach?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/libplctag/libplctag.NET/issues/101#issuecomment-719866080, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AIY6RY5G7CKXUQEUPCPNJALSNNTHHANCNFSM4S2KSWVQ.

[kyle-github]

@timyhac sorry, no. The comparison is always the other way when reading about how Linux mutex perform. “Looks how great Linux mutexes are, see these numbers!” And then no numbers for other platforms.

That said, there is a fairly large difference between a naive implementation of a mutex and one that tries very hard to be cheap when there is no contention. Linux tries very, very hard in that direction. That entails a lot of code which embedded systems usually leave out just due to code size considerations.