UK PCB sources?

I'm looking for a convenient source for the various control board pcbs. It is safe to assume that I don't have the facilities to print or carve them myself, though I'm happy to find and nail the components in afterwards.

I'm UK based, so ideally somewhere in the UK would be best, but does such a place exist? Or would it be better just to order the complete set of boards from RRRF?

well, i would love you to order from the RRRF. every order we get helps out tremendously and will go towards improving the RepRap project in general.

Perhaps what needs to happen is for Ian to bulk stock some of Zach's boards in UK.

I had shipped some stuff to Adrian and Ed from time to time and assumed that shipping to the UK was fast and efficient. Nophead painted me a very different picture recently, however. Apparently, it can take a month or more for shipments from the US to get to ordinary people, as opposed to institutions, in the UK.

I'm a patient guy, so I'll cope with long delivery lead times. I was thinking more of the shipping costs, which tend to be rather uneconomical for small orders.

Obviously the ideal thing would be to do a bulk order, but I'm all to aware of the challenges involved in arranging enough people to make it worthwhile. Bitsfrombytes would be the sensible place to arrange such things... I'n fact, I see a comment in the [www.rrrf.org] blog suggesting this is going to happen 'soon'.

When I say patient... more specifically when I *know* something is coming I'm happy to wait for it. But when something may or may not be available in the near future, then maybe I won't wait in hope

Hi I'm working on an electronics solution at present it will be Arduino based but will be single sided to allow home build if required I've already done a first prototype and will be routing the MK2 tomorrow if all OK I'll be ordering some professional ones for stock, this is my main development priority at present. The board can also be driven directly from a parallel port allowing simple use of the free CNC programs available like MACH 3 and Turbo CNC etc.

Mk1 is working fine just adding LEDs more sensible connectors etc.

This a versatile 3 channel board using SLA7062M stepper driver chips good for 3A drive (fully adjustable) micro stepping from 1/2 to 1/16 steps, voltage input 12v to 36v on board regulation of 5v @ 1.5A and 12v @ 3A for other circuits (extruder etc).

I will post full schematics and Gerbers etc as soon as i have finalised and tested the boards.

---

Ian
[www.bitsfrombytes.com]

the SLA7062M says its for driving unipolar steppers... is it possible to drive bipolar ones as well, or will people have to re-wire?

Yes it will be wired differently but all the motors you or I supply will work fine any motor with 5 or more wires is OK.

