LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

ESP300 motion controller

ESP300

 

I've written a few VIs that incorporate the library VIs issued by Newport for this controller. The VIs work to a point and then have a tendency to crash for no obvious reason. After a crash no communication with the device is possible. I’ve tried to play around with various bits and bobs but to no avail.

The only way to get the VIs to work again is by turning the controller off and then on again.

 

Obviously I can’t put up with this problem – is this controller known to be prone to crashing?

 

The VIs concerned are attached. If someone could have a look and tell me what might be wrong I’d be thankful. Thank you.

0 Kudos
Message 1 of 7
(3,874 Views)
 
 
The error code is shown in the attachement (it says code 6). It would seem to be a software timeout of some sort but I'm not certain.
0 Kudos
Message 2 of 7
(3,868 Views)
Error 6 means I/O Operation aborted and it's probably related to the poor design of your program. What it usually means is that a GPIB operation in progress, such as a read, has not finished when another operation, such as write, is issued. In your case, it could be a move command issued and before the move is complete, you issue another one. You've got all of these little separate functions scattered all over and most of them are not connected by any type of dataflow. The diagram and front panel are way too large to spend much time analyzing exactly where the problem lies. A general guideline is to keep the block diagram sized to fit your monitor. You should look at some of the better progamming architectures such as the state machine and producer/consumer.
0 Kudos
Message 3 of 7
(3,861 Views)

Ok, I won’t argue with you about my layout. I use a lot of space and things could be more compact.

 

There are several functions that control the device but they are all entirely independent and none are active until a button is pressed. Even the individual functions, for example, “move relative” if used on their own (as separate VIs) cause the same error as if the onboard memory of the device is being clogged up – I don’t know enough to say more but the problem isn’t related to a conflict in my VI. If the problem is a time out problem I'm baffled because increasing the delay after motion is complet has no positive effect - or am I using this parameter wrong and causing the problem by setting it greater than zero?

 

I’ve tried to contact Newport on this issue but they haven’t responded yet.

0 Kudos
Message 4 of 7
(3,857 Views)

I have never seen an error 6 problem related to timeout. It is a timing problem in the sense that I mentioned - correct sequencing of commands. With your use of local variables and the program structure, I think it is a distinct possiblity that you have multiple commands at the same time. This is going to be difficult to debug. You can turn on NI-Spy and watch what happens when you get the error. You should also be checking the move complete status before issuing each command.

0 Kudos
Message 5 of 7
(3,853 Views)
I had a similar problem using the serial interface of the ESP300. To
minimize the lock-ups, I had every function strictly sequenced with time
delays between steps. The lock-ups didn't stop until Newport serviced our
controllers for other problems. They might have done something to the
serial interface and upgraded the firmware. Follow up with Newport and see
if a firmware upgrade is available for you unit.

Also, I didn't look at your code, but based on the other reply, you should
make sure commands have enough time to finish (and maybe even check that
they are finished) before issuing new commands.


"raff" <x@no.email> wrote in message
news:1176918009901-509004@exchange.ni.com...
> Ok, I won?t argue with you about my layout. I use a lot of space and
> things could be more compact.
>
> &nbsp;
>
> There are several functions that control the device but they are all
> entirely independent and none are active until a button is pressed. Even
> the individual functions, for example, ?move relative? if used on their
> own (as separate VIs) cause the same error as if the onboard memory of the
> device is being clogged up ? I don?t know enough to say more but the
> problem isn?t related to a conflict in my VI. If the problem is a time out
> problem I'm baffled because&nbsp;increasing the delay after motion is
> complet has no positive effect - or am I using this parameter wrong and
> causing the problem by setting it greater than zero?
>
> &nbsp;
>
> I?ve tried to contact Newport on this issue but they haven?t responded
> yet.


0 Kudos
Message 6 of 7
(3,851 Views)

DD wrote:

Also, I didn't look at your code, but based on the other reply, you should
make sure commands have enough time to finish (and maybe even check that
they are finished) before issuing new commands.


I'm going to tackle this beast too in an upcoming project and already played a bit with it. And yes it seems to have its issuesI have decided to not go with the original drivers but instead write a (minimal) instrument driver based on VISA instead as the original driver hardly can be called a driver and I like to have some structure in my programs.

 

I think that the suspection of confliciting reads and writes is probably one of the possible reasons for an error 6 and one of the fixes in another thread about checking the read and write status bits before doing the actual read or write seems to support that claim. However according to the documentation there is no need to wait for a move to finish before executing another command as the commands will be executed whenever they arrive, of course possibly aborting an already ongoing move if the new command is for the same axis. If that is only whishful thinking by Newport or actual reality I probably will find out soon Smiley Very Happy

 

Rolf Kalbermatter

Rolf Kalbermatter  My Blog
DEMO, Electronic and Mechanical Support department, room 36.LB00.390
0 Kudos
Message 7 of 7
(3,434 Views)