Four or even more axes support in smoothie

[Stefan Hauer]

Hi everyone,

I was in contact with Arthur and Daniel regarding four axes support
for smoothie for a hotwire cutting machine. But this group is maybe a
better place to discuss ;-)

The historical/technical background:

I'm a model (plane) builder and i try to build a cnc hotwire cutting
machine to cut polystyrene. The machine consists of two independent
portals (x/y-axes and a/b-axes). Between these portals is a hot wire
mounted. The following movie shows a machine - not mine - "in action":
http://www.youtube.com/watch?v=JR83M_k4yro&feature=related

As you can see, performance is not a issue ;-)

In my case, g-code is generated with Profili2 [1] and my first
intention was to use EMC2 [2] to control the machine (i use it with my
milling machines). But then i found grbl [3] and smoothie. Smoothie
looks really promising due to it's flexible design, but it needs to be
extended to support four axes - or to be more exact: it needs to be
extended to support two parallel cartesian spaces (each with two or
more axes), which allow independent moves in each cartesian spaces,
but are coordinated in time.

As Arthur wrote in his mail:

> That's what I was shooting for. Would work well if implemented correctly.
> That's part of why I implemented the Player module and the take()/release()
> mechanism.
> Basically we would have two MotionSystem objects, both having it's own
> robot/planner/stepper, but both sharing the same Player object.
> Every time a new gcode is received, a new Block is created, whatever
> happens, and and then the combination of that gcode and that empty block is
> passed to both motionsystems.
> If they have something to do with that block they happen their respective
> axis movements to it, adjust the speen, taking into consideration that if a
> speed has already been set by the other module they shouldn't go faster than
> that.
> And then we get to the crazy part : both must do their planner calculations
> ( compute acceleration/deceleration curves ) in a way where both end up with
> the exact same absolute ( incl. acc/dec ) duration for each move.

Any ideas, how to solve this issue are welcome :-)
A sample g-code file can be found at [4].

Kind regards,

Stefan

[1] Profili2: http://www.profili2.com
[2] EMC2: http://www.linuxcnc.org
[3] grbl: https://github.com/simen/grbl
[4] Sample g-code file: http://pastebin.com/dMwi1UWn

[Daniel Dumitru]

Thank you Stefan for stepping in !

I had almost the same discussion with Arthur. What to do ? How to implement ?
2 separate engines or a single engine for 4 axes ?

I would say that it's needed a single engine that would correlate movement for all 4 axes.

I have seen somewhere that exists a version of GRBL that has 4 axes. I will look on it.
It is very good thing that you have us an example of G-Code.

Original : 

1. G1X0.7140Y0.0045A0.4086B0.0044
2. G1X0.7139Y0.0123A0.4086B0.0056
3. G1X0.7139Y0.0160A0.4086B0.0068

What do you say ? Would be an option to have it like

1. G1X0.7140Y0.0045  Z0.4086A0.0044
2. G1X0.7139Y0.0123  Z0.4086A0.0056
3. G1X0.7139Y0.0160  Z0.4086A0.0068

 
I would be tempted to implement only the 4'th axis. Can be profili configured to give to 3'rd adn 4'th axis the name Z and A ? Would be this a good ideea ?


Kind Regards,
Daniel

[ARTHUR WOLF]

2011/12/5 Daniel Dumitru <dand...@gmail.com>

That's not the problem. Smoothie can very easily handle a 4th axis ( for example the extruder on a 3d printer, or the C axis on a pick and place ), but here we are not talking about a 4th axis ( that does not infer on the movement of the machine ), but two separate 2-axis robots that must be synchronised.
Meaning that they must share the same queue of movements, and the planning calculations must take into consideration the acceleration/deceleration limits of both robots.
Fortunately Smoothie is designed in a way where this is made easier than with other firmwares, but still it's a long road to implement it, and a lot of work.

The only difficult part here is the planner and I'm beginning to see a bit better how that would work.

Cheers !

Kind Regards,
Daniel

--
Courage et bonne humeur.

[Daniel Dumitru]

That's not the problem. Smoothie can very easily handle a 4th axis ( for example the extruder on a 3d printer, or the C axis on a pick and place ), but here we are not talking about a 4th axis ( that does not infer on the movement of the machine ), but two separate 2-axis robots that must be synchronised.
Meaning that they must share the same queue of movements, and the planning calculations must take into consideration the acceleration/deceleration limits of both robots.
Fortunately Smoothie is designed in a way where this is made easier than with other firmwares, but still it's a long road to implement it, and a lot of work.

