controller communication response

[Juanjo Vega]

Hi everyone, I'm working with a SCORBOT ER-IX. I have a LabVIEW program to communicate with robot controller (controller-B). All works fine, but sometimes, my labVIEW program enters on infinite loop

The way I work is: send a command and reads serial port until ">" char comes (controller always returns ">" at end of response). Hyperterminal works fine all times, but my programs doesn't: sometimes waits infinitely for ">" and never ends because the "Bytes at serial port" function returns "0" all time and ">" is lost.

Does someone know why this happens or how can I investigate what happens to ">"?

Thanks in advance and sorry my english.

[Conseils]

I generally put a loop counter in and every time I read 0 bytes increment the count by one. I also include a delay equivalent to one character being sent and allow for say twice the standard message length plus any other overheads in the systems. If I get to the end of the count then I resend the command, if this doesn't work after say three goes.... someone has pulled the cable

[JaimeC]

Hi,

Yes that is the answer, insert timing to wait a maximum time.

Reagrds,

Jaime Cabrera

NI Applications Engineering

[Conseils]

Yup, it's been pretty bullet proof for the last 10 years or so that I have been bashing with LabVIEW.... before that of course it was all text based, guess what?

 It worked then as well, of course you were luckier then if you had the horsepower to spare.

More often than not you were lucky to get round in time for the next character... ahh bring back interrupt service levels, stacks and 1K of RAM

[Juanjo Vega]

Thanks everyone!, your ideas should work to avoiding infinite loops, but i think that controller responses can't be lost. If hyperterminal works, why my labVIEW program don't?

I wait a second between write and read, but only sometimes the "VISA Read" module don't reads anything. I'm confused because the program is very simple and should work.

If you want so, I can post the program here. Thanks everyone!

[Conseils]

Why are you waiting a  second ?
Do you leave the com port open all the time?
Are you sure the data hasn't been lost before you start looking for it (as 1 seconds 'sounds' like a long time)?


As a rule for simpler applications....(there are always exceptions) I have a receiver routine running and leave it going all the time. Then I try to seperate out the data as messages in the code. I would like to give you confidence, in that it won't be LabVIEW its self loosing stuff. Rather, more likely; it will be the software implementation and or configuration (read connection details).

P.S.
In LabVIEW 8 there is a rather nifty RS232 state monitoring VI, you might want to check this out. You could check out the web for some RS232 monitoring software to check timings for received data and port states; as this will probably help debugging.

[Juanjo Vega]

I wait for a second between the send and receive, it is: send, wait and then a loop: "bytes at serial port" + "read serial port" until ">" arrives.

I tried to wait only 500 ms. but the behaviour is the same. I even tried to wait no time between send and read.

When i started programming it, I made a subVI for open, send and close, and the return parameter was controller response, but I though that is better to open and close only one time, keeping the port open while the VI is running.

I was thinking in making a subvi running concurrently, so it reads serial port in background. In this way I could get response from serial port while, for example, homing, but I don't kown how to make concurrent VI's and is not very important.

I'm using LabVIEW 7.1, because the university bought that license.

Thanks a lot, Conseils!

[Conseils]

Try the attachment....
Its possible to have finer control by retaining the reference to the VI and closing the reference on exit from the application...


This was used for a simulator implemented in LabVIEW for a Eurotherm 24XX series PID system, fully controlled over RS232.

For each command on the simulated unit, a VI was selected and excuted to change the state of the virtual controller, this allowed the system to expand flexibly and in a modular fashion. My real softare could then be tested against a variety or simulated conditions and environments.

[Juanjo Vega]

Hi again!. I have been trying the counter solution: I have included logic in order to abort reception after 5 tries of read serial port. I'm not very satisfied with this solution, but I have noticed that even if the controller response is lost, the command is executed correctly.

I post the VIs I uses, If anybody can and wants help I will be very pleased...

Thanks!

[DaviD_H]

Hola Juanjo, me parece increible pero cierto, y tengo que hacer mi proyecto fin de carrera casi como el tuyo, solo que yo he de controlar el SCORBOT ER-V, tengo que comunicarme con el, mandarle instrucciones y esperar a q me llegue el ">" para que no haya problemas. Ademas le tengo que añadir una webcam para verlo y poder trabajar desde internet con el.

Lo tengo algo avanzado, pero me gustaria que contactaramos. Mi email, msn y skype es: xdivadx@hotmail.com.


COntactame, gracias