Replacement for g-code, skeinforge and repraphost

My bespoke G-code will probably not work with your reprap and create the same shape.
As a result each object is not guaranteed to be the same.
This costs companies like Boeing millions a year.
The idea is to build a descriptive language which will provide the same part now and
10 years down the line with a different CNC machine when you need another replacement part.

To build an object the process is currently:

1) Download/create STL or equivalent object
2) Convert STL into bespoke G-code for your reprap system
(reprap host or skeinforge)
3) Fiddle with the G-code a bit to make it work on your system.
4) Print using G-code

The "new" way seems to be use STEP.

1) Download / create STEP file direct from CAD. (i.e. no reprap host or skeinforge)
2) Print STEP file directly to reprap

(See
[www.mmsonline.com]
[en.wikipedia.org]
)

What does this mean for us?

There is no way the micro controller firmware is going to handle STEP as it is too big a standard.

So rather than develop a Firmware that handles, SNAP or GCode or 5D Gcode.
Let's look to the future and build a universal small firmware that accepts simple commands which relies on the host PC to work.
Then each dialect SNAP, STEP, Gcode, 5D Gcode, or future language would just be a different PC delivery program.

This gives other benefits

- Reduces cost of microcontroller
(The micro controller does not need to be powerful as it relies on the PC for complex mathematics and storage)

- Creates a set and forget firmware version. (Low maintenance)

- Moves development from firmware (specialised – C/C++) to pc software (less specialised – python or other). This increases the pool of people able to help.

To do this we need a frame work to harness the community’s enthusiasm for building, debugging and documenting the firmware.
Currently I see firmware bugs solutions being posted adhoc on the forum.
With others people building their own bespoke firmware solutions and posting them.
I feel we need someone in the core reprap community to take ownership of the firmware
and approve / disallow changes to the official version and document which versions have been tested with which hardware.

In this fasion we can continue to create and use G-code while being able
to develope code to cope with the new STEP code for the future.

Any thoughts ?

Regards

Stephen


Other notes
[www.steptools.com]

==============================================================================
NOTE
NOTE
NOTE The posts in this thread are out of order. This happened by accident when
NOTE the thread was moved to its own forum. -Sebastien
NOTE Please continue reading at Kintel's post
Posted by: kintel (85-127-117-116.dynamic.xdsl-line.inode.at)
Date: January 07, 2010 10:28PM
NOTE and then back here.
==============================================================================

Edited 2 time(s). Last edit at 01/15/2010 12:21AM by SebastienBailard.

I agree with Triffid_Hunter but maybe a another argument would be:-

Take a look a the processor required in the average ink jet printer it is very much on a par with the processor we are currently using. Now look at the processors in Laser printers or the processors used in graphics cards. Gone are the days of the simple dumb peripheral device tasks need to be delegated down to the firmware. Thus saving system bandwidth and processing power.

There is nothing to stop us having host software that can handle Step or what ever the current industry standard becomes. We can assume that all renditions of a RepRap are like a photo copiers or laser printer when you ask for an A4 picture with a one inch cube to be printed. Thus we need a Step to RepRap Gcode host written to keep up with the current industry standard.

The internal settings in different flavors of RepRaps has no bearing on a RepRaps ability to use this standard.

The only time that this will make a difference is if these parameters are incorrectly set/calculated within any unique RepRap version. This will be obvious to any RepRap builder who prints any standard part as things like stepper motors PCBs will not fit the printed part.

---

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]

Glancing at STEP-NC, it appears it targets subtractive manufacturing.. Am I missing something here?

If this is the case, I think STEP-NC may not fit well into a reprap tool suite, since there is no need to "drill and rough in a pocket", or to "plan a path for a cutting tool that avoids current features". Many of these subtractive problems do not exist for additive processes.

However, I agree the ability to interpret more model description would be useful; I'm sure Boeing would be very interested in your application if it were you that took the Skeinforge source and adapted it to output STEP-NC for use on light milling tasks using the reprap hardware. Seems you should go for it!

Glancing at STEP-NC, it appears it targets subtractive manufacturing.. Am I missing something here?

