Hi I have tried to get papywizard to Control the cameraport on the hand Control. Sky-watcher support answered "There is camera control but it only works through SynScan hand control for the moment. Sorry about that. However, we will consider adding PC command to camera control in the near future. "
So now i'm thinking that if it is possible to use the RS232 to trigger the camera. The same used for the Communication with the teleskop. I Think It could be done by activating the DTR pin in the rs232 when the camere is suposed to trigger. Then it would be possible to use like a optocoupler to trigger the camera like the original camera port. The code could maybe look like this one to trigger for 100 ms
********************************* import sys, serial from time import sleep
Another possibility is maybe to use the "GenericThetered plugin" but i do not quite understand how it works? Is it pyhton comand you can add? is it to add those to the parameter 0-4?
I have also observed that when settin com port i have to set 2 even if i have 3?
In fact, you have to use both. Your script will do the triggering, and the the GenericThetered plugin will call your script. Just replace the default program (gphoto2) by yours.
I think you will have to give the complete path to your script. But I'm not sure how Windows handles execution of scripts... Does anyone know about this? Is giving path to script enough? Or, like under linux, do we need to use some shebang, to tell which program to use to execute the script? Or do we have to give the path to Python interpreter, with path to script as parameter?
PS: Windows start numbering ports from 1, but Python starts from 0:
COM1 -> use 0 COM2 -> use 1 COM7 -> use 6
But Serial object can use strings as com port path, so you can give "COM1" (str), instead of 0 (int), like you would use "/dev/ttyS0", or "/dev/ttyUSB0" under linux.
Thanks So I have to do like an exe function that I will call that trigger the shutter. Could it be a problem that papywizard already "control" the com port and another prg want get access to it. Maybe I should try to use ver 2.0 and shoot.py there I perhaps can use the com port as it is already within Papywizard.
You don't need to build an exe yourself; you can use a python script. I will dig to find the correct way to call it from the plugin.
It won't be possible to open the same com port from another program. Even from Papywizard, it is not possible to open it twice... This would require to share the object using the port.
I didn't realized you wanted to trig from the same com port! What DSLR are you using?
Hi Ok. There is no possibility to add a option in the Papywizard prg like a ceck box that activate RTS on same com port when shutter is released and DTR for mirror lock ? This could be useful for all as there is a lot of used mounts and people having telescope that could use this. Downloaded the original python code and was thinking of adding those prg lines but that's a lot above my prg skills...... //Rikard
Yes, it is possible and very easy to write a new shutter plugin, doing that. I can do it, but I don't have the toolchain anymore to generate the .exe for Windows...
However, if you run Papywizard under a linux machine, no problem.
Ok that sounds good But I'm bad at Linux But have started some with raspberrypi. Have goggled some, but not found any one running Papywizard on a RpPi. Is that possible? Then we also have the GIPO to trigger camera etc.
Is it not possible to run it in windows via python prg as code without any doing it as a exe file? Or is there some one else that can make an exe file? If not maybe simplest buy another rs232 //Rikard
Yes, Papywizard can run on RPi. You just have to install a few libs (Pyqt, pybluez, pyserial...), clone the git repo, and install (see online documentation).
If you go that way, I can write a plugin to use GPIO to trigger the camera.
It is possible to run Papywizard on Windows without generating a exe file. In fact, I just installed again the toolchain, but Papywizard does not works fine: it launches, but then, other windows do not open. I have to check what's going on (different versions of the libs, I think). Once OK, I will be able to generate .exe.
Ok So it is not possible within the original code just toggle RTS simultaneously as the shutter. Suppose you use the com port anyway within the same "module" when you trigger the "normal" port? The CTR is not connected today? If so then it would be possible to use DTR instead. Will think of using a RaPi. the only reason to xp was that I had that tiny portable computer around and I'm running stelarium on it. RaPi would need a screen...
Without modifying Papywizard, you need to call an external process (using GenericTethered plugin) to trigger using CTS/DTR (or any other serial line you want). The problem is you can't do that on the same serial line that is already in use by other plugins (yaw/pitch)... If you go that way, which is the most simple solution for now, you just have to buy another rs232 adapter.
Another solution is to use a tethered program for your DSLR, through the GenericTethered plugin too, or to use on of the already supported tethered programs (DSLR Remote Pro, Canon EOS Utility, NK Remote).
I can modify Papywizard, adding a new shutter plugin triggering using CTS/DTR, but for know, I'm unable to run Papywizard from source¹ under Windows, so you can only run from linux.
If you run linux on the RPi, I can also write another plugin, using GPIO, but the CTS/DTR solution is more simple...
¹ I may have found the issue; I have to make more tests...
Had no time to look inti RPi will try this evening, but tested the interface cable with a small python prg. It worked niccly I was able to blink the LED on the RTS pin (including a 640 Ohm resistor). I hope you get the Papywizard sorce running for the best for me would be that. But I also think a module for the RPi would be a great option (Trigger a GPIO pin). Need to fix a new image and screen for the RPi. That would be a smaller and less power consumption system.
I found the issue on Windows: I was using an obsolete Qt signal from Qt3, which was still working in Qt4.5, and is still working on Qt4.11 but on linux only I switched to the correct signal, and all works fine under Windows, now!