Reprap Electronics Devolpment

rocket_scientist Wrote:
-------------------------------------------------------
> BEEF
>
> But to make the boards truly interchangeable, I
> think we need to define the interfaces much more
> specifically, so that when you replace a single
> stepper driver module with a dual or a quad, that
> the same pines will still be used for the same
> purpose.

My suggestion would be to leverage BEEF, rather than restrict or constrain BEEF to something that may not apply for all possible prototyping or uses of the backplane... The reason for this is you make too many assumptions about what the cards do, and how you drive the motors... how would you use BEEF if you wanted to communicate to a motor child board using a digital RX/TX serial link rather than stepper signals (Maybe the child board is a fully integrated PID servo controller, not a stepper..)

So, maybe define your standard and name it something like "ThreeStep" or "ThreeStep BEEF", which extends the electrical and physical characteristics defined by beef, and creates a pin assignment and function standard defined for a 3 axis, 3 thermoplast extruder platform.

I can see where you are heading and their is mileage in this.

The thing that concerns me is thus. If I were to be using the BEEF platfrom to do R&D into making a bot that was an articulated arm and used servomotor actuators. Then a specification that did'nt allow for this and was too rigidly specifed would be discarded as being unsuitable.

This is the problem of specifying the hardware as what you intend it for rather than by what its capabilities are.

The specification above specificaly assumes you will use everything in that way. Which in the case I highlighted here. I certainly would not.

The specification above is one of many options that are a feature of the firmware and the bot, (So implementation specific) and nothing to do with the BEEF platform which is an open standard that can be applied to many different solutions. It is an R&D platform.

Where the platform becomes closed or exclusive to a particular bot or particular method, or controlling processor, then I personnaly have a very real issue with this. The work I have contributed so far is specificaly targeted at keeping it open. IE Bot and Method and Processor non specific.

Where a contributor wants to specify things further and make it less open I feel that they should be prepared to branch whilst leaving the open format to be developed further both fo rtheir benefit and everyone elses.

To that end I would propose that the un targeted specification is called BEEF and an implementors targeted specification (branching from the open one) is named
with the implementor. If the implementor wants to sub branch again it can have a further appendage to the naming.

ie BEEF/aka47

or BEEF/aka47/ServoArm
BEEF/aka47/MiniMendel
BEEF/aka47/Peas

etc etc.

I will tweak the wiki to reflect this the current state of play in the wiki sugests that everyone is going to follow the earler very prescriptive specification, that excludes cetain directions of R&D. Although rocket_scientist's specification is probably entirely suitable for the implementors personnal branch of the open spec. (I can actualy see the benefit of his/her specification within their proposed sub branch)

Branching is good and the best or most implemented will survive.

Folk are of course free to follow and branch or sub branch which ever route they fancy through the designs.

Thoughts for what they are worth.

Edited 5 time(s). Last edit at 05/09/2010 02:51PM by aka47.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

I'm not looking to detract from BEEF but since I learned of it a while ago I've been trying to think about the pros and cons of the approach. I thought by posting this note the people closest to BEEF development would be able to argue the points more crisply.

If you stand back from BEEF and look at it objectively how is it different from the current electronics?

I think the main thing is the packaging - replacing cables with a backplane.

Beyond that, I think it is hard to differentiate BEEF from the existing electronics.

I can argue that both are "modular" since I can replace the main controller, the stepper controllers, etc. in either case.

I can also argue that the interfaces are pretty much the same (step, direction, min and max). In other words there isn't any major innovation (benefit) here.

I can also argue that BEEF doesn't offer greater extensibility, and maybe even less, because even if I am willing to enhance the main controller the BEEF backplane constrains the system.

So what am I missing, or what am I thinking about the wrong way?

TC

OK

BEEF is an R&D framework, It specifies electrical interfaces between A backplane and modular boards.

The R&D part is key.

Consider where you are wanting to develop your own variant or version of a bot and or control. If you have to do everything from scratch it is something of a disincentive. If you can inovate just the bits you want and the rest is put together from proven components you are on to a winner.

