07-15-2019 02:22 PM
I want to control a Linux box via serial port. I have basic I/O working. I can see responses from the box and it echos characters that I send it. But I can't get the password to work. I know the password and can login using Tera Term. I'm wondering if there is some special handeling that I must do with the password to get it to work.
This is the response I get:
PetaLinux 2016.4 CSMS-BK00377 /dev/ttyPS0
CSMS-BK00377 login: root
Password:
Login incorrect
CSMS-BK00377 login:
Oh I welcome any suggestions to make this work better too.
Thanks,
Norm
Solved! Go to Solution.
07-16-2019 06:13 AM
I'd look into the \r\n termination (see the serial init vi) that is used by default. I don't thing it goes well with what you're doing.
07-16-2019 09:51 AM
Compare the raw hex values sent over Tera Term to the raw hex sent over labview. Probably a spacing or line return issue.
Use IO trace to see what characters are being sent over the port.
07-16-2019 10:21 AM - edited 07-16-2019 10:21 AM
1. You should also be handling the "Enter" VKey to act the same as the "Return" VKey. It is possible that you are sending a NULL character, causing the Linux terminal to give up on the login.
2. Set the mechanical action of your Stop button to "Latch When Released" and get rid of the initialization property node. When the button is read, it will then reset itself and the event case will still detect the value change.
3. Do not use a property node to get/set values. The are SLOW. In this case, you can do the job with a shift register. Create a shift register to hold the current response data and you just eliminated 2 more property nodes and made things a lot more efficient.
4. Generally, it is a bad idea to use the Bytes At Port. But it does not look like you care about getting full messages at the moment, so I won't go down that rabbit hole.
07-16-2019 12:55 PM - edited 07-16-2019 12:59 PM
Some more info. Here is my Tera Term setup. Com 4 is a Silicon Labs cp210x usb-to-uart driver
I have implemented crossrulz kind suggestions as well as a terminating string selection for troubleshooting. I also added a scroll to bottom function so that the string indicator behaves more like the Tera Term window.
The last key typed is a way for me to see what is being written to the serial port. I haven't tried NI IO Trace yet to see what LV is sending. The log file for Tera Term wasn't very helpful into seeing the hex values being sent so I do a comparison.
07-16-2019 03:11 PM
I think you can configure the log file to capture non-printable characters?
07-16-2019 03:51 PM
OP Update:
I have tried to login using a single write for the username and a single write of the password. That gets me a successful login. Something is happening to the password when I send it a single char at a time.
07-17-2019 02:29 AM
The shift register with the \n, \r\n, \r construction is a bit uncalled for. You might as well read the enum in the send event when it's needed. No need for the SR nor the 'termination string' value change event.
But you can use the shift register to add characters in the key down event. Don't send the characters, but add to the string. Unless it's an enter, then send the string and clear it...
Not really a satisfying solution, as it should work character by character, but it would get the job done.
07-17-2019 11:39 AM
Maybe something is adding a linefeed after every send?
07-17-2019 12:02 PM
@billko wrote:
Maybe something is adding a linefeed after every send?
Good thought. There is a property (actually a combination of several) to have VISA send the termination character on the writes. There is the Message Based Settings->Send End Enable and the Serial Settings->End Mode For Writes. The Send End Enable defaults to TRUE and the End Mode For Writes default to NONE. So by default, it should not be adding the termination character. But if End Mode For Writes was set to "TermChar", then it would.
However, then I would expect to send a Line Feed after every character that was sent based on the OP's current code, which we don't see.
Of course, there is also the possibility that the OP is just putting in the wrong password. It is likely that Linux is not sending the echo for the password characters, so we would expect that line to be empty.