C & DCOM Transfer files from / to PNA with remote computer

I am curious if there is a way Agilent would recommend to transfer a file (one of the calibration file types for example) back and forth to the PNA via COM in C#.I am aware it could be achieved by mapping drives and setting up shared folders etc but this requires a little too much setting up for my users... I am trying to keep a system that would allow them to simply swap out / move one instrument for another with minimal effort.

I have seen examples of how this could be achieved in SCPI (view topic) but the rest of my app is constructed using COM and C#.

Thank you for your help.

*edit*Also, just noticed that this codes errors when I have loaded into the PNA one of each measurement class.

It seems this works for "Standard", "Gain Compression" and "Noise Figure Cold Source" but "Vector Mixer/Converter" and "Scalar Mixer/Converter" errors with:Unable to cast COM object of type 'System.__ComObject' to interface type 'AgilentPNA835x.IMeasurement10'. This operation failed because the QueryInterface call on the COM component for the interface with IID '{106E07A5-F2BA-4A4A-89A6-08C63A0A7D7B}' failed due to the following error: No such interface supported (Exception from HRESULT: 0x80004002 (E_NOINTERFACE)).Strange huhh

Use of the "MMEMory:TRANsfer" SCPI command with the COM ScpiStringParser's Parse or Execute method may work OK for files that contain only text, but not for files that contain binary data. The reason is because the input argument and the returned argument are both string data type. When you put the file contents into a string, the ScpiStringParser will stop upon encountering a byte where all 8 bits are zeroes, because that is how strings are terminated (a 'null' byte at the end).

The PNA does not (not yet at least) have a native COM method that serves the same purpose as that SCPI command.

Regarding the IMeasurement10 issue, that was an oversight in the A.08.33.xx releases of firmware (you must have an A.08.33.xx release of firmware as that was when IMeasurement10 was introduced). That has been corrected in our next major firmware release which is due to come out very soon. I can't give an exact timeframe yet but I will make a note to post a reply back on this thread when its released -- I could also pm you if you would like.

the reason for giving file transfer capability through DCOM low priority and thus not having any commands for it yet, is because if you can control the PNA using DCOM then presumably you have a network connection to the PNA and the client PC is running a Windows OS. Given those two conditions, the OS on the client PC provides other means for transferring files from another PC on the network and none of those methods will have any dependency of the type of the file being transferred.

