CANopen has a SYNC message which allows devices such as motors to be synchronized across the CAN bus. This is used in commercial drives, such as those offered by Elmo.

Andy

To elaborate on my last post to show how easy syncing on the CAN bus is...

1. The master transmits one or more CAN messages containing the next x, y, z position. They can be combined in a single message or split into seperate messages (for more flexibility).

2. The axis nodes receive the position data and store it but do not act on it.

3. The master transmits a SYNC message, which does not contain any data.

4. When the axis nodes receive the SYNC message they act on the previously received position data.

Why does this work? For several reasons:

- each CAN message is a broadcast, so a single SYNC message goes to all nodes at once

- if the SYNC message is successfully transmitted then it is guaranteed that all nodes received it, and within one bit time of each other

- any synchronization delay is only caused by the interrupt latency and application latency of each node. If all the axis nodes have the same firmware then the latencies are further reduced

As you can see, it's very simple and easy to implement and can provide a high degree of synchronization. The SYNC message is typically transmitted periodically, but it doesn't have to be.

Andy

How does CAN handle retries if messages are corrupted? I can see how you can sync on a serial bus if all messages get through but what if one node misses a message?

I haven't used CAN but I have used RS485 networks with my own protocols. Normal messages have acknowledges and broadcasts don't for obvious reasons. The way I do synchronisation is to broadcast time packets which each node locks onto with a software PLL so they all have a common time reference. I can then send messages to each node telling them to do something at a future time. That has to be long enough in the future to allow for errors and retransmissions. Does CAN have a better way of doing it?

As I said before you can sync over a bus but it is difficult. Why make things hard for ourselves? The axes need close synchronisation, why not drive them from the same micro? I figure a micro powerful enough to do USB and CAN can easily do three motors as well so you get it for free,

One could argue a case for a separate CAN node to control all three axis so that it could be replaced by a servo version. Also people could use two to make a six axis machine if they wanted. But then you would have a board which was just a USB to CAN protocol converter. Most micros that could do that would be left with lots of spare pins.

Edited 1 time(s). Last edit at 09/29/2007 05:24PM by nophead.

---

[www.hydraraptor.blogspot.com]

IIRC, in CAN, you count your ACKs to the transmission since all CAN communication is broadcast, it depends on the reciever to filter the messages to see if they're appropriate for the node. In most integrated solutions, this filtering is fully automated. THAT is the primary advantage of CAN. A disadvantage is that it was made for engine work. It's meant to be fast and deterministic. It only has a max payload of 8 bytes of information, so some software partitioning is needed for more information.

Depending on how "smart" your drive electronics is, several axes should be fine. I know that modern motion controllers (aka Delta Tau PMAC) run at 40MHz through a 24 bit Motorola DSP and can control 8 axes of motion (analog out, so almost the same as running a DC motor) with plenty of extra horsepower for IO/PLC and communications. A 30 or 40MIPs dsPIC or 40-60MIPs ARM should have no real issue running four axes and extra control capabilities.

The big horses come in when you're trying to do non-commutated motor control (AC, brushless DC, permanent magnet AC). To do the phasing and servo control equations for one motor, you'll need most of the horsepower of one of the more advanced processors.

My personal preference is to use a dual processor access card base system. One side has the USB processor and perhaps data storage (SD card, USB storage), and is fully isolated from the CAN processor/core motion controller on the other side. I'd also put on the motion controller side at least the headers to allow for the addition of an RS485 and the current token ring style comm system, so that other hardware can be brought under control that wasn't part of the development cycle.

thanks for your input, but i think i'll stick to straight USB comms.

i think adding a CAN/Token/etc network is adding alot of extra complexity. its super easy to open a serial connection to the port and send the commands directly. the USB -> arduino stuff is thoroughly tested and it JUST WORKS. i'd rather not have to re-invent that particular wheel. also, doing error checking and such on the Java host is much easier than trying to put that in the firmware.

