My goal was to transfer the EMC personality which was loaded into the NVRAM to another 8595E which had the quasi-peak detector hardware. I was unsuccessful with this approach but eventually found a way to do it via GPIB.
Could you write up the procedure here? I have an 8594E with opt 119 and the noise figure measurement personality installed, but I don't have the original noise figure personality card. It would be great to be able to safely back it up.
Well, it's not a straightforward procedure, unfortunately. But I'll give it shot.
Let me caveat all this by first saying it worked on a 8595E (maybe it was a 8591E?) loaded with the EMC personality. I don't have the EMC card itself to double check, but everything seemed to work fine after being transplanted to a second 8595E that had the quasi-peak HW installed.
One thing missing, however, are the various EMC limit profiles which are loaded by the DLPs directly from the card. Since I don't have the card, manual entry of the profiles is needed. I don't know if Noise Figure and other personality cards have the same issue.
Also, I did this a couple of years ago, so hopefully I got it right.
In a nutshell, everything the card loads is visible via GPIB commands but they are scattered throughout different storage types. The procedure is to get a directory of all of them, retrieve them one-by-one, and then push them back into the target.
I'll point out there is a command call "USTATE?" which appears to dump everything in the SA, including what was loaded by the card. In theory I think it can be used to transplant the personality, but I couldn't get it to work. I think something was wrong with the format of the dump I captured. Pushing it into the target always failed. Perhaps someone else can try with better luck.
To do it piecemeal like I did, you would first use the "cat" command to get a directory list of everything. The EMC card created ACTDEFs, DLPs. KEYs, and TRs.
cat d* <-- includes dlps, actdefs, and keys
cat t* <-- includes traces and variables
There are other "cat" commands for other storage types which other cards may use (cat on*, cat prefix*, etc). See the programmer manual for the full list. You may need more than what I used.
From the "cat" output above you then sort out what's what. The output is minimal with each item name and the length in bytes. As you retrieve individual items it's a good idea to always sanity check the number of bytes received against the length reported by cat.
For cat d*:
- KEYCMDs and KEYLBLs are tagged with "KEY#nnn". Both the KEYDEF and the KEYCMD must be retrieved for each KEY entry. This is done with the commands (nnn is the key number):
keydef nnn?
keycmd nnn?
- DLPs and ACTDEFs are co-mingled. Retrieve everything with (xxx is the name):
xxx?
Compare the length of the item returned against the length reported by cat. If it's wrong, it's an ACTDEF. Retrieve ACTDEFs with:
actdef xxx?
For cat t*:
Both variables and traces are retrieved with:
xxx?
If the returned value is in A-block format (see programmer manual), it's a trace. Otherwise, it's a scalar variable. I can imagine other cards could also store vectors in addition to traces. They should show up here too in A-block format.
Ok, so now you have a pile of ACTDEFs, DLPs. KEYCMDs, and variables, and traces. How to get them into another analyzer?
ACTDEFs: They can be pushed back in the exact same format that they were read out. The readout includes the "ACTDEF" command, and the value is in A-block format. (Note: In fact, much of the data retrieved in the preceeding commands is in A-block format so you need to do everything with an 8-bit clean path.)
DLPs: Recreate using "FUNCDEF xxx,yyy" where xxx is the name and yyy was the definition.
Variables: If the variable retrieved is in A-block format, it's a vector and restored as a trace (below). Otherwise it's a scalar. Recreate scalars using "VARDEF xxx,nnn" where nnn is the value.
Traces: Recreate by reading into trace C with "TRCyyy". Then define the target trace with "TRDEF xxx,401", and move trace C to the target with "MOV xxx,TRC".
KEYs are complicated. You will find that for each key number, a KEYDEF and a KEYCMD exists, AND they are different, BUT some of the definition overlaps in memory, so you can't use both. How do you know which one to pick?
If the KEYCMD retrieval has an A-block, its either a KEYCMD or KEYDEF. If no A-block, then it's a label and recreate with "KEYLBL xxx,yyy" where yyy is from the KEYDEF. That case is easy.
If the definition has two commands in it, it's a KEYCMD. Recreate with "KEYCMD xxx,yyy". If a single command it's a KEYDEF. Recreate with "KEYDEF xxx,yyy". If the definition of the KEYDEF of the same number as the KEYCMD also has a label associated with it, recreate the label with "KEYLBL xxx,yyy" where yyy is the label from the KEYDEF readout.
That should be it. It seems likely I did a "DISPOSE ALL" on the target to make sure it was clean before pushing the new definitions at it.
I never said it was simple. HP's crazy formats and inconsistencies in the command parser doesn't help.
The EMC card loaded 3 ACTDEFs, 103 KEYCMD/KEYDEFs, 118 trace/variables, and 118 DLPs into memory. The procedure is not something you want to do by hand.
I have a pile of perl and bash scripts written for linux that calls linux-gpib that does what I've described above. Some hand tweaking of the data was also needed. This was a one-shot use for me, so I never finished it to be generalized. If there's any interest I can post it with the expectation that it's a guideline for someone who wants to do a real implementation. There was one eevblog member who was interested in doing this, but other priorities indicated it would be months away.
I'll say again that the "USTATE?" command has promise to replace all this nonsense. It bothers me I couldn't figure out why it wouldn't work.
Home
Help
Search
Login
Register
