serial device with loopback - need to discard sent message

[louis_nichols]

Hi!

I'm using VISA to communicate with a device using the serial port, via a protocol converter, because the device's native serial interface isn't rs232.

The problem is that the converter I use is quite dumb and loopbacks the sent message so, when reading, I always get it into the receive buffer. An obvious solution to this would be to manipulate the received string in order to delete the sent message from the beginning, but that is a dirty workaround and would be very ill suited for my particular application.

I tried using the VISA flush buffer immediatelly after VISA write, then I wait 30ms and use VISA read. The target device needs this long to answer, anyway, so I figured this should work. But all I get is either a completely empty buffer or the same sent+received message, depending on the mask I use for the flush function. I think I tried all possible masks.

I'd appreciate any idea in solving this matter. I've been trying to find the solution myself for quite a while now and I'm out of ideas.

[Dennis_Knutson]

I'm not sure why manipulating the received string is such a dirty workaround. It would be much more robust than trying to do some tricky timing with flushing the buffer. It would just take a Match Pattern function. I also looked at the string length of the Match String output. If you ever get a converter that doesn't loop back the sent message, it would still work.

Message Edited by Dennis Knutson on 10-27-2006 02:25 PM

[louis_nichols]

Hi and thank you very much for your response!

The reason I'm trying to avoid manipulating the string received is that the system I'm working on is a little more complex (that's of course very relative, but I'm pretty much a beginner, so it doesn't take much ).

My program is spread across several vi's and it looks something like:

serial write -> do actions -> serial read -> do more actions

with the read and write in different vi's. Now, I know I could just pass the written message down the line, but I'm worried about this approach because it might cause problems when synchronisation between sending a message and receiving the answer is not done right, which a user of my app other than me might do. I am documenting everything, but not everything will be read, I'm afraid.

In the meantime, I did just what you predicted: serial write > wait 5ms > flush buffer > wait some more (do actions) > read  and it seems to work. I'm more confident about this approach, because I think it's less confusing seen from the outside. Now all I have to do is make sure it works in all cases. Do you think there are problems that might arise from this?

Sorry I didn't post a sequence diagram, but I'm not at work right now. Oh, by the way! Have a great week-end!

[Dennis_Knutson]

Well, since you are presumably passing the VISA session down the line (or should be anyway), you could bundle the sent string with that and not have to create an extra wire. The VISA flush method may work for a while but you should know that a 5ms wait can easily become a much longer wait if the OS is doing something else in the background and it often is. About all that you are guaranteed is that the wait will not be any less than 5 ms. If the serial converter is echoing the transmit, you should find one that doesn't.

[louis_nichols]

yeah, I know changing the serial converter would be great, but unfortunatelly part of the whole point of my app is to make it work with this particular hardware setup. The timing is indeed an issue, but if get it running in an acceptable manner for a sufficient amount of time, I won't consider that a concern.

I will try passing the message down the line, also, and see what happens there.

Thanks for your help.