Copied serial port access fails

[CyO Mike]

Hello all-

I've been working on this for a couple of days and I can't figure out what's gone amok here.

In short, I'm polling a motion controller to see when it has completed its movement.  I wrote a nice,
tidy little while loop that queries the controller, parses the response, and repeats as needed.  It
works brilliantly for the first iteration in my code (the homing routine) but then fails to deliver a
response in the second iteration (waiting for completion of initial index).  The request for status
goes out, but nothing comes back.  This is under LabVIEW 8.5 and, if anyone cares, the device is
a Newport SMC100 motion stage controller.

I know it SHOULD work- if I go into HyperTerminal and manually type the commands, I can watch
the motion progress and ultimately complete, so the controller is capable of responding to these
commands while moving.  It works fine when I open the Instrument I/O Express VI, although then
the motion isn't working.  The command is immediately preceeded by another command to the
device which gets there fine, so I know the device and the serial port are okay.  It can't be an issue
with the previous command tying up the device because if I stick a long-ish (3s or more) wait in,
I still get the glitch.

I'm watching the comm port traffic on Portmon, and what I see is
0.00000115    LabVIEW.exe    IOCTL_SERIAL_GET_COMMSTATUS    Serial0    SUCCESS       
repeated over and over and over until the timeout hits.

This is very frustrating- I'm very new to LabVIEW and this sort of thing keeps happening over and
over.  It seems like there's an awful lot of "tribal knowledge" surrounding the serial port usage,
and I've yet to see a good, single-source list of problems of this sort. 

Thanks!
Mike

[Albert.Geven]

Hi Mike

I'm sorry your program is way to complex to find out why this happens.
Try to split initialize and the function you are testing to separate.

Another thing is that Newport has a nice labview driver, where you don't need the ioassistant so much.

Please try in a simple version of this program. Now debugging is very difficult.

[Ray.R]

It is unfortunate that the IO assistant hides so much of the code..  It makes it difficult to "look" at the code and point towards the problem area..

[exo]

I'm having my own troubles using the SMC100 with LabVIEW 8.5 on a MAC.  I'm not even sure I'm talking to it at all.  In any event, I have some previous experience with a MM4006 and LV. There, as with the SMC, I use the LV TCP protocols. This allows me to remotely access a device, through a TCP to RS232 convertor.  In order to get the MM4006 to work, I had to close the connection after every command sent and reopen it for the next command.

Try it. Maybe it will help.

[olifr]

Hallo CyO Mike,

unfortunately I'm responding so late to your post, so I hope you are still listening for replies.

I've discovered almost the same problem with the same controller. I'm using two cascaded SMC100 and communicate via a USB<-->RS232 adapter. The same phenomena, issuing commands work fine, but queries sometimes won't get answered. I start an absolute motion and query position and status while moving (xxTP? and xxTS?) and don't get any response from the controllers. Sometimes yes, sometimes no.

I don't use this IO Assistant, I don't like ExpresVIs at all since I've used one and debugged for weeks to find out that it produced a memory leak in my application:-(

I used both, the provided LabVIEW driver and my own customized message strings via VISA, but that don't make any difference.

Since you've posted in february, have you resolved this issue, can you tell me anything interesting about that? At the moment I'm pretty sure that my code works (I'm definetely no LabVIEW newbie anymore) and I suspect this USB-RS232 adapter not working correct, but I couldn't verify this theory yet, because of lacking hardware.

Greetings

Oli 

[Song_M]

Hey Olifr!

Often times I have r un into problems where I will write to my RS232 instrument and not read anything back.  Sometimes, the simplest fix is to add a delay between the write and the read.  That way the instrument gets time to process the write, and allow you to read something back on the bus. 

[olifr]

Hallo Mr Song,

thanks for trying to help me. That's definetely not the problem, I inserted delays of up to 100ms, and even single step debugging showed up the same behaviour. What would help me is to contact the initiator of this thread, maybe he has resolved the problem. But unfortunately I haven't got his email and it is very likely that he (maybe she) doesn't watch this thread anymore, because it is almost over half a year old. It's great that you've answered!

Greetings Oli

[Song_M]

Hey Oli!

The original poster probably isn't monitoring this thread anymore; however, I can try to supply what you need.  You seem to be doubting the correct working of your USB-RS232.  Could you test with a straight RS232 connector?  Also, would hyperterminal work for you?  Thank you Oli!