Toolhead controller design ideas

I'm building a toolhead controller for my extruder experiments so that I have a common platform for controlling all aspects of the toolhead. There are a few advantages to this, such as controlling all the toolheads in a standard manner.

I'm trying to decide on the featureset. I'd like input on what features will keep this design extensible without major revisions.

After playing around with a few ideas, I've decided that there is a relatively small feature set which will allow for most of the possible toolhead configurations:

Carriage connections
1xRS485--Host communication
1xGPIO(commited)--Toolhead dock detect
4xGPIO(commited)--Dock ID

Motor connections
1xGPIO(commited)--Motor Direction
1xPWM(commited)--Motor Speed
2xInput Capture--Quadrature,tach,etc.

Other connections
2xPWM--Heater,solenoid,etc. drivers
2xADC--Pressure,Force,etc. transducers
2xSPI headers--Thermocouple & other sensors or expanders

Optional: a few more uncommited GPIO?

With this controller, we should be able to control at least 6 toolheads:
-Extruder
-Paste dispenser
-Hot air wand
-Vacuum nozzle
-Laser profiler (scans an object from the top)
-Milling toolhead
-EDM toolhead

Are there any features I've missed? Other toolheads I haven't thought of?

Check here:

[dev.www.reprap.org]

Maybe you can find some more?

Annirak Wrote:
-------------------------------------------------------
> I'm building a toolhead controller for my extruder
> experiments



> 1xGPIO(commited)--Toolhead dock detect
> 4xGPIO(commited)--Dock ID


Annirak, et al,

It seems to me that you can do this with fewer GPI pins -- or have more dock IDs for the same Npins:

Determine the logic level when disconnected (probably 1, with pull-up resistors) and reserve all ones for undocked, then you have (2**Npins) - 1 combinations left for various docks.

Best regards,

---

Larry Pfeffer,

My blog about building repstrap Cerberus:
[repstrap-cerberus.blogspot.com]

For node ID's I usually use two MCU pins to give me 10 ids. Each pin of the MCU has a series resistor and a capacitor. I can detect whether it is tied high, tied low, floating or connected to the other pin. That gives 10 combinations. Three pins would give 37 I think.

---

[www.hydraraptor.blogspot.com]

Mr. Seeker Wrote:
-------------------------------------------------------
> Check here:
>
> [dev.www.reprap.org]
> Ideas
>
> Maybe you can find some more?

I think I actually covered more options than there are on that page, though with much more general terms.

An RS485 bus can be used for multiple devices. If you just leave that connected (via a flexible ribbon cable) you'd not have to worry about plugging and unplugging, which would both be easier and more reliable.

