Hi,

attached modified cpp and h file. Most of the functionality should be working but you will need to check against a real device. (Especially the commands send, these could be wrong due to the mods needed)

Good luck

Paul

Dear Paul, really appreciated. I just downloaded and compiled without any problems. Also, the driver immediately connects, faster than before. Just the motor is not moving, and I hope I will have some time tonight to analyze. You were already hinting, that the commands could be wrong, but why do you think they could be wrong?

BTW: the way I connected the BT module to the Tic controller is one-way only, i.e. I only send signals, but do not receive back (which so far there was no need). In case the new code needs to feedback anything from the controller, please let me know.

Thanks once again for dedicating your time to this!!

Helge

I had to change the command array from uint8 to char, so there might be a problem with the assignments of the values (at least there were some warnings) So for the commands you need to check is the values are still correct.

It would be nice to have feedback from the controller, but it should work without. Only thing that will happen is that from INDI you can send new commands while the motor is still running. After the move commands have been sent, position in indi is updated immediatelly and INDI assumes the controller is in the new position. (When there is feedback, this can be avoided)

Regards,

Paul

Hi Paul, I was just trying to figure out what is happening, so I added a few lines to the code at line 75 I squeezed in the following:

IDMessage(getDeviceName(), "Command 0 %d", command[0]);
IDMessage(getDeviceName(), "Command 1 %d", command[1]);
IDMessage(getDeviceName(), "Command 2 %d", command[2]);
IDMessage(getDeviceName(), "Command 3 %d", command[3]);
IDMessage(getDeviceName(), "Command 4 %d", command[4]);
IDMessage(getDeviceName(), "Command 5 %d", command[5]);

The log file is interesting and seems to confirm your doubts, see attached log file from time stamp 2019-02-10T20:52:15.932 onwards (to the end of the file). I first set steps to 100, then back to zero, then 400 and back to zero. The command[] should in hexa decimal be 0xE0, according to the User Guide (www.pololu.com/docs/0J71/9). But in the log I see -32. Maybe this is the char value of "0", as the term 0xE0 starts with 0 (???).

But how to resolve, as the tty_write command requires a char variable?

Sorry, just realized I have been fooling myself with %d for showing the content of the char command variable.

I am giving in for today!

I am reading the polulu guide, trying to understand what exactly needs to be sent. Will see if I can find a solution.

P

Try this, it compiles and sends data but can't check the result.

change command back to

uint8_t command[6]

change write to :

if ( (rc = tty_write(PortFD, (char *) command, sizeof(command), &nbytes_written)) != TTY_OK)
{
tty_error_msg(rc, errstr, MAXRBUF);
DEBUGF(INDI::Logger::DBG_ERROR, "Init error: %s.", errstr);
}

Dont't forget to correct alst exit_safe_start (That was currently sending no data (i forgot to set the data byte) maybe that caused your problems.

uint8_t command[] = { 0x83 };
(and cast in tty_write)

I think INDI sets the terminal raw as needed to send this binary data. So hopefully that works. Binary data on a ttyport can be interrpreted as contol chars if not all tyy settings are correct.

Looking at the doc it seems you can read the motor position from the device, so you could read that periodically (Timerhit) and wait until correct position is reached before accepting new commands. (Some programming needed, but should be possible)

Looks like an interesting motor controller, maye I should buy one for myself.

Regards,

Paul

I ordered one. Should arive tomorrow.

Paul

Dear Paul, it is working now! I am really impressed, thank you very much once again for your support.

First, it did not work, then checked via the ticgui the status, and the motor needed to be re-energized (there is a button at the bottom of the GUI).

I uploaded the file in its latest version.

Best, Helge

One more thing - tried different things to save the configuration for the port, in my case rfcomm1. Attchached the .cpp and .h file - but that did not work.

I hardly dare to ask again Paul - but in case weather conditions are again unfavorable, could you have a look?

Must be a conflict between the built-in save-routine and your declarations. (Did you use the "save" button in the options panel?

So if you want to save your extra items, try this:

in the .h file change:
virtual bool saveConfigItems(FILE *fp);
to
virtual bool saveConfigItems(FILE * fp) override;

in the c++ code add just before line 320:

INDI::Focuser::saveConfigItems(fp);

Rgrds,

Paul

Hi Paul, it works, I am really pleased - thank you once again!!

Attached just a picture of the TIC825 with the HC-05 module.