If you can take a number of off the shelf components (either off the shelf designed ready to make or off the shelf to buy in) and rapidly plug them together (Because they have compatible electrical connections and electronic interfaces) you can rapidly build the electronics of your RepRap dreams.

I for example might want an arm bot with servo actuators.

I would use the standard back plane, the standard PSU board and maybe a standard controler board. Plug them together (about 5 mins) and then DIY my actuator interfaces. I might even plugin a breakout board that let me use the current Extruder controler with 485 interface (straight off the backplane).

The point is because there are no electrical/electronic incompatabilities this is quicker for folk to bend to their own wants and interests.

The guys that want to develop an ARM based micro board for a conventional stepper bot can do just that bit and use the standard Backplane, PSU, Stepper Axis cards etc,

They only need to work on the bit that interests them ie the micro controler.

Clearly each different build will need to have the firmware tweaked to suit. This is arguably why specifying the bot function of the electrical connetions is a bad idea. Depending on what you are building (Lego like, plug and play hardware) using BEEF components (Some DIY) the bot function of that connection will change. Its electrical spec though will not it will be the same. Digital input will be input, Digital output will still be digital output.

Think of BEEF as an electronic LEGO or Meccano kit for RepRap bots. Where you plug it together and DIY just the bits you need.

All the components in lego are physicaly compatible, one can plug to the other. What you use them for though varies according to your implementation. That 4 way brick can be part of a gun, house, car, robot, spaceship what ever you like. But it is still a brick whose mechanical specification means it will connect witht he other bricks in a predicatable manner.

This is what the BEEF framework is about. But we are doing it with discreet electronic subsystems, rather than discreet plastic blocks.

If you don't want to tinker in this way and just want an off the shelf single board, ready to go set of electronics. Makerbot, or some such, are your people.

Hope this helps

---

Necessity hopefully becomes the absentee parent of successfully invented children.

As a further thought,

This would perhaps be clearer (Perhaps even a no brainer) if someone were making and selling a full range of BEEF boards ready for folk to plug and play.

As it is we are currently desigining these. Or at least I have done some and am inviting your selves to contribute........

I have put together the concept, a back plane board and prototyping boards for folk to mess with and come up with ideas and design for. (Me included)

All should be doable (Single sided) on the kitchen table.

At the moment if there is no interest I will waste no more time on it. There are too many other things I need to do.

The last piece for now which I guess I am still waiting for some input on is the standard ATX PSU card. (Takes powere from the ATX PSU, provides a dummy load, reset, Pwr Good, 12v and 5v rails)

For publishing the full Kicad sources as opposed to the PDF's on the wiki I am waiting for the RepRap repository to be agreed/sorted.

As no one has blogged making any boards, or any designs or Emaild/PM'd me for copies of the current Kicad source. The development work so far seems to have been something of a waste (Although fun to do).

---

Necessity hopefully becomes the absentee parent of successfully invented children.

Let me throw my hat into the ring,
For what its worth, I think the concept of a plug-and-play electronics platform, on which to perform "modularised" electronics R&D, is an important avenue worth persuing. I think that most reprappers simply do not see the need for such YET, simply because most reprappers (I assume), like me, have not completed construction of their first printer yet. But I can foresee a day, not far after the bulk of the mendel generation come on-line, when additional non-plastic extruders , together with enhanced/modified mechanical design and additional toolheads, will require a more "structured"/modular/holistic approach to electronics design and development. This will be a requirement, in order to reduce complexity, IMHO.

The boundary between host and embedded control also needs to be tested. There is no reason why BEEF cannot implement some sort of proto-buffer functionality, that will inevitably please some within the bit-bang crowd.


Areas where BEEF could, potentially, play a meaningful role:
1. Decoupling electronics "boards", which currently may have poorly defined- / multiple functions
2. Management of "common" functions eg. power regulation, power monitoring, control signal noise reduction, auto i/p voltage level regulation for control signals
3. Auto error detection eg. CRC checking.
4. Host Buffering or pre-defined interface/inter-board buffering.
5. Hi-speed duplex comms to host.
6. Hi-speed duplex comms between multiple controller boards and mother-board.
7. Auto programming i/f for various controller boards i.e host can select target board.
8. Generic i/f between "main motherboard" and all peripheral controllers.

