Hi, I just updated my CCDOPS from rev. 5.56 to 5.61 and notice that I now have to go through an extra step when initializing my STL-11000 Filter Wheel. Previously, in rev.5.56 (Build-1-NT), when CCDOPS established communication with the camera, the internal FW-5 filter wheel would startup, and rotate to the (user's default) filter position. That position, for those who may be unaware of the hidden option - was set by the last user selected filter position, when CCDOPS was last run using ADMINISTRATION mode, to redefine filter names. However, in CCDOPS rev. 5.61, the filters are now grayed out ... AND ALSO are showing the "default SBIG" names. If I click on menu "Camera->Auto Filter Setup", I get the message that this is only available for the current STX and STF-8300 cameras. Now, I am forced to click on the Filters menu "FILTER SETUP" command - which finally opens the Filter Names I had been using all along, for years. On the other hand, CCDSOFT, written by Software Bisque as contracted by SBIG, doesn't have this bug. There, when the camera is "connected", the filter wheel is AUTO identified and initialized to its user set names, with no further action required of the user. Since the automatic Filter Setup, on startup was previously working so well with CCDOPS rev. 5.56 - WHY did you remove it, and added an extra step to our session startup workflow? There are still a lot of STL cameras out there. I had hoped there were some "unidentifiable improvements" in CCDOPS in this new rev., to make it worthwhile, but it seems to be more trouble than it is worth. Only solution is to stop updating CCDOPS every time, and go back and stay with the last known properly working revision. Given this annoyance, will Diffraction Ltd. fix this oversight ... or is it really just a bug? Joe
When we took over CCDOPS was already at 5.57, and we have no revision history (except for release notes) prior to that date. Changes to CCDOPS since then have been limited to bug fixes, switching the default file format to FITS, adding some new camera models, and updates to factory test functions. We've definitely not done anything to STL functions, since we can't test any changes in that area (for whatever reason the old company apparently didn't keep an STL camera available for technical support, so we don't have one). Additionally I've looked at our source control system, and I don't see any changes to filter wheel functions. I'll see if Adam has any insight.
Thanks Doug, I will be interested in what you and Adam discover. Whatever happened along the way to rev. 5.57 (and later), I should have also mentioned that I had initially done the update from rev. 5.54 (which I used for years), to a newer revision, saw this problem, and after a few minutes, decided to go back to the old trustworthy workhorse CCDOPS rev. 5.56 Then the other day, I relented and figured I might have done an improper update, or there was an STL Firmware update required to fix it, perhaps I installed some other interim rev. which introduced the filter bug, So I re-downloaded and installed the very latest update 5.61 again - just to be sure - and the problem is definitely still there. I assume you have the old rev. 5.54 installer somewhere on file, and can quickly verify the "filter initialization" annoyance in a matter of minutes, before returning to whatever you are presently running on your PC. The problem must have started when SBIG introduced the STX and STF-8300, since a "specific" message does pop up saying ONLY these new cameras are supported by the old "Auto Filter Setup" command. Could it be that the firmware commands are so radically different for these compared to the STL and earlier vintage camera codes, that it was easier to just purposely erase the subroutines to handle the additional different programming, for vintage cameras? Luckily, this bug is not a show stopper, but I would like it fixed. CCDOPS is still a simple and great tool. Joe
Hi Adam and Doug, I originally stated that: ... "the internal FW-5 (or FW8-L) filter wheel would startup, and rotate to the (user's default) filter position. That position, for those who may be unaware of the hidden option - was set by the last user selected filter position, when CCDOPS was last run using ADMINISTRATION mode, to redefine filter names." The other thing that was lost in later CCDOPS updates was that even if I run it now, in rev. 5.61, as ADMIN mode (one time), the updated version(s), no longer keeps the "user default starting filter position", on the next NORMAL mode run. It now always rotates the filter wheel to the CLEAR position instead. That may seem "logical" - i.e. always start the camera looking straight through a clear filter - but I find it convenient and quicker, to always have it rotate to my own favourite starting filter by default - perhaps it is always the RED filter since I may always do RGB runs. In my case, I chose "starting with the LUNAR filter" position (which actually contains my "IDAS Light Pollution" filter - better than using Clear, on start up orientation shots, here in the suburbs). So, it was nice that up until (rev. 5.57) came along, the filter wheel quickly initialized itself and spun directly to the user's preferred filter slot. CCDOPS rev 5.56 had it just right, on both cases. Something else Adam can check into while looking at the filter wheel handling code. Thanks, Joe
We did make one change to CCDOps' filter wheel initialization sequence relatively early on in our tenure of the source code: there was erroneous behavior where CCDOps would save the filter wheel type in the registry, and make connecting to new filter wheels impossible. The default behavior of CCDOps now is to auto-detect the filter wheel type, unless it is explicitly overridden by your camera (which is only true for Feather cameras, and a few other special cases -- not the STL-11k). It is possible this is a bug, but I'd need to know more about the connection attempts in order to start diagnosing things. Can you collect a driver log demonstrating the issue, and upload it here? (Instructions on how to do that here: https://paper.dropbox.com/doc/Collecting-SBIGUDrv-Logs-o0g0LaUnOGvXS7fGCjMp8)
************************** Hi Adam, I re-installed the last 3 versions of CCDOPS, and ran my "filter wheel initialization & recognition" test on each one. The test is simple and basic. I found that in the previous ver. 5.56 and also 5.57, all I had to do when launching either one, was just to click on the "FOCUS" icon and the STL-11000 would come alive, and rotate the FW5-STL filter wheel right to the LAST User Defined (or redefined) filter position. In my case, I once ran ver. 5.56 in ADMIN mode and redefined the five basic default "CRGB & Lunar" filters and gave them new Narrow Band filter names (still retailing the original CRGBL names, "concacted" with the new ones - as currently required to be done). Interestingly, re-installing either of the two older version over the top of the latest one (ver. 5.61), did NOT erase the new filter names. Installing either of the two previous versions, CCDOPS immediately found, and initialized the filter wheel, without any further user commands - not even "Establishing Connection" with the camera. The old versions save an enormous amount of time in the workflow with that built-in capability. On the other hand, the current ver. 5.61, requires many steps to get to the same point as the one-click method of the older ones. Even worse, the current one forgets everything if CCDOPS is closed - requiring the user to go through the same 4 or 5 step filter wheel initialization workload. One thing odd about this is that if you pop up the FILTERS menu item, right after doing a formal Filter INIT in the previous run. It's not as though the program doesn't know which wheel model and its installed filter names are already defined - it expects the user to use the INIT command every time. It just doesn't want to remember the very first initialization. In fact, it says it is going to a CLEAR filter, then the info bar says it has not been FOUND, even though it is clear as day that it is there - then proceeds to take a FOCUS image sequence using the NOT Found filter ! CCDOPS ver. 5.61 is a mess ... needs a lot more regression testing. One other thing I found was that installing the previous CCDOPS ver. 5.57 - it wants to install "Microsoft Visual Studio 2010 (x86)". In my case, it found a newer version of that "essential" module on my PC, so I avoided a further serious problem with that install. Seems Microsoft has been distributing a flakey version of the (x86) year 2010 version with its automatic UPDATES over the past year - and hasn't fixed the problem and has not updated the included Update to the present time. I found a web post suggesting that users go to the ( Microsoft Updates Visual Studio C++ Updates ) webpage, and install THAT one DIRECTLY - it is required for both x64 and x86 Win-10 systems ... but ONLY the (x86) has the bug, and needs to be replaced. This has cured another apps problem for me, and for many other users as well. Couldn't believe how sloppy and inattentive Microsoft has become. I suspect you are also distributing the bad Visual Studio 2010 (x86) module as well. However, I doubt it is the cause of the present CCDOPS problems, since ver. 5.61 still fails even on my PC with its "correct module" installed - and the one provided in CCDOPS ver. 5.57 INSTALLER, is bypassed. To help your analysis, and according to your suggestion, I am uploading FOUR CCDOPS LOG files for you. The first three are very brief run logs, of each of the latest THREE versions, where I opened the program and Clicked on "FOCUS" - which always automatically initialized the STL-11000 and positioned the filter wheel to the "default (user) filter" - enough to prove the problem. The FOURTH log file, is also CCDOPS ver. 5.61, but somewhat longer, showing the song-and-dance I had to get through, to actually position the filter wheel to the default filter - EVERY TIME I ran CCDOPS. Comparing the older version logs with the two current 5.61 runs should give you some leads. Hopefully, if there are any major benefits in 5.61, - it will eventually run as well as the two earlier ones did. Meanwhile, I'm going back to CCDOPS ver. 5.57-3, which "seems to be" hassle free - for STL cameras, at least. Attached LOGS ZIP folder, containing: (a) CCDOPS 5_56-1 GOOD for FILTER INIT.txt (b) CCDOPS 5_57-3 ALSO GOOD for FILTER INIT.txt ... then the two failed runs: (c) CCDOPS 5_61 FILTER INIT BUG.txt (which logs the same simple "FOCUS Command" test as (a) and (b) above) (d) CCDOPS 5_61 FILTER INIT BUG-2.txt (which logs everything I had to do to get to the same point as the simpler (a) and (b) versions). Good hunting and thanks for your support, Adam. Joe Z.
Hi Adam, I guess you have been busy with other problems, but its been two weeks, and I haven't heard from you regarding this CCDOPS 5.61 issue. Did you actually get my log files (attached in this thread), which you asked me to send you, or was there a Diffraction Ltd. Forum software glitch, and you are still waiting for me, for some unknown reason ? Hopefully my efforts in describing the version 5.61 bug, haven't been lost, in vain. Thanks for any update. Joe
Sorry, yes I did receive your log files, and I have been bouncing around a lot. I am currently working on your issue, trying to diagnose it. I hope to have an update for you later today.
Long story short, bug found and fixed. If you would like to beta test the change, it would be a big help. Let me know, and I'll send the updated app your way.
Hi Adam, Sorry to be so late replying - I missed your response here, since I was expecting a direct PM. For some reason, this thread's response didn't even pop up in my LIVE MAIL, as NEW posts always do. Is there no way for your forum program to automatically deliver not only NEW posts, but also replies on "watched threads" ? Please email me the CCDOPS BETA with the bug repaired - ASAP. Is there a non-BETA release of this fixed version, already available? Didn't see any messages on that either. Thanks, Joe Z.