Script issue

[Astrojunk]

Since the latest update (4.1.13502.0) I'm getting a script error 'Module' has no attribute 'utcnow'. This script is loaded on start up.

If I run the script again, creating a second instance on the menu bar, both work just fine as if something failed to initialize properly first time round.

Screenshot 2025-08-05 193621.png (40.78 KiB) Viewed 1696 times

[Astrojunk]

Actually, another issue popped up - I recall there have been some changes to the version of Python, I'll do some digging around.

Screenshot 2025-08-05 200022.png (18.72 KiB) Viewed 1700 times

[admin]

Hi Jonathan,

do you remember what version you were on before 13502? That would help limit the scope of where to search for any changes that might have caused this.

From the first message, I expect that you are trying to access System.DateTime.UtcNow (if you could share the script, that would be great!). However, I wonder if you are doing it via just DateTime.UtcNow in the script and that somehow 'DateTime' has been given a different value than the expected one (ie, it's not referencing the class System.DateTime, but something else). There was a post a bit similar here recently where somehow the 'SharpCap' object was getting replaced in the same sort of way, although I couldn't make that happen when I tried to reproduce the error.

cheers,

Robin

[Jean-Francois]

Hello,

I have with some of my scripts the similar problems on my desktop computer.
I tested several older version, and I have the errors "down" to the version 4.1.13332.
I did not test with older SharpCap version. I tested with different version of my script (LED_Calibration.py).
It is not easy to test ... SharpCap crash completely after the error (need to restart and reconnect the camera and Telescope Simulator).

I have something strange with the GPS recognition. I can not say if it is from SharpCap or from my test to install a new test firmware from QHY.

Script_error.jpg (56.72 KiB) Viewed 1688 times

Regards,
Jean-Francois

[Astrojunk]

My house PC runs ok with 4.1.13332, but it's not a comprehensive test as I don't connect a camera and only use it for tinkering with scripts.

I've added my version of Jean-Francois's script (I've added a pre-point option) and a test file that can be loaded.

[Jean-Francois]

Hello,

I tested this morning with 2 other computer.
I have no error or other crash with the other computer.
It is not 100% sure that I used exactly the same script.
I will repeat some tests this evening and in addition test the modified script of "JB".

But I have the same behaviour with the GPS extra status.
It seems that the "FixQuality" status is now missing.

Regards,
Jean-Francois

[Jean-Francois]

Hello,

I'm still at home ... so I continue some tests ...

Concerning the "GPS status" ...

Here the (complete) list in the version 4.1.13332:

GPS_status_4-1-13332.jpg (72.13 KiB) Viewed 1651 times

and the less complete list in the version 4.1.13393 and following:

GPS_status_4-1-13393.jpg (52.64 KiB) Viewed 1651 times

I have now other problem with the LED calibration ... it is no more working. The Start and End value does not work.
I can not say if it is coming from my GPS camera. I will check it with the second camera.

Regards,
Jean-Francois

[admin]

Hi,

OK, the GPS Status thing is my fault - I had done some work to make the way that GPS cameras are handled more consistent across the different brands that support GPS, and ended up accidentally making the details of the QHY GPS status inaccessible to scripting. I will fix that for Monday's update.

I am more puzzled by the random seeming failures - the whole point of a programming language is that it is supposed to be consistent and carry on working if it has once worked and you haven't changed it.

Apart from adding the second copy of the 'SharpCap' variable a couple of weeks back, I haven't changed anything related to the script engine or how it is activated in SharpCap since the beginning of the year - at least as far as I can see from looking back at the code history, so I can't quite work out why it is starting to break now, particularly in such an inconsistent way.

I think my first step is going to be to update IronPython, as I am still using 3.4.1 and there is now a version 3.4.2 which has the normal array of bugfixes - I will put that into the next update and we can see if it helps. Perhaps there has been a change in the .NET8 runtime that SharpCap uses (maybe some bugfix in the runtime) that causes issues with the current version of IronPython?

cheers,

Robin

[admin]

Looking back at Jonathan's errors and his script, I still suspect that something has redefined 'datetime' after the initial import. Sort of a bit like this snippet where I deliberately redefine it as a string. Perhaps another script could be doing this?

Code: Select all

>>> print (datetime)
<class '_datetime.datetime'>
>>> print (datetime.utcnow())
2025-08-06 15:37:53.763000
>>> datetime = "123"
>>> print (datetime.utcnow())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'str' object has no attribute 'utcnow'

If you encounter the issue again, running 'print(datetime)' in the console window might help work out what the 'datetime' symbol has been changed to.

The 'math domain error' looks like it is Python's way of reporting an illegal mathematical operation, like dividing by zero or taking the square root of a negative number or similar. I wonder if this depended on the exact values of some calculation done by the script at the time and therefore might not reproduce easily. Certainly I loaded your version of the script and then imported the test data file into it and nothing bad happened (at least when importing - perhaps something else needs to be done to cause the issue).

thanks,

Robin

[Jean-Francois]

Hello Jonathan,

I tested the script of JB. I have no error.
Except one time with the variable "Prepointed_Flag". It was used before defined (not difficult to correct).

The basis of the modified script is my script of April 2024 ... a lot of things happen in between.
For example: I added the stars in the field from the UCAC4 star catalogue, I added automatic view of Deep Sky Annotation window, I changed the Cal_LED script, I corrected exposure time function for report in SODIS, I corrected bug with saving of the FITS images, I added a warning for the saving of the FITS images and other small corrections.

If you have comments on your script Prepoint function, please communicate it to me before I insert it in my next script version.
I remarked that the tracking was not every time switch off after the pre-point action.
I guess while the telescope is still performing a GOTO and it does not change the tracking status during a slew.
I need to investigate and find a solution.

Note that during the summer, my occultation observation is near zero. From home all the events are too low and fast every time behind the next buildings (or they are in the middle of the week at 04:00 local time).

Regards,
Jean-Francois

Note: I found the problem with my camera ... the USB connection !
The USB connection with the back connector of the PC was producing a strange behaviour.
All fine after changing the connector on the PC (to the front panel or a different USB connector from the back).
Very strange.