Newport ESP300 GPIB communication stops after query

[pjr1121]

Hello,

I'm trying to control a Newport ESP300 motion controller via GPIB with labview and I've run into a problem that I've not seen in the forums.  I can tell the controller to move to various positions, wait, change velocities, etc, without error.  However, when I query the device, it stops all communication with Labview.

Example

1mo      //axis 1 on

1pa2     //move axis 1 to absolute position 2

1ws      //wait for stop

1pa?     //query absolute position

2          //ESP300 response

1pa3    //NOTHING HAPPENS

1mf      //NOTHING HAPPENS

The GPIB READ.vi has mode=2 (for terminating on LF character) to terminate the read operation as specified by newport, but communication stops every single time I query the device.

I've tried doing everything that this newport document mentions, with no effect.  ftp://download.newport.com/MotionControl/Archive/Motion%20Controllers/ESP300/Software/ESP300%20GPIB%...

I should mention that I have been unable to deactivate autopolling (the box is greyed out).  Although I don't believe this is the problem.  I've also tried replacing the GPIB READ.vi with VISA code, but this had no effect.

Sending the same series of commands through NI-MAX does not show this odd behaviour.  I've tried asking Newport about this but they were not able to help.  Does anyone have some advice on how to reliably read/write over GPIB with the ESP300 controller?

Thank you.

[JÞB]

Well,  "Sending the same series of commands through NI-MAX does not show this odd behaviour."  Certainly points us in the right direction.  MAX uses VISA to open a GPIB::Instr class session so we know that WILL work if properly configured.

The manual suggests that the device should be unaddressed on each read or write by sending a _? using the GPIB driver but this can also be set as the desired behavior with a VISA Property node (BTW. the interactive panel in MAX unaddresses after each operation but this is not the default for VISA) 

Add this to your initialization and see if that helps

[pjr1121 · Accepted solution]

I've found the problem.  Turns out that while using the GPIB READ.vi, I had set the number of bytes to a value that was too small.  As a result, the read terminated early, leaving the rest of the message in the buffer.  I'm not exactly sure why this resulted in a "freeze" of communications but it did.  Increasing the number of bytes to 255 solved the problem.