Using a Newport PMC200-P Motion Controller with LabVIEW 8.0

[Nelson S.]

Hello,

I am trying to get a Newport PMC200-P motion controller to work with a newer computer (Pentium 4) running LabVIEW 8.0, through a PCI GPIB board.  I have downloaded drivers for LabVIEW version 4.0 and am able to get them to work on an older computer (Pentium 1, 200 MHz) running LabVIEW version 4.1 (not sure which type of GPIB board), but am having no luck with the newer machine.  When the drivers are recompiled under version 8.0 the only warnings I get are that there are two front panel controls that are set to coerce a value and that is not supported under 8.0 and I should use the coerce sub-VI.

The motion controller is visible under the two different versions of MAX installed with the two different versions of LabVIEW (it appears as Instrument 1, Address 4 (the controller's default)), but does not respond to a "*IDN?" query on either computer.  I went through the GPIB Installation/Configuration Troubleshooter using the Interface Bus Interactive Control (IBIC) program on both computers and was successful up to the point of performing the "*IDN?" query which returned a count # of 5, but the read data command (ibrd) returned a timeout.  The Troubleshooter guide suggests that there is a hardware problem when this occurs, but the hardware works fine with the older machine and LabVIEW 4.1.

I don't beleive that the "*IDN?" query failure is causing my problem since the drivers work fine on the older machine running version 4.1.  Could there be a problem with the newer computer running at bus speeds that are too fast for the PMC200-P motion controller?  I would think that since the GPIB boards a standardized this should not be a problem.  Does anyone have any suggestions?

Many thanks,

-Nelson

[Albert.Geven]

Hi
Start with setting the gpib board settings to a lower busspeed.
The default is a bit high for the newport but should work.
Is the cabling as short as possible?

[Nelson S.]

Hello,

I'm new to the world of GPIB - how would I go about setting the board to a slower bus speed?

Thanks for the quick response!

-Nelson

[Albert.Geven]

In MAX expand Devices and Interfaces
rightclick your gpib board and select properties
then in that tab select advanced.
default is 500ns and better is a few us

[Nelson S.]

Hello,

I tried slowing the GPIB bus speed down to 2 microseconds and had no luck.  I removed LabVIEW 8.0 from the new computer and installed 4.1 and was able to get the example program (Example Program readloop.vi) to move the actuator connected to the motion controller, but it would not read the current position (the example program is supposed to tell the motion controller to move the actuator and read the position as it moves to its new position).  It would update the previous position when the VI was re-executed and told to move to a new position, but would only update it before it began moving, not during motion is it is supposed to.

Here are some more details on my setup:
GPIB Card: PCI-GPIB
GPIB Cable: 2.1 meters (Does the length really matter?  The cable worked fine with the older computer.)
Motion Controller: Newport PMC200-P
Actuator: Newport 850B-2
LabVIEW Drivers: pmc200.llb (Downloaded from Newport)

Thanks for the help.

-Nelson

[Albert.Geven]

Cable length is not really important. Officially it has to be 2 mtr between 2 instruments and at least half of the instruments have to be switched on and not more than 16 instruments etc.
But in practice I've seen 12 mtr with 1 instrument work (I'm not advising this!)

What is a possibility is that the software is polling the newport controller is too fast to  let it do its own job.
Can you post this llb.

[Nelson S.]

I attached the library.

I've tried playing around with the Wait function in the drivers and that didn'r seem to help - specifically, I changed the Wait in the "PMC200 Realtime Pos read.vi" sub-VI from 1 ms to 100 ms and the program did not behave any differently.

When I run "Example Program readloop.vi" and the "PMC200 Realtime Pos read.vi" sub-VI with execution highlighting turned on it seems to get stuck in the while loop in the "PMC200 Realtime Pos read.vi" sub-VI.  From what I gather about the driver and device is that the device is supposed to set a SRQ flag which the driver reads then it knows that the device is ready for it to read data from.  Is this correct?

[DarylE]

Hello,

The SRQ line from the device is used to get the attention of the controller (The PCI-GPIB Card) to let the controller know that it is ready to communicate.  More information on how the SRQ line works and how the controller finds the devices which have asserted the SRQ line can be found at the following link Serial Polling and SRQ Servicing.

As for changing the wait time of the "PMC200 Realtime Pos read.vi" sub-VI and seeing no change and also the while loop getting stuck in that sub-VI with highlight execution, the best way to see what is happening on the GPIB line is to use NI-SPY.  NI-SPY captures the communication between a device and the controller as you run your VI.  This way you will see any errors that are occuring.  For steps on using NI-SPY follow this link NI-SPY Capturing for Troubleshooting

Daryl E
National Instruments
Applications Engineer

[Nelson S.]

Hello,

Thanks for the information and help.

I ran NI-SPY while trying to communicate with the motion controller.  I tried a few different things and attached the capture files:

Capture1.spy – queried “*IDN?” using MAX

Capture2.spy – ran “Example Program readloop.vi” from Pcm200.llb driver library with excecution highlighting turned on for both “Example Program readloop.vi” and its sub-VI “PMC Realtime Pos read.vi”. Capture3.spy – ran “Example Program readloop.vi” from Pcm200.llb for less than 1 second then stopped it to prevent the capture file from reaching 1000 lines. It seemed to get stuck while waiting for an SRQ from the controller - any suggestions?

Thanks for help!

-Nelson

[DarylE]

Hello,

Based off of your first capture, it appears that you are getting an EABO error, I/O operation aborted, in MAX which would lead to the reason why running the VI's would not produce the correct results.  The first step is to troubleshoot the capture taken in MAX.  There could be several reasons why there is a timeout on ibrd (read function of the controller from the device).  One reason could be if your device does not send an EOI (End or Identify) character to the GPIB card after the card reads a message from the device.  This would result in a timeout from the GPIB read.  The following link discusses what else can be done to solve this error GPIB Error Codes and Common Solutions.  Also it would be good to use the interactive control (In MAX go to tools>>NI-488.2>>Interactive Control) and run the example found on the following link GPIB Installation/Configuration Troubleshooter

Daryl E
National Instruments
Applications Engineer