Send Data thru Serial THR?

[CodeMunkee]

I would like to send commands to my instrument thru a serial port.  Specifically, I would like to send a (CTRL-U) to the THR port, then send 1024 bytes of ASCII, then send another (CTRL-U).  I am unfamiliar with serial ports, and confused as to how to accomplish this task.  My botch job is attached.  Can someone straighten me out please?

Thanks!

[Dennis_Knutson]

You are sending hex 15 which is CTRL-U so that is correct. What exactly are you having trouble with?

[CodeMunkee]

I'm doing it right?  That's kind of a bummer.  I thought it was operator error.  My instrument is not responding correctly.  There is something else I can check...  If it doesn't work, I'll be back with more details.

Thank you for your quick response.

[JasonSmith]

You are explicitly unasserting DTR and RTS in your VI, is this required by your instrument? Sometimes when devices require software-handshaking using the modem lines, you may need to add a small delay before you transmit data. This will ensure that these lines have time to be set on the serial port and be recognized by your instrument before you start sending data.

-Jason S.

[CodeMunkee]

I thought this Unasserting was required by LabView to correctly define where the data was written when using the VISA Write.  Am I wrong?  Yes, I have placed a small delay (300ms) prior to sending the dummy ASCII chars.  No real change in response yet. 

[CodeMunkee]

I'm back.  I had a few more commands to try, but still have trouble.  Here is what I am told...

All comands to be sent thru the THR port

CTRL-U - toggles the instrument into a mirror where it simply reflects bytes that are written.  this is how I am supposed to write my ASCCI header metadata info.

CTRL-Y - begins recording data to memory, prepends 1024 bytes ASCII to binary file then starts logging.

CTRL-Z - ends all data recording

So the order of commands I need to send are:

1. CTRL-U (turn instrument into mirror)

2. CTRL-Y (begin data record to disk)

3. send 1024 bytes of ASCII

4. CTRL-U

5. Add button that allows for a CTRL-Z

I am unclear about this Asserted/Unasserted business.  Previously, I had to turn DTR and RTS States to Unasserted to write to them, and then turn them back to Asserted, but I am uncertain of what this does.  All of this is contained in a while loop.  Do I need to Unassert DTR and RTS *every* time I use a VISA Write command to send the command to the THR port?  Code attached.

[Dennis_Knutson]

Normally, you don't have to do anything with the control lines. If you select handshaking, it's done for you by the driver. Trying to do it manually is probably just going to mess up the precise timing and confuse the instrument at the other end.

Sometimes, the instrument does require you to manipulate the control lines. Could you post the manual so that someone can see what it says?

Message Edited by Dennis Knutson on 02-09-2009 05:48 PM

[CodeMunkee]

Normally, you don't have to do anything with the control lines. If you select handshaking, it's done for you by the driver. Trying to do it manually is probably just going to mess up the precise timing and confuse the instrument at the other end.

Handshaking has been necessary for me for at least one other task (turning on a magnetometer light thru the serial port) while some functions have not required manual handshaking.  I assume that since the previous instrument code specifies the THR port that handshaking is necessary.  I will test it once I get the syntax correct.  But first...

1. If I use manual handshaking, is it necessary to manually set the Property Nodes DTR and RTS States to Unasserted every time I use a VISA Write command as is performed in the True case statement in the most recent code attachement (LVSupport.vi)?

2.  If the answer to (1) is yes, when I wish to no longer send data thru the serial port, must I Assert  the DTR and RTS States in order to close the port?  (I had to do this last time with my command to turn the magnetometer light on and off.)

3. If I do need to have a small delay after handshaking, is there a general rule of how long or is it instrument or baud rate dependent?

Sometimes, the instrument does require you to manipulate the control lines. Could you post the manual so that someone can see what it says?

There is no manual for this instrument.  I am copying here some documentation sent to me by the original author of the FORTH code I am trying to replace.  For the record, whoever reads this, this is copyrighted material for a patented instrument called the NIMS.  You would be crazy to want to steal this code anyway.

The Goal:  to prepend 1024 ASCII characters to a binary file that writes to disk.

Thanks for the help!!

[CodeMunkee]

Too many characters for the last message.  Referenced author documentation....

 

