LitePlacer.com forums

Because shipping and tax makes the TinyG controller expensive in Germany (around USD 200) I started to build my own. I used this design as basis for my board.
http://dangerousprototypes.com/2013/04/ ... r-for-cnc/

Because I wanted to use my own stepper driver I erased all needless components and ended up with a simple one layer mill out design:
It is more or less only the ATxmega192A3 (USD 8), the oscillator and the end stop pull ups plus a 5 to 3.3 Volt supply. All pins are routed to terminals. With this I get the maximum flexibility for my tests. Main Issue to get this to run was my AVR Dragon programmer. After two days of wondering why the PDI programming did not work I found a little hint in an AVR manual that you can not program this ATxmega192A3 with the Dragon and PDI. Using JTAG instead worked perfect and I could program the boot loader xboot.hex and the tinyG code tinyg-master-440.18.hex from the original TinyG web page.

Till now I did a test setup with a RepRap RAMPS 1.4 stepper driver shield out of my shelf and some end stops - in the moment it works perfect with my self made TinyG. Later I will use the ordinary black box steper driver from ebay with some powerfull motors. Because I did not have a USB to serial adapter at hands I used the FTDI driver from an Arduino Uno by removing the Atmel Chip.

I will keep you updated
Rainer

Nice work, Rainer.

With your approach one can use all the extra I/O ports on the chip that are just unconnected on the TinyG.

I am looking forward to seeing this put to action

This is probably a bit crazy, but could a "distributed" TinyG be mounted on the back of each of the four stepper motors?

The idea is to have four separate boards each with one super-low-end atmel chips (they are only $0.50 for low-pin-count QFN) and one stepper driver, on a small PCB mounted to the back of each stepper motor.

The goal is to reduce wiring: then you only have four wires (+24V, GND, data-in, data-out) running through the dragchains. The data links are chained JTAG-style.

You still have a fifth Atmel chip driving the whole thing, but it just sends commands along the digital data-wire to the other four chips; those are the ones that issue commands to the stepper drivers, which actually step the motors.

The data link could also carry feedback from the limit switches, but it would have to be fail-safe: constantly actively transmitting a "no limit switch hit yet" message every few milliseconds, and every motor-control chip knows that if that signal isn't received (for any reason) it should cut power immediately.

This would reduce the wire-bundle from 16 high-current wires and ~14 low-current wires to only two high-current and two low-current (this doesn't include the downlooking camera's USB cable).

I'm sure this is stupid for some reason, please tell me the reason

I would not like to change the TinyG software to realize such a bus system because I would like to use all TinyG software improvements in the future without any trouble. On other hand it would be stupid to collect all the data at the output of the TinyG controller for sending it though your chained system.

Rainer

The axes need to know about each other. Even a simple XY move needs to be synchronized to be smooth. With a distributed system it would be difficult to draw a circle, for example.

@ wayoutwest:

If you take a closer look into TinyG, what makes it so much better than other stepper driver boards is the control strategy which kind of "looks into the future" that is into a buffered set of XYZA movements and tries to control the involved axes at their best. That only works in one memory space. And you need at least 4 wires to connect to each distributed stepper driver.

Why spend so much effort on reinventing the wheel ?

Please believe me building a bus driven distributed solution in a dirty EMC environment you need to use insensitive communications like CAN or RS432. Forget I2C or SPI on the distances. I sold a distributed digital model railroad control system and there you also have dirty wires with induced spike etc.

I would suggest to put more effort in accessory type things for Liteplacer like feeders, Tape holders, Nozzle changer, maybe even solder dispensers.

Just my 5 cents...

JuKu wrote: The axes need to know about each other. Even a simple XY move needs to be synchronized to be smooth. With a distributed system it would be difficult to draw a circle, for example.

Yes, they would know about each other and be synchronized. Sorry, I must not have explained very well.

Think of it this way: 95% of the TinyG software remains the same, but instead of the "big" Atmel manipulating the stepper-driver-chip-pins directly, it instead sends a digital request to the appropriate one of the four "little" Atmels asking it to do this. If necessary, a timestamp can be included with the command ("do this at a specific time").

It's simply a way of multiplexing what are currently sixteen noisy high-current-motor-drive wires into two high-current-power-supply-wires and two low-current digital signaling wires.


And those remaining two high-current-power-supply wires would be much less noisy than motor-control wires: you can add decaps to reduce the di/dt of a power supply wire, but you can't do that to a motor-drive wire since those *need* the high di/dt. This means that the wires can be cheaper, possibly even unshielded (not 100% sure there).

mawa wrote: And you need at least 4 wires to connect to each distributed stepper driver.

Yes of course. But in my proposal those 4 wires are about 2cm long instead of running the entire length of the dragchain. They also don't run parallel to any other wires, which is the main source of noise issues.

mawa wrote: Please believe me building a bus driven distributed solution in a dirty EMC environment you need to use insensitive communications like CAN or RS432.

Then why is the LitePlacer currently able to run a 480mbit/sec downcam USB connection through the exact same dragchain? Clearly sending high-speed data through the dragchain is not an obstacle; all of us are already doing it. However it may be necessary to run a separate quiet digital power supply (as the downcam currently does), which would bring the wire count up to 2+4=6.

> Think of it this way: 95% of the TinyG software remains the same, but instead of the "big" Atmel manipulating the stepper-driver-chip-pins directly, it instead sends a digital request to the appropriate one of the four "little" Atmels asking it to do this. If necessary, a timestamp can be included with the command ("do this at a specific time").

Yes, I don't think why this wouldn't work. [ So many things in the world is not done the optimal way because "this is how it is always done" or "it was done this way first, nobody has yet redone it". ]

I went further with my tests. The NEMA 23 Stepper motors with it's driver black boxes arrived. The Step, Dir and Enable opto couplers are designed for 5 Volt but have no problem to be driven by the TinyG 3.3 Volt. This would open the opportunity to all owners of a mill and such stepper drivers to convert a xyz mill to a p&p machine. But I agree with JuKu that you have build/bought the mill for some other reason . In the forground: hollow shaft NEMA 8 for direct driven A axis powered by a Pololu A4988
Now I am waiting for the belts to arrive from China. In general JuKu's ready to build kit will save a lot of time!

Rainer

WayOutWest wrote:This is probably a bit crazy, but could a "distributed" TinyG be mounted on the back of each of the four stepper motors?

Turns out it can:

https://hackaday.com/2016/06/01/mechaduino-closed-loop-stepper-servos-for-everyone/
This does a lot more than just "distributed TinyG on back of motor" -- you get an encoder and programmable (hackable!) response loop too, so the motors are really being operated like servos rather than steppers. They claim 0.1-degree resolution even on 200-step-per-revolution motors, which would solve the "no hollow-shaft 0.9 degree motors available to the public" problem.

I'm told there will be a kickstarter in a week or two. I don't usually go for those (too many scams) but in this case they've already got a prototype that's good enough that I'd pay for it, so worst case it doesn't get any better and I'm still happy with the results.