Serial only Tx and Rx once

[uss2defiant]

Hi all,

I'm having issues with my VI to communicate via serial to a NewFocus controller.

The issue is that I have to put the command and enable the Write control before I run the VI.

The command, for example VER, would then Tx and I would Rx the correct response. However, I cannot send another command after the initial command has been sent when the VI was runned.

If I'm not mistaken, I should be able to send different commands and their appropriate response while the serial port remains open.

This is true as I've tried it with the Tx and Rx pin shorted for a loopback test.

I have no issues what so ever communicating with the NewFocus controller via Hyperterminal.

The serial connection parameters are as follows: 19200 baud rate, 8 data bit, 1 stop bit, no parity, no flow control.

Attached is my VI which is a modified version of the Advance Serial Read and write example VI.

I'm not sure what's going on......
Any help is much appreciated. Thanks!

[johnsold]

The issue about enabling the Write control is easy. The terminal of the control is read exactly ONE time, probably almost immediately after the VI starts running. The value read at hat time is passed to the while loop. Inside the loop that original value is used everytime the loop iterates regardless of any changes you may have made to the control later.  This is basic dataflow - the fundamental paradigm of LV programs.

Similarly the values of Rx w/termination character? and Rx termination char are read at the beginning and only those values are used as long as the VI runs.

The terminal of any control whose value will be changed while the program is running must be inside the loop.

The ASRL Out property node is required if you want to use End Tx with termination character because that capability is not included in the VISA Config VI. The Read property node is not needed unless you want to change that property while the program is running, which seems quite unlikely. That capability is in the Config VI. As pointed out above changing the mode will only work if the control terminals are inside the loop. The property node should only be written when a value changes, not every time the loop iterates. How long does the port take to change those properties, even if it is changing them to the same values? Are you losing data while the changes are processed?

The Flush Buffer functions may be part of your problem. Flushing the buffer in a loop make it highly probable that data will be lost. Flush buffer is rarely needed.

Bytes at Port should not be used if the receive termination character is enabled. If termination characters are disabled and Bytes at Port are used, you almost always get partial messages and need to accumulate the characters received in a shift register until the complet message has arrived. Of course you cannot write the next command until the message is complete.

The 500 ms Wait runs parallel to the other code inside the loop. That may not be an issue but if you have very long messages, you may not have any delay after the message is received.

Summary: 1. Decide whether you are using termination characters or not. Configure the port accordingly using the Config VI and property nodes if necessary.

2. Eliminate Flush Buffer (at least inside loop).

3. Select appropriate read method based on 1.

Lynn

[uss2defiant]

1. Termination character for both Tx and Rx does not change.

2. I initially had the VI without the 'flush buffer(s)' and I still had the same issue. I thought to add it to make sure nothing is stuck in the buffer.

3. The same goes with Bytes at Port. I still have the same issues with or without it.

[crossrulz]

---

@uss2defiant wrote:

1. Termination character for both Tx and Rx does not change.

---

Then you shouldn't be writing to the property node inside of the While loop.  Write to the properties once before you start the write and read.

You might also want to add some delay between when you write a command to when you read it.  And since you are using termination characters, you don't need to check the Bytes At Port.  Just put in a really large number for the number of bytes to read and the read will complete when the termination character is found.

[uss2defiant]

Ok. I think I got it to work now.

Here's what I found:

The Tx property node needs to be in the while loop and so does the Rx property node.

Both termination character of the Tx and Rx are different with my interface are different but do not change at all.

If the property nodes aren't placed before the VISA write and VISA read, I think they would revert back to the Setting on the VISA Config.

I tried both the suggestions by the previous two posts removing them and placing it outside the loop did not work.

Would either of you like to elaborate further on your replies since what I current have working contradicts your comments?

I most likely misunderstood your replies.

Thanks.

[johnsold]

I cannot explain why it seems to work the way you are seeing it. In my experience things stay as set.

You have a lot of extra code in there and still have not followed the advice we gave you with regard to Bytes at Port.  It may be that the program is not doing what you expect because of the abuse of Bytes at Port.  The sequence structure, except for the frame containing the delay is completely unnecessary due to dataflow. The error case structures are not needed because VISA Write and Read use standard error in functionality. See the Detailed Help for those functions for more information.

I have attached a cleaned up version that I think should work the way you want.  

Lynn

[uss2defiant]

Lynn,

Thanks for the feedback.

I did the property node to bypass the VISA read when no Bytes were received as opposed to waiting.

Maybe use VISA event instead of that?

Do you know how long the VISA read waits on to receive Bytes? The timeout that was set in the VISA config?

Thanks for the cleaner code.

Seems to work fine except for replies from the device. An acknowledgemnt will proceed with a CR, LF, and ending with >.

So now I'm getting in the read buffer as \n>some acknowledgement\r instead of

some acknowledgement\r\n>

I seems like it's still looking for a CR as termination character even though you've set it to 0x3E which is a > symbol. Maybe the VISA config can only be set as CR or LF??

I suppose I have to use the Property node then to set the Rx termination character.

[johnsold · Accepted solution]

You should not need to use the property node to set the termination character. I am not aware of any limitation on the termination character, although there may have been some reports of strange behavior with x00 or xFF. 

I think I found the issue: Careful reading of the help files seems to indicate that there is only one termination character. The same value is used for both read and write! So when the VISA Serial Config VI runs it sets the termination character to >. Then the property node changes it to \r.  The fix is to use > in Config, turn off termination characters for write, and programmatically append the \r to the write buffer.

This works on my serial port when I have a loop back connected (RxD connected to TxD) and I include > in the write buffer.

Lynn

[uss2defiant]

Thanks!