5D and Gen2/Gen3

I spent some time today looking at what it would take to port the 5D (Gen2) code over to the ReplicatorG/Gen3 environment, and it got me wondering about the future of the JavaHost/Gen2 codebase.

With the Gen2 firmware still being actively developed by Adrian's group, do they have any plans to move to Gen3? Or are they looking beyond it?

And is anyone working on porting the 5D stuff to ReplicatorG/Gen3?

-Tim

what's the key identifable difference between "Gen2" and "Gen3" firmware? Are you referring to:
* the use of multiple arduino chips and RS485 comms between them
* the use of a particular custom-designed integrated PCB
* 5D/acceleration logic
* separation of realtime/DDA/step generation/asynchronous firmware functions from G-code reading/writing/interpretation/comms/synchronous functions


All these things are "third gen" in my books, but I dont think anyone has all of them together in one-place yet, do they?
short-comings:
Makerbot code still uses 3D, and may have other issues.
5D_Firmware code in SVN doesn't use multiple arduino chips and RS485 ( I've seen adrian hacking on it though?)


Buzz

Hi

I think the 5D code here supports both G2 and G3 electronics.

[reprap.svn.sourceforge.net]

Details of use in readme.

---

Regards

Ian

I haven't been doing this long, so I'm still trying to get this all sorted out in my head.

The Gen3 Firmware wiki page [dev.www.reprap.org] seems to indicate that Gen3 firmware should utilize the Gen3 communication protocol.

Looking at the 5D code, it appears to have GCode interpretation on the master, and thus doesn't use the Gen3 communication protocol, so I mentally labeled it Gen2 (correct me if I'm wrong!)

The Sanguino3G is clearly Gen3 since it uses the Gen3 communication.

In any case, firmware development appears to be split between 5D and Sanguino3G. I'd like to help out, but I'm not sure where my time would be best spent.

-tim

Yep I think you've sussed it right. A couple of weeks ago I had a sift thought trying to figure out the differences between the two.

I collected up all these links:

latest 3d (gen 3)
[reprap.svn.sourceforge.net]
[www.reprap.org]

latest 5d (gen 2)
[reprap.svn.sourceforge.net]
[dev.www.reprap.org]


skienforge is 3d based, but there is this converter:
[objects.reprap.org]

general:
[objects.reprap.org]

blog:
[blog.reprap.org]

gcode:
[objects.reprap.org]
[www.reprap.org]
[reprap.org]

I think the Bath team / Adrian are currently checking into the 5D / gen2 source, while New York / Makerbot are checking into Sanguino3G.

Hi

Latest Darwin 5D firmware seems to be here:-

[reprap.svn.sourceforge.net]

The readme states the 5D from Adrian supports G2 & G3.

I quote:-

"For instructions on how to use the RepRap 5D GCode Interpreter and Extruder programs in a RepRap controlled by a Version 1.0 Motherboard or a Sanguino
and having directly-controlled extruders, see:
[www.reprap.org]

For instructions on how to use the RepRap 5D GCode Interpreter and Extruder programs in a RepRap controlled by a Version 1.x (x >= 1) Motherboard or an Arduino Mega and having RS485-controlled extruders, see:
[www.reprap.org]
"
Those pages are not up to date with the latest firmware links.

There is a define in parameters.h

// Sanguino or RepRap Motherboard with direct drive extruders: 1
// RepRap Motherboard with RS485 extruders: 2
// Arduino Mega: 3

#define MOTHERBOARD 1

---

Regards

Ian

I've been reading and still am reading up through both the 3G Sanguino and 5D GCode versions of the extruder, and just trying to figure out how to drive a DC motor with the 5D firmware, as it appears to be coded just for stepper motors only.

The general method to handle it would be to increment and decrement a position store in place of sending the step and direction signals. That would give the target position of the shaft encoder. You then calculate the difference between that and the actual shaft encoder position to add a PID control loop to decide the direction and PWM value to drive the motor, possibly with a dead band.

I think there has been a PID motor control implementation in some variants of the code, so it should be not too hard to cobble it together.

---

[www.hydraraptor.blogspot.com]

If the shaft encoder has enough resolution you may be able to do what I did on HydraRaptor, which was as I described above but with just the P term. I.e. I set the PWM to a constant times the error term.

Depending on the the number of steps and the gear ratio you may get oscillation, in which case you will need full PID. Either that, or fuzzy logic [www.mstarlabs.com] but that seems to not be trendy any more. Anybody used both and would like to comment?

---

[www.hydraraptor.blogspot.com]

I'm also caught up in this Gen2/Gen3 confusion. Looking at the two code sets, I can't see that there will ever be a resolution between them: the approaches are too different. However, neither one will drive my extruder (gear motor with quadrature feedback) so I need to write my own. The question is, which horse to back? Each has serious drawbacks:

