Hm, it should work, did you have the https:// in the url, the forum software seems to eat that part? Ie. change "indilib" part to "jpaana" in the url that works for you and add -b (or --branch) scopedome_update to checkout the correct branch, or go to the resulting indi directory and run "git checkout scopedome_update" there.

yes i added the https and it is working ...still compiling will keep you update, should i see another scopdome model available or is it the same driver as your previous version that works with both ?

It's in the same ScopeDome driver and you need to select the card type before connecting in the connection tab. Also serial baud rate should be set to 9600 for the Arduino card, but 115200 for USB Card V2.1 so that is another slight complication. I tried to do automatic detection of the type, but it was hard to make it robust so I've disabled it for now. The setting is saved with other options so you should only need to do it once.

Hi 
first step is fine, i'm able to connect to the arduino  



but seems impossible to interact (i tried open shutter, move CCW or CW) and get following error message 

 

sensors seems to be read correctly, will investigate deeper tomorrow

Eric

Thanks, it seems there no connection to slave controller so the status response is missing fields that should come from there and the code doesn't seem to cope with that. I'll fix that, hopefully tomorrow. Have you used the dome with the Windows drivers successfully? Ah, and do you have a slave controller paired for the dome or do you use just one controller in the clam shell mode?

For further testing, it would be useful if you enable driver debug, INDI and dome logging in KStars and attach the log, they are easier to search for things than screenshots

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.

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

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.

No problem, let me know when you have done something that i càn test

 

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


Rgds

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.

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