If this is the case, I think STEP-NC may not fit well into a reprap tool suite, since there is no need to "drill and rough in a pocket", or to "plan a path for a cutting tool that avoids current features". Many of these subtractive problems do not exist for additive processes.

Yes, but we're slowly bringing subtractive problems under the RepRap umbrella:

EMCRepStrap:
[objects.reprap.org]

RepCNCLathe (stub):
[objects.reprap.org]

Eiffel:
[objects.reprap.org]

Millstrap (stub):
[objects.reprap.org]

While Boeing already has 100K - 500K machines with their own CAD->Swarf toolchain, RepRap is very interested. Because I'm part of RepRap, and because Stephen is part of RepRap. The RepRap umbrella is very big, and there's lots of room under it.

Has anyone been experimenting with any of the non-reprap, linux based toolpath from part programs out there? Here's a starting point:
[wiki.linuxcnc.org]

Also, once this thread has enough momentum, I'll create a dedicated forum for it.

Triffid_Hunter () said
I think the reason that the controller is calculating curves and things is that the step timing is as critical as the movement speed, and the extruder has to extrude at a rate proportional to movement speed to within a relatively tight tolerance. PCs without a RTOS are dreadful at tight timing, and the (usb) serial link coupled to another (async/rs232) serial link doesn't help either.

My response

I am not saying get rid of the micro controller. I am simply saying let’s do all the hard number crunching on the PC end and speak to the micro controller natively rather than in Gcode.

Let’s take a gcode simple example.

// Set the temperature of the extruder to 255 C
M105 S255;

The micro controller now has to convert the number 255C into something it understands. (i.e. an arduino anlog reading)

It does this by accessing a table of conversion values.

short temptable[NUMTEMPS][2] = {
{1, 841},
{54, 255},
{107, 209},
{160, 184},
{213, 166},
{266, 153},
{319, 142},
{372, 132},
{425, 124},
{478, 116},
{531, 108},
{584, 101},
{637, 93},
{690, 86},
{743, 78},
{796, 70},
{849, 61},
{902, 50},
{955, 34},
{1008, 3}
};

Then it runs through each until it finds a conversion code just below it and then takes the average between the upper and lower to find the correct arduino analog byte (0-255)


The code is a follows.

int raw = sample_temperature(temp_pin);

int celsius = 0;
byte i;

for (i=1; i raw)
{
celsius = temptable[i-1][1] +
(raw - temptable[i-1][0]) *
(temptable[1] - temptable[i-1][1]) /
(temptable[0] - temptable[i-1][0]);

break;
}
}

// Overflow: Set to last value in the table
if (i == NUMTEMPS) celsius = temptable[i-1][1];
// Clamp to byte
if (celsius > 255) celsius = 255;
else if (celsius < 0) celsius = 0;

return celsius;


And this is just to read the extruder temperature to work out if we need to turn the heater on or not. The more complex code requires floats which has a 2kb overhead on the micro controller before you even start.

My suggestion is to do all the above on the PC side and simply say to the microcontroller

if (temperature reading below 54) then set heater on
else heater off;

// where 54 is the arduino anolog reading for 255C


Note: I am not saying get rid of G-code I am simply saying process it on the PC side and communicate the instructions to the reprap in instructions which are easy to process for the microcontroller.

In this fashion if someone wants to use STEP they simply process it into the native reprap code and send it to the same universal micro controller code.

You then have a reprap that can talk Gcode,5d gcode,SNAP and any other future langauge

Regards

Stephen

P.s. Happy to go through the code required to generate a curve / straight line and show how we can move more code to the PC side.

Edited 1 time(s). Last edit at 01/10/2010 07:19PM by stephen george.

I plan to write software that takes G-Code output from Skeinforge, and converts this to Cubic Spline paths for a polar XY stage. I'll probably need to create a lot of my own firmware to convert these commands to motor control steps on the firmware.

This seems very much to be the kind of thing you are proposing, are you not? I don't think there is any kind of mandate for firmware to interpret G-Code in any form or fashion. It may be (I don't know for sure) that Mendel specs were drawn up and a G-Code subset specified for the firmware implementation. I think RepRap has greater scope than that though -- Mendel exists as just one suggested implementation (out of a few but growing number of implementations.)