I initially did try this, but I selected a CSA file (which we now know wouldn't have worked) to test and never got it working correctly.Perhaps you have an example which uses the parser which works for an ascii file?

"The PNA does not (not yet at least) have a native COM method that serves the same purpose as that SCPI command."

D'oh!

"

Regarding the IMeasurement10 issue, that was an oversight in the A.08.33.xx releases of firmware (you must have an A.08.33.xx release of firmware as that was when IMeasurement10 was introduced). That has been corrected in our next major firmware release which is due to come out very soon. I can't give an exact time frame yet but I will make a note to post a reply back on this thread when its released -- I could also pm you if you would like."

Bingo, that's the firmware I'm using for sure... if I used IMeasurement9 instead would it work? (at home now so can't check till work tomorrow).

I am a little confused about the interfaces in general for the PNA.E.g. IMeasurements, IMeasurements2, IMeasurements3 ... and now up to IMeasurements10. I can see that the number is used to distinguish newer/updated interfaces without disrupting previously written code. Would you say I'm always best (when writing new code) to use the highest interface number available?

Also some clarification; when/why should I use Measurements or IMeasurements when creating a new object ?Ignoring the iMeasurement10 oversight; these three all seem to create the same result.

"the reason for giving file transfer capability through DCOM low priority and thus not having any commands for it yet, is because if you can control the PNA using DCOM then presumably you have a network connection to the PNA and the client PC is running a Windows OS. Given those two conditions, the OS on the client PC provides other means for transferring files from another PC on the network and none of those methods will have any dependency of the type of the file being transferred."

I agree with this rationale but... and there's always a but for me, when swapping out one instrument for another or installing my software onto a new PC the PNA has far too many steps in just getting it all working (certainly when trying to explain over the phone). Creating user accounts on the instrument (workgroup mode), PNAProxy, DCOM, Security, AgilentIO etc... it's far from the "good old days" of simply plugging it into the mains and making sure the GPIB cable is fitted.I would be nice if the PNA acted more like a .NET enabled web server so many of these steps were simply removed... any plans for this kind of thing??*cheeky grin and fingers crossed*

I am a little confused about the interfaces in general for the PNA.E.g. IMeasurements, IMeasurements2, IMeasurements3 ... and now up to IMeasurements10. I can see that the number is used to distinguish newer/updated interfaces without disrupting previously written code. Would you say I'm always best (when writing new code) to use the highest interface number available?

"

"

Also some clarification; when/why should I use Measurements or IMeasurements when creating a new object ?

"

You should always use an interface number that gives you all the functionality that you need at the time you are writing your code (and that may not be the highest interface number available at the time). Following this practice consistently makes your code the most portable among different versions of PNA firmware. The interface number that you use sets the lowest possible PNA firmware version that can support your code. If you always pick the highest then you always have to make sure that all the PNAs that you need to run your code against are updated with that same latest version. If you only have 1 or 2 PNAs to worry about then this not a problem, but people who write code for large distributed production test systems have to be more aware of the choices they make. The answer to your second question is related to the first. By using Measurements instead of IMeasurements, you are saying that you always want the latest IMeasurements interface available in the proxy DLL that you have installed on your client PC. If you then run your program against an older PNA version that had a lower IMeasurements interface number, then your program is not going to work if you used a method or property on that interface that is not available in that older interface.

Regarding:

"

I would be nice if the PNA acted more like a .NET enabled web server so many of these steps were simply removed... any plans for this kind of thing??*cheeky grin and fingers crossed*

"

We currently have no plans to do that, but it is an interesting idea and if we can find a simple way to wrap a .net server implementation around our existing COM interface we might consider that.

"Bingo, that's the firmware I'm using for sure... if I used IMeasurement9 instead would it work? (at home now so can't check till work tomorrow).

"

You'll find IMeasurement8 was the highest IMeasurement interface implemented by FCA in the A.08.33.xx firmware revs."

Hmmm... this leaves me with a new interesting quandary.I found the page within the pnahelp8_35.chm file which explains the use of the Interfaces (apologises for not finding this before posting my query).

This would be the ideal place to use Measurement as it would use the latest interface available based on which instrument I'm running it on which should all be dandy.Unfortunately due to the oversight in IMeasurement10 i cannot rely on this mechanism as it was intended.I somehow now have to go though all measurement classes that could possibly be available, find out which interface they first appeared in, then find out which firmware version that interface was implemented in.When working through the chm file; this isn't always clear (mainly due to some inconsistencies in the file).

Is there a big table or lookup mechanism available to assist me in this task?I can foresee myself having to rewrite the code above to something like this just to gaurentee no exceptions being raised.

*edit*Deliberate mistake (yeah right!)... That list of firmwares was taken from the help file from within the Measurement page history section which identifies when certain interfaces were introduced.My if statements don't account for firmware releases in between the one's mentioned...

else if (fwMajor == 7 && fwMinor == 2)

would have to be replaced with

else if (fwMajor >= 7 && fwMajor < 8 && fwMinor >= 2 && fwMinor < 35)

It's going to be awfully complex as time goes on to maintain this... (of course i could reverse the if order and keep just the LessThan's)

This would be the ideal place to use Measurement as it would use the latest interface available based on which instrument I'm running it on which should all be dandy."

No. C# resolves "Measurement" at compile time to whatever the latest version of the typelibrary that you have. By resolving at compile time, you don't get the latest interface of the instrument you are running on - you get the latest interface of the typelibrary that you compiled with.

If you are interested in running your code over multiple versions of firmware, you should use the lowest interface number possible. Start with just IMeasurement. Make it IMeasurementX if you need a method that doesn't exist in IMeasurement. Then look in the help document for which version of Firmware that interface was added. Now, you can document that your code requires that version number.

If you also have to run against a previous version of PNA code, then you will have to add logic within your code to handle the case when that interface doesn't exist.

For your example, IMeasurement will work fine - and will work over all versions of PNA FW.

I think I updated/edited my post whilst you were in the process of constructing your response.To always use the lowest interface available won't i have to construct that large if structure (or similar) each time I make a reference?Your suggested approach, when we encounter the IMeasurement10 oversight scenario, would involve much validation per new firmware... i'm trying to create structure where this isn't as required. Build in the stability from the start rather than wait for an oversight to be found then add code round it.

You will be able to determine - at compile time - what is the lowest interface required. Simply write your code against IMeasurement. If you find that you need a method that only exists on a later version of IMeasurement, only at that time should you start using the later version.

If you find that IMeasurement isn't sufficient, you can cast the IMeasurement pointer to a later version. You only need to do this local to the code that needs the later version. You can protect the catch with a try/catch or use the C# as operator to determine, at run time, whether you have support for this interface.

But, don't pre-emptively try to figure out which version of IMeasurementX you have available, without having a specific need for an IMeasurementX.

"You will be able to determine - at compile time - what is the lowest interface required. Simply write your code against IMeasurement. If you find that you need a method that only exists on a later version of IMeasurement, only at that time should you start using the later version.

If you find that IMeasurement isn't sufficient, you can cast the IMeasurement pointer to a later version. You only need to do this local to the code that needs the later version. You can protect the catch with a try/catch or use the C# as operator to determine, at run time, whether you have support for this interface.

But, don't pre-emptively try to figure out which version of IMeasurementX you have available, without having a specific need for an IMeasurementX."

I agree... perhaps the IMeasurement10 oversight pushed me off track into thinking this kind of thing was the norm as opposed to an exception.There'll come a time when I need something that was introduced inside IMeasurement10 and that'll become my minimum for that function... I'll just have to try and remember that it'll crash if I try grab the measurement name (and whatever else the oversight effected).

Thanks for your wise insights.Much appreciated you taking the time out of your day to assist.

*ponders if a similar oversight happened during IMeasurement6 since it appears to be missing from the help file... maybe IMeasurement10 will get banished in a later help file update*

IMeasurement6 added the ability to get to the EquationEditor. It's not going anywhere.

It isn't listed in the revisions at the bottom of the Measurements page in the help file. Just assume that it was added with IMeasurement7. It may have been added on a private build before IMeasurement7.

This help file currently is tied only to the N5264A PNA-X Measuring Receiver and none of the other PNAs. It may have information and commands listed that are not relevant to other models yet due to firmware differences. If you are not using the N5264A, the link below has a listing of the other help files based on latest firmware revisions.

FYI, PNA Firmware A.08.50.07 was released onto the web today (for N5242A PNA-X, N5264A, and 'C' models of PNA and PNA-L); it addresses the IMeasurement10 interface issue with FCA that was mentioned in this Forum thread.