×

INDI Library v1.9.6 Released (21 May 2022)

Bi-monthly INDI Library released with new drivers and bug fixes.

Cannot connect to 2m Scopedome / Arduino

  • Posts: 23
  • Thank you received: 0
I had the same. First it was a fuse inside of the shutter motor controller box (it was told so by the Polish engineers).
Now I have the same again, but the reason for this errors are the slip ring power transmission. If you rotate the dome then you can see the shutter power LED flickering. If the dome stops at a position without power then there is no connection to the slave - no connection by missing power. I have written a small script (work around). It is looking for connection. If there is no connection then the dome will be rotated by a fraction of a second. If it is connection then I am controlling the shutter. If not, then I am rotating the dome again ... and so on. The second way was to add a buffer battery inside of the moving part of the dome.
But this is not the way how it should work. Therefore we (including our lawyer) hope to get a repair by our local dealer.
The last way of operating the dome is to setup a much smaller controller by our own. It's much faster and more easy than to debug the arduino controller.
For shutter control we would do it at home position only including an inductive coupler without any mechanical contact. This is easy and save in operation.
Additionally the optical home sensor (sensitive to bugs and dust) must be exchanged to a reed contact.
Name: Frank Fleischmann
Interests: nature, technics, astronomy, optics, space
Developments: motor control, sensors, networking, radio detectors astronomy, cameras for spacecrafts
Using: 3m Baader dome, 2m ScopDome, GM4000, EQ8, and homebrewed ones, echelle spectrograph and ... INDI
1 year 3 months ago #68724

Please Log in or Create an account to join the conversation.

  • Posts: 35
  • Thank you received: 0
Yes i have a full motorised dome (dome and shutter)
I’m able to open/close the shutter and move dome ccw /cw whatever it is by usb ( under w10) or ethernet

Eric
1 year 3 months ago #68730

Please Log in or Create an account to join the conversation.

  • Posts: 416
  • Thank you received: 154
I fortunately haven't had issues with powering or linking the shutter part with my 2M dome so I haven't implemented robust fallback for problems with that or "shutter power only available at home"-mode required for some of the 3M+ domes. I'll see what I can do for that.
Remote observatory running Ubuntu 21.10 x64 with ScopeDome 2M, Skywatcher EQ8, TS 8" RC, Atik 383L+, ASI178MC, ASI120MM-S, SX Lodestar X2, SX USB wheel with OAG, ZWO EAF, Gemini SnapCap, USB_DewPoint, KomaHub
1 year 3 months ago #68760

Please Log in or Create an account to join the conversation.

  • Posts: 35
  • Thank you received: 0
No problem, let me know when you have done something that i càn test

 
1 year 3 months ago #68774

Please Log in or Create an account to join the conversation.

  • Posts: 35
  • Thank you received: 0
HI

i did some first test and i'm now able to connect using tcp connection and send commands

first point is that i had to force to use ethernet by modifiying the commented line by the one below in scopedome_arduino.cpp
as i did not find where was the "useEthernet" variable, i replaced by 1 for the test. i assume it was forced by you somewhere as you were focusing on uart debugging ??

//ScopeDomeArduino::ScopeDomeArduino(bool useEthernet, int fd) : ethernet(useEthernet), PortFD(fd)
ScopeDomeArduino::ScopeDomeArduino(bool useEthernet, int fd) : ethernet(1), PortFD(fd)

i also added the two lines below in the same function with CURLOPT_USERNAME and CURLOPT_PASSWORD to setup curl lib

if (curl)
{
curl_easy_setopt(curl, CURLOPT_USERNAME, "scopedome");
curl_easy_setopt(curl, CURLOPT_PASSWORD , "default");
curl_easy_setopt(curl, CURLOPT_WRITEFUNCTION, WriteCallback);
}

by doing those modifiation
the ScopeDomeArduino::performCommand perform the command via ethenet (when hard coded directly)

