Reprap Module Communication Working Group

nophead,
"simple" master/slave protocols have two failings: 1) they don't handle slaves communicating with each other well, 2) they require the master to poll each slave at a regular interval.

david,
We're not designing a bridge; if we overengineer a bus, it won't be cost prohibitive. In fact, I showed above that 10Mbps transceivers cost $.80 in single unit quantities.

As for latencies, I honestly don't know enough about robotics to decide what those should be. I was hoping that someone would pipe up and say how long an acknowledge should take.

Why am I doing this work?
It's relatively simple. I expect that reprap will continue to evolve in a multitude of branches. The two extremes will be a single motherboard that does everything, and a single module for every task. I expect there to be everything in between these extremes. I expect that there will be boards built by a great number of people. I think that they should all work together.

When I have the time and the money to build mine, I intend to experiment with linear induction motors as X/Y drives, optical position sensing, a toolhead changer, and multiple toolheads. I want to make these work together. I know that I'm going to need a protocol which will tie them all together, so I'm trying to develop one. I thought that I'd share that process with the community so that everyone could have input.

Annirak,

I would be VERY surprised if we needed anything approaching 10Mbps. In fact I would surprised if we needed 1Kbps per interface.

As to latency, it matters, as it sets how quickly a packet can get to the target while other packets are moving around. It can occur if there is a collision based network and there is a lot of contention. It also matters whether the latency is predictable.

Yes it needs to be cheap and small. I get the impression you think I am suggesting something of great complexity and cost - I am not suggesting anything yet, not until there is a target to aim at.

David

David,
The bandwidth that is necessary is dependent on how intelligent the devices are. If the bus controller has to control and monitor every aspect of a toolhead, for example, and the toolhead controller just acts as an interface point, I'm not sure that 100kbps would be enough. If the toolhead controller ran its own software, and provided an abstracted interface to the bus controller, then the only reason it would take more than 1kpbs would be for timing.

I don't think you're suggesting anything yet. I do get the impression that you don't think much of the work I've put in already, though.

I can not evaluate it in any way having no idea what criteria you have to judge it by.

In my book the only way to design a good system is to know what problem you are trying to solve. Otherwise you can never know if you have solved it.

David

Hi guys

The issue of the actual spec is important, we should have thought of it sooner. We should make an effort to calculate how many packets/second are passed during a build and do some calculations to specify latency - possibly it's as simple as feed_rate * max_latency < x.

I would guess that the maximum latency will be the limiting factor, rather than basic throughput or average latency.


jbb

Yes its quite simple. The target accuracy is 0.1mm so you just compare that with the latency times the feed rate. At 16mm/s 0.1mm is ~ 6ms. My extruder control packets are about 6 bytes at 100Kb so about 0.5ms, an order of magnitude less. I only talk to the extruder when I am extruding, so all is well.

---

[www.hydraraptor.blogspot.com]

nophead,
Is your extruder controller smart or dumb? I.e. do you set feed rate, feed size and tell it to start, or do you control everything from the far side of the RS-485 link?

At the start of a filament run I send the extrusion rate, at the end I tell it to stop.

At the end of each layer I get statistics from it: temperature, motor and heater PWM averages.

I send the temperature setting only when I need a change and then I poll it to find out when it has got to the target temperature.

---

[www.hydraraptor.blogspot.com]

davidgoodenough Wrote:

> In my book the only way to design a good system is
> to know what problem you are trying to solve.
> Otherwise you can never know if you have solved
> it.


To be fair, Annirak has been involved in some discussion of that sort on other threads, but you do make a good point.

I think, a very quick summary, (and I might easily miss some important possibilities):
Tool head/s
Extra axis
Pick and place features
Machine vision.
Parallel print head.
LCD and or keypad interface.
Arc eroder.
Milling head.
Optical Encoder, linear or rotary
Magnetic encoder,
Extra memory interface i.e. IDE, SATA, USB, SD card.