As I have mentioned before; I believe that the development of this (intelligent) backplane, is perhaps, a little ahead of its time. It may simply be that complexity (in design and construction), has not caught up yet. But in my opinion complexity will increase, as evidenced by the myriad of different ideas of potential applications.
...and when complexity arrives, modularity-of-approach is one of the best answers I know.
For inter-working purposes, EVERYONE in the R&D community, at least, will have to customize their respective "modules". This is an important area where BEEF can be the "combining standard" (as yet not defined), that will allow freedom of customization, while still falling within a broad over-arching framework of inter-working with other modules/controllers.


OK. I will get off my soap-box now....

Best wishes
Marius Botha
Pretoria, South Africa
[mariushermanbotha.wordpress.com]

No don't get of your soap box. I agree pretty much with most of your input.

Happy to accept it may be considered a little ahead of it's time.

I am personally a big fan of thinking forward and anticipating needs/solutions. I guess this is why I like RepRap and have stuck with it for as long as I have.

It really is one big, "ahead of its time" concept and project (Of Projects).

---

Necessity hopefully becomes the absentee parent of successfully invented children.

Is there documentation on BEEF besides the Wiki?

[reprap.org]

I've read the Wiki on multiple occasions over the past several weeks. This is largely because I am having trouble assessing BEEFs merits, and not because I don't understand the material on the Wiki. I seriously don't want to detract from BEEF or interest in it and I hesitate to post questions as a result.

I do see the need for a modular platform to support development, tinkering, etc. So, I don't need to be sold on the merits of a modular approach. The problem I'm having are the ones I posted a few days back.

The responses have some good insight re: motivation for modularity. However, I don't think the responses really articulate how BEEF provides the desired capabilities and I think that is what I'm looking for.