In terms of where temperature control is performed, someone more comfortable (or excited by?) writing an Arduino sketch file appears to have written the code you reference. It does mean that perhaps you need a beefier but more expensive microcontroller. If I had more time, it might be fun just to write a forth interpreter on the firmware; then you would simply send it forth command blocks to execute your motor control commands!

And, I agree with Sebastion, being able to do STEP-NC could be useful; I responded earlier to an implication I read; "CAD programs spit out STEP-NC from the model itself, so if used STEP-NC you're set and won't lose millions because the CNC machines 10, 20, or 30 years down the line can use them". If STEP-NC files do subtractive specific commands, Boeing may still lose millions when the CNC machines 10 years from now use nano-steel additive (REPRAP!) processes, rather than CNC lathing and milling (One can dream, no? -- well, about the part of nano-steel additive processing, not the Boeing losing millions part..) Apologies if I got that wrong and it wasn't really about STEP-NC afterall.

BeagleFury ()
This seems very much to be the kind of thing you are proposing, are you not?

My reponse
yes

Note: The implementation is of STEP called step-NC is open souce. Boeing want CNC systems to use it as it means that parts are exactly as requested. rather than having been interpreted by a machinist and then using g-code.

BodgeIt said
Take a look a the processor required in the average ink jet printer it is very much on a par with the processor we are currently using. Now look at the processors in Laser printers or the processors used in graphics cards. Gone are the days of the simple dumb peripheral device tasks need to be delegated down to the firmware. Thus saving system bandwidth and processing power.

My response

Printers are a good example to follow.

In the old days you could send postscript/ascii directly to a printer in much the same way we send G-code directly to the reprap. The printers were expensive as they had to have a powerful microcontroller to handle the conversion
(notes [en.wikipedia.org])

Then new printers became available with the concept of a “win printer or GDI printer”. Basically you could still print ascii, postscript, or even a graphic from paint but this information was converted into simple commands for the printer by a driver. The processing power was taken from the PC itself. You could not print directly to the printer by sending ascii directly to the lpt1: port.

(notes [en.wikipedia.org] see GDI printers)


I suppose the question comes down to this.
How do you want to communicate with the reprap?

1) G-code - A programming language created many decades ago for CNC systems

2) Reprap native code - designed with the reprap in mind. Based on the capabilities of the reprap which can be translated to from Gcode, Gcode 5d, STEP or some future language.




BodgeIt said
There is nothing to stop us having host software that can handle Step or what ever the current industry standard becomes. We can assume that all renditions of a RepRap are like a photo copiers or laser printer when you ask for an A4 picture with a one inch cube to be printed. Thus we need a Step to RepRap Gcode host written to keep up with the current industry standard.

My response:
I understand what you are saying. However STEP is a replacement for g-code.
It not only describes the shape (In the same way as an STL file) but it provides the method to create that shape(in the way that g-code does for us currently).


BodgeIt said
The internal settings in different flavors of RepRaps has no bearing on a RepRaps ability to use this standard.

The only time that this will make a difference is if these parameters are incorrectly set/calculated within any unique RepRap version. This will be obvious to any RepRap builder who prints any standard part as things like stepper motors PCBs will not fit the printed part.

My response:
I am afraid I have to disagree with you here. If Gcode gave you exactly the correct shape everytime why do we need to recreate it each time? Could it be that my extruder has a smaller output than yours? And therefore it has to print an extra line to give me that perfect square?

Maybe my extruder have a different heating element. Maybe the plastic is different. Also maybe the room temperature is different. All these little things have to be compensated for in g-code.

Beaglefury () said
Glancing at STEP-NC, it appears it targets subtractive manufacturing.. Am I missing something here?

If this is the case, I think STEP-NC may not fit well into a reprap tool suite, since there is no need to "drill and rough in a pocket", or to "plan a path for a cutting tool that avoids current features". Many of these subtractive problems do not exist for additive processes.