Really, you can make an "Expert system", highly optimised for one task, or you can go to the other extreme and make somethings capable of how ever you want to assemble it.

As Annirak says, there are a variety of systems operating, and new ones coming on line also. Zach's approach is very modular, allowing for easy replacement/upgrade of parts, but with an extra price tag on the modularity, from the extra plugs, leads and PCB real estate, standoffs etc making that modularity possible. Others may be making machines more like the one I'm building, ARM cortex controller, 4 axis, 5 servo drive, 1 x I2C, 1 x RS485, SD card, LCD, Keypad, 5 x Darlington transistor drivers, 2 x Optical encoder channels, 2 x temperature inputs, and all on one circuit board.

Looking at davidgoodenough's quote again:"only way to design a good system is
> to know what problem you are trying to solve", with reference to what I'm working on, my design goals were to have enough on board capability to handle most problems I would encounter in milling, extruding and arc eroding, without needing anything extra, that had complexities of it's own.
Because I had a wide design goal(s), I've ended up with something that could easily be perverted into doing pick and place, robotics, door or gate control, Wheel chair control, automated handicapped vehicle motorised assists, Networked articulated robot.
Plane motion sub system controller, Deep sea submersible sub system controller, Zach's creations might well do these things too. I judge success based on my primary design goals, flexibility to deal with unexpected challenges, and being able to keep costs down.

However, this thread is about RS485 communications, in situations where the motherboard *can't* do specific tasks without an add-on card, or conglomeration of them

grael wrote
-----------------------------
> However, this thread is about RS485 communications, in situations where the
> motherboard *can't* do specific tasks without an add-on card, or conglomeration
> of them.

Or the motherboard was designed exclusively as a communication interface (this is what mine will be when I get to building it). That may seem like it doesn't make sense, but hopefully as I go through this problem outline, the reasons for doing so will become clearer.

I was taking a bottom-up approach to this discussion, working from the part of the spec which had already been locked in (RS-485, HDX). Apparently, that's not helped build consensus. I'll take a more top-down approach here, where I'll describe the problem we're trying to solve a little more clearly.


Logical Structure
=======================
A Reprap, or similar device is composed of a number of logical blocks. In the Gen2 electronics, several of the logical blocks have been merged into the same device.

[STL->Gcode translator]
|
[Gcode interpreter]
|
[Motion Controller]
|
+----------------------+--------------------+---------------------+
| | | |
[Extruder Controller] [X-axis controller] [Y-axis controller] [Z-axis controller]

This is the current RepRap. When we figure out tool-head swapping, there will also be the tool-swap controller and the additional Extruder controllers on the same level as the axis controllers.

I must stress that the code organization or physical grouping are not illustrated here. These are logical blocks. So grael's solution may have all of these elements integrated onto one board, using one code base; Zach's solution may have the elements grouped into two blocks, using two code bases. That doesn't mean that the LOGICAL blocks are not present.

The STL-Gcode translator is generally present on the PC, but that is not necessary for systems with more embedded processing power.

The Gcode interpreter translates each layer of Gcode into a sequence of movements that the motion controller executes. The motion controller instructs each of the controllers one layer below it to perform specific actions. As an example of what these actions are, they might include "extrude at rate" to the extruder controller, or "move to," or "move at velocity" as instructions to an axis controller.

Again these are logical instructions; any given code base may not have anything which resembles these, but the logical function still exists.

Abstraction
======================================
When broken up as logical blocks like this, it seems clear to me that the interface to each block can be easily abstracted into a relatively straight forward command set.

To give an example of what this looks like, here's a rough idea of what the X-Axis controller command set would look like:

Functions:
Get Max-speed
Get Resolution
Set Speed
Move to
Go
Stop

Alerts:
Target Reached
Endstop Reached


Toolheads
==============================
Toolheads are significantly more complicated than axis controllers. There are also several classes of toolhead available. Here are some examples:

