GPIB instrument Screen Capture in Definite Length Block format

Question

Need help for a person wanting to convert to LabView!
I need to do a screen capture of an Agilent spectrum analyzer (Model 4408B) and this SA will output an image in JPEG in 488.2 Definite Length Block format. This means the JPEG file will have a header that starts with a "#", is followed by a single digit that gives the length of a following count field, and then the count field, which gives the length of data being sent. For example, to send a block of 1024 bytes, the header would have the form "#41024".
We do a lot a screen captures in our testing, so we have a many programs in Agilent VEE to do this on a routine basis. In VEE, there is a function called Read BINBLOCK which reads the image data and strips of the header mentioned above before we write the data to a file.
I started to port this program to Labview to see if we can speed up our testing (in general, not for screen capture). So with Labview 6, I use the "GPIB Read" function to read the image data from the GPIB bus, then write the data into a file. But using a probe, I found that header mentioned above is still there and any image program wouldn't read the image file at all (Can't Open or Can't Determine Type). Furthermore, the "Write File" function in Labview adds some additional header before the "#41024"-type header mentioned above.
By the way, I tried the GPIB function "RECEIVE" instead of the "GPIB Read" function above and got exactly the same result.
So the problem has 2 parts:
1. Is there a way to read, or receive, Definite Length Block data from the GPIB bus (similar to VEE's Read BINBLOCK function).
2. Is there a way to prevent Labview's "Write File" function not to add some other header of its own to the saved file.
NOTE: In the "Write File" function, I experimented with using a Pos_Offset value ranging from 1 to 8, in order to get rid of the header caused by part 1 above. But anytime the Pos_Offset value is greater than zero, the saved file will be empty!
I appreciate any help from the Labview community for this seemingly simple problem.

Answer 1

Ray K., you are a scholar and a gentleman! I appreciate your extremely helpful suggestion.
I tried your suggested VI to strip off the header portion added by the 488.2 Definite Length Block format, and with a little modification, it works like a charm. The only thing is that I have to use the "RECEIVE" function (the "GPIB Read" function wouldn't work). But "RECEIVE" works beautifully, and that's what counts.
The only minor issue is that you have to set the Byte Count of the "RECEIVE" function to tell it the size of the file being received. If Byte Count is not wired, no data will be recieved, even if you set the mode to 1 or 2 to detect the end of file. If Byte Count is set to a number greater than the actual file size, it will work OK. In this case,
I know the file size so I can set Byte Count correctly. But is there a way for the "RECEIVE" function to detect automatically the End of File so that I don't have to fumble around with Byte Count? As I said, I set Mode value to to 1, 2, or other values but that wouldn't work either.
Both the "Write File" function (with Header set to False, which is the default) and the "Write Characters to File" VI work perfectly as you pointed out.
My only remaining question is why "GPIB Read" wouldn't work (with any value of Mode setting and Byte Count) while "RECEIVE" function works. "GPIB Read" did receive the GIF file, but it can't be opened.
Thank you for your great help.