STXL Timeout Errors

OK I decided to run an automated session last night as described before. I did turn on Enhanced SBIG Logging. No errors over about 6 hours.

I started with an aborted run due to an error but I'm not sure the SBIG logging was catching the error. In any case here is a dropbox link to the gigantic log file:

https://www.dropbox.com/s/osbdmyo9xukawpx/STXL_LOG_10_4_16.txt?dl=0



It looks like this error may be related to the camera/focuser being unresponsive. Here is the end of the CCDAP log showing the error:

0:51:34 Plate solving...
20:51:35 Telescope RA: 20 19 10.2, Dec: +40 48 55
20:52:19 D:\Users\Owner\Pictures\AstroImaging\SyncImages\Sync_20161005_205135.fit
20:52:24 Stars: 972, FWHM: 0.3 arc-sec.
20:52:24 Solved RA: 20 18 16.0, Dec: +40 43 37, PA: 0.1 (4.1s)
20:52:25 Plate Solve Time: 50.4 sec.
20:52:25 Pointing error (arcmin): RA -0.1; Dec 0.0
20:52:25 Try 1 slew error: 6.6 arc-sec
20:52:25 Telescope RA: 20 19 10.1, Dec: +40 48 55
20:52:26 Series Loop 1 of 1
20:52:27 Series 1, 4 Exposures, 300 sec., 2x2, H filter
20:52:29 FoFM1, CCDSoft2XAdaptor.CCDSoft5Camera.1: Error: command failed. Error = 206.
20:52:29 Unable to move focuser
20:52:30 Telescope RA: 20 19 10.1, Dec: +40 48 55
20:52:30 Exposure 1 of 4
20:52:31 Guide exposure for this series manually set to 0 sec.
20:52:31 Periodic refocus due
20:52:35 FoFM1, CCDSoft2XAdaptor.CCDSoft5Camera.1: Error: command failed. Error = 206.
20:52:35 Unable to move focuser
20:52:35 Focusing using L filter...
20:52:36 Telescope RA: 20 19 10.1, Dec: +40 48 55
20:52:36 Getting focus stars...
20:52:45 Focus stars available: 1
20:52:46 Focus stars available: 2
20:52:51 Focus stars available: 3
20:52:51 Moving to focus star number 1, HIP 98194 @ HA: 1.5 at 71.6 deg. altitude
20:52:51 Slewing scope...
20:53:00 Slewed to RA: 19 57 49.2, Dec: +40 25 13
20:53:00 Mount settling for 3 sec. after slew.
20:56:33

An application error occurred. Please contact support with the following information:

Error: command failed. Error = 206.

If it exists, the script d:\Users\Owner\Documents\CCDWare\CCDAutoPilot5\RunOnError.vbs was run

The above information is on the clipboard so you can paste it into notepad or another application.

Robert Mueller

 

I have discovered that the STXL camera still has timeout issues with the newest driver. At first I was encouraged doing normal imaging sessions. Last night while collimating a scope and running Sky X continuous exposures 0.3 sec I had 7 separate SBIG transmission timeout errors. While running continuous exposures, I was also jogging the scope to recenter a star in a subframe periodically.

Robert Mueller

 

Robert,
I have to admit that I too experienced this time out since upgrading to the new driver, but only once. After re-tightening the strain relief on all the USB cable connections, I've not seen the problem since. Absence of evidence is not evidence of absence, but it might be worth checking on your system, if you haven't already.
- Rick

 

Rick,
I understand....However in my case I had 4-5 all night imaging sessions with no errors. Then when I try very short exposures continuously I get multiple errors is a short period of time. I think this should point to a continuing issue.

Never the less I will check cables again and make sure. I wonder if others are seeing success with the new driver?

Robert

 

Hello Robert,

I have not experienced a timeout error since he last update. I must confirm that my failures where twofold:

1. The driver, and
2. A problematic filter wheel.

Now with #2, the fault always occurred with focusing runs, the same senario as youre collimating setup. Fast repeated cycles. Here the filter wheel failed to reach the closed position and the camera just waits for that to happen, then you get the timeout message. The filter wheel requires MANY repetitive cycles for this to happen, exactly like would have happened in your circumstance.

Perhap you could bench test like i did, with an open camera, so you can watch the performance of the wheel. If it fails, it wont make it to the closed position. Its visibly easy to see. The bearing was the fault. Gritty. The new replacement was so smooth relative to the old.

Just an idea.

Steve.

 

My suggestion was merely a long shot. Although, I run the AOX guide camera often as fast as a quarter second without fail, I haven't run the main at such short exposures since the driver update. Unfortunately, my observatory computer had its hard drive for lunch a few days ago and I'm grounded until next week. Hopefully someone else can run the experiment and provide some independent data. If not, I'll try it when I get running again.

- Rick

 

Robert,