Additive toolheads:
-Extruder
-Arc Welder

Subtractive toolheads:
-Router
-Plasma cutter

Manipulative toolheads:
-Vacuum wand
-grabber
-Screw driver

Measurement toolheads:
-Laser scanner
-Ultrasonic mapper

I'll just give an example of the command set for the additive and subtractive toolheads:

Additive
------------
Functions:
Get Material Code
Get Operational Temperature Range

Get min/max Width
Set Width
Get min/max thickness
Set Thickness
Get min/max speed (this is not extrusion rate, but toolhead movement speed)
Set speed

Start Warmup
Shutdown
Get Status

Start Extrusion
Stop Extrusion

Alerts:
Warmup Complete
Feed Empty
Out of Operating Range (for thermal extruders, this is for when the temperature falls below operating temperature)

Subtractive
------------
Get Force Feedback (if a router can measure the force applied to it, it can return a value here)
Set Force Report Rate (how often to report the applied force while cutting)

Get min/max Width
Set Width
Get min/max thickness
Set Thickness
Get min/max speed (this is not spindle speed, but toolhead movement speed)
Set speed

Spinup
Shutdown
Get Status

Toolhead Down
Toolhead Up (On a router, these two simply inform the toolhead that it is about to start cutting. On a plasma cutter, they apply power.)

Alerts:
Force Applied (see above)
Error (on a router, this could be spindle lock)

===========================

These are a rough outline of what kind of messages need to be sent to toolheads. Manipulative toolheads have the potential to be significantly more complex, which is why I haven't covered them.

I think this demonstrates reasonably well why I say that the interface is abstractable. The command set I've created there is not complete. I suspect there are a fair number of commands which I've neglected to describe.

The idea is that the motion controller needs to know very little about the specifics of a toolhead to control it. Likewise, the motion controller doesn't care whether the Y axis is built with steppers, servos, LIMs, or has feedback. It assumes that the Y-axis controller will implement suitable feedback and do what it is instructed to do.

Again, these may be on the same processor, but from a logical perspective, this is what happens.

What I want to do is formalize these logical divisions, and create an abstraction layer which allows the motion controller to execute these commands over the RS-485 HDX bus.

Edited 1 time(s). Last edit at 05/06/2009 02:37PM by Annirak.

Nice work Brendan,
I would be trying to layer my software internally on my integrated PCB too, the difference being, that a request can be passed through internal memory and interrupt polling, or even direct calling of appropriate routines.

In theory, I could have a set of commands for different "hardware modules" and even use the MMU to read the alerts and write the actions, whether I strive for interoperability of internal and external software modules controlling hardware remains to be seen though. The ARM is powerful, not just in processing bus width, but also in speed, special instruction, and also, especially, (on this STM32 beast anyway), it's also got some great features to automate what would otherwise be done in polled or multitasked software I/O control.
I see my particular implementation as a micro factory base unit, with expansion only required for special hardware functions or networking multiple of the same units, off one PC, via the RS485.

However, carry on Annirak, and lets see how the different connection implementation modes settle out. Potentially, we could run core tasks on one machine, and pheripheral tasks on the same machine, OR on pheripheral hardware with their own OS and drivers. How much is potentially sharable, is debatable, there needs to be substantial reusability to make the additional protocols worth while.

Disclaimer:
Written late at night/(early morning), may not seem as coherant as I hope for !

Graham.

Q: how to program stepper motor using MpLAB IDE and C language to be controlled by PIC18F4550 microcontroller this is used in a system work as mixing chamber the system use two stepper motors one at each pipe of hot and cold water the motors pass fixed amounts of both hot and cold water in order to give a mixture that has the same temperatue as a user entered using keypad please send to me the program ( the code) in very fast time.

ASD,
Thank you for your interest.
That very same solution has just been posted right here, and is completely free:
[www.w3schools.com]