since these boards are all modular, technically if you have a board that has enough i/o pins then you could do it all on one board. personally, i have no problem using 2 USB cables, one to the axes controller, and one to the extruder(s) controller. eventually i think the Arduino will have a larger board using the ATmega32 chip. that would really rock.

since its just a project i'm doing because i feel like it, i dont have to worry about people who only want 1 USB cable. i have no problem with it. if there are other people who don't mind as well, and would like to use my design, then even better. all i know is that i want a reprap machine that is easy to make, easy to hack, and easy to operate. if that means an extra USB cable, then so be it. i'd rather do that than have to make a serial cable between boards and program that in C.

who knows. perhaps this little experiment will fail, perhaps not. but i know that i'm having a blast, and i'm making real progress as well as learning tons about the various components of a system. at the end of the day, thats what this is all about.

So it looks like there is no consensus on hardware system design at all. People cannot agree on processors, serial buses, stepper drivers, mosfets or Darlingtons, connectors or cables. There are as many variants as there are people on the project able to design electronics and then some.

I think I will bow out of these debates as I already have all my hardware and firmware up and working well, and in a reasonably short time. I will concentrate my efforts on room temperature FDM which is really where the unknowns are as far as I am concerned. How to control motors and heaters with electronics was solved long ago and is not hard. There are infinitely many ways to do it so everybody can have their own design if they want. I feel sorry for people who are not interested in electronics who must find this lack of consensus bewildering.

I will leave you to find out how good USB is at synchonising multiple motors.

---

[www.hydraraptor.blogspot.com]

Not a bad idea nophead. I'll be doing the same myself after this post (probably).

I have a different method to my madness than the normal RepRap group. I know Forrest has migrated to a single PIC18F processor. I'm aiming for what may be the start of an open source generic machine controller someday. I've seen several start off as a "cool project" on the CNCzone boards but they've always disappeared or went commercial. I know my wishes are not through hole compatible, so I try to keep out of the general electronics direction threads.

My major concern with the Arduino is mostly because I'm not certain what its performance is. I'd have to look into the compiler to see if it actually compiles or if its an interpreted language and how efficient it is.

I'd still stick with a standard serial connection instead of USB for the heads. Might even be simple to use the current extruder/controller cards then if the protocol isn't TOO bad. There's just so little backwards compatibility in most of the ideas and I'm afraid that some early adopters may get left in the dust so early in the game.

Edited 1 time(s). Last edit at 09/29/2007 09:03PM by SOI Sentinel.

Well said Nophead. Pick a path of action and stick with it. Stop leading people down a path of dispair. Stop selling crap in the RRRF that has no future application.

Kevin Wrote:
-------------------------------------------------------
>
> Stop selling crap in the RRRF that has no
> future application.

Just because you, Kevin, in particular don't have a use for some of what the foundation is selling doesn't make it crap.

Edited 1 time(s). Last edit at 09/29/2007 11:36PM by Forrest Higgs.

OK, TIME OUT. Much of the work being done is for a future upgrade to the RepRap system. Yes, some of us are going different directions, but we're also trying to get this right.

nophead and I do NOT have the idea of a pure reprap. It's gotta be robust, and those parts it does not make itself must be easy to work with. It's meant to do additive parts production.

Zach and the main dev team is trying all sorts of different ways to stay within the spirit of the RepRap. There will be false starts. Any project of a major undertaking will have dead ends they find. Sometimes you have to go down the path a bit before you find it. Now, while many of us do not think that the serial comm token ring system of the current stable design is great, it WORKS. Research runs into dead ends, explores the possibilities. If you don't rethink what you're doing, you'll never learn.

The Arduino will be similar, and has more support in a community. This will help with design and programming support, but it still needs the shields and other boards to make it all work. Zach may find that it doesn't work as well as he hoped, but he will find that out. He's not dragging the entire project that way yet. It still matches the ideals of RepRap being an open source project with open source hardware and open source software.