The only difficult part here is the planner and I'm beginning to see a bit better how that would work.

Cheers !

Unfortunately here I have to disagree.  I claim that this 4'th axis should be handled in CORE because it has to be part in the same interpolation algorithm.
Those events for block start can manage only the starting moment but not what's happening during composed movement.
Again I understood that GRBL has implemented 4'th axis maybe we can have a look...
Kind REgards,
Daniel

[ARTHUR WOLF]

2011/12/5 Daniel Dumitru <dand...@gmail.com>

That's not the problem. Smoothie can very easily handle a 4th axis ( for example the extruder on a 3d printer, or the C axis on a pick and place ), but here we are not talking about a 4th axis ( that does not infer on the movement of the machine ), but two separate 2-axis robots that must be synchronised.
Meaning that they must share the same queue of movements, and the planning calculations must take into consideration the acceleration/deceleration limits of both robots.
Fortunately Smoothie is designed in a way where this is made easier than with other firmwares, but still it's a long road to implement it, and a lot of work.

The only difficult part here is the planner and I'm beginning to see a bit better how that would work.

Cheers !

Unfortunately here I have to disagree.  I claim that this 4'th axis should be handled in CORE because it has to be part in the same interpolation algorithm.

 

Sure I did not say otherwise, what I'm saying is that we need two cores instead of 1. There is no difference between the XY cartesian system and the AB cartesian system, and as such XY can just be duplicated and used as AB in parralel.
Then we can use one Player and one Stepper that is common to both Robots, that's not a problem.

You seem to think that all we need to do is to take the current XYZ robot and integrate an additional axis to it. That makes no sense whatsoever with how the system currently works and how the math is done.
You *could* do that : simply add an additional axis for example A, in the core, but then you would have a robot XY that would work correctly, and a second robot ZA that would have no sense of acceleration/deceleration etc, and would be impaired by the movement of the other robot.
 

Those events for block start can manage only the starting moment but not what's happening during composed movement.

How is this a problem ?
 

Again I understood that GRBL has implemented 4'th axis maybe we can have a look...

Implementing a 4th axis is easy, the edge branch of smoothie has one ( the E axis ) ... but we don't need "just an additional axis", we need to duplicate the current Robot module, have a Planner module that takes into consideration the fact that it can be used several times by several robots for a given block, and a Stepper that can handle more than 3 axes ( that was planned anyway ).

Cheers !

Arthur.

 

Kind REgards,
Daniel

[DAniel Dumitru]

Sure I did not say otherwise, what I'm saying is that we need two cores instead of 1.

Two cores of 2 axes synchronized are the same as one core with one with 4 axes.

You seem to think that all we need to do is to take the current XYZ robot and integrate an additional axis to it. That makes no sense whatsoever with how the system currently works and how the math is done.

One system can be multidimensional. For example I have seen cutting machines with 2 parallel x-y axes and one rotary ax. For example to cut chess shapes. Or a screw ...

You *could* do that : simply add an additional axis for example A, in the core, but then you would have a robot XY that would work correctly, and a second robot ZA that would have no sense of acceleration/deceleration etc, and would be impaired by the movement of the other robot.

I disagree here again . Could be made an interpolated movement of multiple axes taking care of acceleration supported of motors.

 

Those events for block start can manage only the starting moment but not what's happening during composed movement.

How is this a problem ?

It is a huge advantage. Not a problem - it's just that I think that are not enough for this situation.

Implementing a 4th axis is easy, the edge branch of smoothie has one ( the E axis ) ... but we don't need "just an additional axis", we need to duplicate the current Robot module, have a Planner module that takes into consideration the fact that it can be used several times by several robots for a given block, and a Stepper that can handle more than 3 axes ( that was planned anyway ).

I don't have enough time because I would have given a try to my idea. First I have to finish the breakout board for mbed/xpresso/smoothie.

Regards,
Daniel

[ARTHUR WOLF]

2011/12/6 DAniel Dumitru <dand...@gmail.com>

Sure I did not say otherwise, what I'm saying is that we need two cores instead of 1.

Two cores of 2 axes synchronized are the same as one core with one with 4 axes.

No they are absolutely not, that's the whole point. In Smoothie, one core ( Robot module ) handles only one cartesian coordinate system, not two.
In Smoothie if you want two cartesian coordinate systems, you want to use two Robot modules. Or you want to fork Smoothie and do something totally different from it.