I might follow it with a Bipolar driver just these are really nice chips and most decent bipolar stuff is surface mount (it's all going that way!) although there are some nice through hole options.

---

Ian
[www.bitsfrombytes.com]

I've been playing around with the SLA7052's and I have to say, they're very nice...

Edited 1 time(s). Last edit at 02/27/2008 05:10AM by TheFallen.

check out this stepper driver: [avrstmd.com]

i want to buy one and build it. i have a feeling something like this could be a very nice addition to our arsenal. it has lots of potential.. especially if we update it to the atmega168 and make it compatible with arduino.

LOL! You like that one, too, huh?

Is that not a backward step you are making a uC drive a H bridge (albeit a good one) I don't think the Arduino could do that for a three off channels and 1 for each channel is very expensive, that is the thing I like most about the Arduino is the ability to use dedicated stepper driver chips which cost the same as an H bridge but does exactly what you need.

---

Ian
[www.bitsfrombytes.com]

its not really a backwards step. let me break it down:

the L297 costs $10. the atmega168 costs $5. of course, the drivers cost more, but you could also theoretically still use L298s. i'd rather go with these h-bridges for various reasons, but i will stay on topic.

the benefits of using a reprogrammable microcontroller based stepper driver are huge:

* microstepping. - up to 16 steps!
* you could build in support for limit switches and rotary encoders
* you could customize the interface: i2c, serial, step/dir... whatever you want!

you could simply use this board in place of the current stepper drivers, no change... just a drop in replacement.

of course i could think of a bunch of different things i'd like to try with these.

1. create some sort of i2c/serial/shift register interface to tell it to step x steps at y frequency. the main reason would be that the biggest problem with the current centralized arduino is that it acts as both the host that receives commands, as well as sends the individual step signals. the problem with this is that it gets extremely complicated to send two different speed of stepping signals. a prime candidate i can see for this is if we wanted to create a stepper based extruder and wanted it to extrude at a precise rate. it would be relatively easy for the 'master arduino' to tell it the speed to move.

now, to head off the inevitable 'wasnt the universal controller based on a uC + dual h bridge'. the answer is yes, but the problem is deeper than that.

1. the pic16f648 is underpowered for the job.
2. the pic doesnt have analog inputs (no current sensing, or other fun stuff!)
3. the pic doesnt have i2c
4. the universal controllers were based on a token ring... no nice, easy central control board.
5. the pic has very poor open source support (sdcc) whereas the avr line has great support (avr-gcc, avrdude, arduino)

both routes (smart master, dumb slaves) and (smart peers) have relative merits. changing it to a system with smart masters and smart slaves is even better.

of course i'm not advocating a switch just yet... after all the arduino stuff just got finished. however, i can see a need in the future to revisit this topic and perhaps make some changes.

I guess it'd be like a more accurate version of the L297/L298 combo, an upgrade for more complicated models/versions of rep-rap.

See the joy of reprap is that it almost makes hardware like software, self-updating. You don't have to start from scratch, you can simply upgrade the old files/parts with new parts.

In this case, the old standard stepper motor drivers are replaced with ones that are able to monitor their own condition, where they are, their speed, have they finished the last sent job, are the motors getting tired/old (like the SMART monitoring system in hard disk drives) and so forth.

If we agree on a common standard for the message protocol between boards and smart boards, it could be quite simple to swap boards out with new ones once you have the resources.

Personally I'd equip all core boards, the main interface with the PC, with a jumper, select whether to have basic or smart communication. Basic would be step and direction, where as smart would be something like an RS232 link to each stepper motor board and extruder board.

That brings me to another point, I can't actually find if the data protocol for passing commands to the core board is documented. If anyone knows where I wouldn't mind a link. Thanks.

---

[thefallenindustries.wordpress.com]

Zach,

>the problem with this is that it gets extremely complicated to send two different speed of stepping signals.

No its trivial, I do all three axes simultaneously with the same code, I will send you it when I get home.

You just run an interrupt timer at the rate of the fastest axis and use Brezenaham to decide when the other axes step.

---

[www.hydraraptor.blogspot.com]

Nophead,

Zach has already implemented Bresenham. I think he wants to run all steppers at a different rate, but with properly spaces signals. Not sure what that will add though. The easiest way of doing that is priority queuing your interrupts ahead of time (with the priority equal to the time you need the interrupt). Then when the first interrupt happens, it gets the next highest priority item of the queue and resets the timer. You can keep pretty small queues because each axis can reschedule after it is serviced, leaving you with 3 (or 4 with the extruder) items in the queue.

--Blerik

If you do it that way you are limited by the timer resolution. I.e. each rate has to be a multiple of the timer tick. That means you cannot get lines with exactly the right gradient leading to significant errors at the end points.

Brezenham gets exactly the right number of steps on each axis so the end point is exactly right. Of course the line is aliased but in practice the mass of the mechanics smooths it all out if you are moving at more than a snail's pace.

---

[www.hydraraptor.blogspot.com]

Nophead,

You can still use bresenham to control your intervals, you just have finer control over your intervals. And the only gain over using a high resolution bresenham with thresholds is that you have less interrupts. Hmmm. A threshold scheme on bresenham is much easier to build, so forget about the priority queues. The average microcontroller is fast enough anyways.

You cannot fix the aliasing of the lines with this, because the steppers still have a minimum step. The only gain is sometimes stepping in between the other steppers instead of always in sync. But this adds artifacts to the line because you cannot go at 45deg anymore, just horizontal and vertical. So you get more resolution to work with, but it doesn't make the motion smoother.

This is really a pain because it means you cannot run the bresenham at a constant high speed, and run all the steppers (including the extruder) from it. I finally understand what Zach means now. Either you include the extruder in your bresenham dda moves with each command you process, or you get into trouble trying to keep both the steppers and the extruder running at their own speeds.

--Blerik

Why not have one microcontroller run the 3 axis with another to run the printing side of things that way it's very unlikely you will ever need to update the 3 axis stuff. Basically the 2 Arduino option. Knowing how complex the current slice & dice is then the thought of having more axis is unthinkable at this point. The cost of uC means you can easily have one per print/extruder used on the machine.

---

Ian
[www.bitsfrombytes.com]

Blerik,
I run my extruder at a constant speed and calculate the Bresenham timer value for each line. My timers run fast enough to make the errors in rate matching minute. Even a few percent would make no difference because the variation in feed stock diameter would dwarf that.

When milling the feed rate is even less critical so I can't see any reason not to use the simplest Bresenham plus single timer algorithm. Any aliasing is less than one step so does not affect resolution and gets antialiased anyway by the inertia in the system. For FDM the filament diameter is much bigger than the step size so you would never see the aliasing as it has a minimum bend radius.

So I cannot see Zach's reason for wanting a micro per axis to make timing issues easier.

---

[www.hydraraptor.blogspot.com]

Nophead,

Fair enough. I was just thinking out loud anyway. And I think I just reasoned for not having a micro per axis: you need very good sync between the micros, otherwise you lose the diagonal smoothing you get with steppers running in lockstep.

--Blerik

the reason for a micro on each one isnt to solve the 3-axis dda Bresenham stuff. like nophead said, thats already solved. infact, thats how both the arduino does it. that stuff works great, and if you want to print stuff now, its easy!

however, what happens when you want to step outside that nice little box?

what if you want to do a polar printer where the bed is at a constant rotation, the R at a different speed, and the Z at another one?

what happens if you want to have a syringe based extruder using a stepper where you can calculate the steps per cc of material and want a target flow rate?

what happens when you want to use a quadrature encoder on 3 axes and you only have 2 edge-trigger interrupts on your arduino?

here's what i'm saying: the current way we're doing things works great, but its by no means perfect. the arduino was a step in the right direction and it does indeed work better than it was before. however, there are ways out there that we should put in our brains and consider for when it comes time to make the 3rd generation of electronics.

All those things are easily done with a single micro of moderate power. It's always cheaper and much easier to do things with one more powerful micro than it is to use several small ones.

I think the optimum topology is as I have done: a mid range micro to do comms to the host, control all the axes and the comms to slaves for head/tool controllers which can be tiny micros, but I would say than wouldn't I

The micro I use runs at 25MHz, has four timers and can have edge triggered interrupts on many pins. It easily drives three steppers, Ethernet, I2C and reads two shaft encoders. Another encoder would be no problem and it has analogue inputs so it could do the extruder I/O as well.

The STM32 ARM micro I recommended a while ago is cheaper and even more suitable for general use because it has USB. It has three or four timers, each of which can do four channel PWM so micro stepping steppers is no problem. Likewise PWM control of DC servos or even commutating brushless servos would not tax it.

---

[www.hydraraptor.blogspot.com]

interesting.

are there any of those mid-high level boards available as DIP?
what about open source development tools?
finally, does anyone have experience with smaller, single board computers? i was reading an article on that and they seem pretty rad as well.

Not much modern electronics in DIP now. A lot of micros have an evaluation board which breaks out the I/O though.

Many micros like STM32 are based on the ARM core these days. That has good gcc support I believe.

I am not clear exactly what the project philosophy is on OS. The PICs got abandoned because the open source C compiler is crap but Microchip give you a free (as in beer) compiler which is quite good and has a simulator and a debugger. In fact most micros have a free but code size limited development environment, much better than Arduino where you don't seem to have a debugger. These seem to be ruled out of the project because they are not open source but you are happy to use Eagle for PCBs. Also we use hardware like Atmegas and stepper controllers which are closed IP. You have to draw the line somewhere.

Personally I am happy to use anything which I don't have to pay for. The amount of code I am using on my project is so small that I can get by with the free limited versions of the dev kits.

Mind you I don't have anything as high level a G code parser on my hardware. I simply do the real time control there, use the simplest protocol that guarantees delivery with commands parameters in the native units of the slave. All the unit translation is done on the PC and I will parse G code there as well.

Any work which doesn't require real time should be left to the host as it much easier to develop on a PC and it has at least 2 orders of magnitude more processing power.

---

[www.hydraraptor.blogspot.com]

Just for the record, the hated firm Microsoft is handing out Visual Basic .NET 2008 Express for free. All of the Tommelise PC-side code, including the USB modules can be compiled and run on Express.

I'm of the opinion that open source is rather more important for software than hardware for this sort of project; at least the core bits of software that actually make a replicator go.

Without the ability to see and freely modify the source of the firmware or host software, improvement will be tricky. Use of less-than-free licenses (such as non-commercial, see cam.py for example) I guess would be possible, but limits long term usefulness.

For hardware though, the barrier to modifying and creating your ow microcontrollers is slightly higher

Closed IP hardware isn't exactly ideal, but on the other hand if the bits are cheap and widely available that will have to do. With a suitably dumb replicator, replacing one set of control boards with another shouldn't be excessively difficult due to simple interfaces. Replacing a complex controller with a more powerful microprocessor on the other hand could be more tricky.

Quote

Mind you I don't have anything as high level a G code parser on my hardware. I simply do the real time control there, use the simplest protocol that guarantees delivery with commands parameters in the native units of the slave. All the unit translation is done on the PC and I will parse G code there as well.

Any work which doesn't require real time should be left to the host as it much easier to develop on a PC and it has at least 2 orders of magnitude more processing power.

When you have an intermediate format (such as gcode) which can be created in many ways on whatever platform, and a tool smart enough to understand it, you need only a very small and simple driver to talk to the tool. This lets you access the tool from a whole range of plaforms and more importantly use different tools from the same platform without needing a dozen new complicated host programs to be installed... consider something like printers and postscript, perhaps (and postscript is waaaaaaay more complex than gcode).

(please try to ignore the trend in windows printer drivers towards bloat and unneeded functionality!)

Edited 1 time(s). Last edit at 02/29/2008 04:05AM by Ru.

Compare the two approaches:-

1) A simple host that interprets GCode, converts it to machine specific units and sends it to the slave with a secure protocol. The slave does the Bresenham stepping.

2) Something that sends the GCode to the slave with a secure protocol, the slave parses the GCode, converts the units and does the Bresenham stepping.

Exactly the same amount of s/w complexity and same flexibility but 1 has more s/w on the powerful PC and less on the slave which is has limited resources and is harder to program and debug. 1 also will work fine with the PIC distributed electronics but 2 can only be done a more powerful single controller.

---

[www.hydraraptor.blogspot.com]