Problems with serial communication in both directions

[Andband]

Hello guys,

What I am: A LabView Noob

What is my situation:

I have a controller for a sensor connected via the COM-port. If I write "GET" in hyperterminal, I get one pair of measurement data of it.

Now this controller has two modes which results in two different datapairs.

It is easy to switch the mode with hyperterminal. I just write

mod=d   ENTER

get ENTER

mod=h ENTER

get ENTER

and I see everything I want (using Hyperterminal, 9600bps, no hardware flow control)

This is the code, what Free Serial Port Monitor Monitors returns, when I am typing this stuff in Hyperterminal:

 Read Requests:

 6D 6F 64 3D 64 0D 0A 67 65 74 0D 0A 20 20 34 2E   mod=d..get..  4.
 38 32 43 20 20 20 20 32 31 2E 36 38 43 0D 0D 0A   82C    21.68C...
 6D 6F 64 3D 68 0D 0A 67 65 74 0D 0A 20 20 34 2E   mod=h..get..  4.
 38 31 43 20 20 20 20 32 31 2E 36 38 43 0D 0D 0A   81C    21.68C...

Write Requests:

 6D 6F 64 3D 64 0D 67 65 74 0D 6D 6F 64 3D 68 0D   mod=d.get.mod=h.
 67 65 74 0D                                       get.

What I want Labview to do:

To stay in a while-loop and always entering these commands and returning the answers of the controller in a Datafile.

Actually, I thought this is simple but I have somehow a problem with reading out it. I tried to put many VISA-reads in a row, but no single one of them contains the data itself. They contain just the commands itself jumping back and forth. What do I do wrong? (I attached a Picture of the Loop)

Thanks a lot!!

[RavensFan]

Is the device echoing back the commands?  If it is, then you are getting back the echoed command instead of the data.

Do you have the termination character enabled for this VI?

[smercurio_fc]

At a minimum I'd say you need a delay between the write and read.

You also need to configure the serial port to use the termination character since your capture indicates the reads end with a linefeed. Enable the termination, and set the termination character to linefeed (hex A).  Then for the VISA Read set a large number for the bytes to read. The Read will end when it sees a linefeed.

[Andband]

Thanks guys for answering so fast.

Yes, the device is somehow echoing the commands. I created a subvi which includes a VISA WRITE that writes the "GET" and which has 3 VISA READS. The first two, I just ignore (because this is somehow the echo of the data), in the third one there is the data I want to have. Is this a good way to do it?

Anyway I have now another VISA WRITE before this SUBVI and this WRITE should change the mode (look at attaced picture). But this doesn't work. There is just absolutly no influence of those 'mod='

commands. I now activated the termination char, too - which has Linefeed already as preset I think - but it doesn't help.

I also thought, that maybe I should give the controller some time to change the mode. How can I insert extra time the best? With the help of a flat sequence structure?

Message Edited by Andband on 11-03-2009 10:07 AM

Message Edited by Andband on 11-03-2009 10:08 AM

[Andband]

Yeah, I think you are right. Waiting time helps. I used the flatsequence structure. Is that ok for that?

Another interesting thing: I always thought, if you wire Error Ins and Error Outs you dictate a defined sequence of SubVIs/Elementes. But that is not true, at all. 

...oh, I think I was wrong, It is true...isn't it?

Message Edited by Andband on 11-03-2009 10:21 AM

[RavensFan]

Yes. A flat sequence structure works fine for forcing a wait statement to happen in sequence.  Wiring up the error wires does force VI's or functions to execute in sequence.  Since the native LabVIEW wait statement doesn't have error terminals, it forces you to use at least 1 frame of a flat sequence structure.  Just make sure you wire the error wires (and/or the VISA reference wires) through that frame holding the wait statement as well.

[Andband]

Ok I tried it like that (see picture). At least the mod commands have no some effect. But I think it is weird.

Read buffer 3 always displays the datavalues in mod=d. That is ok, and I supposed that it would do that.

But read buffer 4 displays the datavalues in some order like that

mod=d

mod=h

mod=d

mod=d

mod=h

...

thats kinda weird, why should it do that....

[Andband]

ok, was just a question of time. Now its 2 sec wait-time after every mod-change and it seems to be fine 🙂

Another thing: If there is a WAIT in a structure, will that wait time be before the other things or after? Or is that impossible to say and you should always put your wait into a frame of an sequence structure?

[AnalogKid2DigitalMan]

The way it is currently set up is not deterministic- you need to have the waits in their own frames between the write and read functions. As it is currently, the waits can execute before or after the write and read operations since they are contained in the same frame.

-AK2DM

[RTSLVU]

Instead of hard wait times I suggest you use the "bytes at port" to wait just long enough to get the data.

My example shows waiting until the byte coult is not=0 but if you know the exact amount of bytes and it's always going to be the same change it to wait until you get that byte count.

You can adjust the loop delay if needed too.