I feel that I should provide something specific to better explain myself. For the most part, the backplane distributes power and provides a bus for the signals that are currently used in a RepRap, or are anticipated to be needed for future developments (to some extent). But that seems to be about it (unless I'm missing something).

So, I started thinking about how one would map the current RepRap electronics into a modular BEEF system. There were be a main controller that would drive step and dir for x, y, z, and the extruder. There would be four stepper controller boards that connect to these backplane signals and drive the min and max signals from the opto-endstops, etc.

So the simple thing conceptually is that the backplane replaces the cabling for power distribution and signalling. Fine. But there are issues...

For example, each stepper board has to be different, or individually configured by some means, to use a different set of signals (one set for x, another for y, z and e). This doesn't really provide any greater modularity than the existing solution and is likely to be more error prone than the point-to-point cabling approach.

Note that the existing electronics allow me to change boards, for example, replacing an existing stepper motor controller with an improved one. Similarly, I could replace the main controller and keep the current stepper controllers. The point is that although the existing solution uses cables rather than a backplane, it is still modular.

So, I still feel like I'm missing the merits of BEEF.

I hope I'm being constructive. As I've said before, I'm not looking to detract from the effort.

TC

Edited 1 time(s). Last edit at 05/11/2010 08:58PM by TC.

OK

Maybe for yourself the better way to go is wires etc between discreet boards.

It is after all a personal choice.

The BEEF framework gives you a consistent interface both electrical and mechanically.

The discreet wire connected boards vary depending on who/where yo got them from and you can spend a not insignificant time making adapter boards/cables etc just to get to where you might have been had a BEEF spec board been available to plug in in about 10 seconds.

They don't have any consistency between boards and interconnects, Some are Ribbon some are RJ45, some use 0.1" pin strips etc etc etc. Even from the same vendor.

If folk design and contribute using the BEEF spec interconnect you can be sure that boards are electricaly and mechanicaly plug and play.

Key points, BEEF specifies electrical and mechanical interconnects. Not the end or intended implementation.

If this is'nt for you then I understand you will see little value in it.

The object is'nt to have folk trash what they have already got, but ot develop electronics systems and subsystems using a reasonably spec's interconnect that is consistent and quick to use.

I guess this is why the first boards I laid out were the interconnect board (backplane) and some prototyping boards.

The backplane connections were speced in terms of their electrical function. ie Digital out/PWM, Digital in/AtoD etc So that you could plug different boards in and they should'nt damage anything else if the end function was different.

Consider by comparison. the Spec'd standards for ethernet (or anyother standard) match electrically and mechanically, you can plug anything into anything (PC, WIFI Router, ADSL Router, Printer, Instrumentation, Cash Register). But the specs Don't in any way prescribe what the content of the data is or what you might use it for.

Ethernet then is a standard method for interconnecting and Messaging.

Similarly BEEF is a standard method for interconnecting and signaling between the subsystems that make up a RepRap Bot. How you use this compatible interconnect is up to you the implementor.

Where you do use it though you are building in a degree of reassured compatibility with other items you might design and also with the work others will do as well.

Everyone can get on with their own thing but their is a better than average chance that those items developed in a degree of isolation will play nicely together. (Or at least in a non mutualy destructive way).

You don't have to worry about which way round the wires go.

Follow the spec, then plug it in.


Consider.

AKA47 may design, build & Publish a Servo Motor Axis Driver Board.
TC may design, build & Publish an ARM7TDMI Processor board.
Adrian may design, build & Publish a PSU that does'nt use an ATX PSU.
VIK may design, build & Publish a Heated Bed PID controler.
NopHead may design, build & Publish a laser scanner for 3d capture.
Zak may design, build & Publish and improved stepper AXIS controler.
etc
etc
etc

Where all of these items have been design and prototyped using the BEEF framework anyone else can build a bot using whatever mechanics they want then pick n mix the electronics to give them the functionality they want.

The designers could all do this without needing to constantly hack out how it was all going to communicate and connect because they used a simple common standard. BEEF....

The arduino shield spec gives mechanical and electrical compatiability to a range of plug in boards (but not realy suitable for more than one, and the real estate is limited by the arduino's foot print). It does not specify what those compatible
boards will do.

BEEF then is to RepRap electronics what the arduino Shield spec is to Arduino projects.

You can wire your arduino with individual wires if you so wish. Is'nt it much easier to buy/make a shield board with the knowledge that it willplay nicely with the Arduino you plug it to ????

Probaly a long winded explanation of what basic standards and spec'd interfaces are all about, Sorry.

Hope this helps

---

Necessity hopefully becomes the absentee parent of successfully invented children.

aka47 Wrote:
-------------------------------------------------------
> ..lots of good discussion..

I wanted to pipe in as well, and expand on a better analogy:

BEEF is at the same level of specification as RS232 or 10BASET... I.E, it is hardware only. Just because two devices use an RS232 interface does not mean they can connect and work correctly, simply because the functions using the RS232 devices may not have compatibility... but... you'll be relatively confident that if you plug them together, you won't lose the smoke from your capacitors.

What I believe I hear some saying -- in addition to the hardware description, they want a functional description that they can work with, to get the start of true compatability.

I'd propose creating such a standard, and extending the analogy of "X.25 over RS232" vs. "SLIP over RS232" standard, I'd propose tuning the standard rocket_scientist has defined, and name it "ThreeStep over BEEF" (in spite of the horrific dancing image incited by this description.)

This standard would define specific functions for each line in the BEEF protocol to create the potential for a category of compatible and interoperable boards.

This would allow you to use your a ThreeStep XY and ThreeStep Z cards with either the ThreeStep Arduino bridge daughterboard, and can later swap out one or the other with a faster, better, or different ThreeStep driver (The ThreeStep ARM controller), etc.

Yup I agree with that.

The question I have at this point is whether the BEEF wiki pages are the best place to do this.

Or is it better that an implementor creates their own boards/designs and references the BEEF pages as the standard it is based on ?? Within the implementation then the implementor is free to observe/ignore/rename as much as they want without impacting on the base spec. (Sort of like inheritance in OOP)

I guess this way the BEEF standard can still be clearly seen as purely that.

I worry (perhaps unnecesary) that someone reading the pages as they stand will decide not to use the other wise useful standard/convention because they read it as being implementation specific.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

Just thought of another useful analogy that does'nt need folk to understand data comms.

Think of your home electrical supply.

You can buy any electrical goods you like, without having to worry about whether you can plug them in at home or not.

This is because their is a published standard specification of what shape your plugs and socket & pins are, how big they are, how they are arranged and what is provided by the pins. ie Live, Neutral and Earth.

You home supply will also run at a specified voltage, current range and type of electricity. (110v AC 60Hz USA, 240 AC 50Hz UK)

The manufacturers all use the same standards to make sure you can plug your goods in.

The standard for the power plugs etc though does not specify what you will use those electrons for. ie TV, Radio, Hair Straighteners, RepRap, Power Drill, Lathe etc etc etc. That part is down to the implementation.

In much the same way we are talking about potentially adapting a convention/standard (it is only adapted of folk use it, and is a waste of effort if they don't) for interconnecting the sub systems that make up the RepRap control system.

I guess some of the complexity comes from the need to offer something to just about everyone.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

aka47 Wrote:
-------------------------------------------------------
> Yup I agree with that.
>
> The question I have at this point is whether the
> BEEF wiki pages are the best place to do this.

No, I don't think so. However, a section on the BEEF wiki page linking to standards that use BEEF would definitely be a Very Good Thing (tm).

Beef wiki organization something like:

Introduction
...
Specification
...

Protocol Extensions using BEEF
- link to ThreeStep over BEEF
- link to BEEF.Ether/IP
- etc.

The pages extending beef should also link back to the BEEF page. Hypertext -- just do it!

OK

Rocket Scientist. I don't want to loose the work you put into thinking about the implementation dependant functions that were writen up in the BEEF wiki pages. It is definitely worthy of consideration and worth keeping.

Do you have an implmenmtation that they might better belong in that i can link to ??

BTW.

On the subject of EMC2 and minimalist control there is no reason why the breakout board (or a simple firmware free interface board) cannot be use to link the Controlling PC's parallel ports to the BEEF framework and use BEEF compatible driver boards to run your Bot. This is just another example of another BEEF compatible implementation.

I personally prefer firmware rich implementations (no surprise there for anyone who has read the firmware sections of the forum) but there is room here for a whole range of implementations.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

Thanks for the follow up posts to my questions about BEEF. I'm pretty sure at this point that I do fully understand what it is, and what the objectives for it are.

TC

Hi aka47,

I see a lot of time has passed since this topic was being actively discussed, I hope it isn't dead. I have recently got my repstrap up and running and am starting to print parts for my reprap.
Electronics-wise, I plan to use the BEEF framework as I like the 'plug and play' aspect of it. In fact, I am considering fitting a spindle to my repstrap and milling the PCBs.

Do you still have the source files for this project, and if so could I have a copy please?

Thanks,
jmg.

---

[emaker.io]

[emaker.limited]

Looking at BEEF again after not managing to keep up with Forum posts..

Its a nice development platform to start from.
Reminds me a little of the Map80 Nascom modular computer backplane solution. Where things Like the Pluto i8286 graphics board with Inmos colour pallet, Ram disks boards, Rom disk boards, Hard disk & SCSI controllers and Speach processor boards were added to the original Z80 Nascom system.

Im not sure that BEEF would become the main stream route.
It would create some neat/low cost all in one Burger boards that could be feed back into the main stream project.
Particularly for the non electronics engineering users who seem to want a plug and play 3d printer solution.

---

Bodge It [reprap.org]
=======================================

---

BIQ Sanguinololu SD LCD board	BIQ Stepcon	BIQ Opto Endstop
BIQ Heater Block PCB	BIQ Extruder Peek clamp replacement	BIQ Huxley Seedling
BIQ Sanguinololu mounting	BIQ standalone Sanguinololu or Ramps mounting	Print It Stick It Cut it

My rep strap: [repstrapbertha.blogspot.com]

Buy the bits from B&Q pipestrap [diyrepstrap.blogspot.com]
How to Build a Darwin without any Rep Rap Parts [repstrapdarwin.blogspot.com]
Web Site [www.takeaway3dtech.com]