Writing to serial port and looking for characters returned

[TestEngineer11]

Hello,

I have a UUT that has an embedded processor on it. I want to run a certain test on it and it requires the following steps:

1. send a 'reset' command
2. immediately send any character to stop the full boot process and bring up test menu
3. send '1' once test menu has come up
4. send '1' again to select the specific test
5. read the serial port until 'test passed' text is read. 

Can you take a look at my VIs and see if my approach is good? The first VI accomplishes step 2. The second VI accomplishes steps 3-5 (send reset command) is not shown in this VI, will be executed in a separate VI. 

Thanks!

[crossrulz]

Does the UUT spit out many lines and then a single line contains the "test passed" text?  If so, then completely get rid of the Bytes At Port and greatly simplify your VI.  You can just tell the VISA Read to read more bytes than you ever expect in a single line.  This will allow the termination character to stop the read and you get a single line of data.  You then only need to search in that line for the desired string.  This will eliminate the need for your buffer shift registers, the concatenate strings, and your waits.

[TestEngineer11]

HI crossrulz,

yes the UUT will spit out a few lines of text and the one I'm lookinf for is the 'test passed.' I see what you;re saying there, I can get rid of the items you mentioned. 

However, in the first VI, I believe the approach is good because the boot process takes a little while, with a bunch of text spewed out, until it stops at the 'test menu' portion,  so I believe I want to continuously monitor the port so that I get the timing right because:

1. send reset command

2. send any character (wait for the test menu to pop up)

3. Send '1' within 3 seconds of the test menu popping up (otherwise normal boot will proceed)

So for me, the timing of all this is crucial. 

[Alexander_Sobolev]

Technically while using bytes at port you need to (I see all these potential sources of error in your approach)

1) check if this value stopped changing

2) or bytes at port = 0, but not at first iteration because instrument might be thinking) and

3) look for result string in concatenated string, not read bytes.

4) what if test fails and response string is different.

With termination character logic becomes much simpler

Small things

On the first picture you can reduce sequence (just place Timer into 1 frame) 

Put second timer that you do not use into sequence

Add delay into first loop

Check error to stop loop (you can wire it into Boolean operations without unbundling status)

[crossrulz]

---

@TestEngineer11 wrote:

HI crossrulz,

yes the UUT will spit out a few lines of text and the one I'm lookinf for is the 'test passed.' I see what you;re saying there, I can get rid of the items you mentioned. 

However, in the first VI, I believe the approach is good because the boot process takes a little while, with a bunch of text spewed out, until it stops at the 'test menu' portion,  so I believe I want to continuously monitor the port so that I get the timing right because:

1. send reset command

2. send any character (wait for the test menu to pop up)

3. Send '1' within 3 seconds of the test menu popping up (otherwise normal boot will proceed)

So for me, the timing of all this is crucial. 

---

Yes, and I assume the test menu has a line for each option.  So you should be able to detect the first option using the read lines method and then send the 1.  3 seconds is an eternity.