Thanks again everyone!
I've done a fair bit more experimenting. I have to say the PC side of the Rigol does appear to be a major weak link. Well, I don't know how other scopes compare
But certainly it seems pretty weak on this scope.
To answer my earlier question, UltraScope has been updated since Dave installed it - according to what he showed on screen in his January video, he installed version 03, and it's now 05 on the website. But unsurprisingly, there's no huge difference - I guess maybe some bugfixes, but nothing seemingly major. Still no control panel and lots of obvious visual/UI bugs and plenty of missing features.
As a quick example of an egregious bug - on first connect it always shows the probe as being X1. Fortunately it doesn't actually tell the scope to change its X10 setting to X1, and if you then set the probe to X10 in UltraScope you will be in sync again and future changes will work OK. Not the end of the world, just struck me as an example of a bug that should have been spotted in 30 seconds if anyone at Rigol had thought to QA their PC software
I've also had some significant problems with the LAN connection. I got it configured on the scope fine, but then UltraSigma couldn't find it or connect to it until I rebooted the scope, even though it said it was configured and I could ping it. Far more annoyingly, I've now had the scope hard crash a total of four times, always while doing LAN related stuff. Once it happened when I was trying things in the Network menu. The other three times, it's happened while I have been connecting to the scope from external tools: twice with UltraScope, once from a third party tool, the LabView software released by Alessandro. In all cases, the scope just stops responding to new commands. It's still showing a waveform, and all lights are on, but no button or dial does anything, and the PC app connected to it will freeze or hang or show an error.
So that's a bit worrying, and I guess maybe I should go back to USB - it didn't happen when I was connecting with UltraScope via USB.
I'm currently in the process of installing a new KUbuntu VM in VMWare Workstation, so I can try out DSRemote. Maybe I'll get a bit further with that - certainly its UI looks a bit more complete than the others.
Anyway, I don't mean to sound down - the scope itself is clearly awesome, and I'm sure I'll find that I don't need tight PC control or fast screen updates. It's no hardship leaning over and using the scope interface. And I'm sure I'll find I can export the data I need. The only reason I'm concerned at all is because the data I will mostly want to look at, in the short term at least, will be long running captures, lasting tens of seconds or a couple of minutes, with no repeating data. In other words, several screens of data, which I had hoped I could easily get exported as a single wide image and then a corresponding CSV data table. I'm sure the latter is possible, but for the former I'm wondering if I need to simply take multiple screen shots as I scroll across a recorded capture on the device.
I'm sure I'll figure it out. The Labview-based software by Alessandro did look promising, with its Long Wave Capture mode, but when I tried it that was one of the times the scope hard crashed (and the PC app. I'll try that again, maybe over USB next time, and contact Alessandro the author if it persists.
Unless you have a special project, I think you'll use the scope directly and not want to operate it remotely.
In this case, I imagine yes - as there's no complete control panel option available for the DS1054Z it seems (I don't think DSRemote is complete, though it does have lots of options.)
But had there been a complete option - as the software for the DS1052E seems to be - then I can't imagine why I'd use the scope rather than the PC. I'd much rather look at the UI on a 1920x1200 screen and click through menus with a mouse, than press buttons on a physical device that I have to lean over to reach. Not that the front panel of the DS1054Z is hard to use - in fact it seems like a pretty decent UI - or that leaning over is hard!
Just, with full remote control, I can't see why it wouldn't always be quicker to use it via a PC. At worst it would be no slower, but at best it would be a lot quicker - eg where on a physical UI I have to turn a dial to change from <high value> to <low value> and with mouse/keyboard I can click and then type. And just in general, I feel mouse/keyboard would be quicker than using physical buttons. Not to mention it enables having the scope much further away than I would otherwise, if there's no need to easily read the screen and physically press buttons.
But anyway that's all moot because the DS1054Z doesn't have that. And that's fine. I can see now that it's definitely better to have a sophisticated scope without decent PC access, than a good PC interface on a rudimentary scope, so I'm certainly glad I got the Rigol.
I've written many QT programs and if you can get it compiled on Windows or find a Windows executable, it should be totally transparent whether you're running it on Linux or a Windows system. After all that's the main purpose of QT (to be cross platform compatible). If you have trouble, I may be able to make time to compile it for you.
Thanks very much for the offer. I've done a bit of QT development and compiling before, so I should be OK in theory. My concern was that there might be platform-specific code in there which wouldn't compile on Windows. I know in theory QT is meant to prevent that, but in practice I suspect that's not always the case - especially in any software that connects directly to hardware. DSRemote supports USB connection via a Linux-specific USB driver. I would suspect it therefore includes headers or makes system calls that can't compile on Windows. So given it appears to have been targettd at Linux exclusively, I'd be surprised if it compiled immediately on Windows (or OSX.) But it might just be a case of commenting out those references, or there might be a make variable to exclude anything USB-related from the build.
For now I'll just use it via Linux as I can do that fairly easily via VM and/or Raspberry Pi. But if I find the software useful I might have a go at compiling it on Windows at a later point.