OK, I figured it out. I found the file
~/.config/kstarsrc
in which I changed
[DarkLibrary]
shutterfulCCDs=QHY CCD QHY5-M-
shutterlessCCDs=CCD Simulator
to
[DarkLibrary]
shutterlessCCDs=CCD Simulator,QHY CCD QHY5-M-
Read More...
From the Dark Library management, I can remove the darks themselves but nothing to reset that my guider has a shutter. I also tried removing the guider from my profile, saving, restarting, and re-adding. That does not work either
Read More...
In Ekos Guide module, when taking a dark for my guider, I accidentally said that my guider camera has a shutter. It now no longer prompts me to put the dust cover on. Anyone know how to I make Ekos forget my previous response to the shutter question, either through the UI or by editing a settings file somewhere?
Thanks, Edward
Read More...
OK, I see that if I am at position zero and press Position Reset that the focuser moves inward by some amount while leaving the position at zero.
What is the amount it moves by? Watching the telescope, it looks like the same amount as 1000 ticks but this amount is not affected by either the "Main Control > Relative Steps" parameter in indi control panel, nor the "Steps" parameter in the Ekos focusing tab. Is this a hard coded value or is it specified somewhere I am missing?
Read More...
This sounds very promising, thank you! The explanation of what exactly Park does helps alot. I am still unclear about what the Position Reset does. Can you explain that a bit more? I have not found docs for either of these two features.
Read More...
My question is about configuring how the focuser starts up. Much of my issues might be my lack of understanding of how to configure Indi/Ekos.
So Far:
I now have piface_focuser controlling my DIY focuser on my Orion ED80T-CF refractor. Yay! I left the motor's step delay at 1ms since anything faster is stalling the little 24BYJ48 I am using. I also bumped up the maximum steps allowed to 100,000 ticks. This gives me a total dynamic range of 20mm of tube displacement, a slew which takes about 2min to complete. Unfortunately, the focusing point for my equipment is about 55mm of tube extension.
Problem:
On startup, I disengage my focuser-stepper and manually rack the focuser to the approximate in-focus position.
When I then restart indi-server through Ekos, I would like the piface focuser to startup assuming that its absolute position is 50,000 ticks (half way within my focusing dynamic range). This would allow me to electronically adjust the focus both up and down from the initial starting point. This is especially desirable when restarting indi-server after a crash (something like this always happens in the field to me). The tube would already be at the right position and I want to effectively sync the driver to approximately the same point.
Currently, If I set the position to 50,000 and save the indi configuration, then on startup, piface immediately begins to move the focuser by 50,000 ticks, something that cannot be interrupted. Instead, I want it to not step the motor but tell the client it is already at absolute position 50,000.
Is this possible through either settings in Indi control panel or by some tweaking to the initProperties method of the piface driver?
Also, can anyone point me to documentation on what the "Parking Enable|Disable" and "Position Reset" buttons are supposed to do in the Indi control panel as they seem like they might be relevant.
Read More...
OK, I found the critical "usleep" command in the driver that controls the slew rate. I tinkered with changing the scaling factor from 1000 to 100 to make the Step Delay motor parameter act like tenths-milliseconds. In principle this worked but it seems that the Ekos bogs down a crashes when the delay is too small.
Read More...
Thanks, that solves that problem .... stepper motor is finally turning! Very exciting.
Due to the gearing ratio between my stepper and the crayford (I am driving the fine-focus knob), I had to bump up MAX_STEPS from 20,000 to 100,000 in the driver code. Thanks for exposing that as a #define.
When you set an absolute tick position in Ekos, what controls how fast the steps are made by the driver? Is that a loop-pause in Ekos, something in the driver, or does Ekos just move as fast as possible? I am finding the motor is turning pretty slowly on a absolute position slew and would like to speed it up.
Read More...
Thanks Kaczorek, though I have not solved the missing stderr problem, I have figured out why the device was not connecting. The "Enable SPI" setting under raspi-config somehow reset itself back to disabled.
Read More...
As an alternative to finding the log for stderr, I tried modifying mcp23s17.c to return different error codes for the 4 possible failure conditions. However, the piface build automatically pulls a fresh copy of mcp23s17.c as part of its generated make.
Read More...
OK, partly answered one of my questions. From main Ekos screen I pressed "Logs" button. I configured verbose file logging for INDI and focuser drivers. I then pressed "Open Logs Directory" and found the following appear in a file after trying to reconnect the piface.
[2019-02-09T14:09:27.137 CST DEBG ][ org.kde.kstars.indi] - PiFace Focuser : "PiFace Focuser 1 device is not available. "
[2019-02-09T14:09:27.138 CST DEBG ][ org.kde.kstars.ekos] - PiFace Focuser is disconnected.
[2019-02-09T14:09:27.147 CST DEBG ][ org.kde.kstars.indi] - < PiFace Focuser 2 >: < DEBUG_LEVEL >
[2019-02-09T14:09:27.168 CST DEBG ][ org.kde.kstars.indi] - < PiFace Focuser 2 >: < LOGGING_LEVEL >
[2019-02-09T14:09:27.171 CST DEBG ][ org.kde.kstars.indi] - < PiFace Focuser 2 >: < LOG_OUTPUT >
[2019-02-09T14:09:27.186 CST DEBG ][ org.kde.kstars.indi] - PiFace Focuser 2 : "PiFace Focuser 2 device is not available. "
[2019-02-09T14:09:27.187 CST DEBG ][ org.kde.kstars.ekos] - PiFace Focuser 2 is disconnected.
So, here is the original error message I was asking about. However, non of the critical mcp23s17_open STDERR messages are going here.
Read More...
I am still trying to debug why I cannot connect piface_focusers. I added some extra tracing into piface_focuser.cpp:
bool IndiPiFaceFocuser1::Connect()
{
// open device
mcp23s17_fd = mcp23s17_open(0,0);
if(mcp23s17_fd == -1)
{
DEBUG(INDI::Logger::DBG_SESSION, "Focuser1 :: Open :: FAILED");
IDMessage(getDeviceName(), "PiFace Focuser 1 device is not available.");
return false;
}
else
{
DEBUG(INDI::Logger::DBG_SESSION, "Focuser1 :: Open :: OK");
}
I find that I get my "FAILED" error message in the INDI Control Panel .
I do NOT get the original message "PiFace Focuser 1 device is not available" showing up anywhere.
I do see "PiFace Focuser is disconnected." in the main Ekos message panel; this message does not originate from the driver.
I see that the mcp23s17 libarary code sends extra details to stderr. I read on the INDI docs that driver stderr is passed on to the indiserver stderr.
My questions are:
(1) where is the error message the piface_focuser driver writing supposed to show up? IDMessage(getDeviceName(), "PiFace Focuser 1 device is not available.");
(2) I am running KStars/Ekos all locally on the RPi and starting the INDI server from Ekos. All my other devices work fine, so I known INDI server is doing something. With this configuration, where do I see or configure the STDERR output of the INDI server? I would like to see what specific error mcp23s17_open(0,0) is generating.
(3) Any other board setup that I have likely missed causing this error? I have verified the address jumpers on the Relay+ board.
Read More...
In previous thread, I reported not being able to run this build sequence:
cd astroberry-piface
mkdir build
cd build
cmake ..
make
make install
Specifically, the "make install" failed with bizarre git unstash errors. The work-around of not doing "make install" and instead moving the libraries manually appeared to work. However, after I attempted to modify the source to add some more logging, I found that I am not able to invoke the "make" command again to rebuild. Specifically, after editing the code and attempting
cd build
make
I get the same errors:
Performing update step for 'libmcp23s17'
Current branch master is up to date.
No stash found.
No stash found.
No stash found.
CMake Error at /home/edward/Tilion/astroberry-piface/build/libmcp23s17/tmp/libmcp23s17-gitupdate.cmake:136 (message):
Failed to unstash changes in:
'/home/edward/Tilion/astroberry-piface/libs/libmcp23s17/'.
You will have to resolve the conflicts manually
CMakeFiles/libmcp23s17.dir/build.make:94: recipe for target 'libmcp23s17/src/libmcp23s17-stamp/libmcp23s17-update' failed
make[2]: *** [libmcp23s17/src/libmcp23s17-stamp/libmcp23s17-update] Error 1
CMakeFiles/Makefile2:67: recipe for target 'CMakeFiles/libmcp23s17.dir/all' failed
make[1]: *** [CMakeFiles/libmcp23s17.dir/all] Error 2
Makefile:127: recipe for target 'all' failed
make: *** [all] Error 2
The only work-around I have come up with is to move a copy of my modified source outside of astroberry-piface, redownload a fresh source, and replace the modified files each time I want to test a change. Needless to say, this is pretty slow going. Any ideas on what I can do to fix this build? I am not very fluent in cmake.
Read More...