Showing results for 
Search instead for 
Did you mean: 

ESP300 Timeout During EP - Enter Program Command

I have a Newport ESP300 three axis motion controller that I am controlling via LabVIEW (version 7.0).  Newport provides a LabVIEW llb file including a subVI for each ESP command.  These are simple wrappers around GPIB 488.2 "Send" VI that add a carriage return termination character (\r) and use send mode 2 (Send EOI with the last data byte in the string).
Most things work ok; I am able to communicate with the device and direct my axes to move.
However, when I issue the "EP - Enter Program" command and begin sending commands to be stored as a program, my second or third "Send" command times out, and I am no longer able to send any command until I do a hard reset of the ESP300 (physically switch the unit off and on).
The ESP300 comes with a (Visual Basic?) utility program that provides a simple terminal with which to send commands to the ESP300.  Entering a program with this utility works fine whether I enter my commands line by line on the terminal or send them all at once as a text file.  Using NI-Spy, I observe that this utility program is, after some initialization, issuing only ibwrt() and ibrd() calls.  When loading a program from a text file, it sends each line of the file in a separate ibwrt() call.  From my LabVIEW VI, NI-Spy reveals a different pattern of calls.  Send() and Read() are used rather than ibrd() and ibwrt(), and after each Send() or Read(), ThreadIbsta() and ThreadIbcnt() are issued.  Not sure if this is relevant, but it is the one difference I noticed between the software that works and that which doesn't.
In my LabVIEW subVI, I have tried sending each command in a separate "Send" (emulating the working program), and all in one lump with each line separated by a carriage return (to try to avoid the ThreadIbsta() and ThreadIbcnt() calls), all with the same failure.  The same failure results after modifying the VI to use the VISA rather than the GPIB VI's, though different calls are observed in NI-Spy.
My ESP300 is using firmware 3.08.
I am using a National Instruments PCI-GPIB on Windows XP.
The driver version is listed as "not available" by the Windows Device Manager.
Via NI-MAX, I disabled Auto-Polling on the GPIB card as per some instructions from Newport, but this did not seem to make any difference.
Any ideas are appreciated.  Thanks.
0 Kudos
Message 1 of 10
Hey imperfection,

Are you getting any error (other than a possible timeout error) when this lock up occurs?  If so can you post a screenshot of the error?  Also, if you can post the driver versions of both NI-VISA and NI-GPIB, this will help.  You can see the driver version by clicking the plus sign next to the software section in MAX (Measurement and Automation Explorer).  From there just click on the driver and the screen on the right will show the version currently installed.  One last thing that might help is a copy of the Spy capture you took.

Best regards,

Jason W
Applications Engineer
National Instruments
0 Kudos
Message 2 of 10

I have a similar problem.  I am also using a ESP300 controller with LabVIEW 7.0.  But, I am just trying to send a simple command such as "1MO" (motor on axis 1) which works fine.  When I try to send another command such as "2MO" I get a timeout error.  I will keep getting a time out error unless I restart labVIEW and the motion controller.


My NI-VISA version is 3.0

I am using as Agilent 82357A USB/GPIB interface

Download All
0 Kudos
Message 3 of 10

Hi, there was a known timeout issue with the ESP300 and the official newport libraries. Maybe it is the problem you are facing. Use one of the attached libraries that were modified. You might find more about the problem here on the forum if you search. If it does't help: are you sure you command the right axis? = is there really a stepper mottor attached to the second axies?

LV 2011, Win7
Download All
0 Kudos
Message 4 of 10
Here is the thread regarding the timout issue I mentioned.
LV 2011, Win7
0 Kudos
Message 5 of 10

I looked back at my code, and it looks like I used the tried and true solution of adding manual delays.


My VI sends a program to the ESP300 one line at a time, with a 10 ms delay after sending each line.

0 Kudos
Message 6 of 10
Is there a file which solves the problem with VISA commands instead of GPIB?
0 Kudos
Message 7 of 10

zibby wrote:
Is there a file which solves the problem with VISA commands instead of GPIB?

Look here in the forum for various threads that contain the term ESP300. There is at least one version of an ESP300 library posted that is actually using VISA. Not sure if it solves all the problems this instrument seems to have in terms of its GPIB interface implementation but it's a start. If you use it through GPIB I would recommend to enable the GPIB->Unadressing property after initializing the resource as this instrument seems otherwise to get into hickups after some time of intensive communication.


Rolf Kalbermatter

Rolf Kalbermatter
Averna BV
0 Kudos
Message 8 of 10

I had a similar problem to that posted by imperfection, and have now succeeded in solving it.


Ceties, the solution you posted has some bugs: (1) the "greater or equal" function should actually be a "less or equal" function, and (2), in my case, the true-false array leading into the "not exclusive or" function was also incorrect, and needed to be fixed. There is a more thorough discussion of this in the string Ceties has linked in the 1-14-2009 post.


In any case, neither of these solutions did very much to solve my problem. It kept on timing out even after implementing revised "Send" and "Read" functions. What did help was combining the new "send" and "read" functions with the following changes:

(1) Upgrade firmware from version 3.03 to version 3.09 (see the link in Ceties's 1-14-2009 post).

(2) Verify that autopolling is deactivated in my PCI-GPIB NI Max communication settings (see the link in Ceties's 1-14-2009 post).

(3) Select a reasonable GPIB cable length in my PCI-GPIB NI Max communication settings.


I unfortunately don't have the patience to figure out which combination of these changes is the minimal solution, but hopefully the list will be helpful to anyone else having similar problems in the future. I suspect that the primary issue was the firmware.

0 Kudos
Message 9 of 10

For us we needed to set "enable readdressing" to be False.

0 Kudos
Message 10 of 10