Think about it, RepRap is really about the extruder technology. It's about making the specialized software that drives the machine in the right patterns and right controls. The electronics and cartesian robot are necessary but are not the main goal or hurdle of the project. That is truly why RepStraps are still RepRaps. The core is the same, just sometimes the mechanics vary a bit.

Edited 1 time(s). Last edit at 09/30/2007 12:47AM by SOI Sentinel.

Each CAN frame has an acknowlege slot, where all nodes much ack the message. If a single node did not receive the frame properly then it converts the message into an error frame and all nodes junk it. The transmitting CAN controller then automatically retries. This is all automatically handled in hardware and is no firmware needs to be written to handle it. So syncing with CAN is pretty simple.

I have some general questions however...

Is there a formal specification somewhere with the requirements for the electronics (for example timing)? I have searched the site and didn't see one. Having that information would allow someone to work out in advance if a specific microcontroller using a specific crystal frequency would be able to handle the job, without wasting time giving it a try.

Why doesn't Dr. Bowyer enlist the help of the Eletronic Engineering department at the University of Bath for this part of the project? I'm sure there are a lot of talented people there who can have this section of the project wrapped up very quickly.

Andy

Sounds like CAN is the most appropriate bus for this project then. It is electrically suited because it is differential which is important when you can't separate ground currents, and the protocol sounds ideal for synchronising multiple motors. Not surprising as that is exactly what it is designed for!

---

[www.hydraraptor.blogspot.com]

I'm still unsure what is the problem with the existing electronics. Today on the blog Vik has a minimug and is starting to attempt to replicate Darwin parts. Seems like the electronics are working ok to me.

Andy

I wonder if the problem is so much with the electronics as with the descriptions of how to put them together. In my experience documentation is far more often at fault than hardware.

I haven't gotten one completely right from memory yet, but...

IIRC, the first thing that doesn't always work is getting the serial chain to sync. This is usually a problem seen during checkout of the boards.

Second, there's often a small delay in transmitting a move around the ring, causing delays and possible "bloat points" in the extrusion. That is probably the biggest reason to investigate condensing the system down to one motion control board.

Third, the current code is not dynamic, so you have to recompile to change, say, token ring address. I think they're pretty much out of space in the RAM of the current chips, too. This will have an adverse effect if any upgrades that may be dreamed up.

These weigh in versus the good points of the system. The boards are all identical, so it reduces part count and makes it easy to replace failed boards. The system is fairly expandable, as it takes another connector and a recompile to add on a second extruder (check the main blog from a month or two ago?). They're using lowest common denominator parts, so it's likely you can walk down to your local electronics part supplier and they'll have them on the shelves (might be a bit dusty, though).

...

For a reprap-centric design, I personally think Forrest and Zach are going down the same spiritual path right now. Slightly higher component cost per part, but better performance and lower part count overall helping to reduce the total cost of the system. few external connectors, which helps to reduce wiring woes. Forrest has a leg up in both time spent on it so far (it's already working) and hardware compatibility (he can steal code directly as its the same family). Zach's open source support of his platform may make software support down the road easier, and also make it more accessible to the mod community at large if Wiring is what it's claiming to be (I've not even looked at it).

... what's the trouble with direct driving all motors from one controller without hanging on syncing different driver-boards?

When i first build a pen-plotter with steppers, i used a 6502-EMUF (german short for Single-micro-processor-board with universal-fixed-programming ) and a lot of discrete transistors, so the main advantage was to have many I/O-pins ...

The next run was then with a PIC-controller as a 'dumb' Interface from PC-parallel-port to some IMT901-drivers with only 2 Pins per motor (DIR and CLOCK).

So for every motor you need 2 I/O-pins (makes 6 for the motors and 2 for the extruder), some extra for driving peripheries (e.g. solenoids or PWM) and maybe one or two 10-bit-AD-inputs.

I have some eval-boards for basic-stamps (C8051F330-cores with wireless communication [www.hst-elektronik.de] ) with 10-bit-AD/DA, I/O and SPI or I2C ready.