You seem to think that all we need to do is to take the current XYZ robot and integrate an additional axis to it. That makes no sense whatsoever with how the system currently works and how the math is done.

One system can be multidimensional. For example I have seen cutting machines with 2 parallel x-y axes and one rotary ax. For example to cut chess shapes. Or a screw ...

I'm not saying a system can's be multidimentional, we're talking about the best way to get smoothie to handle those additional dimentions/coordinate systems.
I'm just saying the way to do that is by duplicating instances of the Robot module.
 

You *could* do that : simply add an additional axis for example A, in the core, but then you would have a robot XY that would work correctly, and a second robot ZA that would have no sense of acceleration/deceleration etc, and would be impaired by the movement of the other robot.

I disagree here again . Could be made an interpolated movement of multiple axes taking care of acceleration supported of motors.

I absolutely don't see how. At least not without changing most of Smoothie's internals in a way where it would be crippled for other more common uses. The whole point of modularity is that it works simply for simple stuff, but that more complicated stuff is possible.
I really think the problem here is just a misunderstanding on your part of how Smoothie internally works, leading to a misunderstanding of the modification I suggest.
Anyways, really, simply suggesting to keep a single core, and add additional axes to it, really makes no sense with how Smoothie is designed.
I now see pretty much all of what is needed to do, and it's clearly not that.
 

 

Those events for block start can manage only the starting moment but not what's happening during composed movement.

How is this a problem ?

It is a huge advantage. Not a problem - it's just that I think that are not enough for this situation.

Yes and so the question was : what do you mean by not enough, what more is needed ?

Implementing a 4th axis is easy, the edge branch of smoothie has one ( the E axis ) ... but we don't need "just an additional axis", we need to duplicate the current Robot module, have a Planner module that takes into consideration the fact that it can be used several times by several robots for a given block, and a Stepper that can handle more than 3 axes ( that was planned anyway ).

I don't have enough time because I would have given a try to my idea. First I have to finish the breakout board for mbed/xpresso/smoothie.

Can't wait to see it done, do you have some previews of the schematic or something ?

Cheers !

Arthur.

Regards,
Daniel

[DAniel Dumitru]

Smoothie Breakout board preview.
Please provide constructive criticism.

DAniel

[ARTHUR WOLF]

It looks good !
Can you explain a bit more which is what ?

2011/12/6 DAniel Dumitru <dand...@gmail.com>

Smoothie Breakout board preview.
Please provide constructive criticism.

DAniel

[DAniel Dumitru]

SD\MMC - socket for sd card
magjack - socket for ethernet connection
P1 - connector for a board that it's keyboard and has led's for limit switches https://picasaweb.google.com/111390975142045997947/CNCUSB1#5624272421707480962

K1-K4 connectors for input limit switches
P2- conn for serial port - for programming lpcXpresso
P5 6 8 9 - connector for open source stepper motor driver boards - like picstep -  mainly found on pminmo.com
DB25 connector for old stepper driver board with parallel port connector
P7 - connector for my stepper driver board https://picasaweb.google.com/111390975142045997947/CNC4X35ACNCUSB#5674397202437899826

P4 - pwm out (for laser or motor inverter)

Should I give more details ?

Daniel

[bobc]

Hi there!

Looks like a nice design. I like the idea of using off the shelf CPU module Mbed/Xpresso. I can't comment too much on the hardware design, it is not really my field. Ethernet would be a very useful interface to have.

On the software side, I implemented a 4th axis for the GRBL derived R2C2 firmware, it was quite straightforward. R2C2 firmware uses standard LPC libraries and LPCUSB for USB. It might be an alternative route to consider. I haven't tried porting to XPresso, although I have a board lying around waiting.

Do you have an idea of the total cost of electronics?

[Daniel Dumitru]

https://picasaweb.google.com/111390975142045997947/NewBoards?authkey=Gv1sRgCLb4gpmN1PmuSA

Happy new year!
I have made a prototype for that board too. The most expansive component it is the pcb board next comes the magnetic ethernet jack

[bobc]

Happy new year to you too :)

Are these boards going to be on sale anywhere?

[Daniel Dumitru]

Design of board it's open source. I will publish it next few days. I just want to test it first. Regarding sales I don't know what to say... If we can get more pasionates we could order toghether. Right now it seems that we are 2 or 3.

