Closed Skippy-the-bush-kangaroo closed 1 year ago
Is the OPC just responding with a '1' every time? Commands are already queued within the TCP server so this '1' would only be returned once all previous commands have finished executing
Yes, Although it differs from one manufacturer to another. I'm now implementing a mini circuits generator which has no OPC command, but it does not need to because every command get's an answer immediately so there is noting left in the buffer to wait for. (As far as I can tell at the moment, I just started.)
The interaction with the LibreVNA-GUI sometimes hangs if there is no data to be read. I have to check to be sure and if I'm able to, but I don't think other devices block my socket while waiting on an answer. But.. , I'll have to double check to answer this.
Keysight and "Rohde & Schwarz" devices also return errors as a tuple ( #number , ERROR ). This format might also be helpful for the LibreVNA. For these devices I always do a subsequent error check after every call. (SYST:ERR?)
I still don't understand the need for the command completely (as the LibreVNA-GUI already returns an empty response after execution of each command) but as this is a really simple addition, I have added OPC command. Sorry it took so long.
Summary
If I'm not mistaken, the *LST command is the only command which need to be polled and stored, one by one, into a buffer. This is time based as there is no way to tell what is the last entry.
On the other hand, when you ask for measured data:
:VNA:TRAC:DATA?
You'll receive the data in one poll. This is good. However when you ask for data which is not there you'll have a chance your SCPI application hangs or blocks at least the subsequent process flow.
PS: The *LST? command also returns some SCPI commands which are not listed in the programming application note.
Paths to implement it
Other devices have a buffer ready indicator: *OPC? Is this possible to implement this into the LibreVNA application?
Thank you .
Extra information
..