Question to Telnet Notifications with M118 P4

mloidl

As far as i know these messages are never sent as json.
If you send e.g. a status request via telnet then it will respond in a json format, as in the other interfaces.

In case of M118 P4 S"Some message" only "Some message" without the quotes is sent via the telnet socket.

A Former User

i've only tried serial and M117 on the Duet 2 and it was offline so I couldn't test, but they are json. So I though maybe if they were the same you could use the closing bracket.

mloidl

I'll try to send this to other targets than Telnet and check if they are in json format when i'm at home. But i still need messages on the telnet socket.

A Former User

I've had a stern conversation with the idiot who though the switchport was unused just because it didn't have active link and the Duet 2 is online again..:P

Tested, and seems to be different. No json or eol of any type. I would have expected M117 and M118 to behave similar as there is no documentation to suggest they are different in the message handling, just the targets, but no.

mloidl

@bearer : Thanks for testing this out

A Former User

I strive to set straight at least 80% of the confusion I create;)

On another note, if you cannot implement a EOL character that M118 can transmit you could always try to describe your use case and maybe some bright heads will suggest some alternative solutions for you.

mloidl

@bearer
The use case is very simple.
Read a line from telnet stream. If it matches some special message, do some action. At the moment of reading the message i do not have any information about the string i'm searching for.

What's currently not working is to read a line from the input stream, since this will never return because no line ending is sent.
I've found a solution which i don't really like.
Instead of reading a line from the stream, read single characters, build the string. Configure a timeout for the socket. If the timeout happens (SocketTimeoutException in my case because i'm doing it in java) i can take the buffer.

This works but is not a very good solution in my opinion. I think it's better to get the line ending at the end of the message so it's possible to clearly identify a single line.

Also my solution with the timeout does no work well if there are 2 messages sent within the timeout. In this case i'll get 2 messages in one line.

I've studied the Timelapse script from @resam, which does basically the same. His solution works because he's sending some status requests via telnet and is getting a json response + the message. Means there are line breaks and json brackets in the message, that's why it's working.

I think it's not too complicated to send the \n at the end of the message in firmware. The code looks very straight forward, but I've not tried to implement it yet.

The question is if there is any good reason why it's not already done.

A Former User

Thats more a description of how to want to achieve something, not what you want to achieve, subtle difference that makes a huge difference in how easy it is to suggest alternatives.

Just pick a character that you don't need to use in your protocol and use that for you EOL marker, much easier than maintaining custom firmware.

dc42

Currently a \n is appended unless the destination is http or telnet. I can change that in the 2.03.1 release to add a line ending for telnet too. Should it be just \n or \r\n ?

Edit: I just checked, and the \n is only appended in RRF 3. I'll change RRF 2 to append \r\n if the destination is Telnet, otherwise \n unless the destination is http.

mloidl

@dc42 That would be great. I think adding a \n should be enough because later in Webserver::TelnetInterpreter::HandleGCodeReply, \n is already replaced by \r\n before sending.
Hopefully this does not have some negative side effect to existing scripts or something else.

mloidl

@bearer
I agree with you that a custom EOL marker would be the easiest way, but only if i specify some kind of protocol.

Currently i'm implementing a common java lib for communication with reprap firmware. Since it's only a library, i have to be able to pass the raw string to the caller of the lib.

mloidl

Successfully tested 2.04RC1 yesterday and can confirm that the line ending is now sent correctly. It's now very easy to handle the messages from the telnet port.

@dc42 Thank you very much.