labview velmex

[RavensFan]

Reference this thread. modifying user input in for loop

---

@Velmex wrote:

Not all replies have a terminator character

---

And that is why there is a problem with the communication protocol which is actually not a LabVIEW problem, but a protocol problem.

If there is no termination character, how is the program supposed to know how many characters to read, when to stop reading, and whether it got a complete, valid message?

[mnanda98]

So bytes at port is the way to go then?

[RavensFan]

If you use bytes at port, how long do you need to wait?  How do you know when you have a complete message?

Until Velmex gives some accurate information to tell what the protocol is, I can't recommend a way to do it.  A good communication protocol should have a reliable and accurate way of knowing when a message is complete without having to guess at it.

[mnanda98]

Right now if I wait 2000ms it works. The read indicator tells me if the message was complete.

But yes, I completely agree with you - bytes at port does not seem like the idea way to read. It may be unreliable at times and some adjusting would be needed depending on the message being sent.

[RavensFan]

If you knew for sure that depending on your command, it read X amount of bytes, you could do that.  But if the same message could give X+1, X+2 or whatever bytes, then you can't do that.  So if you send command A, you know you could read X bytes.  If you sent command B, G, or M, you know you read Y bytes.  Command C, read Z bytes.  Then instead of wireing a constant, you'd have a case structure that depending on the command woud have either a value of X, Y, or Z going into the VISA read.

You may find that you can shorten the wait time, but that depends on how long it takes the instrument to respond, and how reliable it is.  If it take 500 msec this time, but 1100 msec some other time,  you'll always need to wait at least 1100 or 1200 msec.

You might be able to read bytes at port.  Then if bytes at port =0, then stop the loop and concatenating of the message to a string.  So perhaps every 50 or 100 msec, you read however many bytes there are, append them to the message, when the Bytes as Port is equal to 0, stop the loop and pass the message out.  It's not completely reliable,  (suppose it sends part of a message, pauses, then sends the rest of the message?  you might think it stopped sending when it really hasn't).  It's not the most robust solution, but you are battling against a poorly defined communication protocol.  It might work a bit better for you than just waiting a long period of time.

[ColinCR]

I need to dig through my code (not in front of me) to see how I handled this, but I believe a wait after last byte received is probably the best way absent a termination character. You can also poll the controller for ready status, which is something I do anyway, for example before issuing commands after a move routine. 2000ms is certainly quite excessive. Timing is certainly important, and well-placed and spaced delays of optimized duration will go a long way toward predictable communciation with these controllers. 

Colin

[Velmex]

I agree with you guys (believe it or not) but it is what it is

I can tell you that if asking position then it does end in a carriage-return (and I think 11 possible bytes?)

There is also a command to make some responses end in a carriage return when they normally do not.

What complicates things is if the control was brought online with echo ON or Off??? to know whats in the read buffer

Timing is PURELY up to the operating system (Mac and Linux may well be better than M$ Windows, but this has yet to be proven)

The same problem has existed since the 50s (or earlier) as it does today, but with todays protocols its much harder to see.

[Velmex]

Mnanda, if you can tell me the command you are sending (or the status you are requesting, then perhaps I could tell you the best way to expect the end of the response?)

You also have to be careful that there is not a prior response in the que before you send the current request.

[mnanda98]

Hello everyone,

Thank you for your help.

RavensFan, I looked on the vxm manual and I see that each command uses a specific amount of memory (such as ImMx uses 4 bytes). Since the generic commands are hard coded in, are you reccommending that I calculate the total number of bytes and then wire that in as a constant?

Colin, 

Could you please elaborate what you mean by adding a wait after the last byte? How would I know what is the last byte sent? When you say "poll the controller for ready statue" you are referring to the "V" command, correct? So how would I use that information with the terminaition command? Sorry for all the questions - this is very new to me.

Also, how long would you recommend as a delay?

Velmex,

Right now I am sending E (echo on) to bring the VXM online

The attached programs have the code I am working on (Simple Serial Customized 4 uses bytes at port and Simple Serial Customized 5 is still in progress using termination charcter)

Thank you all very, very much for your help!

Mridu

[ColinCR]

Velmex,

The timing issues you mention are exactly why a termination character should be used.Terminating the transmission with something not used in any other message (e.g. a linefeed, carriage return, semicolon, whatever) lets the listener know that the transmission is incomplete. The listener therefore need only be on the line for long enough to receive the message and return status 0 or No Error. Without a termination character, even in the case that you provide a timeout long enough to receive all characters, you are wasting time between the last character and your timeout period. Furthermore, if you timeout because the transmitter has encountered some error, you will never know and continue on to process an incomplete message as if everything is fine. You can see where all of these cases are problematic. 

Mnanda, 

I would probably read byte-by-byte in a for loop and wait a set time after each byte to decide whether the message is complete. You could get fancy by predicting the length of the message based on what type of message you are sending, and terminating the byte-by-byte read after you have received the expected number of bytes for those of known length OR post-character timeout has been reached. You could set the expected byte number to something large when the message is of unknown length (I don't recall without looking if this is the case for any of the command responses). 

Now, I use the dll functions, and they work well. Velmex could probably tell you what parameters are built into the dll calls. There must be standard read timeouts built in, and these were surely empirically determined to work well. 

From a higher level, this is a great example of where toolkits will save you lots of time. I seem to recall you being on a mac, so this doesn't matter here (my toolkit is built on wrapped up dll functions), but if you start to add up the number of hours you have spent and throw a reasonable number at how you value your time, you'll often find that things that cost tens of dollars have in fact saved you tons of money. That is, in fact, why I started writing toolkits, Things like 1Wire, LabJacks, and Velmex controllers took time to make work right, and thought that I'd gladly have paid somebody to write it for me, or to have it already written. 

Cheers,
C