03-15-2011 06:09 AM
Hi, I used ESP 300 few years ago and I also encountered some problems including the mentioned problem. I got somewhere library solving this issue and it actually might be the one jberney made. So have a look into the attechment there is more. Hopefully something will work for you.
03-15-2011 09:39 AM
Thank you, my problem is completely solved now!
06-01-2011 04:06 PM
Hello,
I'm also encountering this problem with the ESP300, using Labview 2009 on Windows 7, and a USB to GPIB cable. I'm testing my set-up with the sample code provided by newport on the CD, "ESP300 GPIB Comm Test.vi", before encorporating esp300 control to my application code. For those that haven't seen this file, it cycles between two specified positions with a delay between movements, using the 0MD? command to determine that movement has stopped.
With auto-serial polling turned off, I usually get this error in less than 20 cycles, regardless of the delay I choose. I looked at the files posted previously in this forum which apparently solved the problems for others. The send/read vi's were simply modified with a short delay (as the while loop terminates after the first iteration); 5 is greater than 0 so the loop terminates regardless of what the status register values were. Perhaps the greater than or equal to comparison vi was different in version 7? Nevertheless, I added this while loop to my code and found that it had no effect, the time-out error persists.
Could someone post a simple example file that works? Since the code provided by newport does not work, I would like to test some operational code to determine if the problem is in the code or the gpib settings.
Thank you,
Paul
06-02-2011 03:22 AM - edited 06-02-2011 03:23 AM
You need to make sure that the controller has firmware 3.09 installed. This document shows that this version fixes a bug with GPIB communication timeouts. Happened to came across this when I recently had to install an old application on a brandnew system where the Newport was inherited from I don't know where.
Finding the firmware patch on the Newport site was a pain in the ass, but Newport support should be able to provide that also.
06-02-2011 07:10 AM
I should have mentioned that it has been updated to version 3.09, which I understand claims to fix this bug, but I am still encountering it. The time-out errors occur almost immediately after sending a message, so the 10 sec GPIB time-out is not the source of the error. As such, I thought that maybe I was sending commands too fast, but adding more delays didn't solve the problem.
I'll do a little more work to try and figure out exactly when the time-out is occuring. In the mean time, I would appreciate any more advice you can share.
06-06-2011 09:11 AM
I've looked into it a bit more and found that my errors aren't completely random. They always occur when trying to query after I send the command to change position.
The attached NI Spy image shows the commands sent prior to the error; in this case the query was "MD?" to check for movement stop. Although "MD?" is sent numerous times during a while loop, the error only occurs immediately following the move to position command (I've watched about 40 of these errors). Since the error always occurs at the same place in the code, I tried adding a delay, thinking maybe the messages were sent too fast. Unfortunately, this only seemed to make the error more frequent.
Communication with the ESP300 stops after receiving this error, making it unreliable to automate a 3-5 hour data acquisition session. Any advice to help solve this issue would be greatly appreciated.
-Paul
06-06-2011 09:17 AM
You say you are writing "MD?", but on line 34296 of your attached NI-SPY screenshot, you are actually writing "0MD?" Why is that?
06-06-2011 09:25 AM
Sorry, I didn't write the 0 here. The 0 simply means to check for stop on all axes, as opposed to using 2MD? to check for stop on only axis number 2.
06-06-2011 12:21 PM - edited 06-06-2011 12:21 PM
For me the MD? didn't work reliably too, but in my case it often returned TRUE while the motion had still not reached the end position. I changed my code to read the actual position and check for it to be between an Epsilon of the desired position, adding some extra delay to let the axis zoom in on the actual position, it always had some overshoot and then check again and after that switch of the axis.
All in all this controller doesn't impress me at all.
06-20-2011 01:24 PM - edited 06-20-2011 01:31 PM
For what it's worth, I had success using jberney's ESP Read VI, with a few modifications:
In words, I changed the >= to <=, the timeout from 5 ms to 10 ms, and the number of tries from 5 to 20. The ESP300 still seems to have occasional pauses, but they no longer result in errors or the infernal BEEP. Honestly, I can't say I understand why changing the numbers worked, exactly. Also, I only had to replace the ESP Read function in the MD sub-VI.
Regarding firmwares, our controller has firmware 3.08, and getting 3.09 on there seems to be a major PITA, starting with the fact that I need to find a Windows computer around here with a serial port. However, if anyone wants to try it, I found the necessary files here: ftp://download.newport.com/MotionControl/Archive/Motion%20Controllers/ESP300/Updates/. It seems that the ZIP file for the Motion Controller Utility is password-locked (et tu, Newport?), but you could probably use the HyperTerminal instructions to do it, if you're feeling bold.
EDIT: The password for the above ZIP is "newport", and you can get the full software CD here: ftp://download.newport.com/MotionControl/Archive/Motion%20Controllers/ESP300/Software/LastRevisionof...