I.E. Have all toolheads plugged in to the RS485 bus AND power (and probably a sync line) at all times. When the toolhead is inactive (i.e. the switch on the toolhead informs the toolhead processor that it's docked, and not connected to the carriage) it would go into a low-communications mode, sending little or no information back to the central processor. This would avoid clogging the pipe, in order to allow the active toolhead maximum bandwidth for more precise control.

You'd only need three pins on the main processor to control ALL the toolheads - the RS485 bus takes 2, and the sync line is shared, as it's ignored unless the toolhead is both active and has a queued command to execute.

As for the pins/controls needed on the toolhead's processor, I think you've pretty much got it covered. I do question the need for multiple SPI headers, and for a dockID. Wait - maybe you're thinking that one "toolhead processor board" will control multiple toolheads? I was thinking that each toolhead would have its own processor. And the PWM, motor driver, temp sensor, etc. would be on the same board. The components wouldn't be populated for toolheads which don't use it, is all. Since the boards themselves are quite inexpensive, and it's the components on the boards which are most of the cost of the electronics.

---

--
I'm building it with Baling Wire

A few points:

I was planning on doing full duplex RS-485 so that the main controller never has to wait for a toolhead processor to release the bus.

The having multiple SPI headers is so that multiple sensors can be attached. It's one extra GPIO pin to add a second header, so why not?

I don't know if we need a dock ID. It just made sense to me that the toolhead processor be able to tell which dock it's in, and tell the main controller where to get it. Possibly not necessary, but could be useful.

I'm beginning to think that the 28-pin AVR's aren't going to have enough I/O. For the featureset that I've described, we've got a lot of pins:

6 (spi)
2 (I2C)
2 (PWM)
2 (Motor)
4 (RS485)
2 (ADC)
2 (Quadrature)
1 (Docked)
-----
21

For devices limited to 23 I/O pins, we're already pretty close to the limit, where features start overlapping with no option for dock ID's and extra GPIO. Particularly, I wanted to provide two GPIO per PWM for opto endstops on actuators, or quadrature feedback. We fall two pins short of that possibility, while using multiplexed-function dock ID.

With that in mind, I'll be designing this board with the ATMega164 in mind, though most of my testing will be done with ATMega162, since I already have some of those. This will just mean that analog functionality is disabled.

Edited 1 time(s). Last edit at 01/26/2009 07:17PM by Annirak.

I am thinking that I agree with John,
Why build a huge multi capability controller and shuffle lots of data back and forth when you can build small specialized boards that sit on the toolhead and pass minimal info to the main controller? The result is simpler, cheaper boards, fewer cables to get tangled and a modular system that is easy to expand/adapt. I would design the Cartesian bot/controller board to work with a minimal command set {docked/undocked, toolhead ID, ready/unready to print, start/stop printing, toolhead crash report), The toolhead would carry a board with a PIC chip which can interface with those commands and do such things as regulate extruder temp and monitor the amount of available material in the paste extruder (did you remember that?) as well as driving the motors, etc to do the actual printing. Such a board could also continuously monitor the tools likely failure modes and send a not ready when needed. The complex multi tool controller will also have to be programmed on the fly, perhaps hundreds of times per print, as to how to handle the info coming from the tools (is the info on channel 10 heat or pressure? what are the proper values and what to do with out of bounds values? With on board controllers each controller is programed once per print at most. If more commands are needed for new toolheads they can be added to a modular system later without disturbing the operation of existing toolheads. Remember that someday RepRap may have hundreds of different toolheads available for use. Do you want to be in charge of keeping that database up to date?
Also, I was talking to Zach at the HacDC Build-a-thon this weekend and he said that the Gen3 electronics, which are currently in the works, are going to distribute some processing out to the toolheads; for the reasons mentioned above.

Some other thoughts on possible comm needs:
direction of travel for tools which are directional like knives/scissors or tape applicators
I would include several motor channels as there are likely to be heads with multiple motors working at different speeds, such as a tool to mix epoxies or other multipart polymers or a color mixing head to print colored plastics to order.
Are you planning to test or monitor the toolhead for proper function? What data transfer would that involve? What about head crash or calibration?

My design is one controller per toolhead. It always has been.

The I/O are
6 (spi + 2 SS for MAX6675 + 1 spare slave select)
2 (I2C)
6 (2xPWM + 4 quadrature or endstop)
8 (2xMotor + 4 quadrature)
3 (RS485 TX/RX/TXEN)
4 (ADC)
1 (Docked)
-----
30

As of yet, the remaining two I/O pins are reserved for the second serial port as a debug port. I expect that to change as I develop the code.

Incidentally, I've worked out a way to get a SYNC line without using an extra pin:
Just disable the UART for a moment, and enable the pin-change interrupt. meanwhile, on the opposite side, disable the UART transmitter and flip the pin to sync.

Edited 1 time(s). Last edit at 01/27/2009 10:32AM by Annirak.

As of this morning, I have everything except the Docked signal and I2C laid out in schematics. I'll be trying to do the PCB in single layer to facilitate hobby prototyping methods. We'll see how that goes.

It's good to see someone getting into it... on the software management side, the micro (PIC/AVR/whatever) can store a little configuration string which identifies it to the main board and hence the control PC.

One comment I'd make, though: sharing a comms line with a synch line might cause trouble if your software does something weird - you could end up with your comms locked out. Would it be acceptable to simply send a reserved character to the UART as a synch pulse? The timing should still be pretty deterministic, and I wouldn't think a few microseconds of jitter while you check the character and error flags is going to be a massive problem.

Another note: I haven't tried it with RS485, but when I once tried using RS232 in an industrial environment I found that the parity check bit wasn't enough protection, nor was a standard 'add up all the bytes' checksum - I had to use a proper cyclic redundancy check (CRC) to protect the data. The avr-libc library that comes with WinAVR comes with some predefined libraries for this.

jbb

jbb,
I agree that a shared sync line could cause problems. My solution is a little simpler: Just run the RS-485 at 1Mbps (most transceivers go up to 5Mbps). You'll get very little jitter then.

RS-485 is designed for industrial environments with precisely this problem in mind. Because it is a differential signal, the majority of electrical noise is dropped because it is common to both halves of the signal, and the receiver's common mode rejection ratio is quite high.

Annirak

Here are the initial schematics for my toolhead controller. It's not ready to go to PCB yet. Consider this a request for comments.

Caveats:
1) Some of the bulk storage and decoupling caps are missing. That's purely because I missed them when I was exporting the schematics.
2) I see now that I've missed the I2C pullups.
3) No resistors have values set yet, and the MOSFET's are missing model numbers.
4) The pinouts for most connectors are definitely going to change
5) The designators will all be changed to flow well physically after I put everything onto PCB.
6) J4, 9, 3 are intended to be one single expansion connector, but the schematic looks better when they're seperated.

Looking pretty good!

I have a few suggestions, but feel free to ignore them - it's your project.

Power supply:
How about a power ON indicator?
Reverse polarity protection is a good thing - or are you using a polarised connector?
Maybe you should include a trusty old 78L05 on the board? Something people have been talking about on these forums is that a PC power supply can have poor voltage regulation at light load.