My response:
Yes STEP-NC is a Subtractive technology. But then again so is G-code.
It would have to be adapted. Also reprap will probably have a CNC style printer head in the future. Which does fit in with step-NC as it stands.

Beaglefury () said
However, I agree the ability to interpret more model description would be useful; I'm sure Boeing would be very interested in your application if it were you that took the Skeinforge source and adapted it to output STEP-NC for use on light milling tasks using the reprap hardware. Seems you should go for it!

My response:
Thanks for the encouragement.
I am currently at the stage of asking the community whether this is of interest to anyone and whether my ideas are flawed before I commit serious time to this project.
I don’t think it is possible for 1 person to complete this project and it will require some sort of structure to allow people to cooperate together.

E.g. I have a DC motor extruder with Gen2 electronics. So testing GEN3 with a stepper extruder would be problematic for me.

Edited 1 time(s). Last edit at 01/11/2010 12:32AM by stephen george.

One point for thread readers who haven't studied this in any depth - G-code just means "move here, drill this deep, up, and now (describes a slot) etc." but that's doesn't really specify the toolbit width or so on, and especially doesn't describe the workpiece. It could be a cubical block of aluminum, or a large triangular sheet. But g-code just describes the movement of the toolbit.

On the other hand, STEP-NC precisely describes the part geometry. And a STEP-NC to jpg rendering engine for humans might show a jpg of a gear. While the reprap cuts one out of brass.

---

stephen george, let me know if you need me to create a dedicated forum (and eventual mailing list) for your STEP-NC stuff. Because there's lots of room under the RepRap umbrella.

I'm not a firmware guy yet, so I've no idea who to talk to about what gets checked in or suchlike. That person will no doubt speak up shortly.

I just know I want to us to be able to generate 5 axis toolpaths to make machine parts out of steel and this kind of thing:
[dev.forums.reprap.org]
And we'll need the software in order to motivate the hardware, and vice versa.

Thanks SebastienBailard () for the level of support. Much appreciated.

Before we get started is there anyone out there who sees a problem with what I have proposed?

A sanity check would be greatly appreciated.

regards

Stephen

What do you forsee as the minimum set of commands for the embedded software. How does that differ from current G code implementation? Did you just plan on removing the linear and temp unit specific conversions only, and retain the remaining commands?

Abstractly, I see the firmware only having 3 functions: "Set your state to the known state", "Tell me what your current state is", and "Change your state in a predictable way from your current state to a target state". It only needs to respond with 3 indicators "I'm beginning a path along a set of target states", "I've finished changing to the final target state", and "I've entered a 'time to build a new extruder' state!"

The protocol I envision consists of abstracting 'state' to a vector of control values, labeled "A" to "Z". Only one 'move' command needs to be supported, a path described by a vector of functions having one variable, t. The functions can be designed to be easy to compute V(t+1) values in firmware from V(t) values.

I plan to use a cubic as my function basis and use stepwise integer addition to compute each target (No multiply needed to compute any polynomial if you design it right..). This allows the host to choose any one of the following motions with (relatively high) positional accuracy:
- Set (fast) position; don't care how, don't care which direction (if value is cyclic), just get to that position.
- Change value with constant velocity from current position.
- Change value with constant acceleration with specified initial velocity from current position.
- Change value with constant change in acceleration with specified initial accelleration and velocity and current position.

These motions would be linked to all other control values. As time advanced, they would synchronize their motion to the target state.

Apologies for the late reply.

Thanks Beaglefury () for your post I have spent much time considering it.


Beaglefury () said
What do you forsee as the minimum set of commands for the embedded software. How does that differ from current G code implementation? Did you just plan on removing the linear and temp unit specific conversions only, and retain the remaining commands?

My response:

I want to create a firmware version that does not have any hardware specific code.
It should all be handled by the PC host.

The strength of this idea is that if we make the system generic enough it should be able to handle any future tool. Xray cutter? Molecule assembler? Magnetic shifter? Microwave bed heater. These devices should all have the same firmware code. After all the firmware does not care what hardware it is connected to as it just sends and receives 1’s and 0’s

