Instrument Control (GPIB, Serial, VISA, IVI)

cancel
Showing results for 
Search instead for 
Did you mean: 

Kepco BOP 36-12M / BIT 488-B Lockup/freeze

Hello,  I am running continuous control and queries to a Kepco BOP 36-12M power supply with BIT 488-B interface.  When I run it in a monitor/control loop alone everything is fine, indefintely.  However when I combine this with other monitor loops queriying other devices on the bus, I eventually get a hard lockup of the Kepco device -- this can happen anywhere between 15 minutes to hours later.  the Kepco will no longer even respond to even an IDN? query once everthing else is turned off.  When this occurs, the only solution seems to be to power-cycle the Kepco.  I have captured output using a bus analyzer and see timeout events for many instruments including the Kepco which seems a nominal case since the system is using asynchronous transactions.  Anyboday have issues like this?  I am using Windows XP with LabView 8.6 and the accompanying NI tools.

0 Kudos
Message 1 of 7
(4,969 Views)

Hi,

 

You mentioned that the Kepco device runs fine on its own, but when hooked up to the same bus as a other devices it no longer functions properly. What are the other devices, and what is the bus type that you are referring to?

 

Best Regards

National Instruments
0 Kudos
Message 2 of 7
(4,941 Views)

Hi,

 

Its all on standard IEEE-488 GPIB.  No HS operations.   The equipment list of devices on the GPIB is as follows:

 

One Keithly Digital Multi-meter

One Sensotec SC3004 transducer conditioner

Two North Atlantic Industries API 8810A-R R/D converters

One Agilent 6654A DC Power Supply

One KEPCO BOP-36-12M Power amplifier

One Agilent N6700B DC Power Suply

 

Note that in the loop, all instruments are continuoulsy queried, although some at a considerably higher rate.

 

-Bob

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

Hi,

 

Is there any unusual behavior of these other devices when they are all synched up together? It seems to me that it may be an issue with the device itself.

National Instruments
0 Kudos
Message 4 of 7
(4,925 Views)

THe things that I see that are unusuall are that even when things are "nominal", that is, data is being sent and received, I see lots of asynchronous timeout errors on the bus capture, mainly from the Kepco but also from the two R/D converters.  From what I an see that seems to be a "tolerable" condition as the controller simply waits while it processes other information.

 

To address one aspect of your question: I dont think anything is actually "synched" with this scheme that being used.  Everything is run in independent asynchrounous loops (for better or worse... not my design).  I am wondering if, by somehow going to a synchronous scheme (e.g. the controller will wait for a given transaction to complete before initiation a new one) that will alleviate teh problem.  I havent yet attempted to try that.

 

Again, if we just operate the Kepco in its own loop, we never get a lockup.

 

The strange thing is this.... We have about 7 identical systems.  This issue only crops up on two of them.  We have tried things like swapping Kepcos, and even swapping PC/controllers.  The problem still occurs only on the problem systems. That is we havnet been able to isolate any "bad" device yet.  I am thinking we might be operaing the sysm marginally and somehow its only "crossing that line" on these two problem systems.

 

Any thoughts as to "going synchronous"?

0 Kudos
Message 5 of 7
(4,911 Views)
First try setting the VISA functions to synchronous mode but I would also recommend that the whole architecture be synchronous as well. GPIB is essentially sequential where one instrument is addressed at a time. Trying parallel operations can be problematic.
0 Kudos
Message 6 of 7
(4,909 Views)

Yes I was afraid you were going to say something like that.  Unfortunately our organization paid a lot of $ for a small army of people to architect complicated test systems using "always ON" independent monitor loops (one for each instrument)complete with semaphores, etc  running at all sorts of rates.  I will however try to force some sort of synch on the system for this test to see if it will help.

0 Kudos
Message 7 of 7
(4,906 Views)