- LinuxCNC
- General LinuxCNC Questions
- linuxcncrsh telnet only taking GET commands and not SET commands
linuxcncrsh telnet only taking GET commands and not SET commands
- Daddio
- Offline
- Junior Member
Less
More
- Posts: 30
- Thank you received: 5
02 Jan 2024 06:25 - 02 Jan 2024 06:34 #289531
by Daddio
linuxcncrsh telnet only taking GET commands and not SET commands was created by Daddio
Hello folks,
I'm running into an interesting situation with my telnet connection to linuxcnc via linuxcncrsh. I have a telnet connection established, and after connecting, enabling EMCTOO, and turning the machine on I am then only able to successfully send GET commands; all my SET commands return a "SET NAK" response.
If I connect via PuTTY, I have perfect communication. I'm trying to command my machine from a python script. Here is the snippet of python code that is only allowing GET's to get thru (pun intended) and not SET's:
<python linuxcncrsh 1 picture>
Is there a piece of synax I'm missing when building my write command? I'm following each command with \r\n and encoding in ascii. Everything looks the same as my PuTTY connection in wireshark, also.
When I connect, handshake, enable EMCTOO, and turn the machine on I use this code bit which works no problem:
<python linuxcncrsh 2 picture>
The only difference is I write out the command rather than setting the string up as a variable to send.
Why would linuxcncrsh Not Acknowledge all my SET commands but not my GET commands?
Thanks and happy new year!
I'm running into an interesting situation with my telnet connection to linuxcnc via linuxcncrsh. I have a telnet connection established, and after connecting, enabling EMCTOO, and turning the machine on I am then only able to successfully send GET commands; all my SET commands return a "SET NAK" response.
If I connect via PuTTY, I have perfect communication. I'm trying to command my machine from a python script. Here is the snippet of python code that is only allowing GET's to get thru (pun intended) and not SET's:
<python linuxcncrsh 1 picture>
Is there a piece of synax I'm missing when building my write command? I'm following each command with \r\n and encoding in ascii. Everything looks the same as my PuTTY connection in wireshark, also.
When I connect, handshake, enable EMCTOO, and turn the machine on I use this code bit which works no problem:
<python linuxcncrsh 2 picture>
The only difference is I write out the command rather than setting the string up as a variable to send.
Why would linuxcncrsh Not Acknowledge all my SET commands but not my GET commands?
Thanks and happy new year!
Last edit: 02 Jan 2024 06:34 by Daddio. Reason: pictures blew up
Please Log in or Create an account to join the conversation.
- Daddio
- Offline
- Junior Member
Less
More
- Posts: 30
- Thank you received: 5
02 Jan 2024 19:45 #289591
by Daddio
Replied by Daddio on topic linuxcncrsh telnet only taking GET commands and not SET commands
I forgot to mention what the linuxcnc terminal prints out, where "X" is my laptop's hostname:
Connected to X
linuxcncrsh: eof from client
linuxcncrsh: disconnecting client X (1.1)
linuxcncrsh: eof from client
linuxcncrsh: disconnecting client Default (1.0)
I get connected and am able to SET ENABLE EMCTOO and SET MACHINE ON but then get disconnected by the server (linuxcncrsh).
Does anybody know what terminal type linuxcncrsh is set to, i.e., vt100?
What other telnet negotiations does linuxcncrsh require?
Thanks again,
Connected to X
linuxcncrsh: eof from client
linuxcncrsh: disconnecting client X (1.1)
linuxcncrsh: eof from client
linuxcncrsh: disconnecting client Default (1.0)
I get connected and am able to SET ENABLE EMCTOO and SET MACHINE ON but then get disconnected by the server (linuxcncrsh).
Does anybody know what terminal type linuxcncrsh is set to, i.e., vt100?
What other telnet negotiations does linuxcncrsh require?
Thanks again,
Please Log in or Create an account to join the conversation.
- LinuxCNC
- General LinuxCNC Questions
- linuxcncrsh telnet only taking GET commands and not SET commands
Time to create page: 0.048 seconds