: p? begin 3f8h 5 + p@ ( get byte from line status register LSR )

20h and 0= not until 300 0 do loop ; ( test for THR, TSR

empty )

P? is simply a test to see whether COM! THR [transmit holding register] is
empty. 3f8h is the COM1 base address, the 5 + gets the offset for the LSR
[line status register]. p@ reads it. 20h and o= not tests it. 300 0 do loop
is a delay loop after the begin-until loop terminates.

: headermode ." enter headermode" cr ^u 3f8h p!

50 0 do loop ;

HEADERMODE writes a CTRL-U to COM1, then a short delay loop. CTRL-U is used
to toggle the NIMS into and out of headermode. In headermode the NIMS simply
reflects bytes back off its serial port, thereby allowing the control
program to write characters to the data logger. Things like ." enter
headermode" cr, simply write comments to the local screen.

: headermodeoff ." terminate headermode " p? ^u 3f8h p! ." complete" cr

." any key to leave header write operation... " key drop ;

." terminate headermode" [write text to screen = WTTS]
p?              observe empty THR
^u 3f8h p!      write CTRL-U to COM1 [return NIMS to normal mode]
." ....."       WTTS
key drop        wait for keystroke before continuing execution

: headerwrite begin key dup ^u = if sp! 1

else 3f8h p! s.rcv emit sp! 0 endif

until 7 emit  headermode mm ;

HEADERWRITE is used for single byte writing of text to NIMS. It is not used
in the following code and may be deleted. Mostly it's for my own testing.

: openheader cr ." open header.tmp " cr ; openheader

OPENHEADER writes the text message "open header.temp" between carriage
returns. It executes immediately. The following two lines of code also
execute immediately:

a000h 1024 00h fill file1 openf header.tmp

    fill 1024 bytes beginning at A000h with 00h, then open file header.tmp

a000h 1 1 r/w closef ( get header into memory )

    read up to 1024 bytes from header.tmp to address A000h, then close file
    [call A000h, 1024 bytes "the buffer"]

: sendfile ." transmit header.tmp" cr

      [another text message]

1024 0 do a000h i + c@ ^z = if 20h a000h i + c! endif loop

      [scan buffer for CTRL-Z, replacing them with blanks. CTRL-Z is
      toxic to the data logger, as it's used to terminate all logging]

1024 0 do a000h i + c@ dup emit dup 00h =

if drop leave ." end-of-file character found" cr

else p? 3f8h p! endif loop ; ( send 1kbyte from

memory )

       1024 0 do           start of do loop
       a000h i + c@        get i'th byte from buffer
       dup emit            write byte to screen, leaving byte on stack
       dup 00h =           test for 00h, leaving byte on stack
       if drop leave..     true, exit from loop
       else p? 3f8h p!     false write byte to NIMS
       endif loop          exit if, exit do

: "log ." start compact flash log" cr ;

    [another WTTS]
    the following stuff executes immediately:

p? headermode "log p? ^y 3f8h p! sendfile headermodeoff 0h go

       p?                  look for empty THR
       headermode          enter NIMS headermode
       "log                WTTS
       p?                  look for empty THR
       ^y 3f8 p!           write CTRL-Y to COM1 [turn on data logger]
       sendfile            transmit header.tmp to NIMS
       headermodeoff       return NIMS to normal mode
       0h go               exit FORTH

[pflores]

Hello CodeMunkee,

In regards to the DTR and RTS lines, these are used for hardware handshaking. The Serial Communication Overview DevZone article has a simple explanation of how this works.If your hardware requires hardware handshaking, you can configure VISA to control these lines, by using the VISA Configure Serial Port VI as shown in the attached example. Setting Flow Control to anything but None gives control of these lines to VISA, so you will not be able to set or clear them manually.

- If you are using manual flow control, there is no need to re-unassert these lines everytime. You have control over these lines, so the VISA drivers will not change the value of these lines.

- In most cases, when the DTR and RTS lines are unasserted, this means the port is 'turned off' for receiving. This is because the transmitter on the other end will check these lines before they send data and if they are both lowered, then it will not be clear to send data.

Message Edited by pflores on 02-10-2009 05:11 PM