STXL-11002M. Maxim DL v.6.21. When running continuous exposures, the subject message stalls the exposures. Is there any info on this? Alan
Is this running with a manual exposure or under program control (eg ACP or some other program driving MaxIm via automation) ? Is threading on? Is USB selective suspend turned OFF (disabled) for the USB hubs, USB root hubs, and PCIe devices? Does it occur if the camera is directly connected to the PC with a reasonably short cable, eg 6ft, no USB hubs, extenders, etc.?
Colin, Thank you for your reply. I will check this out and get back to you. Where is USB selective suspend?
It's a Windows Power Management function. Device Manager will show you for some devices. Here's an example. And here's the other part:
Colin, I turned threading on and made sure USB selective suspend was turned off. Below is my sequence of events. 1. My first exposure was Manual Continuous and no error message was received. 2. I stopped Manual Continuous and directed FocusMax4 to do an auto focus via Maxim. It was successful. 3. I returned to Manual Continuous and got the error message with each exposure. 4. I stopped Manual Continuous and took a Manual Single exposure. No error message. 5. I then proceeded one more time to Manual Continuous and received no error message. So the error message happens right after FocusMax has played out? Alan
I would suggest trying the 6.22 beta first. You can certainly revert if you wish to try that. We havent looked into your report in any depth - Friday was very busy and a quick review didnt reveal anything.
This message inserts itself after exposure and before download, and each time it occurs it consumes 10 seconds. This needs to get fixed.
Is your observatory setup internet accessible eg via AnyDesk/TeamViewer ? Am thinking we need to take a look. Outstanding questions: Is this 6.22 beta or still 6.21?
Sorry, not accessible via internet. Using 6.21; however, a fellow amateur tried 6.22 beta and the message is still there.
I've installed 6.22 on my personal observatory with Focus Max and am going to give it a try to night to see if I can reproduce. Assumes clear weather holds.
Alan, I had a couple of "successful" tests - I've now seen the problematic message when FocusMax is attached to MaxIm. Will be working with colleagues to review and see what we can do about it.
Hi Colin-- I have spent a good part of today tracking this down and believe I found the culprit. I developed a script to isolate FocusMax from the testing and have found that a 10 sec delay is imposed when cam.AutoDownload = False is used. Further, this appears to be a premeditated change as noted in Help. In the MaxIm V21 Help/Scripting/CCDCamneraProperties/AutoDownload I find "When AutoDownload is set to false, upon completion of the exposure ReadyForDownload is set to true, and up to 10 seconds remain before download begins automatically." In the MaxIm V20 Help "Used in conjunction with ReadyForDownload and StartDownload. When AutoDownload is set to false, the camera will not read out automatically upon completion of the exposure. Instead, ReadyForDownload is set to true. During an exposure, the client should poll ReadyForDownload". Once FocusMax has initiated an image, the 10 sec delay will remain in effect even when the MaxIm Expose button is pressed which is what Alan is reporting. FocusMax has used AutoDownload property for over 20 years. This change is imposing a significant performance penalty which is affecting all FocusMax customers and any other 3rd party who use this property. I hope this is helpful to the Diffraction Limited team and can be quick solution can be impelmented. Best regards, Steve Brady The VB script follows: Dim cam Dim ActiveCamStartX Dim ActiveCamStartY Dim ActiveCamNumX Dim ActiveCamNumY Dim ActiveCamBinX Dim ActiveCamBinY Dim ActiveCamExposure Dim ImArray Set cam = CreateObject("MaxIm.CCDCamera") 'Store camera settings Call GetCameraSettings 'Internally cache MaxIm settings cam.CacheCurrentExposureSettings 'Take an image cam.DisableAutoShutdown = True cam.LinkEnabled = True if Not cam.LinkEnabled Then wscript.echo "Failed to start camera." Quit End If 'Set autodownload off cam.AutoDownload = False 'cam.Expose 1, 1, 0 cam.Expose 1, 1 Do WScript.sleep 100 Loop While cam.ReadyForDownload = False Do While Not cam.ImageReady ' Don't consume CPU time while waiting wscript.sleep 100 Loop 'Download the image cam.StartDownload 'Get image array ImArray = cam.ImageArray 'Restore camera Settings Call RestoreCameraSettings 'Restore cached internal MaxIm settings cam.RestoreCachedExposureSettings 'cam.SaveImage "Script.fit" wscript.echo "Exposure is done" Sub GetCameraSettings ActiveCamStartX = cam.StartX ActiveCamStartY = cam.StartY ActiveCamNumX = cam.NumX ActiveCamNumY = cam.NumY ActiveCamBinX = cam.BinX ActiveCamBinY = cam.BinY ActiveCamExposure = cam.ExposureTime End Sub Sub RestoreCameraSettings cam.StartX = ActiveCamStartX cam.StartY = ActiveCamStartY cam.NumX = ActiveCamNumX cam.NumY = ActiveCamNumY cam.BinX = ActiveCamBinX cam.BinY = ActiveCamBinY cam.ExposureTime = ActiveCamExposure End Sub
Colin, What is the status of the fix for this issue? It makes it impossible to use v20 or v21. The issue causes my plans to fail in ACP. Thanks to Steve for tracking this down, as I've spent many hours working around it. I'd appreciate an update on when a fix will be available.
ACP's author @Bob Denny is working on a maintenance release (8.3.2 I think). We're also working on a final release of 6.22 which may be available soon. I'd like some more info on what you are experiencing Bradley. Is there a report on the DC3 forums about your experience?