For all three motors and the extruder it's a bit low with I/O-pins, but two can handle them all and much more.

With an extra SPI- or I2C-port-driver i can handle all pins of the stepper-modules with only one of them, so my primary aim is to put my fingers on a software for my PC, which converts STL-data into the right slices and motor-movement for my low-mechanic-tripod-system ...

Viktor

CAN is a very robust comms solution but for DIY use it can be difficult to de-bug rs232/485 can be read easily with hyper-terminal etc, but i agree just use one controller which can easily handle four tasks and many more! then there is no sync issue if the Arduino has enough outputs it will at least satisfy this. using dedicated stepper driver chips means only 2 pins per axis + extruder

Just looked at the Arduino in more detail it looks to have enough I/O to run everything not sure now good the complier is so can't say if 20MHz is enough but i would expect it to be.

Zach in an earlier post you say not enough pins can you expand as to me the 168 has more than enough total 23 I/O and after being a little negative towards it the core chip certainly looks capable and it is cheap and available globally.

Not to sure how the RepRap currently sends commands to the PIC but if done in packets which the Arduino then carries out should be no issue with real time.

Ian

Hey guys,

Thanks for the input, and sorry about this turning into a bit of a debate.

There's alot to touch on here, but I would like to address one thing, which is Nopheads assertion that these problems have all been solved before. That may be true, but in my opinion they have not been solved properly.

Take programming the board for example. Currently, this consists of:

1. writing code for PIC. struggling with defines, banksel, poor library support.
2. interfacing with the computer via a serial port or a special USB -> serial converter
3. compiling the source code to a hex file (which in and of itself is rather tricky, not to mention sdcc manages to mangle the code quite badly.)
4. removing the PIC chip to program / inserting the PIC into your programmer
5. programming the PIC in any number of poor quality and/or proprietary systems
6. removing the PIC from the programmer / inserting it into the board again (you can easily damage the chip here)

Compare that to the Arduino platform:

1. write C code in an open source cross-platform integrated environment with helpful programming libraries for micro controllers
2. compile / program mcu / verify in one easy step

That is a major problem I'm intending to solve with these boards. Also, by removing the microprocessor from them, they become much more modular. You can hook these up to any sort of microprocessor you want, and use them to do any number of things. Even if it doesn't end up helping the RepRap project itself, it can still benefit the Arduino community.

Anyway, I'm glad you're focusing on FDM. The sooner someone prints useful, usable parts, the sooner RepRap will really take off. The knowledge you gain and provide to the rest of us is invaluable.

Zach,

>Nopheads assertion that these problems have all been solved before

I didn't mean they had been solved before in RepRap, I meant that in the world of electronics: driving motors, heaters and real time serial networks are all well understood.

Reprap has made things unessarily hard for itself by not using an ADC to measure temperature, trying to synchronise motors over a low speed ring network, using Darlingtons with heatsinks instead of MOSFETs, using PICs not suited to running C, choosing a C compiler that is broken. Correct me if a I am wrong but as I understand it the work on Darwin is stalled because of delays caused by the serial comms.

