Dynaload XBL-50-100-4000 GPIB Driver Control Difficulty

[Mako]

I've got a brand new TDI Dynaload XBL-50-100-4000, which I'm trying to control with LabVIEW via the GPIB interface.  I've controlled an older RBL-series load successfully in the past with the same GPIB card, cable, and software.

TDI has a LabVIEW driver for the RBL series (which is a very similar older version of the XBL) for download at their website, but it's archaic (LV5).  NI does, fortunately, have a LV8 driver available through the driver library, which I successfully converted to LV2010; I also have an older version of the TDI driver (it's somewhat simpler in terms of how it handles writes, but is similar) that has been grandfathered through several versions of LabVIEW.  Since the XBL series seems to have the same GPIB commands as the RBL series, it seems like this should work.

And it almost does; it successfully performs reads and writes to the Dynaload.  But only some of the time; as best I can figure, if more than one parameter is written in too quick of a succession, the second command is ignored.

So, for example, I can programatically set the Dynaload's range (which is the first command written in the chain), but cannot also enablel it at the same time (because the on/off command is immediately after the range command).  Some later commands in the chain do go through, though.

I built a stripped-down test version that does nothing but the first two commands in the driver chain: Set the range via one GPIB write, and then turn the load on or off via a second.  I also inserted a configurable delay between the first and second writes.

Either command can be successfully executed by itself, but if I try to do both with no delay, the second command fails.  With a 100ms delay between the two, they both execute reliably.  I've triple-checked the end-of-line settings and randomly experimented with various configuration options in the MAX GPIB configuration page for the GPIB card, none of which seemed to help.  It feels like a synchronization issue, and I could probably work around it by just wiring in a delay between each write, but I really don't want to do something so kludgy without understanding what's causing the problem.

Am I overlooking something obvious here--some GPIB parameter default that's changed since older versions of LabVIEW--or does anyone have any suggestions of why I seem to need a delay between commands now, when nothing indicates that should be necessary?

[Dennis_Knutson]

The installation of a new version of LabVIEW does nothing to change the GPIB settings.

Do you have an older version of the instrument. Have you talked to the vendor?

[Mako]

I've got a message in with the vendor, but figured it wouldn't hurt to try here in addition, in case they're unhelpful and/or slow to respond (and/or someone here is using an XBL load and already knows what the difference is).

And yes, I have an older RBL488 50-1000-4000; it behaves exactly as expected using the same code, computer, card, and cable--I tested again to be certain.  I'm not seeing anything unexpected (or different between the two) in NI Spy, either, apart from the failed commands showing a 0.00 time to execute.

[Dennis_Knutson]

That indicate to me a problem with the new model. I've only used the Dynaload briefly. It was to review problems with an older program. One the complaints was that occasionally, the Dyynaload would not accept a command. I never got very far as I was pulled onto another project. Sounds similar to your problem.

[Mako]

An update in case anyone else runs into the same issue:

While TDI tech support was totally useless, I did eventually figure it out myself.  While I didn't really dig into the protocol, so it's possible that my fix worked for a reason different from why I think it worked, I now have a re-built version of the RBL driver working smoothly and reliably on the XBL.

The problem seems to be that whenever you issue a command to the XBL, it wants to respond with a status indication that the command was received.  As such, if you immediately do a read after wrirting a value, it will accept the next command without complaint.  So basically, I went through the RBL driver and added a GPIB read after each GPIB write.  I don't even bother looking at the data (though I suppose you could, if you wanted to confirm that your command was accepted), but this is enough to get it working reliably.

I've run into some mildly annoying issues with the LabVIEW runtime environment not realizing that a new GPIB interface is present unless it is fully removed from system memory and re-launched, but it's otherwise doing what it's supposed to.

I may try to tidy up the driver and post it somewhere to save anyone who buys one of these in the future having to write their own XBL driver.

[jjp377]

You can submit the updated instrument driver to IDNet