Motor Addressing Solved

Finally, I have solved the motor selection problems.   This blog update will try and cover both problems in detail....


1. PCB interconnections (only applies to prototype models)

As suspected the PCB interconnects was crossed on my Armdroid causing motor selects to drive the wrong motor.   The cables feed the the bottom two data bits (CDIR & CCLK) from the interface to driver circuitry, and look like this:

They combine two channels into a single connector at the other end.

They need to be wired such that the outputs on the interface board below feed directly into the corresponding inputs on the driver circuit board above in the same sequence.   As pictured above, the ordering is - starting from the left-hand side, motor #1 - motor #6

The colour coding of my cables are Purple, Blue, White, and Grey

The labels on all my connectors will be replaced in time to correctly reflect the motor channels they represent.


2. Motor Addressing Logic

The ordering of the Motor Address Bits was not as documented

The give away is the 74LS138 IC6
If you look closely at the pin-out for the 74LS138, you'll see that pins 1 - 3 are the input select bits, illustrated as follows:

The Truth Table says, to get output Y1 selected (ignoring the reverse logic), where Y1 happens to be our motor select for channel #1, you need to set the input pins as follows:

C B A

L L H

L = LOGIC LOW,  H = LOGIC HIGH

Looking at the interface schematics :

You can see address bits D2 - D4 are wired to the 74LS138 as follows:

D4   -->   A (pin 1)

D3   -->   B (pin 2)

D2   -->   C (pin 3)

Which means to select motor #1 the address bit pattern would have to be:

D4   HIGH

D3   LOW 

D2   LOW 

The most significant address bit is actually D2, and least significant D4.

This is not quite what the article in the ETI magazine documented for the interface specification.   Previously, I was setting addresses with the assumption D2 was the most significant bit - for example 001 in binary.

I revisited the construction manual looking for further clarification, unfortunately the documentation is somewhat ambiguous here.

Of course, none of this is actually a problem... we're dealing with an address pattern that is essentially reversible, so if your happy to re-wire your motor assignments, everything will then fall out in the wash.

I decided not to do this, and instead will compensate in software...
By introducing an array of motor addresses, we simply index into this array to fetch the desired motor address bit pattern:

 // motor address bits  
 // 1 0x08 = 1000  
 // 2 0x04 = 0100  
 // 3 0x0C = 1100  
 // 4 0x02 = 0010  
 // 5 0x0A = 1010  
 // 6 0x06 = 0110  
 //          |||  
 //          ||+-- A3  
 //          |+--- A2  
 //          +---- A1  
 const int mtr_addr[] = { 0x08, 0x04, 0x0C, 0x02, 0x0A, 0x06 };  

When constructing our output control byte, the new code looks like :

   int output = CCLK + mtr_addr[ mtr-1 ] + SYNC;  

I no longer need to shift the address bits into position because they are now already defined in the correct position.   The mtr-1 of course is needed because all arrays in "C" have indexes starting from zero.

Actually, I prefer this approach because it allows other readers to easily adapt to their Armdroid's configuration.   This is essentially mapping logical motor numbers to physical motor addresses.  If a motor has been incorrectly wired to the wrong channel, you only need to modify this address array to compensate.   Good eh?


The updated source code for the test program will be added later this weekend to the software section.


I still have plenty of other problems to investigate.  Some of the motors, not all, are not reversing properly, yet everything works when operated by the manual controller.   I also rigged up a test circuit to check the signals coming from the feedback switches - and not convinced this is working properly either.    But, resolving the motor addressing is certainly one step in the right direction.....