×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

Celestron Motorised Focuser - Is it supported in EKOS yet

  • Posts: 200
  • Thank you received: 57
Check if you have write access to the serial device. Usually you need to be in dialout group to have that right. You van check this using following commands:
ls -l /dev/ttyACM0
groups
Post the output here if you are not sure
The following user(s) said Thank You: Jasem Mutlaq, Chris Rowland
5 years 1 month ago #35342

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

  • Posts: 210
  • Thank you received: 104
Hi Chris,

In complement to checking the access right also be sure the device is not taken by ModemManager, this program as the wrong behavior to think that any ACMx device is for it's own exclusive use.
If you not use analog modem the best is to remove it: sudo apt-get remove modemmanager
The following user(s) said Thank You: Jasem Mutlaq
5 years 1 month ago #35343

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

It is worth noting that I recently made a change to indicom tty_connect. I don't think it affects this but it's worth mentioning here in case anyone else believes otherwise. So now immediately after connect, I use :
ioctl(t_fd, TIOCEXCL)

To make the port exclusive. Also, then the serial device is now opened, it is opened like this:
t_fd = open(device, O_RDWR | O_NOCTTY | O_CLOEXEC);

The O_CLOECEC removes the exclusivity on close. So the rational behind this is that when there are multiple serial devices on the PC, and INDI is set to "Auto Search", each driver will try to open a connection to each device and then the driver would try to perform a handshake to see if there is proper communication going through. If not, it moves on to the next port on the list.

This behavior turned out to be quite problematic since it makes several drivers interferring with each others as each compete to open and test a device. So after the change above, when a device is opened, it is made exclusive (by non-root processes anyway), and any attempt to open the serial port would result in EBUSY. Once the driver finishes the hankshake, it is either a successful hankshake in which the driver continues to use the port, or a failed handshake in which case the driver closes the port thereby ending the excluscivity lock. So far this behavior results in a more reliable connection experience and I can connect "blindly" to all my observatory serial devices with this method, while before the exclusivity bit one one or two devices connect and the rest fails.

This feature has yet to see more testing to see if it leads to any side effects.
Last edit: 5 years 1 month ago by Jasem Mutlaq.
5 years 1 month ago #35347

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

  • Posts: 554
  • Thank you received: 138
Thanks for the feedback, I'll try to answer the questions here and provide more information.
ls results:not sure what type c is.
Read and write access for the User and Group, no access for other
User is root, group is dialoutI have a dialout group.

I've removed the modem manager and restarted.

Nothing has changed, this is the kstars log data
And this is the relevant part of the kstars log file:It seems to connect.
The CS: line is the checksum calculation, this is OK.
The two data lines are the packet to be sent, these seem OK.

Then tty_write returns -2 with the number of bytes sent - br - as 0 so I fail.

The code that does this is:
void AuxCommunicator::Connect(int portFD)
{
    serialPort = portFD;
}
 
bool AuxCommunicator::sendPacket(AuxTarget dest, AuxCommand cmd, buffer data)
{
    AuxPacket pkt = AuxPacket(cmd, src, dest, data);
    buffer txbuff;
    pkt.fillBuf(txbuff);
    int br;
    int tty;
    int len = txbuff.size();
    char buf[len];
    fprintf(stderr, "buff len %x:", len);
    for (int i = 0; i < len; i++)
    {
        buf[i] = txbuff[i];
        fprintf(stderr,"%2X ", buf[i]);
    }
    fprintf(stderr, "\n");
 
    tcflush(serialPort, TCIOFLUSH);
    tty = tty_write(serialPort, (const char *)buf, len, &br);
    fprintf(stderr, "sendPacket br %x tty %x\n", br, tty);
    return tty == TTY_OK;
}
Is there a way to get more information about why the write failed? All that reply gives is TTY_WRITE_ERROR.
5 years 1 month ago #35349

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

  • Posts: 554
  • Thank you received: 138
This code works:
#include <iostream>
#include <stdio.h>   /* Standard input/output definitions */
#include <string.h>  /* String function definitions */
#include <unistd.h>  /* UNIX standard function definitions */
#include <fcntl.h>   /* File control definitions */
#include <errno.h>   /* Error number definitions */
#include <termios.h> /* POSIX terminal control definitions */
 
