You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I decided to implement screenshot using usbtmc. This means sending two commands (":hardcopy:inksaver 0" then ":display:data? fmt") then doing a read of raw data. As currently implemented usbtmc.Device and ivi.Instrument each expose a single interface -- Read. usbtmc implements that method using an instance-wide value of termCharEnabled which is always set to true. This works well for reading ASCII responses, but has problems with raw data such as the PNG screenshot.
Why am I filing an issue in ivi? ivi.Instrument appears to be the interface that matters. If a ReadBulk method is to be added or the Read signature changed, it would appear that ivi.Instrument is the place where it starts, with usbtmc following along.
So, what is your preference for how a term-char-insensitive read routine should be implemented? In my futzing around, I made a ReadBulk that calls a common doRead (the current Read method, but with a useTermChar argument). I assume changing the Read signature would be bad, as it would break the termChar functionality (which I assume is useful elsewhere). Looking at python-ivi (also MIT licensed) they appear to prefer the term "IEEE block", but I haven't read the IVI spec so I don't know if that's an official thing or something they've made up.
The text was updated successfully, but these errors were encountered:
I decided to implement screenshot using usbtmc. This means sending two commands (":hardcopy:inksaver 0" then ":display:data? fmt") then doing a read of raw data. As currently implemented usbtmc.Device and ivi.Instrument each expose a single interface --
Read
. usbtmc implements that method using an instance-wide value oftermCharEnabled
which is always set to true. This works well for reading ASCII responses, but has problems with raw data such as the PNG screenshot.Why am I filing an issue in ivi?
ivi.Instrument
appears to be the interface that matters. If aReadBulk
method is to be added or theRead
signature changed, it would appear thativi.Instrument
is the place where it starts, with usbtmc following along.So, what is your preference for how a term-char-insensitive read routine should be implemented? In my futzing around, I made a
ReadBulk
that calls a commondoRead
(the currentRead
method, but with auseTermChar
argument). I assume changing theRead
signature would be bad, as it would break the termChar functionality (which I assume is useful elsewhere). Looking at python-ivi (also MIT licensed) they appear to prefer the term "IEEE block", but I haven't read the IVI spec so I don't know if that's an official thing or something they've made up.The text was updated successfully, but these errors were encountered: