Submitted by Inco on Sun, 05/02/2010 - 00:58
Posted in
I'm not sure if this happens in the last version, I'm working whith a old version because it's not easy to me to move my changes to the last version every time you make any change.
in the documentation of om_serial_com_client.pde you say
5 (set motor enable)
byte 2 : motor #
6 (set motor disable)
byte 2 : motor #
but if you write
motor 2 disable 5
slim sends
02 04 02 06 02 05
and, of course, if you write
motor 2 disable
you get
02 04 02 06 02 00
I know that is not important but I'm writing a gui in gambas :( and I notice that.
I have modified OpenMoco::Interface::Timelapse and now it sends 4 bytes for "motor steps" and "move motor dir steps". I have modified openmoco to receive that and to enable the use of external i2c devices to control the motors,
byte motor_i2c_0 = B10100000;
byte motor_i2c_1 = B01000100;
/*
motor_i2c0 information about motors 0 and 1
motor_i2c1 information about motors 2 and 3
byte motor_i2c_1 = B01000100;
/*
motor_i2c0 information about motors 0 and 1
motor_i2c1 information about motors 2 and 3
B7 = motor 1 internal or i2c controled
B6 = motor 0 internal or i2c controled
B5,B4,B3 = I2C_device_address motor 1
B2,B1,B0 = I2C_device_address motor 0
motor_i2c_1 same use of bits
*/
byte motor_external_active = 0;
/*
B3 motor 0
B2 motor 1
B1 motor 2
B0 motor 3
*/
I have not implemented yet the use of "motor_external_active", because at this moment it's not critical for me.
best regards,
Inco.
That's because there's one
That's because there's one method to handle several different motor commands, as they all share a common path in the API. Don't give it the extra argument to the slim command (slim does handle things slightly differently than the underlying API). This is the correct documentation for 0.82: http://openmoco.org/node/143 -- I'll look later and see if the perl API is sending any extra data, but even if it were, it wouldn't be an issue as the engine would successfully ignore it. The data length byte is right, so there wouldn't be garbage left in the buffer, and the code path doesn't care about that last byte -- it will just be discarded.
!c