DPO7054 viScanf TekVISA V3.0.2

[Roman_Vasiliev]

I am very new user of the digital scope DPO7054. I trying to understand and apply the buffered I/O with the DPO7054 scope using TekVISA V3.0.2.

Examples "bufferio" and "formatio" are not working properly. Even the already compiled binaries of this examples prints the error mesages in command line. The error messafes are:"The format specifier string is invalid" or "The specified operation or request timed out". I try to modify and to compile the examples, and my investigations brings the next information. Breakdown appears when the programm try to readout waveform from scope using viScanf() operation:

formatio.cpp:

...

...

 // Get first char and validate
 status = viSetAttribute(vi,VI_ATTR_RD_BUF_OPER_MODE, VI_FLUSH_DISABLE);
 status = viScanf(vi, "%c", &c);                                                                            // this viScanf() ok.
 if (status < VI_SUCCESS) goto error;
 assert(c == '#');
 

 // Get width of element field.
 status = viScanf(vi, "%c", &c);                                                                             // Programm terminates here 
 if (status < VI_SUCCESS) goto error;                                                                 // The error is : "The specified operation or request timed out"
 assert(c >= '0' && c <= '9');
...

...

The compilers are MVS++ 2005 Express Edition and Borland C++ 5.5.1 for Win32. Operation system Win XP.

Could someone make explanetion of this situation? Or show please the equivalent way how to make the console application for buffered I/O with DPO7054 using TekVISA?

[Makoto]

It seems like you are trying to read an IEEE488.2-formatted block response data, which begins with #nXXXXXXXX style header.  This is size-oriented data format I think it is easier to use viRead() rather than viScanf().

To read a 488.2 block resoponse, read the first 2 bytes (which shall be "#<number>"), read the next <number> bytes (which is normally 1 to 9 bytes such as "00004096" or any) to acquire the info about data entity length.  Then finally read the remaining data entity.

For example, if the response data begins with #800004096XXXXXXXXXXXXXXXXXXXXXXXXXXXXX..., the "X" array must have 4096 bytes without newline (LF) termination.  In this case you can read it by splitting to 3 time intermitted readings using size-oriented viRead() function.

[zhichu.chen]

Hi Makoto,

I've met the same problem of Roman_Vasiliev, and I'm new to Oscilloscope too. Could you give an example that can store the waveform to an array? I've modified the source code, it occurs error when it reads the very character after #, I cannot figure how this happen.

---

Makoto wrote:

It seems like you are trying to read an IEEE488.2-formatted block response data, which begins with #nXXXXXXXX style header.  This is size-oriented data format I think it is easier to use viRead() rather than viScanf().

To read a 488.2 block resoponse, read the first 2 bytes (which shall be "#<number>"), read the next <number> bytes (which is normally 1 to 9 bytes such as "00004096" or any) to acquire the info about data entity length.  Then finally read the remaining data entity.

For example, if the response data begins with #800004096XXXXXXXXXXXXXXXXXXXXXXXXXXXXX..., the "X" array must have 4096 bytes without newline (LF) termination.  In this case you can read it by splitting to 3 time intermitted readings using size-oriented viRead() function.

---

[Makoto]

Sorry but I do not have Tek DSO models, so I can't provide example codes here.  If the waveform response data sent from your instrument is IEEE488.2/SCPI binary block format, the same #dnnnnnnnnXXXX.... rule must be applied.  This is one of the IEEE488.2/SCPI standard data format and not specific to Tek scopes.

Actually what data image (expressing a BYTE array) do you receive the instrument?  Probably it begins with "#" and some decimal characters.

[zhichu.chen]

Thank you for your concern,

When I use viRead to read the buffer, I get something like "#400006" which has only seven characters. But when I use viScanf to read it, it occurs error when I read the "4" character. I'm totally confused. With LabVIEW, I can read the whole waveform but LabVIEW is not an option. I guess there should be some "secret" setups that affects the format of the waveform.

[Makoto]

it's bit strange...

> I get something like "#400006" which has only seven characters.

Is the data correct? By applying IEEE488.2/SCPI rule, the data contains no entity of waveform. The 1st "#4" means that the next "4" byte decimal indicates the length of data entity (= waveform data part), but it is "0000" meaning zero-length data entity.  And I can't see why the next byte is "6".

> But when I use viScanf to read it, it occurs error when I read the "4" character. I'm totally confused.

When you receive IEEE488.2/SCPI binary block, I don't recommend viScanf() function because it is optimized for ASCII data and not for binary block.  Instead it will be simpler to use viRead().

>  With LabVIEW, I can read the whole waveform but LabVIEW is not an option.

>  I guess there should be some "secret" setups that affects the format of the waveform.

When you could receive whole data, how many bytes did you receive from the instrument? Just 7 bytes, or more? (Recommend to use NI-SPY to capture the traffic for more accurate data watch.)  If the instrument really returns "#400006" (no data entity there?), I think the instrument seems like not generate waveform data to read due to some other instrument-specific setups.

PS:

Sorry I now noticed you are using TekVisa, not NI.  But I believe TekVisa also comes with a "trafic capture" tool like NI-SPY.

このメッセージは　07-18-2007 10:19 AMに Makoto が編集しています。

[zhichu.chen]

Yes, I use viRead to read as many data as it can, and it turns out that only 7 characters are read. I think that's it. TekVISA has something called "talk listener" thing does the same thing as NI-SPY, I suppose. And it gets all the message I need.

When using viScanf, only the first sharp symbol is read. So I think it's not an option here.

[Makoto]

>  With LabVIEW, I can read the whole waveform but LabVIEW is not an option

If you could acquire the whole waveform from LabVIEW program, try to capture the successfull traffic.  Then compare it with the traffic log on your problem case.  Something must be different.

[zhichu.chen]

---

@Makoto wrote:

>  With LabVIEW, I can read the whole waveform but LabVIEW is not an option

If you could acquire the whole waveform from LabVIEW program, try to capture the successfull traffic.  Then compare it with the traffic log on your problem case.  Something must be different.

---

Yes, I've saved some traffic as in the attached file, but it has some very strange visa commands which I didn't use and  how to use them. e.g., viGetAttribute.