VDT2 Data Reading Differences between Terminal Port and Command Port

Share icon

Hi,

I am reading data from a Keyence laser displacement sensor using VDT2 and I am having trouble reading the data output stream and I am getting different results when using the the terminal port and the command port. I had the system running on an XP based system a while back without issue and the current one is a Windows 7 machine. The XP based machine is no longer available. The basic code was just carried over from the XP machine.

For the Keyence sensor, the basic commands are:

VDTWrite2 "DS,01"+"\r\n" //reset buffer 01
VDTWrite2 "AQ"+"\r\n" // clear accumulation another reset of buffer
VDTWrite2 "AS"+"\r\n" //start data collection
VDTWrite2 "AP"+"\r\n" // pause data collection
VDTWrite2 "AO,01"+"\r\n" //request data from buffer 01
VDTRead2/n=1000000/O=3/Q /T="\r\n" input //read data

I can do all this from the terminal window by entering the text string commands.
Here is the problem:
In the terminal window when I issue the "AO,01" command I get the full data stream including the carriage return and line feed.
Within my function I do not get the full stream of data and it times out and gets chopped. I print the input string and can see the truncated values. The string is about 1700 characters long. I never get the carriage return and line feed within the function. I always get it when in terminal mode. Also note that I have a very long time out time and within terminal window I never come close to needing that amount of time.

When I change the time out time from 0.5,1, 2, 3, 4 or 5 sec
0.5 sec I get ~500 characters received and no terminators
1 sec I get ~1000 characters received and no terminators
3-5 sec I get ~1700 characters and no terminators

Any hints on what is going on and how to fix it?
This:
/T="\r\n"

says "terminate on either CR or LF. This means that the first read will terminate on the CR and the next read will terminate on the LF.

If you expect CRLF you should use
/T="\n"

and then remove or ignore the CR.

Start with that and see where it leads.

If you are running at very high baud rates, another issue is the size of the serial input buffer. On Windows the buffer size you request via "VDT2 buffer" is just a request and the serial driver will do whatever it wants. I don't know how big a buffer they allocate or how to find out how big it is. If you can set the baud rate on the instrument, try setting it and VDT2 to a low rate like 4800 and see if that solves the problem.

July 24, 2012 at 01:06 pm - Permalink

Hi Howard,

I have changed the termination string string to "\r", but this did not change the result.

The baud rate is 9600 and I cannot change it at the moment: I actually have to buy additional hardware to change it.

I have removed the the "/Q" flag and can verify that the data stream is timing out even with ridiculously long times ("/T=10")

I tried to collect more data (longer collection time) from the terminal port. It seemed to read correctly including the carriage return.

Does the terminal do anything differently than the command port?

I also added "/buffer=8192" to no effect.

If I look at the data string I am expecting about 2000 characters, which does not seem to be an overly large number.

July 25, 2012 at 08:19 am - Permalink

Quote:
I have changed the termination string string to "\r", but this did not change the result.


That's not quite right. Now it will terminate on CR and leave LF for the next read. You can either terminate on CR and then immediately do another read (VDTRead2/N=1 lfStr) to consume the LF or terminate on LF and then remove (RemoveEnding) or ignore the CR.

Quote:
The baud rate is 9600 and I cannot change it at the moment

That's not too fast so it is probably not an issue of running out of buffer space.

Quote:
Does the terminal do anything differently than the command port?


The operations are more complex because the data has to be parsed and stored in Igor variables but the underlying serial port I/O is the same.

I recommend that you first try to devise the simplest and shortest possible test which hopefully will succeed. Verify that you can run it any number of times without an error. Then lengthen or add complexity a little bit at a time, each time verifying that you can run it any number of times. Eventually you will come up with a test that fails. This process may help you determine the conditions that cause it to fail and provide a further clue.

Alternatively, if you are an XOP Toolkit programmer, you can run VDT2 under the debugger and perhaps gain some insight.

July 25, 2012 at 09:02 am - Permalink

Hi Howard,

The problem is in command port I always time out before I get the termination string. I never see "\r" or "\n". I have tried have much less data collected and still always time out in commas port, but I never time out in terminal port.

Example: this is the last part of the string I receive. The numbers are formatted to be 5 digits before the decimal and 1 after. Notice the last entry it was cut off in mid stream without the decimal point and trailing digit

......,-00056.0,-00058.4,-00058.2,-00057.0,-00055.2,-00057.5,-00057.1,-00054.6,-00051.9,-00054.8,-00059.4,-0005

The system has not finished receiving the data.

This does not appear to happen in terminal port. All the digits are received as well as the carriage return.

July 25, 2012 at 09:38 am - Permalink

Quote:
The baud rate is 9600 and I cannot change it at the moment: I actually have to buy additional hardware to change it.


I'm starting to think that this is a hardware problem. My theory is that you are using some kind of bare bones serial port adapter with a very small input buffer.

I don't know why the terminal works and VDTRead2 does not. Possibly the terminal can read the characters faster though I don't see why. Possibly the time between executing VDTWrite2 and VDTRead2 is too long given the serial buffer size.

I would try it on a different machine or buy a serial adapter with a reasonable input buffer. The only one I have used is Keyspan which worked well.

July 25, 2012 at 09:53 am - Permalink

Hi Howard,

Thanks for your support on this.

I have ordered a new serial adapter, this one from USConvertors which claims that Windows 7 is problematic with generic serial adapters.

I will report back after I test it.

July 25, 2012 at 10:18 am - Permalink

Looking through my support email archive I see that an Igor user reported trouble with the Sabrent adapter but success with the Gearmo adapter. The latter uses the FTDI chipset which appears to be the key. It has a 512-byte hardware buffer.

It appears that US Converters uses the FTDI chipset.

The Sabrent adapter says "Provides a 96 byte buffer for each upstream and downstream data transfer". That is not big enough for this kind of work but there is, no doubt, another software buffer of unknown size maintained by the driver.

July 25, 2012 at 11:07 am - Permalink

I just received the new USB-serial adapter from USConverters.

It has seemed to fix the problem. I am receiving the entire string including the terminal string as expected.

Thank you for your help.

July 30, 2012 at 08:40 am - Permalink