Problem with queues and serial communication

[probably]

As a quick test, you can change the number of iterations on the while loop in the Scan value change event. It works fine for one iteration (MOV then POS?) and hangs at two with VISA read timeout. What's going on? If it works once it should work twice?

[probably]

Two logs attached as requested.

Hardware is LV7.1, Win XP (SP2) talking to Physik Instrumente PI E-621 over serial cable connection

115200 baud

8 data bits

1 stop bit

no parity

RTS/CTS flow control

LF receive termination character

LF transmit termination character

If you need more details I'll try and hunt them down.

Thanks for taking the time to try and sort this one out, it's not very clear what's going on.

Got to go, train to catch, but I'll check this thread regularly over the next while.

Best wishes.

[Sarah_Coleman_NIUK]

Morning!

It sounds to me like your hardware is getting confused, as it only falls over when two commands are sent back to back, and even that it works for one iteration but not two. That sounds to me like it takes the first MOV command, it's ok for the POS? command but that's followed instantly by another MOV then POS? which is when it's tripping up.

As a diagnostic, try putting a small bit of timing in the test program. Use a sequence structure with a 50ms delay and put it directly after the MOV command. This should give your instrument time to right itself before it receives the next command. You probably don't even need a full 50ms. Try playing around with different times and see if it makes a difference. Also try putting the timing in different parts of the program and see what happens.

If it's not that let me know and I'll start looking up data sheets!

Best of luck,

Sarah

AE | NI UK

[probably]

I'll try your suggestion Sarah, but I thought that was the whole point of using RTS/CTS flow control: these lines are only asserted when the device is ready to receive data?

Anyway, I'll check it out when I'm back at work (I'm off next week).

Best wishes.

[johnsold]

RTS/CTS may be controlled by the state of the communications buffer, not by the readiness of the instrument for the next command. Unfortunately, the RS-232 "standard" only applies to signal levels and not to the way it is used.

Does the manual for the instrument specify the delay between receipt of a command and readiness for the next? Does the instrument have a status message which will let you know when it has processed a command and is ready for the next? Ideally this information is in the manual, but even good manuals often do not have it or it is difficult to extract. The delay may be different for different commands.

You may need to run simple experiments to determine the actual behavior of the instrument.

Lynn

[probably]

I'm not sure if anyone will spot this late addition to the thread, here goes anyway.

In essence the problem seems to be that the E-621 was receiving commands faster than it could handle them and falling over.

For example, with 0ms delay in the command sending loop the device typically falls down after a few loops; with a delay of 50ms in this loop it works fine.

Just to confuse matters more, i've installed a USB2/2. This connects the serial E-621 to my laptop's USB port (I've been doing all the development on the same machine).

Now with 0ms delay it works fine every time! The only explanation (apart from a bug) that I can think of is that there is "traslation time" within the USB2/2 that slows things down to a workable level.

Comments anyone?

[Sarah_Coleman_NIUK]

Hi,

Like you say, I assume the new hardware and software layer have added an additional buffer to the data transfer which is allowing sufficient time for your E-621 to process each command before it receives the next one.

Originally the data was going straight to the OS then to the hardware.

Now it's being passed to the USB232 driver, which instructs the OS to write to the USB port which in turn writes to the E-621.

This additional time delay is what your instrument seems to require in order continually receive writes.