I fully agree with a move to a platform with a working development system. That is exactly what I did but I was not constrained to open source. The dev kit for the little micros I use cost $20 which is as close to free as it needs to be for me (with the current

---

[www.hydraraptor.blogspot.com]

I think we're in agreement here. Those are all valid criticisms of the current state of our electronics.

Perhaps I haven't explained my Arduino idea properly. The Arduino is a general purpose microprocessor that is easily programmed and gives you easy access to 14 digital I/O pins, and 6 analog pins. Being cheap and open source is icing on the cake.

My original plan was to make a stepper controller board that would drive *three* stepper motors from *one* Arduino. It has more than enough pins for this. After I started, I realized that making one board with 3 duplicate circuits was redundant and asking for trouble. I then switched to making a stepper driver board that controls *one* stepper, which is much more modular and simpler.

So now, you would have *three* individual stepper driver boards that all hook into the same Arduino. There are no sync issues, because the steppers are all driven from the same microprocessor. The host simply sends a list of coordinates to move to, and it moves to them.

The extra arduino boards only come into play when you start adding extra extruders. It is probably possible to run a full reprap + one extruder from a single arduino. thats probably the route i'll take, but in order to do multiple print heads, at some point in time we'd either have to move to multiple-usb connection system, or to multiple arduino's with CAN.

There would be nothing stopping you from setting up an arduino to arduino network with whatever bus you like. once we have truly modular electronics based on a simple microprocessor setup, then it becomes very easy to change that software to do something like that.

Also, since we're removing the circuit from the micro controller, theoretically if someone comes up with a better circuit to control steppers that has the same interface, it would be trivial to switch to that better circuit.

Is it worth starting a new thread to pool all the ideas regarding the control system as i agree with nophead most of this has been solved and the true breakthrough engineering is multi material 3D printing/manufacture, there seems to be a number of competent electronics people active with RepRap and while everyone has a different opinion I'm sure with reasoned discussion a consensus would be reached such that this engineeringly trivial aspect of the project would be solved.

The starting point would be a specific design brief with regard future requirements like multiple extruder heads etc.

I'm very new to the project so don't want to rock the boat but equally don't want to see energy wasted on false starts when there is now a lot of experience within this community.

Hey Ian,

I wouldn't worry too much about rocking the boat. While we may get quite passionate at times, we're all solidly lashed to the deck

It would probably be a good idea to come up with some sort of documentation on the requirements of the electrical systems. I've started to do that off-line when I was looking over the current state of our electronics. This is also what led me to look at breaking apart the microcontroller aspect of the system from the driver circuits.

I started by working backwards from the mechanical systems to what is required to be driven with them. For example, lets look at the Cartesian Robot.

Requirements:

* 3 axes, one stepper motor each, and either 1 or 2 limit switches each (min/max).

So, you have essentially 2 types of boards there: a stepper driver board, and an opto switch board.

From a software point of view, the easiest way to drive a stepper motor is with 2 pins: step and direction. You could also add a 3rd pin for enable/disable.

For the limit detectors, they need one digital in pin each.

If we do it this way, then if we want to upgrade a stepper board, we just have to make sure that it is capable of implementing step/direction/enable, that essentially its pin-compatible.

Looking at the thermoplastic extruder, there are 4 major things it needs:

1. forward/reverse motor control
2. heater control
3. fan control
4. temperature reading

#1. is low power, and can be solved by a basic motor drive board. the one i've designed is based around the L293D and takes 2 inputs: direction and speed (PWM) I call it a DC Motor Drive Board.

#2 and #3 are basically the same: its essentially a PWM signal sent to a transistor. i've made and tested a generic board that has 3 PWM inputs/outputs and is based on the TIP120. i call it a PWM Driver Board.

#4 is pretty simple.. thermistor + resistor + analog input on your micro controller. you can wire it all up without a board even, and plug it directly into the Arduino. no board needed.

taking it a step further, look at the support extruder:

1. dc motor - dc motor controller board
2. solenoid - PWM driver board.

ideally, we can mix and match the various modular components to create the type of system we need.

The bottom line is no one is forced to stick with the electronics - the project can always be forked. The key part really is the extruder. It would be interesting to see what forks people might come up with.

My impression from looking at this project is that support for two print headers is a fundamental need - because it is required to get the machine to make it's own parts. Please correct me if I am wrong.

Andy

Hi Andy,

... you are right - for real 3D-printing you need a second extruder with support-material for overlapping and nonplanar geometries ...

But there are other ideas, beside of extruding plastics, for building 3D-objects, so there sould be forks not only in the use of electronics, but in every aspect too.

I throw in the discussion noncartesic mechanics with a very simple assembly, dotprinting and building 3D with laminated slices, cut by diode-lasers, and so on ...

Maybe we should separate the different concepts, but for me it's not essential, how my reprap/fabber works, more what's the output!

If i get my tripod-system working and have positive results with my laserdiode and selfmixed pastes from different materials, then it would be a reprap too, but capable of building with plastics, sintered glass, sand and metall or stacking of thin slices to sophisticated LOM-structures.

For me the absolute open structure of the reprap was the main argument, to stick here and not at fab@home, but that didn't mean, that reprap and fab@home are two incompatible ways - i think, there could be much more cooperation between, but the folks are split with a sort of ideology and map-locality

Viktor

I very much agree with your summary of what's required for the motor control and this could also control one of Victors Tripods etc and would be very unlikely to need changing i think some work on the USB comms would be worth doing as in

a)direct command move motor X 20 steps motor Y 50 steps (real time)

