EKI: Sending Strings, changes from EKI 2.2 to 3.0

  • Just ran over this with a piece of my long-serving infrastructure code.


    I have a small library for building and sending raw strings (not XML-formatted data) over EKI, that's been in service for, oh, a good ten years now. Runs flawlessly.


    That is, until we ran it on some new robots running KSS 8.5 and EKI 3.0.


    The reason I'm writing this up is that the problem doesn't throw any errors, and the manual appears to be incorrect about the behavior of EKI_SEND.


    So, under EKI 2.x, the EKI_SEND function only accepted two arguments: the string to transmit, and the name of the XML "channel" file that defined the connection.


    But EKI 3.0 adds a 3rd parameter, an Integer (which is described as "optional"). According to the 3.0 manual, this number explicitly describes the length of the string to send, and is only relevant for sending strings of variable length. Furthermore, there's a footnote that, if the string to be sent contains ASCII NULL characters, EKI_SEND only transmits the string up to the first NULL character.


    Well, since I always set the entire string to NULLs before using SWRITE to transcribe the text I want to send, this should work. Especially since I always used a fixed-size string. So, by two different parts of the manual, my old code should have run without issue.


    But it didn't. Once we added a number (the DECL'd length of the string being passed to EKI_SEND) as the 3rd argument passed to EKI_SEND, everything started working. I'm not entirely certain what was going on, but the PLC receiving the data seemed to just be getting 0-length strings.


    The code, for those interested (the added bit bolded in red):


  • Thank you for sharing, will be useful to remember when I run into this :)


    On a related note, this is not the first time that I see documentation for software modules being just plain wrong. I would understand forgetting edge cases or explaining why some parts of an example are necessary or being incomplete. But factually incorrect, for software that's used to control machines that can cause significant property damage or halting a production line? Am I somehow weird by thinking this?

  • Well, no documentation is ever perfect. And in this case, it's possible that this isn't an error as much as a case of ambiguous wording.


    It gets stranger, too. Looking at my older backups, I can see that even at EKI 2.2, EKI_SEND was written identically to how it is written in 3.0. So the 3rd parameter was always there.


    The only thing I can think of is that CWRITE has changed slightly. Both versions of EKI_SEND make identical calls to CWRITE.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account
Sign up for a new account in our community. It's easy!
Register a new account
Sign in
Already have an account? Sign in here.
Sign in Now