Will you please give us more details about your port of r2c2?

On 01.01.2012 10:49, "bobc" <bobcou...@gmail.com> wrote:

[bobc]

Sure. Casainho (Jorge Pinto) and his colleague designed the R2C2 hardware, based on LPC1758, and casainho ported the "Teacup" 3D printer software to it. I then replaced the motion control part of the R2C2 firmware with the relevant part from the grbl firmware (actually chamnit's version). I then added support for a 4th stepper axis which is the extruder. The R2C2 firmware also has support for SD card, a bootloader, but not ethernet (but that would be useful to add).

The R2C2 hardware is very nice, but a little expensive. The R2C2 firmware though should be easy to port to any LPC17xx. It is in C rather than C++, which may be an advantage or disadvantage depending on your point of view ;)

There is also a guy called nullsub who is porting grbl to LPC17xx, I'm not sure what hardware he is using.

R2C2 group https://groups.google.com/forum/#!forum/r2c2-reprap-and-cnc
R2C2 website http://www.3dprinting-r2c2.com/
R2C2 firmware https://github.com/bitboxelectronics/R2C2_Firmware

[DAniel Dumitru]

Hello Bob,

Nice to have your interest on this project.
I will have a look on those links that you have listed. IT's a pity
that we are several peoples interested in this subject but each one it's
following it's own path.

Getting back to subject of thread, could you please tell us how it's
implemented your version of 4'th axis ?
It is handled in same interpolation algorithm as first 3 axes ?
Have you used this implementation to drive a machine ? Like foam cutter ?

Kind REgards,
Daniel

[bobc]

Well, the internet makes it a lot easier for people to collaborate and at least share ideas.

For the 4th axis I added it to the existing XYZ core in grbl, so it interpolates 4 axes in the same algorithm. This was fairly easy, just a question of extending some data structures and extending the code for the extra axis. Now I think about, I might rework the code to work for a variable number of axes. In a 3D printer, the 4th axis is used for the plastic extruder, which is treated like a virtual axis. The extruding of the plastic is linked to the XYZ movement so that the right amount of plastic is always extruded regardless of velocity during acceleration.

However, I have no reason to believe this would not work with a real axis. In your case the foam cutter has 4 motors, but the cutting wire is a single tool, so you want motion synchronized on all 4 motors. In the general case, any single tool may have N motors which should be interpolated in the same algorithm. I suppose theoretically you could have 2 tools each with a set of axes, and then have independent motion on each tool, but I don't think the GCode standard allows that. It is assumed that you have one tool in operation. I don't know of any machines that operate multiple tools simultaneously, but I'm not an expert in CNC.

Since smoothie was derived from grbl, I would have thought it should be easy to implement a 4 axis core, but I have not looked closely at the smoothie code.

One question, are you planning to used mbed or xpresson? And also what development environment would you use?

[DAniel Dumitru]

Arthur had a great job and made Smoothie extremely simple extensible.

Regarding 4'th axis we had different point of view. If and when I'll
have time I will try to add the 4'th axis as you did.

> One question, are you planning to used mbed or xpresson? And also what
> development environment would you use?

I will test them both (since I already have them). After those tests I
will put a LPC17XX directly on board to lower more the price of board
(right now since I have already made the board it's not so complicated
just a little more to work).

Arthur did all the hard work. Compilation it's done using Core Sourcery
GCC .
http://smoothieware.org/compiling-smoothie

If I managed to compile it everyone will do !

[Arthur Wolf]

It's not really a 4th axis, it's a 2x2 axis thing :) ( it's XY AB, and currently smoothie is XYZ+tools, and you don't want XYZ+A but XYZ-AB or XY+AB )

But smoothie is built in a way where it would be possible to do actually have TWO "grbl-like" cores, that only share the same queue and gpios ( the abstraction is there, it just needs a bit of work )
So you would have XY with it's own acceleration, jerk, etc, and AB with the same.

But understanding more about the machine itself, it looks more and more like you don't want acceleration at all, because different acceleration curves would cause the two robots not to be synchronized correctly, by a tiny bit, and you don't need acceleration, because the machine is actually quite slow.

So if you throw acceleration out of the picture, then you can have our normal XY core, and a AB tool ( both without accelation, only XY having a queue ).

That would be incredibly easy to code, it's even much simpler than the current extruder module that has advance and neat stuff like that.

