Error Message

Questions and answers about the best way to get started with Prism including: est hardware to use, software settings, etc..
Post Reply
Posts: 8
Joined: Thu Jul 18, 2019 2:50 am

Wed Oct 23, 2019 2:28 am

I returned to the trial version of Prism Pro last night with the first clear sky for over a month!

I'm still getting used to the software and last night tried to do a longer exposure using my SX H36 CCD. I couldn't so any exposure over 120secs! All I got was this error message from Prism ...

Screenshot (4).png

I don't understand what it means and certainly don't know how to resolve the problem. The interesting part was that the camera control screen didn't count down the time outstanding. It simply said '0 sec .. Digitizing'.

Edit - Just noticed that the 'Stop' and 'Abort' buttons are mementarily highlighted but then become almost instantly greyed out.

Can Hamza or anybody else tell me where I'm going wrong?

Posts: 8
Joined: Thu Jul 18, 2019 2:50 am

Sat Oct 26, 2019 1:29 am

I've resolved the issue temporarily but then it recurs when reverting to the original set-up. I borrowed a non-SX guider to work with my SX imager and everything now works as I expect. The issue reappeared when swapping back to the SX Lodestar. And went away again when swapping the SX imaging camera for another manufacturer's.

This error seems to be a symptom of a more fundamental problem with Prism in that it struggles to deal with situations where both the guider and the imaging camera are from the same manufacturer. My issue relates to two SX cameras and it also appears to recur when using ZWO cameras in a slightly different manner. It's as though Prism cannot differentiate between the two cameras from the same manufacturer. Maybe that's something to do with how the native drivers use the camera's PID data which is how camera's can be differentiated? It appears to be a recognised problem and there is even a work around which partially resolves the problem.

I'd like to see the issue investigated further by the developers and a permanent resolution developed for the issue.
Posts: 128
Joined: Thu Aug 23, 2018 8:22 pm
Location: Missouri, USA

Fri Nov 01, 2019 11:42 am

Steve, This is a well known thing several of us have ZWO camera's and experience the same thing, thought I can hint that it does get better with a recent update, but not totally eliminated.

What I've done in the past was to use the Native driver for the main imaging camera and the ASCOM driver for the guide cam (or visa-versa), but you'll have to experiment with which way around works for your camera's.

@Hamza Touhami do you know if there's been any headway on this? I know last we talked there was some dialog going on with ZWO??
Hamza Touhami
Site Admin
Posts: 564
Joined: Sat May 20, 2017 6:05 pm
Location: Phoenix,AZ

Mon Nov 04, 2019 6:37 pm

nothing of note yet as some code needs to be revised on their end. I must say this is an issue for at least a couple of folks. I will find a better way to transmit all these enhancements
Hamza Touhami | Site Administrator
Posts: 44
Joined: Thu Apr 18, 2019 3:53 am

Sun Nov 10, 2019 6:04 am

@Hamza Touhami cool beans man.

The better way to transmit in my opinion is to state what is wrong, whatever technical details you can provide - don't keep things that don't need to be a secret a secret and state the technical problem so no-one has to wonder what is going on. I can work that with ZWO more directly, say by providing them a program that clearly demonstrates the problem but is minimal. If there's some miss on prism's side wrt driver handling I may help shine light or advise on that too - TBH I expect a little of both really, since I don't observe the problem with other zwo direct software - but having worked with many camera driver stacks in the past, I'm aware of weird issues, especially wrt threads, callbacks.


Code: Select all

int ASIGetNumOfConnectedCameras();

typedef struct _ASI_ID{
	unsigned char id[8];

typedef ASI_ID ASI_SN;
ASIGetSerialNumber(int iCameraID, ASI_SN* pSN);
ASIGetID(int iCameraID, ASI_ID* pID)

typedef struct _ASI_CAMERA_INFO
	char Name[64]; //the name of the camera, you can display this to the UI
	int CameraID; //this is used to control everything of the camera in other functions.Start from 0.
	long MaxHeight; //the max height of the camera
	long MaxWidth;	//the max width of the camera

	ASI_BOOL IsColorCam; 

	int SupportedBins[16]; //1 means bin1 which is supported by every camera, 2 means bin 2 etc.. 0 is the end of supported binning method
	ASI_IMG_TYPE SupportedVideoFormat[8]; //this array will content with the support output format type.IMG_END is the end of supported video format

	double PixelSize; //the pixel size of the camera, unit is um. such like 5.6um
	ASI_BOOL MechanicalShutter;
	ASI_BOOL IsCoolerCam;
	float ElecPerADU;
	int BitDepth;
	ASI_BOOL IsTriggerCam;

	char Unused[16];

ASICAMERA_API ASI_ERROR_CODE ASIGetCameraProperty(ASI_CAMERA_INFO *pASICameraInfo, int iCameraIndex);
int ASIGetProductIDs(int* pPIDs);
Where is the gap in functionality for prism to not get confused using the native driver? Every routine that needs to takes the camera id, and it looks like everything is there to stably store settings in prism to files and later re-associate through serial numbers and product numbers. Of course I could be missing something and maybe the driver isn't producing useful data here, but please clarify what it is so I can help get it fixed - I'd say that's exactly the transparency that should be provided rather than the hints in the changelog.

Really looking forward to having one less typical night gremlin - keep in mind I gotta do full setup and teardown every session since I don't have a permanent setup so the error rate for me and time premiums are high.
Post Reply