Agilent E44xx spectrum analyzer remote control utility

[jhenderson0107]

Here's https://www.dropbox.com/s/vc7dwis2ykg8m9n/SA.exe?dl=0 a minimal Windows applet to control the Agilent E444x -series of spectrum analyzers.  It is dependent on the NI or Agilent VISA runtime libraries.  Hope you find it useful. 

[mankan]

Looks nice, I tried just to realize that my SA is missing a 4. Do you think E440x would work with your program, if you allow it to connect to it? I'm happy to do some basic testing.

[jhenderson0107]

What specifically does your SA return when sent the IDN? command?  I just added the E44xxB variant support to the application in the off-chance it uses the same command set.  Get a new copy of the executable and give it a go. 

[mankan]

Awsome, it returns

Code: [Select]

Hewlett-Packard,\sE4407B,\sMY41440643,\sA.14.06\n I fail to get the updated copy, dropbox says file is deleted.

[jhenderson0107]

I've updated the link with the new version. 

[mankan]

It starts and works, a bit sluggish, still useable though. I suspect some commands are not supported and times out.

[jhenderson0107]

Are timeout messages recorded in the Log on the first tab?  Are you connecting via ethernet, GPIB or usb?  On my PC, it detects instruments and begins operating quickly and operation is fluid. 

That "Query Unterminated" is indicative of a SCPI message parsing error.  Perhaps you could fire up a SCPI event viewer to isolate which command(s) are misbehaving.  Then, I could address the problem. 

[mankan]

The log just says:

Code: [Select]

Scanning (USB|TCPIP|GPIB)?*INSTR for devices...
Device E4407B #MY41440643 GPIB discovered
Device opened ok
I'm using GPIB (Genuine NI USB).

Attaching command trace (csv file as txt), line 50 is highly suspected "ROSC:SOUR?". Cannot find it in the programming reference for PSA & ESA (aka E440x).
And as you can see in the screen dump I'm using an external reference.

edit: Re sluggish operation, one screen dump round trip takes 5-6s over GPIB.

[jhenderson0107]

The VISA trace reports 4.7s to transfer the screen from the instrument.  That's far worse than my E4440A, which takes about 1/2 second whether connected via ethernet or GPIB.  Perhaps you'd prefer to disable Automatic display updating and manually Refresh after changing instrument state. 

The PSA software manual indicates that GPIB transfers will likely be slower.  Can you plug in ethernet to compare? 

I've changed the applet to eliminate sending the ROSC command when connected to E440x instruments.  Updated the link to the latest SW on the original post. 

[mankan]

Thanks for the update, "Query Unterminated" is now gone. Yes, disabling auto refresh is a must for GPIB.

Unfortunately no ethernet available. For me SA.exe can now replace the PyVisa console utilities I made.

[jhenderson0107]

My bench is also equipped with an Agilent Gpib->Usb adapter and the transfer takes only ~600 mS on my E4440A.  I wouldn't have expected a significant performance disparity between our analyzers, as they are of the same vintage.  While my host PC is a relatively-modern Ryzen 3950X, I wouldn't expect the host to dominate transaction rates. 

The utility is sufficient to minimize trips between my desk and the electronics bench when sharing results with colleagues.   I've written lots of similar apps to control signal generators and other gear in the lab. 

[mankan]

I tried switching to my NI PCI adapter, equally slow :-(
My host PC is a 10+ year old Intel i7 4 cores @2.8GHz running Windows 7.

I also tested a simple Python script using binary transfer, also 5-6s for one screen dump. Drive R: (RAM disk?) is a bit faster than C: which takes around 8s.

[mankan]

If I remove the ":MMEM:DEL" command I can do 5-8 captures per second in Python. I guess I trigger some slow filesystem code in the analyzer. C: and R: are equally fast.

[jhenderson0107]

I fetch the image using this snippet:

Code: [Select]

   
Command(":MMEM:STOR:SCR 'R:SCREEN.GIF'");
string result = GpibBinBlock(Query(":MMEM:DATA? 'R:SCREEN.GIF'", true));
Command(":MMEM:DEL 'R:SCREEN.GIF'");

Which seems similar to your python code.  But if we remove the MMEM:DEL, then the file won't be deleted.  And consequently, the existing file ('R:SCREEN.GIF') won't be overwritten on the subsequent invocation.  So, I don't think we can omit that. 

[jhenderson0107]

Well, nothing is beyond my capacity for error.  I removed the file deletion from the code snippet in the library, recompiled the app and it still works normally.  I've updated the link in the original post with the latest version including this optimization.  Please let me know if this improves your screen fetch times. 

[mankan]

My capacity for errors seems to be like yours.
I cannot repeat what I did last night, i.e. getting the file overwritten without delete first. So in short SA.exe version 1.0.0.11 shows a static screen for me.

[jhenderson0107]

Why am I not surprised.  The nice thing about software is that it always behaves predictably and is 100% repeatable.  Except when it isn't. 

I've added the file deletion back into the library and pushed v1.0.0.12 to the original post. 

[mankan]

I did another test today and used a USB/GPIB adapter of the following kind: https://github.com/xyphro/UsbGpib. SA.exe connects and sends all commands but fails on the ":MMEM:DATA?" command with the message "Current device doesn't support screen capture". The weird thing is that my Python script works.
Not sure what's wrong. Attaching NI I/O Trace.

[jhenderson0107]

Can you confirm that your python script uses the precise SCPI commands listed below?

Code: [Select]

   
Command(":MMEM:STOR:SCR 'R:SCREEN.GIF'");
string result = GpibBinBlock(Query(":MMEM:DATA? 'R:SCREEN.GIF'", true));
Command(":MMEM:DEL 'R:SCREEN.GIF'");

Perhaps your script is writing to a different drive or some other small detail differs.  And can you confirm that the SA.exe still works with other GPIB adapters such as the Agilent and/or NI?  That is, SA only fails when using the Xyphro adapter?  I believe SA.exe is using a VISA timeout of about 500 mS.  Perhaps that's too short for this particular adapter...

[mankan]

Yep, I'm using the same commands, same drive:

Code: [Select]

dev.write(":MMEM:STOR:SCR 'R:SCREEN.GIF'")
data = dev.query_binary_values(":MMEM:DATA? 'R:SCREEN.GIF'", is_big_endian=True, datatype='c')
dev.write(":MMEM:DEL 'R:SCREEN.GIF'")

but I also have

Code: [Select]

dev.timeout = 15000 so maybe trying increase the timeout in SA.exe?
And yes, SA.exe is still working with my other adapters. Did a quick test with my NI USB one. Lowest working timeout with that one is 3500ms.
For the Xyphro its more like 6500ms.

[jhenderson0107]

The link on the original post has been updated to a new version which increases the timeout to 10s.  Let me know if this works out. 

[mankan]

Yes, the new version 1.0.0.13 works with the xyphro adapter.