but i think the uart comm is also active so it's generate issues
i got this error message in ekos:
2021-03-24T12:10:30: [ERROR] Can't identify the card, check card type and baud rate (115200 for USB Card 2.1, 9600 for Arduino Card) 


do you know where to come back in normal mode in term of communication, i mean the comm used is the one selected in the "connection"
tab of ekos ?

any advice would be welcome 8-)


Rgds
Last edit: 1 year 3 months ago by Eric TINLOT.
1 year 3 months ago #69145

Please Log in or Create an account to join the conversation.

  • Posts: 416
  • Thank you received: 154
Yes, the ethernet/HTTP mode is not working in the version currently in github as it's missing some code like this and I concentrated on having the basic functionality working via USB first.

I have a work in progress version which does work via ethernet, but requires some changes to the core INDI library (currently TCP mode is essentially just raw data stream like serial so it's not directly suitable for HTTP connections). I've successfully connected and used the controller with this hack, but am not ok with it in its current state so I'll clean it up before pushing to the repo. I originally hacked together a third HTTP connection module in addition to the serial and TCP modules, but am currently trying a different approach which would re-use the existing TCP module and not require modifications outside the driver (having curl use the already established socket for connection).

Anyway, unfortunately progress has been a bit slow recently due to other things taking my time (in addition to a few clear nights for imaging, which has been rare this winter), but I'll keep you posted when there's something new to test.
Remote observatory running Ubuntu 21.10 x64 with ScopeDome 2M, Skywatcher EQ8, TS 8" RC, Atik 383L+, ASI178MC, ASI120MM-S, SX Lodestar X2, SX USB wheel with OAG, ZWO EAF, Gemini SnapCap, USB_DewPoint, KomaHub
1 year 3 months ago #69167

Please Log in or Create an account to join the conversation.

  • Posts: 35
  • Thank you received: 0
Hi

find below the status of my investigation done today in USB (UART) mode


Main Control Tab

Buttton "Dome CCW" works fine (after clicking text become hilighted, command sent is "moveDome=CCW" that is fine) dome is turning CCW
another click on the same button (text become lowlighted, command sent is "stopDome" that is fine) dome is stopping

Button "Dome CW" after clicking text become hilighted, command sent is "moveDome=CW" that is immediatelly followed by another command "stopDome" (here is a first issue, the "stopDome"
command should not be there)


Button shutter "Open" and button shutter "Close" (they are radio button, only one selected at a time and anyone selected unselect the second one)
the driver see shutter open as it is closed (inversion of the two position sensor may be)

a click on "Close" (button lowlighted) send the right command MoveShutter=CLOSE

a click on "Open" (button already higlighted) send no command

Rgds
1 year 3 months ago #69179

Please Log in or Create an account to join the conversation.

  • Posts: 416
  • Thank you received: 154
Thank you for testing, as said I don't have anything connected to the controller so it was almost certain there would be things like this (and more to come :).

Some functions are controlled somewhat differently with the Arduino-version than with my older USB Card. For example both these two functions are controlled directly via relay on/off controls in the older controller (CW/CCW and open/close are actually the same relay controls, just one is in the master controller and one in slave) where as the Arduino-controller uses explicit commands based on the function. It seems I've accidentally left some clearing of the relays there (which would send the stop commands with the new controller instead of clearing one of the relays) when trying to abstract these functions for the common code.

I'll double check the open/closed sensor bits too, it's quite possible I've accidentally swapped them. If the driver thinks the shutter is already open, it wouldn't send an open command and vice versa.

In this case I can probably quite easily fix these just by looking at the code, but for more complex bugs it would be useful to have a driver debug log (enabled from Ekos log controls) so I could see the exact commands sent and more importantly status updates back from the controller.
Remote observatory running Ubuntu 21.10 x64 with ScopeDome 2M, Skywatcher EQ8, TS 8" RC, Atik 383L+, ASI178MC, ASI120MM-S, SX Lodestar X2, SX USB wheel with OAG, ZWO EAF, Gemini SnapCap, USB_DewPoint, KomaHub
Last edit: 1 year 3 months ago by Jarno Paananen.
1 year 3 months ago #69191

Please Log in or Create an account to join the conversation.

  • Posts: 416
  • Thank you received: 154
I think I found and fixed the CW/CCW movement issue, but couldn't find any clear reason for the shutter problem. It would be very helpful if you got a log of the status response from the controller when the shutter is closed and when it's open. It should be something like what I get from my controller: getStatus|OK|0:1:0:1:1:1:1:1;0.0000:1.0000:0.4399;32000;31.29:38.00:999.90:999.90:999.90:999.90:999.90:999.90:999.90;1009.21:999.90;0;5.09;1:1:1:1:1:1;0:0:0:0:0.0000:0.0000:0:0:0;0;126;1#0:1:1:1:1:1:1:1;0.0000:1.0000:0.4291;32000;32.31:39.00:999.90:999.90:999.90:999.90:999.90:999.90:999.90;1009.30:999.90;0;5.09;1:1:1:1:1:1;0:0:0:0:0.0000:0.0000:0:0:0;0;106;1#1:0:0:0

There should be one 1 that turns to 0 and one 0 that turns to 1 between those two, like needles in a haystack :)
Remote observatory running Ubuntu 21.10 x64 with ScopeDome 2M, Skywatcher EQ8, TS 8" RC, Atik 383L+, ASI178MC, ASI120MM-S, SX Lodestar X2, SX USB wheel with OAG, ZWO EAF, Gemini SnapCap, USB_DewPoint, KomaHub
1 year 3 months ago #69259

