I've managed to get LABview to retrieve a PNA screen dump ( HCOPY:SDUMp:DATA?) and parsed the header info off of the PNG file, however, after saving the file, when I try to open it in Windows, I get an error saying the file is not the right format. I'm sure someone out there has successfully saved a PNA screen dump. (?) Below are two variations I've tried...
That command works as advertised but, it only parks the file on the PNA itself in the Documents directory. I'm trying to retrieve the file to an external computer. :-)
and I should add that it will read this back as an ascii form, and might stop if it sees the EOF code. So beware of that; the other option is to map a network drive.
(Read-Write) Transfers data between the PNA and an external controller. Other MMEM commands transfer data between the PNA application and the PNA hard drive. If <fileName> already exists, it will be overwritten. The file must be no larger than 20MB. To read trace data from the PNA in block format, use CALC:DATA. | |
Parameters |
|
<fileName> | String - File name. See Specifying Path Names |
<dataBlock> | Block Data - The contents of the file. The data block is a block of binary data. Use the following syntax: #<num digits><byte count><data bytes><NL><END> where: <num_digits> specifies how many digits are contained in <byte_count> <byte_count> specifies how many data bytes will follow in <data bytes>
Example: #210ABCDE+WXYZ<nl><end> Where: # - always sent before definite block data 2 - specifies that the byte count is two digits (2) 10 - specifies the number of data bytes that will follow, not counting <NL><END> ABCDE+WXYZ - 10 digits of data <NL><END> - always sent at the end of block data |
Example | |
Query Syntax | MMEMory:TRANsfer? <fileName> Reads block data from the specified file location. |
Not applicable | |
I was hoping to stay away from doing that, however, I'm burning someone else's money so, I'll give it a shot! Thank you for the tips and tricks. I let you know how it goes.
Hello,
Two recommendations.
1) (Same recommendation as Dr. Joel's) If you are connected and automating via LAN (the analyzer supports GPIB, USBTM and LAN automation interfaces) then consider mapping a drive from the PNA to the controlling PC and then use the HCOPY command to dump the PNG file to the mapped drive letter. EASY!
2) Within the NI LV environment look for an IEEE-754 bin block data transfer.
Usually the corrupted MMEM:TRAN file either still has the binary bin-block header file in the transfer and stored results OR the little endian - big endian LSB / MSB byte order must be reversed, or both are at fault. The NI LV bin-block transfer should auto strip the header (if you can find that data type in the NI-LV environment). The LSB / MSB issue can be swapped via the PNA command FORMat:BORDer [NORMal | SWAPped] command.
I am looking on our archives for an NI LV file bin-block transfer. It will not be for a PNA but regardless if I find an example it should point you in the correct direction (worst case) or it will actually work with the PNA directly (best case). If I find the elusive example I will post it.
Sincerely
tsilchia.
Okay, so far, I have mapped a drive on the PNA pointing to a folder on my laptop. I do the HPCOPY command to the mapped drive and go from there. (See VI snippets) It works well enough for me to continue with my project. I will also continue with the LSB/ MSB issue to see if I can get that to work, which, would be a more elegant solution.
Not sure if this VI will help. It was written as part of an O-scope image save and subsequent bin-block xfr via NI LV.
I did not write the VI.
tsilchia.
I'll have to open this up at home...
VI snippets for saving to mapped file and using Screen Dump in VI.
I think you want this command: HCOPY:FILE "myFile.png"