using namespace std;
 
int main()
{
    cout << "Hello World!" << endl;
 
    int fd = open("/dev/ttyACM0", O_RDWR);
    if (fd < 0)
    {
        cout << "open fail " << fd << endl;
        return 0;
    }
    unsigned char outbuf[] = {0x3b, 0x03, 0x22, 0x12, 0xfe, 0xcb};
    int ws = write(fd, outbuf, 6);
    cout << "written " << ws << endl;
 
    unsigned char inbuf[20];
    int rd = read(fd, &inbuf, 10);
    cout << "read " << rd << ":";
    for(int i = 0; i < rd; i++)
    {
        fprintf(stdout, " %02X", inbuf[i]);
    }
    cout << endl;
    int cs = close(fd);
    cout << "close " << cs << endl;
    return 0;
}
The output is:I'm not even setting the baud rate, I suppose that was inherited from the previous tries.
5 years 1 month ago #35352

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

  • Posts: 554
  • Thank you received: 138
I've got communication going.
It turned out that I wasn't setting the port ID in my AuxCommunicator. I thought I could do it by passing PortFD to the AuxCommunicator once at connect time but the code to do this wasn't being called. Adding PortFD to the parameters for every call to the AuxCommunicator worked.
The move and/or position isn't working correctly but Abort works. Just a matter of debugging.
Always the way, it's the simple things that get you.
Chris
The following user(s) said Thank You: Jasem Mutlaq
5 years 1 month ago #35353

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

  • Posts: 554
  • Thank you received: 138
I've got the focuser working, read position, and move are going and I can read the focuser limits from the focuser.

But I'm having a lot of trouble with Git, I can't even push things locally, so I've attached the files I changed.
Oh. There's a message, with white text on a white background saying that .cpp and .h files can't be attached.
here's a zip file .

File Attachment:

File Name: celestron-backup.zip
File Size:6 KB
5 years 1 month ago #35402
Attachments:

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

Thanks Chris. Did you fork INDI on Github? what's your github username?
Last edit: 5 years 1 month ago by Jasem Mutlaq.
5 years 1 month ago #35406

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

Another issue.. the celestron.h includes "celestronauxpacket.h" but it doesn't exist. There is celestronauxcommand.h but it's empty.
5 years 1 month ago #35407

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

  • Posts: 554
  • Thank you received: 138
I had a fork and managed - somehow - to get your celestron.cpp,h onto my system.

I had added celestronauxpacket.cpp,h and thought that was what I had backed up, not the celestronauxcommand files which were empty and I thought I had deleted these some time ago.

Now it looks as if the celestronauxpacket files, where I had done the majority of the communication stuff, have vanished. I had tried to go the git route and ran into all sorts problems with merge clashed with files that were nothing to do with me. It looks as if somewhere in that git has silently removed my files.
QTCreator now wants to rebuild indi CMake, presumably because of the lost files - and goodness knows how much else
Not sure what to do. I don't feel very inclined to rush around rewriting the files.
I still have a .git folder, which I'm not going to touch because there's a possibility that my files are there somewhere. In fact not toughing git again seems a good idea to me.
5 years 1 month ago #35410

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

Sorry about that Chris. GIT is wonderful powerful tool when you get used to it. Can you please zip the .git folder and share it? I can help in recovering any code if possible.

Actually, if you zip the complete indi directory you were working in that would be even better. Do you recall what happened exactly? did you use git command command? I just checked your online fork and there is no pushed commits there either.
Last edit: 5 years 1 month ago by Jasem Mutlaq.
5 years 1 month ago #35411

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

  • Posts: 554
  • Thank you received: 138
Thanks Jasem,
Here is a git status and git diff, they may give a clue about what was going on.Then did a diff:and no obvious way out other than to close the terminal window.
I've had nothing to do with BasicMathPlugin.cpp

The zip of my indi folder is 842 mbytes, is it OK to send that?

Chris
5 years 1 month ago #35412

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

Time to create page: 0.770 seconds