CNC drilling machine - testing everything

This is one of the most exciting blog posts for a while. After working on the CNC drilling machine as part of the BuildBrighton �50 CNC challenge for a few weeks, we're actually at the point of putting software, hardware, nc drill parsing and motor controller all together and actually trying to cut a PCB.

Actually, we don't have the drill part running yet - but this test shows actual movement, and we've used a laser dot in place of a drill head. But it shows a (sort-of) working CNC machine....

Instead of jumping in at the deep end and trying to draw a complex PCB (the printed pattern on the paper) we started off with a simple square. But as you can see from the video, we deliberately drew (and mounted) the square on an angle, to simulate mounting a PCB on the cutting bed on a wonky angle.

The software takes care of the rotation and follows the dots.
The first few seconds of the video show the machine being calibrated - the software prompts you to place the cutting head over a hole, record this location, then move the head to a second hole. This is what you see as the head travels diagonally across the board at the start (and the slight delay in the finer movement is us changing some parameters on the PC to reduce the jog step size).

The software then works out the cutting path (in this case, a simple down-across-up type pattern) and sets the motors spinning!

It's interesting to note that the cutting head doesn't necessarily follow the "lines" between the dots (if the dots were on the corners of a square for example), since it is a point-to-point machine, rather than a line follower. We'll try to demonstrate this more clearly in a later post.
But for now, sit back and enjoy our first CNC test.

It's not bad. It's not perfect - we need to take out any backlash in the gears (the motors themselves have quite a bit of "slop" on the spindle because of the internal gearing) to get greater accuracy but as an initial test - and particularly the handling of skewed boards - we're quite pleased with progress so far!

Next time we hope to actually cut (or maybe just draw felt-pen dots on) something.....

CNC motor testing via USB

There's an often held belief that you can't do CNCs without a parallel port on your PC and cleverly timed move instructions. That may have been the case back in the day, but we've had the nineties guys, USB is all the rage!

So we're building a USB CNC controller board.
We're quite lucky that these cheap little 5V 28BYJ48 steppers have already been stepped down. They're supposed to be 1/64 but inside they're geared down again. There are loads of places all over the internet which say that they're stepped down again by 1/32 - meaning you need 64 * 32 = 2048 steps for one complete revolution.

If that's the case, we should be able to get pretty precise movement, even with a massive gear/cog riding on the shaft, and without having to bother with the complexities of micro-stepping. There's only one way to be sure - and that's spin one around and count the steps!

In-keeping with our NC drill software, we're looking to build a USB controller which we can give a number of steps and have the motor(s) play out those steps. We've no idea at the minute how many steps we may need to move up to (depending on how many steps per revolution these motors actually need) so we've allowed for a 4-byte value to be sent to our trusty 18F2455 PIC microcontroller.

We're using (as ever) a generic HID device interface and sending data in 8 byte packets.

• The first byte (byte zero) is our "command byte".
• If the value is one, it's a command to set the x motor step count
• If the value is two, it's a command to set the y motor step count
• The second, third, fourth and fifth bytes make up our 4-byte value (0-2,147,483,647)
• The sixth byte (byte 5) is a direction - one is anit-clockwise, zero (or any other value) clockwise.

After sending the x-axis step count (or the y) the controller board stops all motor activity (since if the motors are spinning when new values come in, the x- and y- axis will go out of alignment with each other, as the earlier axis will be ahead of the later one).

Only once the command byte 254 is sent do the motors actually spin up.
For as long as the x/y step count has a value greater than zero, the motor(s) are given a signal to move them onto the next step. The step-count value is decreased by one each time one of the axis motors steps. Once both motors have a step-count value of zero, a flag is set to tell the PC that the motors have stopped spinning and the head is now in it's correct position.

Here's a video of some early testing:

What's happening here? Thanks to the autofocus on our camera-phone it's not too clear - but if you squint and stand back from the monitor you might see:

Firstly, the command byte (7th byte) is given the value 1 (set x motor step count), along with the second byte (from the right) set to 16. Since our x count is a 4-byte value, we're setting it to 16*256 = 4096.

We repeat these values with the command byte set to value 2 (set y motor step count) then clear the buffer and send the command value 254 to get the motors spinning.

Giving our control board a value of 4096 makes the motor complete one full rotation.

So there we have it. Our stepper motor has a 1/64 step angle, geared down, not by 1/32 as some other forums suggest, but a full 1/64 again. 64 * 64 = 4096 so this is the number of steps required for a full rotation.