To achieve this goal I see the micro controller having a truth table uploaded to it and stored in a C array from the PC host.

For example

Our plastic extruder with it’s temperature sensor and heater could have the following truth table.

Min..Max...Output pin.Value
---------------------------
0....100...2..........255 // below required put heater to max
101..102...2..........210 // temperature correct put heater to sustain
103..255...2..........0 // temperature to high turn heater off
103..255...3..........1 // if temp to great then Fan on


So

Line 1 says
When the analog temperature reading is from 0-100 (which corresponds to 20c to 182c on the extruder for example) line 1 says Set the PWM output pin to 255 (equivalent to heater at max).

Line 2 says
When the analog temperature reading is from 101 to 102 (which corresponds to 185c temperature reading on the extruder) line 2 says Set the PWM output pin to 210 which should in theory sustain the extruder at this temperature.

Line 3
When the analog temperature reading is from 103 to 255 (which corresponds to 190c or > temperature reading on the extruder) line 3 says Set the PWM output pin to 0 which is the same as turn the heater off.


Line 4 says
When the analog temperature reading is from 103 to 255 then turn the fan on to cool the extruder.

(Note: there is no corresponding off for the fan so it would stay on forever unless the PC host directly shut it off in this example.)

In this fashion we can configure the firmware to do anything and handle anything based on it’s inputs.

If we are using a different plastic to extruder we can upload a different truth table.
If we are using a different tool again we can upload a different truth table.

The micro controller does not care it just reacts to its digital input with an output.


Beaglefury () said
What do you forsee as the minimum set of commands for the embedded software.

My response
As an overview I see the following groups of commands

Group 1
Definition
Commands that define and configure the various pins
e.g. pin 1 is pwm input. Pin 2 is analog output etc
(after all why change the firmware just because you have changed the wireing)

Group 2
PC host Direct control
Commands that send the micro processor output.
e.g. Pulse the stepper motor. Turn extruder on. It does this by setting micro controller pins off and on directly.

Group 3
Flow control
Commands that control the flow of Group 2 commands.
e.g. repeat the last three commands six times. Wait 10 U seconds etc


Group 4
Micro controller decision control
Commands that describe how the micro controller handles its inputs and how it affect’s it’s outputs.
i.e. the truth table idea


So as an example the micro controller could get these commands:

1) Define pin 1,2,3 to digital output. (group 1 command)
2) Set pin 1 to 1, set pin 2 to 0, set pin 3 to 0. (group 2 command)
3) Set pin 1 to 1, set pin 2 to 1, set pin 3 to 0. (group 2 command)
4) Wait 100 Milli seconds (group 3 command)
5) Go back to 2) and repeat 255 times (group 3 command)

Notes pin 1,2,3 are connected to the following steppers x,y,z respectively.
The command would move the x once then the x,y once and then repeat that 255 times. Resulting in the x moving 510 steps and the y 255 steps and the Z 0 steps.

(Direction of stepper not included for simplicity sake)

Have I missed anything? Does anyone have anything to add before I start writing the code? All comments welcome. I would rather be told I have missed something than have to rewrite the code in six months time..

Regards

Stephen

That seems much too low level to me. If this is the level that you want to work with, I'd suggest writing a program that can generate C or assembly for the firmware, and a boot-loader, and execute it that way. Alternatively, implement an interpreter/compiler on the firmware itself.

For example, there is a FORTH interpreter available for an AVR. If you had predefined your forth dictionary to include the primitives you describe, the commands you'd send such a firmware device that mimic what you've described would be something like:

1 pinout! 2 pinout! 3 pinout!
255 0 do
1 1 pin! 2 0 pin! 3 0 pin!
1 1 pin! 2 1 pin! 3 0 pin!
100 delay
loop


If you're not trying to do a general (or limited) purpose language, then you're left with something closer to G code.

My own "In my head still" protocol, would look something along the lines of:

  GOHOME
  P1 X=100;Y=30;Z=50;T=210
  P2#64 X=100,-15,-29,240;Y=30,4,7,-60;E=0,13,25,-210

