Serial port control -- what's this code snippet?

Question

Hi, all.
I've just become active working with LabView, version 6.0i. And this because of a program which "suddenly" stopped working, with no changes made by anyone that I can see (yeah, likely story, right?).
In short, the screenshot which I'll include with this post is of one tiny code snippet buried deeply in the .vi which runs an X-Z positioning system. I'd like to know what people thing this code snippet does. I have my suspicions, but I can't believe that whoever wrote this code actually used it for this purpose!
The X- and Z-positioners which I'm using are controlled by separate power sources, and separate ports on the computer. The X-positioner is ultra-fine-resolution, and has an optical encoder. It's controlled by the RS-232 port on the computer, and it's meant to be moved only a little at a time. The Z-positioner is a bit more coarse, and usually moves quite a bit at a time. It's serial-port controlled.
The screenshot is of the portion of the code called "XMove" -- that portion of the code which controls the x-positioning stepper motor. Often, the Z-positioner is still running during this part of the code (the "ZMove" subroutine is called before the "XMove"), and then, after both parts of the positioner have stopped, the code should shut down the power to them, and update the position of the translation stage.
However, once the code gets to this portion (screenshot), that while loop just keeps running.
Here's what I think is happening (please correct me if I'm wrong!): The Z-positioner is run by the serial port, which, as far as I know, can be controlled by only one device at a time. Thus, this While loop does the following:
1) attempts to write the characters "1R" followed by a linefeed to port 0 (the applicable serial port on this computer);
2) reads how many characters are stored in the serial buffer;
3) reads all the characters in the serial buffer;
4) takes the first two characters from the string read;
5) compares these two characters to *R;
6) if the two characters are R, then the loop terminates and the code finishes.
As far as I can tell (I've probed many parts of this structure), the code fails when the "N" portion passes the number of characters in the serial buffer to the "R" portion -- it's always zero. It appears to me that the "W" portion writes to the buffer AFTER the number of characters is read (I wouldn't have suspected this unless I'd run it many times and monitored which steps were done in which order). This ain't right!
I found a similar question answered in the KnowledgeBase forum, but the answer to that one was that the serial port may have an "echo" mode. That doesn't change the fact that data is being from to the port before it's written, does it?
Is there a way to make sure that the "read" statement happens AFTER the "write" statement? Am I way off base with what this code snippet should do? And, most importantly, *** is this a good way to tell if the Z-positioner is done with its job? ***. Is this a standard trick to tell if a program is done with the serial port?
Thanks, all. I know the quandary of trying to debug with so few details, and not having the program in front of you. Any help is appreciated!
Sincerely,
Curtis Osterhoudt
Attachments:
VI_diagram.jpg ‏17 KB

Answer 1

I suspect someone did change it, but they just don't realize they did.
THe code snippet is an example of some very bad LV code! What you suspect is happeneing is indeed true. LV uses a data dependacy paradigm that says code execution order is dependent on data availablility. Data availability is determined by ythe rule that the output of a node or sub-VI is not available until the object completes.
In you snipet, the only node that has to complete before the read bytes at port and the write to port VI is the the constant port number constant. That means that LV can execute either the write or the check bytes at port VI's first. This is determined at LV compile time. If for some reason LV decideds to compile in the write before the check bytes at port, the
n the I/O may work as intended, BUT NOT POROGRAMMED!
For a quick fix, put the contant port number and the write VI in a single frame sequence structure. This way the read from the constant and wire operation must comlplete before the seq completes, therby forcing the read stuff to wait.
I hope this help,
Ben
Ben Rayner
Certified LabVIEW Developer
www.DSAutomation.com
Ben Rayner
I am currently active on.. MainStream Preppers
Rayner's Ridge is under construction