Hi

If both / all  of the counters are collecting 1 second data, the GPIB stuff 
isn’t going to be to bad … 

There’s always an If.  You need to run the counters so they do it all 
automatically (arm etc). That’s the way it’s normally done It should not be to 
big a constraint. The rest of it turns into a poll this poll that loop. When 
one of the counters has data you grab it and shove it into a file someplace. 

The counters buffer the data, so they only get bothered if the poll / read 
process gets to a significant fraction of a second. They started out doing HPIB 
/ GPIB with some *very* slow hardware. The 5335 and 5334 date to that era. They 
have been fully debugged with gear that waits a while to grab data from them.

If you are running a lot faster then yes… you can get into issues. 

Bob


On Feb 9, 2014, at 4:28 PM, Bob Stewart <[email protected]> wrote:

> 
> Hi Orin,
> 
> No,
> it's not a matter of just talking to the device.  I can to that.  The 
> problem happens when you want more than one program/process to access 
> the GPIB bus at the same time; e.g. running two different tests.  For 
> that you have to have a server process which manages the interface and 
> relays packets to the clients.  Prologix hadn't written one when they 
> commented here last summer.
> 
> Bob
> 
> 
> 
> 
> 
>>> ________________________________
>>> From: Orin Eman <[email protected]>
>>> To: Bob Stewart <[email protected]>; Discussion of precise time and frequency 
>>> measurement <[email protected]> 
>>> Sent: Sunday, February 9, 2014 12:55 PM
>>> Subject: Re: [time-nuts] Rb as source for ADEV?
>>> 
>>> 
>>> 
>>> Bob,
>>> 
>>> 
>>> If you want a C++ class to talk to the Prologix Ethernet, I have one.  (I 
>>> don't have a USB version, but that would just be a matter of implementing a 
>>> simple subclass to do the communication with the device.)
>>> 
>>> 
>>> I also have code that uses the above and talk to a 5335A and to a 5370A, 
>>> both of which like to sulk if you don't do things in the right order.
>>> 
>>> 
>>> It's written for Windows and should compile in the _free_ Visual Studio 
>>> Express 2012 (it used to, but the last time I built it was with the full 
>>> version).  Porting to Linux/Mac/iOS would be easy enough... maybe I'll do 
>>> iOS for fun, if Xcode doesn't sulk and stays alive long enough that is; the 
>>> only thing Xcode does fast for me is crash!
>>> 
>>> 
>>> Licensing for all but the findAdapters method will be LGPL once I put 
>>> headers in.  findAdapters() is derived from John Miles's GPIB library and 
>>> subject to its licensing.
>>> 
>>> 
>> 
>> 
> _______________________________________________
> time-nuts mailing list -- [email protected]
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

_______________________________________________
time-nuts mailing list -- [email protected]
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Reply via email to