Building the new router is currently not so easy and since there already is a very similar router available I decided to model a new slide that fits the EVOII router and is able to take the new wire feeder mechanism.

Writing the library for the MKS Servo42C driver also shows first results. After some hard nights of failure I was finally able to send commands via UART to program the driver. Sounds easy? Well.. The communication is done via hex serialization. Everything is done with bitwise operations to create the hex blocks. A uint32_t with 32 bits need to be split into bytes and to make things worse some commands have multiple parameters packed into a single byte (1 byte=8 bits). Moving the stepper by a given number of pulses is the worst write command. It sends an 8bit part where the 1bit is for the direction and the remaining 7bits are for the speed. This is followed by a 32bit number containing the number of pulses the motor should move.

The functions for this specific case look like this (after checking the speed variable at the beginning the bitwise operation below it is redundant. Not sure yet which one to keep)

bool SERVO42C::set_move_steps( uint8_t dir, uint8_t speed, uint32_t steps ){
    if( speed > 127 ){ speed = 127; }
    speed &= 0x7F; // redundant
    uint8_t data = (dir==1 ? 0x80 : 0x00) | speed; // direction and speed is packed into a single byte, first bit is dir, last 7 bits speed, padded with leading zeros if needed
    return send_8bit_32bit( CMD_SET_RUN_BY_STEPNUM, data, steps );
}

bool SERVO42C::send_8bit_32bit( uint8_t cmd, uint8_t value_a, uint32_t value_b){
    uint8_t hex_block_set[8] = {0};
    hex_block_set[0] = slave_address;
    hex_block_set[1] = cmd;
    hex_block_set[2] = value_a & 0xFF;
    hex_block_set[3] = (value_b >> 24) & 0xFF;
    hex_block_set[4] = (value_b >> 16) & 0xFF;
    hex_block_set[5] = (value_b >> 8) & 0xFF;
    hex_block_set[6] = value_b & 0xFF;
    hex_block_set[7] = create_checksum( hex_block_set, 7 );
    return send( hex_block_set );
}

 Also had some hard time figuring out why the driver did not respond at all if I tried to send the data. Serial.print() and Serial.println() do not work. They don't send the raw bytes. Serial.write() is needed.

All in all pretty tough especially since there are different requirements for different commands. There are three types of write commands. Most just send a single 8bit value, some send 16bit values and the bad one that sends 8bit and 32bit.

The bad one is also the only one (if I remember correct) that does not get a simple status response with 01  or  00 for success or failure but has a third option (02) in the response.