For the MOSFETS:
If you want to run the MOSFETs at high(ish) speeds you'll need either low gate charge logic-level FETs or a MOSFET driver chip (say the TC1427CPA for $1 US).
You'll also want to do something about inductive kickback - when you switch a MOSFET off, any current flowing through the inductance of the load (and there will be some) will cause a big voltage surge on the MOSFET drain pin, which can blow the device up. Either use an 'avalanche rated' MOSFET which can dissipate this energy, or a high speed power diode from the drain to VCC12, like one normally puts across a relay coil for just the same reason. It should be a high speed diode, though.

Chip Select lines:
If you're running out of I/O, you could use a bit of glue logic to get more bang for your I/O pins. A CD4028 binary to decimal decoder would let you address nine devices from four I/O pins, or 7 devices from three I/O pins (much more efficient), but the catch is that the outputs from the CD4028 would be active high and you want active low for most SPI chips. A CD4069 hex inverter chip would solve this problem too.

Good luck
jbb

i may be behind the curve here but my idea was because they tool head don't need an whole lot of information going back and forth, i mean they are mostly on off, and a sensor or 2, some might be more complex.

so my idea is to have each tool head have its own controller board and when its not being used to be off or have low power, that would save on energy for the whole machine. when each tool is not being used it doesn't need any talking between the main controller and tool head, as long as the main controller board knows witch tool its using.

so forget all this complex stuff management stuff and just say: Current tool move this servo that way and the other this way, and tell me what the temp and pressure are. Then put the tool in This Spot and Take the Tool from That spot and repeat.

This would also allow for a smaller amount of tool head slots on the RepRap and you can just have more tools to swap out for different jobs.

jbb,
I figured that the load would be enough to keep the PSU in regulation, but if that's going to be a problem then I will put in a regulator.

You're absolutely right about the FETs. The ones I have are for >100kHz switchers, so you know they're low gate charge . Good catch on the flyback diodes... Oops.

Nice idea on the decoder, but here's an even better part: 74hc154

Know of any good high-side FET drivers in DIP? I'd like to use N-Fets from the 12V rail rather than connecting them on the GND side.

Cheeswiz,
The toolhead controller is actually an I/O heavy portion of the design. Consider that measuring temperature is best done through SPI, which takes 3 pins, pressure sensing would likely be an analog input, but it might require a specialized ADC, so that would take another SPI port. Two PWM outputs, one with Tach feedback for a fan, A motor drive plus direction and two quadrature lines takes another 4 pins.

Now we're up to 12 I/O pins. I'm attempting to go a step further and make a very general controller board so that anyone can use it for any toolhead, typically with no expansion board, but with a very minor one if necessary. One other reason driving me to use a 40-pin micro is that the low pin-count micros tend to overlap too many peripherals, leaving me choosing between SPI and PWM for example.

Annirak,

im thinking of something a lot different, were everything the toolhead does is converted into a form that the controller board can understand. much like if you had a bunch of tools that were operated by a USB cable and they all plugged into the computer (controller board) and the computer only know how to use the tools based on the job you gave it and what slots the tools were plugged into.

So just put the Tools in the computer and tell it what job you want it to do and where each tool is placed and run.

Your Way on the other hand seems to be going well for you, as i understand it it basically needs only one big micro that does everything. Where as mine will have a micro for every tool witch will convert the data for the controller board.

To Each his own. Im just in the concept stage and not ready to build, but Yours seems to be going Really well so far, will have to keep up to date with it as it progresses. Keep up the Good Work.

Hi Annirak,

What do you want to put on the different tool heads ?
If you look over on the "Beyond the Sanguino" thread, I have further info on the board I'm working on.

I was thinking that the extruder could integrate an RGB+black+white mixer for coloured builds, and simply have each spool come in from an angle out from the vertical. So long as the pressure into the mixing zone doesn't allow back flows, then it could work...

And routing, if heads are to lift/lower independently, can be done with servos.
The board I'm designing can handle all that, I think, so long as geared motors are used for the extruder spool feeds.

Graham.

Hi Graham,
Maybe we should work together on this. I'll check out your thread and see where it's going.

Brendan

Annirak,
I missed your desired toolhead list at top.

That explains it.
I do think though, that rotary switch connections are a viable option, and then you could rotate the heads down, and lock them in place, all with servo motors.
Graham.

Annirak

To put the FETs on the high side seems fair enough, especially if you want to sense operating currents, but it makes things just a little more tricky. There are two approaches:

1) get an inverting gate drive chip (say the TC1426) and use a P channel FET. They have marginally higher on resistance and gate charge numbers, but with a 1A gate drive chip you'll have no trouble switching one.

2) get a fancy high-side MOSFET driver. These come in 2 flavours: a bootstrap type will generate its own +12V rail as the load switches on and off but CANNOT give you 100% duty cycle. A charge pump type will be a little more difficult to find and a maybe touch more expensive, but allows for 100% duty cycle.

My money would be on the P-Channel device - simple, easy to find and cheap.

Also, you're dead right about the 74HC154 chip - it's a much better bet for expanding SPI address lines than the 4028.

A final thought: put a couple of header pins down for the PWMA and PWMB lines - makes debugging much much easier.