I’m back in business. And, I want to follow up on my promise to try to replicate the timeouts you were seeing with short exposures on the current driver/firmware build.

When I installed the new (better, cheaper, faster) observatory computer, as an experiment I first ran the STXL through the MX+ through-mount connection (which is merely a built in hub). I also run my focuser/rotator through that hub. I immediately saw random STXL timeouts, even just doing dark or bias frames. Adjusting the timing on the focuser/rotator alleviated the problem a somewhat, but not completely. I still experienced a timeout every 40 or 50 exposures. Note that in this configuration, mount control, focuser/rotator control, and the SBIG STXL imager, guider, AOX and filter wheel all share the same external hub (in the mount) and that runs off a single physical port of an internal hub in the computer. This is historically a recipe for disaster anyway.

I then re-cabled and reconnected the STXL directly to an unshared internal USB hub, and verified its isolation with USBTreeView. Using TSX, I ran continuous exposures at 0.35 seconds, 1x1 binning, autodark, full frame (unsaved) for over 2 hours without failure. At about 8 seconds total turnaround time between successive image downloads, that’s pushing a minimum MTBF of over a 1000 cycles (which is equivalent to a couple of weeks of full night’s shooting for me… like I ever got in a full night’s shooting every night for two weeks – Ha!).

Anyway, based this admittedly limited test, I have to say that the latest STXL driver/firmware update seems pretty robust, given a healthy hardware and software set up. Prior to this build, I was able to generate failures using essentially the same test rig under similarly congested conditions on a slower computer. Of course, as the saying goes – absence of evidence is not evidence of absence. But there you go.

Best of luck,

- Rick

 

Rick,
Thanks for sharing your results. I do run my STXL 11002 connected directly to my PC. My testing that produced timeouts only occurs with the short exposures (so far). The scope that uses this camera will be down for some time so I won't be imaging or running any tests.

I hope you have stable operation from this point forward.
Robert Mueller

 

Doug, et. al.

I debated about whether I was exposing myself to personal abuse by bringing this up, but I think it's also important to clarify one point that seems to get overlooked every time this topic shows up: that is, connecting your device directly to your computer does not guarantee that it isn't still competing for a hub bandwidth resource. To my knowledge, with any of today's PC's, all USB connections go through internal hubs. And, it's rarely clear which USB connection plugs are "hubbed" with other USB connection plugs, just by looking at them on the back, or front panel. Worse, some computers hook internal devices like built-in cameras on laptops to ports on the same internal hubs that have external connections, and you have no idea. In the USB map below, I've got a least two sets of devices on separate physical connections that show up on the same internal hub, competing for its bandwidth. In this case, however, I've "tuned" the connections by moving the physical connections around so the SBIG Camera, for instance, has it's own hub. Normally, I only allow slower, less time-critical devices like the dome controller, or dew heaters to share a hub, if I can. It's very difficult, if not impossible, to do this kind of tuning without a software tool like USBTreeView, which will give you a map of internal (and external) hubs and ports, and what they're connected to. With it, it's dead simple. That tool is free at http://www.uwe-sieber.de/usbtreeview_e.html. I've found it invaluable in ensuring that I've got true isolation on bulk-data, high throughput, timing-sensitive devices like the STXL.

My humble apologies if this already obvious to everybody else, but there you go...

- Rick

 

Guys what version drivers and firmware are you running? Should I update to 2.51?

 

I'm running 2.51 (and everything else up to date). I've got no complaints. - Rick

 

I'm up to date with same version as Rick. I have had a few timeouts after updated as posted above but currently camera is off my scope.
Robert Mueller

 

Adam,
Sorry I don't. I thought the latest driver fixed my problem in early testing as I was able to image several sessions without errors. The problem resurfaced when I was collimating a scope with continuous short exposures using a subframe.

My scope has been taken down so the camera is inactive. I'll let you know if I can figure out a bench test.
Thanks,
Robert

 

Adam and Doug

This issue has appeared on the CCDWare forum and there is some very interesting info that user has found out.

http://ccdware.infopop.cc/eve/forum...97083106&m=1787049586&r=7547020686#7547020686

Cheers
Martin

 

Not sure it you have resolved this?

I havent been at the forum for a while now, but I see this issue as one similar to what I had years ago with my STXL. It wasnt a USB issue for me [as I first though it was], but a main camera shutter issue. The shutter was getting stuck as it rotated around, never getting back to its home position. Always happened on a focusing run - when the shutter was most active. It would fix itself on a power cycle. I ran the camera open to watch everything move during the camera cycle. Thats when I found the shutter sitting not where it was supposed to on the hang. I changed the bearing and it never happened again.

Just a thought.

Steve

 

Steve,
The scope I run this camera on has been out of commission for months. Now that I have just gotten up and running again the problem persists when running short continuous exposures.

Can you elaborate on how you fixed the camera?
Thanks,
Robert