04-18-2007 10:55 AM
ESP300
I've written a few VIs that incorporate the library VIs issued by
The only way to get the
Obviously I can’t put up with this problem – is this controller known to be prone to crashing?
The
04-18-2007 11:32 AM
04-18-2007 11:50 AM
04-18-2007 12:16 PM
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
04-18-2007 12:40 PM
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.
04-18-2007 01:10 PM
01-18-2009 03:42 PM
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
Rolf Kalbermatter