ASCii data format is considered invalid

[evgmik]

In the Lab::Moose::Instrument::SCPI::Format module the sub format_data_query considers ASCII format as invalid, since it programmed to accept only REAL, i.e. binary format. Consequently, the function croaks if it sees the reply to $self->query( command => 'FORM?', %args ) as ASCII which is perfectly legal and default for most of instruments which I saw.

Also sub format_data in the same module might send misformatted instruction if format => 'ASCII'. In this case the length field is not used. But the sub uses it in the communication with an instrument which might throw an error.

[amba]

thanks for the comment.

I am confused. According to SCPI sec. 9.2 "FORMat[:DATA]", the length parameter is valid for all formats, including ASCII, where it specifies the number of significant digits and "0" uses the instrument's default. I would have assumed that the length parameter is always returned by the query.

Which instruments did you try with and what is returned by the query after writing "FORM ASCII, 0"?

Best, Simon

[evgmik]

Well, I am looking at real world cases: Agilent-E440 and Rigol-DSA800. They both report just ASCII to the query if format was set to it or right after the hardware reset. They both also take only FORM ASCii as the setter without length parameters. Here is exert from the Agilent manual

:FORMat[:TRACe][:DATA] ASCii|INTeger,32|REAL,32|REAL,64|UINTeger,16

Also notice that it could be not only REAL but also INT or UINT for the case of Agilent. For Rigol only REAL,32 or REAL,64 or ASCii.

I tried to execute $instr->write(command=>'FORM ASCII,4', timeout=>1); for Rigol, at least it did not crash and just set ASCII format. But it could be just luck since it it out of the book behaviour.

[amba]

@evgmik: Can we close this one?

[evgmik]

Yes. I think it is fixed.