Closed thseiler closed 4 years ago
Thank you for the PR. In the IEEE 488.2, this section is "informative" and not "normative".
According to SCPI99-6.2.4
Multiple <PROGRAM MESSAGE UNIT> elements may be sent in a <PROGRAM MESSAGE>. The first command is always referenced to the root node. Subsequent commands, however, are referenced to the same tree level as the previous command in a message unit. SCPI parsers shall follow the example presented in IEEE 488.2, section A.1.1. A SCPI parser shall NOT implement the enhanced tree walking implementation described in section A.1.2.
And you need exactly IEEE 488.2 Annex A.1.2. which shell not be implemented by SCPI.
Thank you for the clarification, and sorry for the noise...
Hi,
Thanks for this nice library! While writing a SCPI translator to substitute some equipment in a legacy application, I found a little issue with a command similar to this:
MEAS:CUR?;MEAS:VOL?;MEAS:POW?;OUTP?
libscpi woud mistake the second unit for a compound command MEAS:MEAS:VOL and emit an error.
I found in Annex A.1 of the IEE488-2 standard some example commands that are similar to my case, so I assume these are legal. However, I do not know the standard well enough to judge if my solution is the correct approach.
Best regards, Thomas Seiler
----- commit message ----- Not all program messages with several program message units are compound statements. Currently the parser uses hints like the colon or asterisk at the beginning of the next command to determine whether or not the next program message unit should be treated as compound command.
The approach fails for sequences of valid device specific commands unless they start with colons. Consider:
TREE:TESTA?; TEXT?
In this case , second unit is treated as compound command "TREE:TEXT?" which would not exist.
Therefore modify the parser to first check if the unit is a valid program message as it stands, before handling it as compound command