This calibrates and homes all controls, move fast on any path to (100,30,50) while setting temperature control to match 210. Once that completes and state matches this, it will continue on path 2 by having X,Y to follow a curve (cubic spline) to (20,50), while extruding 70 units of material, in 64 discrete steps.

I'm not even sure how I'd go about trying to do this with your proposed protocol; since these 3 commands represent a significant number (possibly several thousand) stepper bit toggles, feedback tracking, error correction, temperature tweaking, etc. Even if the 'protocol' were transmission of FORTH commands, I'd probably send my firmware program, and then just send messages based on my uploaded program, something along the lines of:

  DEF PATH (... lots of code here ...)

  ; Protocol downloaded.  Proceed by sending abstracted path commands.

  GOHOME
  1 PATH 100 'X GO 30 'Y GO 50 'Z GO 210 'T GO PATH_READY
  2 PATH 100 -15 -29 240 'X CUBIC 30 4 7 -60 'Y CUBIC 0 13 25 -210 'E CUBIC
      PATH_READY

BeagleFury () said
That seems much too low level to me. If this is the level that you want to work with, I'd suggest writing a program that can generate C or assembly for the firmware, and a boot-loader, and execute it that way. Alternatively, implement an interpreter/compiler on the firmware itself.

My reply
Yes the firmware would be written in C. The idea is for the PC to convert from a high level language i.e. Gcode , 5d gcode or Step into this low level language. Which is then sent to the microcontroller to be actioned. This way one version of Firmware would support all of these standards.

Ahhh I understand your system a lot better now. I like your concept of moving the main processing part to the PC in this way.

The only problem I see is the huge amount of Com's overhead involved when printing at the moment there is no hand shaking or Error checking in this Com's link.

So improving the speed and adding some hand shaking to the Com's link would be another thing to do some work on.

The fine detail of exactly how low the Com's language will need to be; will have to evolve over time.

I agree with Beaglefury that your quick example is probably a little too low level but its an idea that can evolve into a purpose built 3D control language.

It will have to add some significant extra value to the existing standard of G-code that we are currently using for communication:-
~ like providing feed back of bed temprature extrusion temperature, material left to extrude, extruder extrusion size, maximum speed of axis movement, axis resolution etc That it can then use in its higher level processing of the STEP commands/description of object.

Edited 3 time(s). Last edit at 01/14/2010 10:02PM by BodgeIt.

---

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]

BodgeIt () said
The only problem I see is the huge amount of Com's overhead involved when printing at the moment there is no hand shaking or Error checking in this Com's link.

My response
I had that exact same thought. So I added a CRC byte to each command and opted for a binary comunication scheme rather than ASCII. Then I discovered that with a loop command and a little flow control the amount of bytes sent was similar to G-code. With maybe 10% over head.

P.s. Incidentally there is a little bit of Error checking in the current firmware code. as it only accepts character greater than Ascii 32 (except /n of course)

P.s. The Arduino should be able to process 1Mbit transfer rate. But I have not tried it yet in practise.

Damn.

Stephen and I seem to have moved the topic at the same time. I'll sort it out by locking this, creating a new topic, and hand move over posts.

This topic has been given its own forum so that people have a space to work on this.

> So rather than develop a Firmware that handles,
> SNAP or GCode or 5D Gcode.
> Let's look to the future and build a universal
> small firmware that accepts simple commands which
> relies on the host PC to work.

This is exactly what the MakerBot firmware does.
All the magic is on the computer side (i.e. in Skeinforge and ReplicatorG).

I don't quite see where STEP fits into this picture though, except as a new file format front-end to Skeinforge.

---

~/= Marius

--
We are Elektropeople for a better living.
[reprap.soup.io]
[www.metalab.at]

kintel () said

> I don't quite see where STEP fits into this picture though, except as a new file format front-end to Skeinforge.

Let me explain