b)Packet of data move to X5mm Y2mm then X-10mm Y20mm etc etc (not real time) would need less sync but more memory, a bit like a glorified G code this could include extruder commands

With the Arduino being so cheap would be very easy to use one for the extruder control but getting its comms from the stepper Arduino this would be a very simple binary message: temp, extrude rate, fan rate, extruder head number (material)

This board would have various control algorithms for the different extruder materials and would soon become the only code that was being worked on, this also allows for a huge range of materials which will come with the multi-head RepRaps we will be seeing soon :-)

Summary: PC <-->(usb)<-->Arduino 1-->(direct)-->Stepper x3
*********: PC <-->(usb)<-->Arduion 1<-->(232, I2C, SPI)<-->Arduino 2<-->(direct)<-->Extruder

When i figure out up loading stuff I'll do a basic functional layout diagram with some baud rate calcs/ packet size etc if this would be helpful?

With clearly defined comms people can easily use their micro of choice if they want to yet still contribute to the whole directly

>
> Summary: PC <-->(usb)<-->Arduino
> 1-->(direct)-->Stepper x3
> *********: PC <-->(usb)<-->Arduion 1<-->(232, I2C,
> SPI)<-->Arduino 2<-->(direct)<-->Extruder
>
> When i figure out up loading stuff I'll do a basic
> functional layout diagram with some baud rate
> calcs/ packet size etc if this would be helpful?
>

bingo! that is pretty much exactly what i was thinking. what would be really helpful would be some info or links on how to best go about the Host <-> Arduino protocol. I've never really done serial protocols, so it would be nice to have some sort of guidance there. I think the closer we can make this protocol to how the reprap host software currently does things, the easier it will be to adapt the current host software.

Hej,

this is David Cuartielles from the Arduino project. I have been following your discussion for a couple of days now, and I will be happy to give you guys a hand in my name and my colleagues' to get you all set with this.

If you need to be very precise with timings, it is possible to make quite amazing stuff overriding one of the clocks using interrupts. Lately I designed a dimmer board shield with 32 outputs, and had to make some serious coding for this.

On the other hand, to control stepper motors, you may consider two interesting options. First there is the Arduino motor shield v4.0 that I designed. I could send you one PCB for you to try. The design is again open hardware and I got a sponsor to manufacture a bunch for me. You need to populate it with a L239 and a couple of capacitors, but then you are all set. The other possibility is to make it run using a bunch of MOSFETs. I am finishing yet another design for an art piece that will also be open and you could of course also benefit from its CC3.0-SA license.

I will be happy to give you guys a hand with both hard and soft, if you need it. My only condition is that the result should also be open, but with RepRap it seems to be the case :-)

Probably the best will be if you post more specific issues in our forum or if you direct the discussion via email. Also if you want to get hold of some of the PCBs I just mentioned just drop me a line and I will put them in an envelope asap.

/d

Hey David,

Thanks for the support. I have most of the boards I think I'll need designed. I'll make a post here when i get them all finished, and i'll send you an email personally to let ya know.

Damn! your project is exciting for sure guys. I am really looking forward to see it, replicate it, pass it (over)

/d

What's the latest on Arduino? I see many PCB's in the RRRF and they look good but how about the reprap software, has much work been done getting the two to talk to each other?