Please Log in or Create an account to join the conversation.

  • Posts: 35
  • Thank you received: 0
Hi

find the  log file enclosed

CW and CCW works fine, still impossible to open the shutter

 - Setting shutter status to  4 correspond to "open" click
 - Setting shutter status to  1 correspond to "close" click

Rgds 

File Attachment:

File Name: log_12-49-32.txt
File Size:17 KB
 




 
Last edit: 1 year 3 months ago by Eric TINLOT.
1 year 3 months ago #69295
Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 416
  • Thank you received: 154
Thanks, the problem seems to be that for some reason there is no link between the controllers so shutter commands time out. This is shown at the end of the status response:

1149;1##0:0:0:0

The slave status should be there between the ## characters and the first 0 after ## should be 1 when link is established. There are prints that the link is established occasionally, but without full debug logs I can't say if the data is otherwise valid. It might be that you need to enable the driver debug level in INDI control panel for them to get logged. That would include all traffic with the controller which would be useful to see what is going on.

I'll try to see how my controllers behave if I turn power off from the slave controller occasionally, but it's a bit weird why the link isn't up if the Windows drivers work fine. I haven't had issues with the link, but I have the controllers next to each other on a table so that might help :)

Btw. how old your dome is, have you updated the controller firmware at some point? I have version 5.4 in my controllers.
Remote observatory running Ubuntu 21.10 x64 with ScopeDome 2M, Skywatcher EQ8, TS 8" RC, Atik 383L+, ASI178MC, ASI120MM-S, SX Lodestar X2, SX USB wheel with OAG, ZWO EAF, Gemini SnapCap, USB_DewPoint, KomaHub
1 year 3 months ago #69315

Please Log in or Create an account to join the conversation.

  • Posts: 35
  • Thank you received: 0
HI

link between both card is in bluetooth, my dome is.....1 month old 8-)
both in ver 5.4, i have few "bad link" with the scopedome windows driver, will try to check tomorrow the wheel that bring supply to the dome
and redo test with driver level debug in indi

keep you update
Rgds
Eric
1 year 3 months ago #69389

Please Log in or Create an account to join the conversation.

Time to create page: 1.255 seconds