1) Direct replacement for G code. (Output of skeinforge)
2) International standard
3) Use xml
4) Paradigm shift
i.e. Describes the shape and then uses a database to lookup and calculate the tool path as defined by your system.
5) Industry Standard.
Apparently people like Boeing are only subcontracting with people who can provide this support. This may be important if you want to build
a career in this industry and want to start with a reprap.
6) The same code describes the object construction for any machine to understand.
Maybe a bit like having an IBM PC standard for CNC machines.

kintel () said
>All the magic is on the computer side (i.e. in Skeinforge and ReplicatorG).

No skeinforge outputs G-code.
This then has to be calculated into specific stepper movements by the reprap microcontroller.
I.e. Curves and lines etc.
What I am talking about is that these stepper movements are calculated by the PC not the micro controller. This will mean that the controller does not have to be so powerful and possibly expensive.

Currently we have the following

STL (or equivalent file)
V
Converted to G code by PC host (skeinforge, repraphost)
V
Converted to Stepper movements by Microcontroller
v
Reprap

I propose a universal piece of firmware which works with stepper movements only and requires a driver to convert to it from the GCode,5d Gcode,STEP or a future Language.

As a result the firmware stays the same and the developement is in the PC area.

Currently we have Firmware that supports SNAP, Firmware that supports G-codes and firmware that supports Gcodes with 5d extension, my version etc

Stephen

I think the reason that the controller is calculating curves and things is that the step timing is as critical as the movement speed, and the extruder has to extrude at a rate proportional to movement speed to within a relatively tight tolerance. PCs without a RTOS are dreadful at tight timing, and the (usb) serial link coupled to another (async/rs232) serial link doesn't help either.

This thread was scrambled when we moved it.

It would be a very good idea to create a new thread for each important subtopic.

Thanks SebastienBailard () for createing a new area for the Step work.

Triffid_Hunter () Said
I think the reason that the controller is calculating curves and things is that the step timing is as critical
as the movement speed, and the extruder has to extrude at a rate proportional to movement speed to within a
relatively tight tolerance. PCs without a RTOS are dreadful at tight timing, and the (usb) serial link coupled
to another (async/rs232) serial link doesn't help either.


My reply()
I agree curves may be a chalange. But the following back of the envelope calculation says it should not be a problem

I extrude at 40m/s.
My stepper on my x and Y axis move 1mm with 8 steps.
Therefore to achive 40m/s my stepper's must recieve 320 instructions/pulses per second to move either the x or y axis.

Let's say 10 bytes (more than enough I think) has enough information to instruct the stepper to move 1 step.

Therefore to achive my current 40m/s I would need a data transfer of 3200 bytes per second (10 bytes x 320 instructions)
or 25,600 bps or half the datatransfer of a 56k modem.

With a good buffer I might be able to run one of Adrian's reprap in Bath (UK) from here in Brisbane (Austarlia) down the phone line.

Hmmm. What an interesting thought.

Stephen

P.s. Thanks Triffid_Hunter for your post. Do you see any other issues?

Well since no one sees any further issues I had beter get writting the BIOS.

Grin

Stephen

Hi folks,

actually I've been working on new primitives for the delta reprap's firmware. The coordinate transformation is not linear and thus is not calculatable on the Arduino for every step; it simple can't handle the math in time.

The option i am currently investigating is to let the host calculate the path of the four motors (p,q,r + extruder e) taking into account acceleration for smooth stepper motors etc. These paths are then converted into cubic polynomials that are directly computable as function of the time. With some optimization the Arduino can compute the points at 19.67 usec/axis i.e. upto say 12000/sec for 4 axis in full floating point even.

When the Arduino needs to calculate the polynomials, the extrusion rate goes to roughly 40-50 moves/second. Streaming the polynomials might not be much faster though since it consists of say a 88 bytes/move, but of course leaves an Arduino with time to spare.

So for now i am planning to build-in both schemes in the MakerBot firmware and see how they will perform each

With regards,
Reinoud

I would be very interested to see you code.

regards

Stephen

Stephen,

You are right, Step-NC is much better than G n M-codes
so please if possible make blog or wiki or something to get more people involved,
hope you succeed

PS
I read that step tools already implemented rapid prototyping into their Step-NC software, so maybe If they would share their knowledge it would be of much help?

regards
supporter