https://reprap.org/forum/list.php?141 Mon, 05 Oct 2026 16:25:46 -0400 Phorum 5.2.23 https://reprap.org/forum/read.php?141,137754,137754#msg-137754 https://reprap.org/forum/read.php?141,137754,137754#msg-137754
Any news for this project?]]> fma STEP-NC Thu, 14 Jun 2012 05:39:44 -0400 https://reprap.org/forum/read.php?141,32372,32372#msg-32372 https://reprap.org/forum/read.php?141,32372,32372#msg-32372 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.
==============================================================================]]> stephen george STEP-NC Mon, 15 Mar 2010 01:19:24 -0400