Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bulk read interface #19

Open
simmonmt opened this issue Feb 22, 2025 · 0 comments
Open

Bulk read interface #19

simmonmt opened this issue Feb 22, 2025 · 0 comments

Comments

@simmonmt
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant