| Products > Test Equipment |
| Open source lxi-tools and liblxi v1.0 released for GNU/Linux |
| << < (6/67) > >> |
| RoGeorge:
5. --- Code: ---rogeorge@debian80:~/lxi-tools$ lxi scpi -r -a 192.168.1.3 "CHAN1:DISP?" 1 rogeorge@debian80:~/lxi-tools$ lxi scpi -a 192.168.1.3 "CHAN1:DISP?" 1 rogeorge@debian80:~/lxi-tools$ lxi scpi -a 192.168.1.3 -r "CHAN1:DISP?" 1 rogeorge@debian80:~/lxi-tools$ lxi scpi -ra 192.168.1.3 "CHAN1:DISP?" 1 rogeorge@debian80:~/lxi-tools$ lxi scpi -ra 192.168.1.3 "CHAN1 DISP?" Command error rogeorge@debian80:~/lxi-tools$ lxi scpi -a 192.168.1.3 "CHAN1 DISP?" Error: Read error (timeout) Error: Failed to receive message rogeorge@debian80:~/lxi-tools$ --- End code --- Passed |
| RoGeorge:
6. --- Code: ---rogeorge@debian80:~/lxi-tools$ lxi screenshot Error: Missing address rogeorge@debian80:~/lxi-tools$ lxi screenshot -a 192.168.1.3 Error: Missing model rogeorge@debian80:~/lxi-tools$ lxi screenshot -a 192.168.1.3 -m rigol Saved screenshot image to screenshot-000.png rogeorge@debian80:~/lxi-tools$ lxi screenshot -a 192.168.1.3 -m rigol -f DS1Z_SCR.png lxi: invalid option -- 'f' --- End code --- Passed Feature request 6.1. - add an option to specify the filename Feature request 6.2. - add a shorter syntax, like "scr" for "screenshot" Feature request 6.3. - make model optional, and auto identify the model using the IP and *IDN? Feature request 6.4. - add an option for datetime-stamp in the filename Feature request 6.5. - add an option for instrument ID in the filename (can be more than just 1 oscilloscope on the same network, so after a save there is no way to identify where from is the captured screen) Feature request 6.5. - add an option to immediately open the captured screenshot - for making multiple screen captures (manually) until the best waveform is captured |
| lundmar:
--- Quote from: RoGeorge on November 06, 2017, 04:04:32 pm ---Made a new build today and testing right now, so brace yourself for a lot of :blah: and :rant:, but no :clap:, even if you fully deserve all the appreciation. While my general impression about lxi-tools is a very good one :-+, and I highly appreciate what you already put there, in the next messages I will focus only on what I don't like, or on what didn't work as I expected. Many of them will rather be about my personal preferences and feature requests, maybe some misusage from my side, so not exactly a bug report. Didn't looked into the code yet. I will repeatedly post here while testing, but I will avoid discussing solutions during testing, so please don't get annoyed if I don't reply until tomorrow. --- End quote --- Thanks. Don't worry, I'm always looking for constructive feedback so we can steadily improve the tools and squash any bugs found. Thank you for your thorough testing. Let me comment on your findings accordingly: 1. Check. 2. I believe the way the commandline is described is fairly conventional. Yes, strictly speaking <command> is optional. However, you can't really do anything without the commands. I think it will only confuse users more if we make everything optional. Popular tools like git is described in a similar way. 3. Good catch. I've pushed a commit that should fix the issue. This is exactly why I need someone with multiple instruments to test :) I only have a single LXI instrument to test with :( 4. To be fixed. Update: FIXED 5. Check. 6.1 Already implemented, "screenshot [<options>] [<filename>] Capture screenshot" . If no filename is provided it will autoresolve it. 6.2 Sorry no. I'm not a fan of shorthand expressions like scr. To help lazy people the tool features full bash autocompletion ;) Try e.g. 'source <prefix>/share/bash-completion/completions/lxi' to load completion manually. 6.3 Seemingly a good idea. Assuming ID strings are consistent then it is possible. I think it should be added to the TODO list as a possible feature in the future. It is something that the screenshot plugin framework should be modified to support. 6.4 Hmm, you win. However, we don't want an option for it. I'll just add date-time by default :) Update: FIXED 6.5 Appending the ID is a bit more tricky since you don't want to include the full string in the screenshot filename. This is something that each screenshot plugin needs to handle because only it will know what to strip from the ID strings of the instruments it supports. This can work if ID strings are consistent, if not it will be troublesome. Add it to the TODO list. As an alternative and simpler solution we could append the model and IP to the filename. 6.6 A good idea but I think this feature should be reserved for a separate graphical screenshot tool to be included in lxi-tools. Something to put on the TODO list too. A simple QT or GTK application would do the job. Btw. feel free to register a github account and submit any issues you find in the lxi-tools issue tracker: https://github.com/lxi/lxi-tools/issues . Using github issues makes it easier to track and manage issues. |
| lundmar:
--- Quote from: glarsson on November 06, 2017, 06:08:01 pm --- --- Quote from: rhb on November 06, 2017, 05:10:30 pm ---I hate seeing unportable code that could trivially have been written to be portable to any Unix system. I've had to fix far too much of it. --- End quote --- Agree 100%. A common way to write code for Linux is to grep /usr/include until you find something. |O --- End quote --- I don't think anyone disagrees here to the extend it is possible. Just be mindful not everything can be done in portable code and sometimes non-portable code is required, especially when dealing with hw interfaces. Also, this is one open source project among many that I'm doing in the little spare time that I have available so I don't have the time to put endless rigor into making everything portable in the first go. That being said, anyone is welcome to contribute to the project and fix any issues they might find, including portability issues. |
| glarsson:
--- Quote from: lundmar on November 06, 2017, 08:25:56 pm ---I don't think anyone disagrees here to the extend it is possible. Just be mindful not everything can be done in portable code and sometimes non-portable code is required, especially when dealing with hw interfaces. --- End quote --- True, but the non-portable code can be located in separate files to make it easier to port to different platforms. --- Quote from: lundmar on November 06, 2017, 08:25:56 pm ---Also, this is one open source project among many that I'm doing in the little spare time that I have available so I don't have the time to put endless rigor into making everything portable in the first go. That being said, anyone is welcome to contribute to the project and fix any issues they might find, including portability issues. --- End quote --- I was looking at adding code to sigrok or port lxi-tools to macOS (a certified UNIX with a marketshare larger than Linux) but did get the feeling that contributions to lxi-tools supporting platforms other than Linux was not welcome. |
| Navigation |
| Message Index |
| Next page |
| Previous page |