The video then skips back to a blurry laptop screen, where we enter the same values, but this time setting byte 4 to 1. This is the direction byte. When this is set to one, the motor spins in the opposite direction.

All in all, we've had quite a successful evening - we've got both axis motors spinning from a custom-built PIC-based USB (HID device) board and some software which we can talk to the board with and get predictable results. Now we just need to remember how to work with Timer1 to create a 20m/s interrupt on the PIC and we can use this to send servo commands for the z-axis (drill up, drill down and motor speed).

Tomorrow is another BuildBrighton open evening.

There's even a slim chance that after the beers and pizza, we might actually get something working......

USB OTG FTDI (any other acronyms?)

A good while back, we made some miniature instruments for playing samples on a PC. They worked quite well and we got a bit of interest and sold a few kits online. But how technology marches on!
No sooner had we got them working with a computer, when users started asking when could they plug them into the mobile phones and Android tablets!

And following on from a discussion with Robot Steve the other night, we're thinking that making mobile-friendly versions of our miniature instruments would be a pretty cool intro to USB OTG.

No sooner had our PIC 24F USB development board arrived, than Jason from Stuff and Nonsense suggested a hardware-based USB stack from FTDI. So we got ourselves a debugger/programmer (https://uk.farnell.com/jsp/search/productdetail.jsp?SKU=1825836) and a development module (https://uk.farnell.com/jsp/search/productdetail.jsp?SKU=1825829) off the Farnell website.

That's right - next day, 8am, sure enough there was a thump-thump-thump on the front door and a beaming postie with a parcel covered in Farnell/element14 livery. I guess we really need to do something about fixing that doorbell.

Awesome Farnell

Just a quick post to remind myself as much as anyone else why Farnell are still number one for me...
After chatting with Robot Steve from BuildBrighton, we were talking about creating peripheral devices for mobile phones. We've already made a few USB devices for PCs (USB/HID slave devices) but this was a whole new challenge.

Android have embraced this idea, but in a back-to-front way.
To enable developers to communicate with the widest range of devices already on the market, they've suggested creating a USB device as a host (not a slave as would be the normal way of going about things) and then having the phone act as a slave, just as it would as if it were plugged into your PC.

Sounds straightforward enough, but we've only ever created USB slave devices, not hosts.
A quick look on the Farnell website reveals that the 24F series of PICs with USB host/slave (OTG - on the go) functionality cost as much as, and sometimes less than, the 18F series of PICs we were using for our slave devices. It looks like it's finally time to think about moving up to 16-bit micros and leaving our old 8-bit friends behind....

We ordered one of these PIC development boards at teatime yesterday:
http://uk.farnell.com/jsp/search/productdetail.jsp?SKU=1605296

At 8am, a hefty thump-thump-thump on the front door (our postie isn't afraid to get you out of bed) and it arrived at Nerd Towers:

That's about fourteen hours from deciding to give this stuff a try to it turning up on the doorstep, ready to give it a whirl. Farnell have once again excelled themselves and are proving to be really hacker/maker friendly! We've always preferred Farnell over their rivals, because their website makes finding components really, really easy. They're not always the cheapest, but when the difference between components can be measured in pence, it's service like this that keeps customers loyal.

Working SMT USB HID device

The ICSP/SOIC chip clip arrived from Farnell today.

They really are excellent for next-day delivery. By UPS courier no less, not just Royal Mail (which can take three or more days to arrive!). If you're prototyping and can't wait for the delivery times from eBay suppliers (or just want to buy from someone with proven customer service) we can't recommend Farnell enough!





Anyway, the clip arrived - it is like a sprung loaded bulldog clip, with each of the fine-pitch pins being taken up to a 0.1" pitch header on the tops of the handles.

Before we could use it we had to make a simple pass-through board for my PICKit2 Clone iCP01 programmer (from piccircuit.com). The idea is to have a board with five pins that we can push the connector from the programmer onto. The other side of the board will be connected to a length of 5-way IDE cable, which in turn is connected to some 0.1" pitch pin header sockets. The sockets slip over the ends of the "chip clip", connecting the PIC programmer to the appropriate pins on the device.









Following the programmer pinout, we had to identify which wires needed connecting to which pins on the headers on the top of the clip handles.







Here's the whole thing assembled







And here it is, in place and ready to program the chip.







By either good luck or good judgement, the chip was immediately recognised by the PICKit2 programming software, and we were able to download some test firmware onto the device.



All went well and after the programming clip was removed, the device was plugged into the laptop via it's miniature USB socket. The usual bing-bong sound told us that the device had connected properly, and further inspection in Device Manager confirmed that our SMT soldered USB/HID device was indeed working.



The last bit of the puzzle now is to update the firmware so that it matches the new pin layout we used (the pin assignments were changed from the earlier version, to make SMT layout easier)

Multiple touch sensitive inputs

In a previous post we talked about how to use a darlington transistor to create a touch sensitive switch.

For a device with multiple touch-sensitive inputs, it seems obvious that we repeat the single input for each pin we want to use as a touch sensor:



However, for each input our component count increases.
In the example above, we're using PORTB on the microcontroller, which has a built-in pull-up resistor on each input pin. If we need to use a different port, or want to use more than 8 inputs, we're going to have to add a pull-up resistor on each input pin. Also required - though not shown on the diagram above for the sake of simplicity - is a 1M pull-down resistor on the base pin of each darlington transistor.
So for each additional input, we're introducing three extra components.

It's worth noting, at this point, that for each touch sensitive input, we need two pads per input: one pad connected to the base pin on a transistor, and one pad connected to the 5V supply (the user touches and effectively creates a bridge between the 5V supply and the base input pin).

However, we can simplify our design massively by swapping the pads around:
instead of a fixed 5V supply and multiple darlington transistors, we can use a single transistor and multiple, variable 5V supplies. How to do this?
We turn each potential input pin to an OUTPUT and use this output to drive what would otherwise be a fixed 5V supply on the first pad. So each pair of pads that make up a touch-sensitive switch consist of an output pin (from the microcontroller) and a pin connected to the base of the darlington transistor.

a simple PIC/usb device with 16 touch sensitive inputs

Every touch contact would consist of a pair of pins/pads - one going to each of the numbered pads (PAD1, PAD2 etc) and the other a common input (COM_INPUT) so there would be a total of 16 COM_INPUT pads all tied together.

The pseudo-code would go something like this:

• turn off all outputs
• turn on output RA2 (PAD1)
• has RA0 gone low? (yes=finger present across PAD1 + COM_INPUT)
• turn off output RA2
• allow time for input to return high
• turn on output RA3 (PAD2)
• has RA0 gone low? (yes=finger present across PAD2 + COM_INPUT)
• turn off output RA2
• allow time for input to return high
• etc.

It depends on the type of darlington transistor you use (different transistors have different response/switching times) and the size of the pull-down resistor on the base pin, but in practice, with a 1M pull-down resistor, we found that 0.5ms (500us) worked well. Using this approach, we were able to poll all pins in under 10ms (0.5*16 = 8ms). At 100 times per second, this was more than responsive enough for our needs!

Until we can use the CNC again....

...the most exciting thing about getting a CNC machine working is the ability to quickly and easily drill our home-etched PCBs. But also, the ability to carve shapes and make enclosures for forthcoming projects is pretty cool too.

We've a few projects in the pipeline, which make use of some pretty simple but powerful underlying technology. After running a few workshops in and around Brighton and receiving a few emails from previous posts on other projects, we're going to document these in their entirety.

We'll be using the 18F2455 and 18F4550 PIC microcontrollers to create USB/HID devices. And we're also incorporating a simple touch-sensitive interface. At the minute, capacitive touch sensors are all the rage. What this basically means is that each touch pad connects to a microcontroller and when the user places their finger over the pad, a simple capacitor is created. The relative capacitance of the pad is compared over time and when the capacitance changes, the microcontroller can detect whether a finger has been placed near or removed from the pad.

The downside of capacitance touch sensing is the need for relatively large pads - or dedicated capacitive sensing hardware.

To keep our project simple - both in writing the firmware (capacitive sensing firmware can be quite convoluted and multiple readings averaged over time to smooth out any rogue analogue readings) and in sourcing the hardware - we're going to use an alternative approach:

A transistor is often used as an electronic switch, but it can also be used as an amplifier. A tiny current onto the base pin of an NPN transistor allows a much larger current to flow through the collector and emitter pins.



Whatever current is directed onto the base pin is amplified onto the collector pin.
By "feeding" the output from one transistor into the base pin of a second transistor, we can amplify the input signal many thousands of times over



In fact, by feeding one transistor into another, even the tiny amount of current that passes over the surface of your skin can be used as a switch. Such transistor pairs are available in a single package, known as a Darlington transistor.

Here's an example of how we can use a darlington transistor as a touch sensitive input device for a PIC microcontroller:

The schematic above uses a darlington transistor, such as a BC517 as a single discrete component. Although a darlington transistor is actually two transistors connected as shown above, we will draw it as a single transistor for simplicity.

Touching the two pads - however large or small they may be - causes the transistor to switch, forcing the current to flow from the input pin to ground. While this may seem counter-intuitive (normally you might expect voltage to flow into an input pin to indicate an input switch) the reason for this should become clear: on a lot of controllers (and had we put this input onto PORTB) you can use internal pull up resistors on the inputs, removing the need for the external resistor as shown in this example. If your controller does not have internal pull-ups, the resistor is there to stop the input pin "floating" when no finger is present on the contacts. The resistor should be quite a high value, say 100K.
Now, when the pads are touched, a tiny current flows from 5v on PAD1, over your finger, onto PAD2 and into the base of the darlington transistor. The transistor amplifies this current, creating a "switching effect" and causes the input pin to go low.
When the finger is removed off the pads, no more current flows into the base pin, the transistor closes the "switch" and no current can flow from the input pin to ground. The pull-up resistor causes the input pin to go high when the pads are not touched.

Although the above gives us a working touch-sensitive switch, we're not quite done. If you try the schematic out, you might find - depending on the type of darlington transistor used - that while the "on" trigger works (i.e. the input goes low immediately after touching the pads) the "off" time can be quite slow (i.e. the input pin remains low for a second or more after removing your finger from the pads).

The reason for this is that the darlington transistor can amplify even the tiniest little current - even residual electrical noise can be used as a trigger; it's a bit like leaving an input pin floating - the base pin of the transistor is so sensitive it can switch on and off almost at random. And like a floating input pin, it can remain active even when the input is removed.



The answer is to put a pull-down resistor on the base pin.
Now, when your finger is removed, any residual current on the base pin has a path to ground, and the switch closes. The size of the resistor determines the response time. If the resistor value is too low, it may stop the transistor switching on at all (the human body has an electric resistance of around 40k-100k so this base resistor needs to be much higher) but too high and the residual current on the base pin may take too long to be pulled to ground, resulting in slow response times. In practice, we found that a resistor with a 1M resistor on the base pin (R2), with a 100K pull-up resistor (R1) on the input pin worked well and gave reasonable response times.

USB servo board - almost done?

This is looking like the final version of the servo board and includes a number of cool enhancements:

At any point in the script, the user can place a label.
This is marker point from where you can play back sections of an animation.
Users can place GOTO commands in the script, such as "goto 1500ms" (the animation jumps to the point 1.5 seconds into the animation) or "goto label 4". It is this second GOTO command that makes the servo board so useful:



We've also updated the firmware so that one or more of the servo pins can be used as input triggers. Simply tell the board how many input pins you want to use (0-8) and when the appropriate input pin is pulled low, the animation playback jumps to that label number.

For example, pull the first input pin (normally servo 20) low and playback immediately jumps to label 1. Pull the second input pin low (normally servo 19) and playback jumps to label 2. Because our servo pins have ground on the outside and signal on the inner (the middle pin is always 5v) the button in the video simply bridges the two outer pins, to pull the input pin low.

Here's the full script, as used in the video above:

'this is the first animation
'it can also be triggered by sending PORTB.7 low

label 500,1
servo 1000,9,50
servo 1000,10,50
servo 2000,9,220
servo 2000,10,220
servo 3000,9,50
servo 4000,10,50
servo 5000,10,220
servo 6000,9,220
tloop 7000,1000 'go to time point 1000

'this is the second animation loop
'triggered when PORTB.6 goes low

label 10000,2
servo 10000,9,150
servo 10000,10,150
servo 11000,9,220
servo 11000,10,50
lloop 12000,2 'go to label 2

end 15000

USB servo board update

We're getting close to finishing the 20-channel USB servo controller board.
This latest update has the servos in the correct place on the board (previous versions of the firmware numbered the servos according to the pins/ports they were on, but the PCB layout made them appear to be randomly placed!)

This latest update also includes a surface mount Flash eeprom, rather than an 8-pin DIP. This means that the 8-pin chip appears reversed when the PCB is printed (pin1 is top right, not top left) but when toner-transferred, will appear the right-way around. We had to swap a few pins around on PORTA to simplify the layout for the PCB so a new schematic is included below.



Also to note is that on this board, the SMT memory chip will actually be on the underside (where all the pins are soldered to the copper board).

Servo Usb Smt Eeprom Schema

Servo Usb Smt Eeprom
Print at 100% no scaling in landscape orientation to create your own press-n-peel transfer to make this USB servo controller board with SMT eeprom chip

We're also working on one last final revision of the firmware, to allow the user to place "labels" along the timeline, and to have the servo controller board jump to specific points along the timeline. This will become clearer as screenshots of the software become available....

USB servo board animation playback - edit

One last amendment as the playback routines are written.
All our animations are simply lists of events that happen a specific time after the user has pressed a button (or sent a signal) to start the animation playback.

The PIC keeps a running timer of the time elapsed since playback started, and a list of events and when they need to happen. The list is already sorted into time order (by the host PC before downloading).

The PIC microcontroller simply compares the current time to the time of the next animation in the list. If the current time is greater or equal to the time of the event in the list, it plays out the animation (moves the servo) off the top off the current "stack" of animations, then moves onto the next one.

This approach allows the PIC to catch up with any missed "frames" - in fact this is an important approach, since three things happening at exactly the same time will actually be processed in sequence, one after the other, but very quickly.



Anyway, this leads us to the latest amend:
Timecodes are stored as two-byte values (any number from 0 to 65,535).
At the minute we're storing times as milliseconds from the start. While this is pretty accurate for playback, in reality, we're more likely to want things to move within seconds or half-seconds of each other, not 1/1000th of a second.
If we stick to storing our animation timecodes as milliseconds, the maximum value we can store is 65,535 milliseconds - 65 seconds. The longest animation would be just over a minute long.

By simply storing timecodes as 1/10th seconds (so one second is represented by 10, two seconds by 20 and so on) we can perform animations with timings as low as 1/10th second, but also increase our playback times incredibly.

If the maximum value possible is 65,535 represents 6,535 seconds, this is a massive 108.916 minutes - or 1hr 48min and 55sec of animation!

The software and PIC firmware will be updated shortly with this amendment.
Following the examples given in a previous post, the data written as

servo 500,09,120
servo 500,10,120
servo 2000,09,050
servo 2000,10,200
servo 4000,09,200
servo 5000,10,060
tloop 6000,1000

...is now converted into

0,5,0,9,120 (500 milliseconds = 5 * 1/10th second)
0,5,0,10,120
0,20,0,9,50
0,20,0,10,200
0,40,0,9,200
0,50,0,10,60
0,60,1,0,10

USB servo board animation playback

After a late night at BuildBrighton last night, we finally got the PIC microcontroller talking to the Flash-eeprom. It turns out that the first SMT-to-DIP board wasn't soldered up properly. So after a few hours debugging some code (that eventually turned out to have been working all along) we fixed the dodgy lines and managed to read and write data to/from the Flash device.

So now we need to consider how animations will be stored in memory.
The first, and immediate, use of the Flash memory was to store data in a sequence of 4-byte chunks.

• The first and second bytes represent the time in milliseconds to have elapsed.
• The second byte is the servo channel number
• The third byte is the movement value (where 100=1m/s, 200=2m/s etc)

500,09,120
500,10,120
2000,09,050
2000,10,200
4000,09,200
5000,10,060

We started building an app to allow users to write their animations to the eeprom chip. Then, after a cup of tea and a biscuit, we decided to make a DLL to simplify the whole process, allowing end-users to create their own animation software and integrate it with the servo board. The final solution we came up with (and decided to stick to) was to read a simple text file, made up of the 4-byte chunks, and stream this data over USB to the usb-servo board.

Full details of how the servo board works will be published later (once we've agreed on the communication protocols!) so that other users can contribute their own animation-creation software in future.

After a bit of thought, and trying out a few animations, it became apparent that the eeprom chip has massive amounts of storage which likely to go unused. It also became apparent that most robotic animations are actually repetitions of relatively small animations. For example, walking animations are just cycles of simple, smaller movements (irrespective of the number of legs involved!).

Our final animation decision was to increase the chunk-size to five bytes:

• First and second bytes are time in milliseconds
• Third byte is a command byte which changes how the fourth and fifth bytes are interpreted
• If command byte is "move servo", the fourth byte is the servo number and the fifth byte the movement value
• If the command byte is "jump to timecode", the internal servo timer is updated to a (two-byte) value represented by bytes four and five

The text file containing these values is updated to an easily-understood format:

servo 500,09,120
servo 500,10,120
servo 2000,09,050
servo 2000,10,200
servo 4000,09,200
servo 5000,10,060
tloop 6000,1000

and these commands are translated into the following byte sequence:

1,244,0,9,120 (500 = highbyte 1, lowbyte 244, third byte=command byte)
1,244,0,10,120
7,208,0,9,50
7,208,0,10,200
15,160,0,9,200
19,136,0,10,60
23,112,1,3,232

The last entry is of particular note.
The command tloop is represented by a 1 in the third byte and in this case means "reset the timer as if it were 1 second after the start of the animation".
As a result, the servo board resets the internal timer, starts at the beginning of the list and reads through the commands, until it hits the appropriate one in the sequence. The result, in this case, is that the last five commands in the list are repeated over and over again.

USB servo board first PCB prototype

After a few weeks away, it was nice to get back to Nerd Towers and start etching stuff and messing about with copper boards and solder again.
After lots of development and testing on breadboards, it's finally time to try the usb servo board out for real - here's the first set of etched PCBs for the controller.

We've tried to keep the board as compact as possible, but still allow room for an 8-pin DIP (or one of our spanky new SMT-to-DIP boards) as well as all 20 servo channels.

Phew! That's a lot of holes to drill with a hand-operated push-drill!

How the controller board looks, from the "business side".

USB servo board eeprom

The little eeprom chips arrived today. I forgot that they were SMT when I designed the USB servo board for PCB manufacture, so the board has an 8-pin DIP socket, and the eeprom chip is SMT. Bugger!

To get around this, I created a simple SMT-to-DIP converter for 8-pin chips:



The SMT chip goes to the left of the 8-pin DIP connectors. I'll put two rows of 4 x 0.1" header pins where the DIP chip would normally go, effectively turning the SMT chip into an 8-pin DIP.

SMT_to_DIP_8PINPrint at 100% no scaling in landscape orientation to create your own press-n-peel transfer to make this SMT-to-DIP converter

If you're making one of these yourself, note that the PCB design has been mirrored (normally we don't bother mirroring designs, as they are reversed on the bottom of any through-hole mounted board anyway). With this design, however, the copper part of the board will be face up, with the SMT chip soldered onto the copper side (rather than the through-hole components being mounted on the top and soldered underneath).
Because of this, the design is mirrored (but when you use press-n-peel/toner transfer to get the image onto the copper board, it'll end up the right way around).



Dont forget to mount the pin headers on the bottom (non-copper) side of the board, with the shorter legs soldered to the top (copper-side) of the board.

The usb servo board was designed to accommodate either a regular 8-pin DIP or our modified SMT-to-DIP board

Servo board PCB layout update

Just a quick update on the 20-channel USB servo board with eeprom playback:
this new PCB layout includes the eeprom chip (Atmel's AT45DB041D). Another slight change to the earlier design is that the USB 5v/power supply now goes to the 5V output pin of the regulator rather than the input. This allows the user to connect 4xAA (or 4xAAA) batteries to create a 6V supply or even use a single PP3 (9V) battery to run the device, but safely connect the USB cable at the same time. The original design required the user to disconnect the batteries before connecting the USB cable to download more data to the device. With this new layout, the batteries can safely remain connected and the board still be connected to a PC to download more data.
(a future board with 3.7V rechargeable lipo is in the planning stages but is still some way off!)


Note in this silkscreen and current version of firmware, the servo pin numbering is a little peculiar. This will be addressed in the final version of the firmware!

Working servo board prototype

Here's a quick video and some photos showing the new 20-channel servo board in action! The actual board registers as a HID device. We're including sample code for Windows (but anyone wishing to port the code to Linux/MacOS should be able to do so using something like HIDApi).



The HID device communicates with the host via an 8-byte buffer.
To move the servos, simply set the 7th byte to value 201 (I don't know why we chose that value to represent the "move servo" command, but we did!) and the zero byte to the servo channel number (1-20) and the first byte to the movement value.
The range of valid movement values changes depending on the servo being used.
In theory, the values should be 100-200. This represents a signal range of 1ms to 2ms.



The mid-point should always be 150 (1.5ms) whatever the servo, but we've found that some of our cheap chinese HXT900 servos accept a much wider range (as low as 30, or 0.3ms and as high as 250 or 2.5ms before they start to "chatter" at the end of their range).


Snapshot of simple VB6 app sending data to a generic HID device through an eight-byte wide buffer