MakerBot code problems:
- It doesn't support 5D, and the protocol needs extending to support length-based extrusion if it's ever going to.
- Why is the host protocol the same as the RS485 protocol? Wouldn't it be simpler to use Gcode for host communication & SD card storage?
- A plain text protocol would be much easier to debug.
- Everything must have a single integer version number. What version number should I give my own code?

Adrian 5D code problems:
- It needs two extra wires as well as the RS485 connection to drive the stepper motor.
- Partly because of the above, it looks as though it can't be adapted for non-stepper approaches.
- Everything is done on the motherboard, losing flexibility & modularity.

My real worry is this: why didn't Adrian use the "Official" protocol? Is there no way to extend it when necessary? His readme files all point to web pages which don't even mention his approach. Is there a great schism coming? Do we need a bit more project management?

For now, I'm planning to add my own extensions to the Gen3 protocol, but unless things change, I don't see that I can ever release my code to anyone else.

Barney.

---

Oak & Silicon

Quote

It needs two extra wires as well as the RS485 connection to drive the stepper motor.

Really? If it does it is complete madness. You have RS485 differential comms for noise immunity and then add two noise prone signals as well. This is as bonkers as token ring and two sync lines to control three motors.

Edited 1 time(s). Last edit at 10/10/2009 09:55AM by nophead.

---

[www.hydraraptor.blogspot.com]

Questions for the core team:

* What is the development roadmap for the 5D code?
* Are there any plans to unify the 5D and Sanguino3G codes?

-Tim

nophead Wrote:
-------------------------------------------------------
> Really? If it does it is complete madness. You
> have RS485 differential comms for noise immunity
> and then add two noise prone signals as well. This
> is as bonkers as token ring and two sync lines to
> control three motors.


here's a code fragment:

  byte s = digitalRead(E_STEP_PIN);
  if(s != stp)
  {
    stp = s;
    sStep();
  }

and another:

  if(digitalRead(E_DIR_PIN))
    coilPosition++;
  else
    coilPosition--;
  coilPosition &= 7;

Adrian seems to be treating the extruder controller as a stepper motor driver, directly controlled by the motherboard.

Barney.

---

Oak & Silicon

perhaps this is just to do with the fact that the irmware is supporting 3 different basic hardware types ( ie wiring configurations)?

I don't think so, it doesn't appear that adding another bit of hardware would cause it to overflow, as its just pin definitions.

Hi

If you look in Adrians FiveD extruder code you will see the stepper pins are defined and written to from the the Arduino on the Extruder Controller in the G3 set up.

I think the code fragment you are looking at is for the single Arduino/Sanguino set up in generation 2 electronics.

---

Regards

Ian

emt Wrote:
-------------------------------------------------------
> Hi
>
> I think the code fragment you are looking at is
> for the single Arduino/Sanguino set up in
> generation 2 electronics.

No it isn't. I've studied the code quite carefully, and it works like this: the motherboard tweaks the E_STEP_PIN and E_DIR_PIN as if it was a fourth stepper motor driver, and the slave board polls these two pins and drives the h-bridges accordingly. The RS485 interface is only used for the thermistor, heater, valve and fan.

I'm now writing my own extruder controller from scratch, which I hope will be a lot more flexible than either of the existing versions.

---

Oak & Silicon

Barney, if what you say is true, then I can only summize that one of the following is true:
* the RS485 communications protocol is too slow for the real-time step/direction information,
OR
* the protocol hasn't yet been extended to support the stepper feature/s
OR
* or it's a work-on-progress, since the 5D code was originally written for single-arduino system/s, and it's a temporary solution to "make it work" for now.

Hi Barney

I am beginning to think we must be looking at different code.

The extruder code I am looking at only has 7 pins defined as I/O.

4 for the stepper, 1 for a pot & 2 for transmit and receive enable.

So where is the slave board polling E_STEP_PIN and E_DIR_PIN on the motherboard?

I will hopefully be able to actually try the code in a day or so.

I looked in the motherboard firmware code and can't find E_STEP_PIN.

I think you may have an old version of the firmware.

I have:-

// Sanguino v1.6 by Adrian Bowyer - implemented RS485 extruders

---

Regards

Ian

Have a look at this diagram dated 7 October.

I do have the latest version, and the E_STEP_PIN is on the extruder, not the motherboard. I wish the "core team" would let us know what they are doing.

Barney.

Edited 1 time(s). Last edit at 10/12/2009 06:27AM by Barney.

---

Oak & Silicon

Ah

I see. The E_STEP_PIN is in the Mendel code, I am looking at the Darwin code.

Unfortunately they have not changed the file names or the version number.

---

Regards

Ian