Oh and BTW : Smoothie now 3D prints fine :) ( pictures as soon as my new extruder is assembled, I have a bowden one that makes small bubbles at corners )
And porting to SAM3U has begun.
And we have composite USB Mass Storage + USB Serial connectivity ( still experimental, will push as soon as the bugs are cleared ) !

Cheers !

2012/1/3 DAniel Dumitru <dand...@gmail.com>

[Stefan Hauer]

Hi everybody,

> and you don't need acceleration, because the machine is actually quite slow.

Just for your information: with our old DOS based machine, we used
cutting rates between 50mm/min and 400mm/min. To get the best result,
the machine must move with constant speed. If it cuts to fast, the
wire is bent - if it cuts to slow, the burn-off loss ist to high. So,
i think you are right, Arthur.

> So if you throw acceleration out of the picture, then you can have our normal XY core, and a AB tool ( both without accelation, only XY having a queue ).

Is there an easy way to disable the acceleration-management?

> That would be incredibly easy to code, it's even much simpler than the current extruder module

I asume it will work the same way as the extruder does (using the
different events to synchronize)?

Kind regards,

Stefan
2012/1/9 Arthur Wolf <wolf....@gmail.com>:

--
DI (FH) Stefan Hauer
Wiesenweg 8 | 4644 Scharnstein
Mobil: +43 (0)680 2021073
Web: http://stefan.tusk.at

[Arthur Wolf]

2012/1/9 Stefan Hauer <stefan...@tusk.at>

Hi everybody,

> and you don't need acceleration, because the machine is actually quite slow.

Just for your information: with our old DOS based machine, we used
cutting rates between 50mm/min and 400mm/min. To get the best result,
the machine must move with constant speed. If it cuts to fast, the
wire is bent - if it cuts to slow, the burn-off loss ist to high. So,
i think you are right, Arthur.

neat, so the "AB" as module approach should work.
 

> So if you throw acceleration out of the picture, then you can have our normal XY core, and a AB tool ( both without accelation, only XY having a queue ).

Is there an easy way to disable the acceleration-management?

not now, but that's very easy to add, it'll just be an option in the config file.

> That would be incredibly easy to code, it's even much simpler than the current extruder module

I asume it will work the same way as the extruder does (using the
different events to synchronize)?

Indeed :)

Cheers !
 

[bobc]

On Friday, 13 January 2012 09:34:56 UTC, Arthur Wolf wrote:

neat, so the "AB" as module approach should work.
  

Even if XY and AB are considered independent robots, their movement must still be coordinated, because they must start and stop movement at the same time. The distance moved on XY is often different to that on AB, e.g. in the foam cutting machines.

The CAM software assumes that XY and AB start and stop at the same time, if XY ends motion before AB has finished (or vice versa), then it will generate the wrong shape.

Since there is a single feedrate for a move, I assume that this must be considered an upper limit, so where there is a different distance on AB vs XY, then one robot will have to move slower than the specified feed rate.

[Arthur Wolf]

2012/1/14 bobc <bobcou...@gmail.com>

That's not a problem, coordination is implemented with the Player module. Actually the Extruder module does exactly that : start at the same time as the Stepper module, stop or move to the next block at the same time ( except with advance in some cases, but that's a whole different story ), and have a speed directly proportional to the main robot's speed.

[bobc]

Ok, cool.

How is the porting/new hardware going? I'd like to have another look at porting to R2C2 hardware.

[Arthur Wolf]

2012/1/14 bobc <bobcou...@gmail.com>

Ok, cool.

How is the porting/new hardware going?

The LPC-based hardware is going nicely, I hope to have a prototype in about a month.
The SAM3U hardware goes well too, the board works fine, porting is about 1/4 done.
I'm also currently documenting how to get smoothie running on a breadboard with an LPCXpresso, as several persons showed interrest in doing that.
And a company contacted me saying they intend to port Smoothie to STM32, but no release date for that.
 

I'd like to have another look at porting to R2C2 hardware.

That'd be neat ! Triffid Hunter has been working on that, but gave up due to lack of time. It's not really a matter of porting, as the code should stay unchanged, it's more a matter of getting it to compile for the new chip, and change some config options
I just got it to work with the R2C2 bootloader btw. I removed the USB-MSC part of it ( now takes only 16k ), it was not necessary :
When plugged in, Smoothie now shows up as both Serial and Mass storage, exposing the SD card, so you can copy the new firmware directly while smoothie is running, reboot, and that's it.