Serial Terminal Emulation in LabVIEW

[Ganeshs]

I am an experienced user in LabVIEW.  I am trying to create a serial terminal window in LabVIEW to work with Modem devices.  I have the following requirements:

1.  Every character I type in the window should be sent immediately via the serial port.  I use "Update While Typing" property and an event structure (value change on string control) to get the character and send it via serial port.

2.  The modem echoes the characters back which is recieved on the serial port.  As the user types in the terminal (which is really a string control), he will see the character he typed ONLY if the modem echoed it back.  If not, nothing should be displayed on the string control.  If the modem is not responding for some reason, the terminal should not display anything even if user is typing in the terminal.

3.  I would like to also support a "local echo" mode on the terminal.  User can turn the "local echo" on which should echo every character he typed in the terminal EVEN if it is not echoed back by the modem.  If the modem echoes back the character and "local echo" is enabled, users will see the character he typed repeat twice.

I am using a while string control as terminal with "Update While Typing".  I use while loop with event structure and handle event "value change" on the string control.  I can get (1) above to work.  But need some ideas to implement (2) and (3) above.

Thanks,

Ganesh

[TCPlomp]

You can use a string control. With the following tweaks you can get a lot of what you want:

Use the 'Key Down?' event.

In the event you will get the key pressed and you can sent it to the serial port. 

Based on the 'local echo' settings you can discard the event.

Putting the characters from the serial port into the control will need some tricks.

But first I would try to get the other things running.

Ton

[smercurio_fc]

You may also want to take a look at the old program LVTerm. However, it's a bit dated, so I'm not sure how much you'd be able to get out of it.

[Ganeshs]

Thanks for the responses.  LVTerm application is quite old and uses parallel while loops.  I am using event structure.  So this may not work.  I will check out the "Key Down" event and let you all know how it went.

[Rod42]

How about three independant loops, one to get typed chars, one for serial I/O, and one to update the terminal window?

Use a string indicator for the terminal window, and queues to handle data to be passed to/from the serial port.

To get characters, use an event structure looking for key down and key repeat on the string indicator. Figure out what character was pressed. Mostly the "Char" input to the event will be what you want, but watch out for control characters, so check PlatMods, and Vkey too. Some experimentation may be needed before you are able to determine the correct character, as the event will also be triggered by (for example) pressing shift. Once you have your character, put it into a charout queue.

The serial I/O loop will check for characters in the charout queue, and write any chars there to the serial port. If local echo is turned on, they will also be written to the charin queue [before writing to the serial port]. Then the serial I/O loop will read any bytes at the serial port and put them into the charin queue. Make sure that there are suitable delays/timeouts in the loop, but don't have infinite timeouts.

The update terminal loop will take chars from the charin queue and append them to the terminal indicatpr. You may want to take special action on control or other unprintable chars (like backspace), or remove chars/lines from the beginning of the indicator to keep its size down and simulate a scrolling window. Here have an infinite timeout on data appearing in the queue.

A stop button detected by the event structure will cause the queues and serial port to be closed, and all loops to terminate.

Rod.

Message Edited by Rod on 26/10/2009 17:48.. 05:48 PM

[LV_Pro]

How about a transparent string control overlaying a string indicator, the whole event structure you've mentioned, the received char being written to the string indicator.

[Ganeshs]

Transperent string control is a good idea as well.  I will try it out.  Thanks.