Smoothieware mixed axis acceleration bug becomes apparent with nozzle runout compensation

465 views
Skip to first unread message

ma...@makr.zone

unread,
May 12, 2019, 9:20:55 AM5/12/19
to OpenPnP
Hi

for those of you using Smoothieware and Runout Compensation, a known bug in Smoothieware is now definitely hurting.

It is best explained using this video:

To fix it, I created a pull request at Smoothieware a year ago. Find detailed technical description and justification there:

At the time of the PR the problem was more "theoretical" for OpenPNP, the request was rejected. But it can no longer be ignored with runout compensation. So I hope this discussion will lead the Smoothieware team to kindly reconsider.

The problem is very likely to have appeared in Mareks machine, see his post to the effect:

He was testing my pull request for some extensions of runout compensation:
But note that the problem is already present in the current develop branch version of it.

Some highlights of the discovery:

The Smoothieware "edge" firmware as of 2019-05-11 with the pull request applied can be downloaded here:

Or you can of course build your own using my branch:

I hope this is understandable enough. :-)

_Mark



Arthur Wolf

unread,
May 12, 2019, 9:25:27 AM5/12/19
to ope...@googlegroups.com
I think the main obstacle to your code being merged was we wanted the code to be more tested on 3D printers and lasers/cnc mills, and on machines with other kinematics ( delta etc ).
You might be able to find people ready to help you with testing on the smoothie-support or smoothie-dev mailing lists, or maybe on IRC or on the forums.

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/1d0aacdf-6fc6-47af-acbd-33a175758988%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


--
Courage et bonne humeur.

ma...@makr.zone

unread,
May 12, 2019, 12:21:07 PM5/12/19
to OpenPnP
On Sunday, May 12, 2019 at 3:25:27 PM UTC+2, Arthur Wolf wrote:
I think the main obstacle to your code being merged was we wanted the code to be more tested on 3D printers and lasers/cnc mills, and on machines with other kinematics ( delta etc ).
You might be able to find people ready to help you with testing on the smoothie-support or smoothie-dev mailing lists, or maybe on IRC or on the forums.

Thanks for your fast response. 

We will surely follow up with testing on the OpenPNP side and report back. Beyond that, I don't think all that you propose is possible for me (or most other contributers).

If reporting bugs and proposing fixes in itself is still useful for and appreciated by the Smoothieware project, then we're on the same page. Being a demonstrated bug after all, at a certain point the community at the receiving project should deal with it one way or another. It's a vital sign of said project. And frankly, simply closing the PR is neither helping that community process along nor making the bug go away.

_Mark

Arthur Wolf

unread,
May 12, 2019, 12:52:02 PM5/12/19
to ope...@googlegroups.com
On Sun, May 12, 2019 at 6:21 PM ma...@makr.zone <ma...@makr.zone> wrote:
On Sunday, May 12, 2019 at 3:25:27 PM UTC+2, Arthur Wolf wrote:
I think the main obstacle to your code being merged was we wanted the code to be more tested on 3D printers and lasers/cnc mills, and on machines with other kinematics ( delta etc ).
You might be able to find people ready to help you with testing on the smoothie-support or smoothie-dev mailing lists, or maybe on IRC or on the forums.

Thanks for your fast response. 

We will surely follow up with testing on the OpenPNP side and report back. Beyond that, I don't think all that you propose is possible for me (or most other contributers).

I'm not sure what you mean. Asking for testing on other machine configurations has been done before, and it's a good way to make sure this change won't cause trouble for other users ...

If reporting bugs and proposing fixes in itself is still useful for and appreciated by the Smoothieware project, then we're on the same page. Being a demonstrated bug after all, at a certain point the community at the receiving project should deal with it one way or another. It's a vital sign of said project. And frankly, simply closing the PR is neither helping that community process along nor making the bug go away.

_Mark

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Sandra Carroll

unread,
May 12, 2019, 1:11:36 PM5/12/19
to ope...@googlegroups.com

_Mark

I don’t see how the project can accept code without it being regression tested which sounds like what Arthur is asking for and is asking for authors to help in this by reaching out to the community

 

Does your code change only affect OpenPNP or does it affect all uses of smoothie?

If it effects everything using a C axis then it has to be tested,   since it interacts with X&Y as well then that in my mind would demand it be tested as broadly as possible (unless there is code specifically for OpenPNP so it can be isolated and you can prove the isolation works.

 

Just my 2 cents

 

As for the pull request,   once the project reviews and rejects it I would expect it to be closed.    It can be reopened again once it meets project requirements.

 

My view is from a systems person and seeing to many times where developers believe their code is good and don’t do the regression testing and it breaks things so only from my personal work experience.

 

Sandra

--

You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

Mark

unread,
May 12, 2019, 6:40:07 PM5/12/19
to ope...@googlegroups.com

Hi Sandra

 

This all turns out to be a misunderstanding. They just use GitHub in their own way and both the readme and the convention says otherwise. See here

 

https://github.com/Smoothieware/Smoothieware/pull/1323#issuecomment-491626231

 

> As for the pull request,   once the project reviews and rejects it I would expect it to be closed.    It can be reopened again once it meets project requirements.

 

Just as a matter of curiosity I’d be interested to understand why one would close a PR when efforts are still underway to “meet project requirements”. If you push into a closed PR, the changes won’t even show up there. Code can’t be reviewed or discussed. All the nice features of Github are useless. And the creator of the PR is reminded to delete his fork.

 

How would a community member know what ongoing work is still to be helped with, including with testing? Even if a contributer has the knowledge, access and time to recruit all these testers with all their machines outside the facilities of Github, how could he convince them to put time and effort into testing a PR that has already been dismissed by the project leaders? 

 

> I don’t see how the project can accept code without it being regression tested which sounds like what Arthur is asking for ….

 

There comes the misunderstanding. Smoothie has an “edge” branch that was officially labeled “Unstable, latest features” and a “master” branch that says “Stable, most tested”. Those descriptions were linked from the central readme (now changed because I pointed that out).

 

What I’ve come to understand as the most usual convention on Github (and similar): if you expect a contributor to tap into the community for testing, then you provide the obvious facility for that: a testing branch. You can’t expect all testers to be coders that know how to integrate merges across forks. If a project has a branch called “edge” as in “bleeding” (remember:  “Unstable, latest features”) after code review and some testing by the contributer and helpers I expect a bugfix to be merged into this “edge” for a community based “continuous integration” testing effort. Enthusiast would be using “edge” with their various machines to help the project evolve. In case of Smoothieware you even have nightly builds for downloads that members with no coding knowledge could use to help with testing. Bugs would efficiently be flushed out.

 

It is then still a long way from a testing branch like “edge” to “master” (“Stable, most tested”). Users that don’t want to (or simply can’t) take the risk of occasional – harrumph – “bleeding” (as in “edge”, hehe) would always use “master”. The others know they are taking a risk. Maybe they want to help. Maybe they absolutely need the newest feature. Maybe both. That’s how I thought the community motor works.

 

That was my misunderstanding with Smoothieware. They are no longer using these branches for what their name stands for. Instead they treat “edge” as “stable”. Consequently they are really, really very, very reluctant to accept merges. And then I took it the wrong way.

 

For all practical intents and purposes: development and testing has to take place outside of their Github repo. Harrumph. Well, it’s their project.

 

> … and is asking for authors to help in this by reaching out to the community

                      

The way I understand Github so far, by closing a PR you are effectively and efficiently denying that, as I explained above. Again, it’s their project.

 

_Mark

 

 

image001.png

Arthur Wolf

unread,
May 13, 2019, 3:25:46 AM5/13/19
to ope...@googlegroups.com
Hey.

On Mon, May 13, 2019 at 12:40 AM Mark <ma...@makr.zone> wrote:

Hi Sandra

 

This all turns out to be a misunderstanding. They just use GitHub in their own way and both the readme and the convention says otherwise. See here

 

https://github.com/Smoothieware/Smoothieware/pull/1323#issuecomment-491626231


Note : in the past I've worked on Perl and web related open-source projects, and they use the same method we do, I don't think it's uncommon, though I can see how it would feel weird if you haven't seen it done before.

 

> As for the pull request,   once the project reviews and rejects it I would expect it to be closed.    It can be reopened again once it meets project requirements.

 

Just as a matter of curiosity I’d be interested to understand why one would close a PR when efforts are still underway to “meet project requirements”.


It's just a general rule we have, mostly aimed at keeping the list of active PRs reasonably short.
Again, re-opening a PR is a click away, this is objectively not a big deal, I don't see why all the fuss.

If you push into a closed PR, the changes won’t even show up there. Code can’t be reviewed or discussed. All the nice features of Github are useless.


Until you re-open the PR ...

And the creator of the PR is reminded to delete his fork.

 

How would a community member know what ongoing work is still to be helped with, including with testing? Even if a contributer has the knowledge, access and time to recruit all these testers with all their machines outside the facilities of Github, how could he convince them to put time and effort into testing a PR that has already been dismissed by the project leaders? 


Again : It hasn't been dismissed. We moved it from one pile to another, and it can go back trivially easily.

 

> I don’t see how the project can accept code without it being regression tested which sounds like what Arthur is asking for ….

 

There comes the misunderstanding. Smoothie has an “edge” branch that was officially labeled “Unstable, latest features” and a “master” branch that says “Stable, most tested”. Those descriptions were linked from the central readme (now changed because I pointed that out).

 

What I’ve come to understand as the most usual convention on Github (and similar): if you expect a contributor to tap into the community for testing, then you provide the obvious facility for that: a testing branch.


That's not how we do things.
We request the person make a .bin ( which you are doing anyway right ? ), and then the community can use that to test and report any issues.
We don't want testers to have to compile themselves, so it's perfectly fine just posting a .bin/link to a .bin somewhere and linking to that in your request for testers. That's how we've done things in the past and it works very well.

You can’t expect all testers to be coders that know how to integrate merges across forks.


That's why you do a .bin :) ( in your case two, since we want to test both CNC mode and non-CNC mode )

If a project has a branch called “edge” as in “bleeding” (remember:  “Unstable, latest features”) after code review and some testing by the contributer and helpers I expect a bugfix to be merged into this “edge” for a community based “continuous integration” testing effort. Enthusiast would be using “edge” with their various machines to help the project evolve. In case of Smoothieware you even have nightly builds for downloads that members with no coding knowledge could use to help with testing. Bugs would efficiently be flushed out.

 

It is then still a long way from a testing branch like “edge” to “master” (“Stable, most tested”). Users that don’t want to (or simply can’t) take the risk of occasional – harrumph – “bleeding” (as in “edge”, hehe) would always use “master”. The others know they are taking a risk. Maybe they want to help. Maybe they absolutely need the newest feature. Maybe both. That’s how I thought the community motor works.


Master was a thing in the beginning, it's not now. If you find other references to it don't hesitate to point them out.

 

That was my misunderstanding with Smoothieware. They are no longer using these branches for what their name stands for. Instead they treat “edge” as “stable”. Consequently they are really, really very, very reluctant to accept merges.


We have strict standards both in terms of testing, function and code quality. We are not reluctant to accept merges.

And then I took it the wrong way.

 

For all practical intents and purposes: development and testing has to take place outside of their Github repo. Harrumph. Well, it’s their project.


Not sure what you mean here.

 

> … and is asking for authors to help in this by reaching out to the community

                      

The way I understand Github so far, by closing a PR you are effectively and efficiently denying that,


That's not the case. There is no denying here, you can re-open the PR at anytime.
You are making a mountain out of a button :)


as I explained above. Again, it’s their project.

 

_Mark

 

 

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.
Message has been deleted
Message has been deleted

Marek T.

unread,
May 16, 2019, 6:29:42 AM5/16/19
to OpenPnP
Hi fish,
Smoothieware is working on the official update for this issue. It is here if you'd like to test it. Unfortunatelly I can't do this on the moment on my actual setup.

W dniu czwartek, 16 maja 2019 11:48:16 UTC+2 użytkownik fish napisał:
Just compiled smoothieware with Mark's fixes and i like it - no more stall's at runout compensation:

msw.PNG












Message has been deleted

Marek T.

unread,
May 16, 2019, 7:34:38 AM5/16/19
to OpenPnP
I don't depreciate Mark's professional efforts at all, I feel the same.
But better to have official firmware working properly, you never know when need to upgrade Smoothie and Mark can change profession to lions' feeding in Africa ;).
So I think it is worth to test official solution too.

W dniu czwartek, 16 maja 2019 13:11:52 UTC+2 użytkownik fish napisał:
Yes, I know - I follow the development.

But Mark's work in this particular case makes a very professional impression, earns unrestricted respect and currently enjoys my fullest confidence :)
Message has been deleted

ma...@makr.zone

unread,
May 16, 2019, 5:13:03 PM5/16/19
to OpenPnP

On Thursday, May 16, 2019 at 11:48:16 AM UTC+2, fish wrote:
Just compiled smoothieware with Mark's fixes and i like it - no more stall's at runout compensation:


Thanks fish!

Very nice looking machine in deed. 

_Mark

ma...@makr.zone

unread,
May 16, 2019, 5:19:16 PM5/16/19
to OpenPnP

Hi all


in addition to the acceleration limit fix, I implemented fixes in the junction deviation algorithm. As described here:
Smoothieware/Smoothieware#1323 (comment)


The firmware can be found here:
https://makr.zone/firmware_PR1323_2019-05-16.bin


Frankly I doubt the junction deviation will be acting up in the current OpenPNP version, as OpenPNP is always waiting for single move segments to complete (M400). But as we are constantly optimizing things it might become relevant soon. It took one year for the acceleration fix to become essential, but now it is.


A big thank-you for all testers.


_Mark


ma...@makr.zone

unread,
May 17, 2019, 2:37:36 PM5/17/19
to OpenPnP
Hi

Good news!

Things took a good turn from here
to here
and we're back in the supergreen.

I just tested the new Smoothieware edge and I am happy to confirm that it resolves the issue for OpenPNP + runout calibration.

People using Smoothieware and runout calibration should use the new edge.
My PR addressed some additional issue that are not relevant for OpenPNP now.

_Mark

Marek T.

unread,
May 17, 2019, 2:42:35 PM5/17/19
to OpenPnP
I can confirm 1398 works good.
But calibration still not - the report on the git, more tests required.

ma...@makr.zone

unread,
May 17, 2019, 2:54:01 PM5/17/19
to OpenPnP
Hi Marek

> I can confirm 1398 works good.

Did you do the not-so-good tests you reported with 1398?

You should use edge now. 1398 was abandoned. See here:

_Mark

Marek T.

unread,
May 17, 2019, 2:57:46 PM5/17/19
to OpenPnP
 Hi Mark,
I have played with:
- 8 days edge - works wrong
- your edge you sent me - is ok
- yesterday edge compiled CNC + 1323 - is ok
- yesterday edge compiled CNC + 1398 - is ok

Arthur Wolf

unread,
May 18, 2019, 3:43:57 AM5/18/19
to ope...@googlegroups.com
We know the solution implemented in latest edge isn't perfect. We chose to do a simpler fix right now so things work for openpnp, and work on the deeper/harder issues on a longer timescale.
If you find any reproducible issue/bug with the current code, don't hesitate to open issues about it.

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/52e70d0f-d49c-42aa-8510-24b495195b89%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Marek T.

unread,
May 18, 2019, 7:39:18 AM5/18/19
to OpenPnP
Hi Mark,
I need just info not solution.
Understand you use 3D standard compilation and you have XYZA axes configured (alfa, beta, gamma, delta).
If you command relative G0 X2 Y2 Z2 A360 - is the final move of every axes finished in the same moment being slowed down to long-time-taking A360, or XYZ is short time taking and A is finished after other axes motion.
In my case everything is slowed down to A and I need info is it normal or not.

ma...@makr.zone

unread,
May 18, 2019, 9:48:26 AM5/18/19
to OpenPnP
Hi Marek

> everything is slowed down to A and I need info is it normal or not.

Yes it is perfectly normal. It must be like that: so-called coordinated moves. Smoothie does only support coordinated moves (like all Open Source controllers, as far as I know).

Some professional controllers also support uncoordinated moves for G0 (as opposed to G1). Those move the axes in the fastest possible way, not necessarily in a straight line in XYZ space. They may not finish at the same time. But the programmer is then responsible to make sure no collision happens.

You see the typical "Hockey-stick" shaped moves here:

The reason is acceleration. If one lightweight axis (e.g. the head on X) has a longer way to go but can accelerate faster than the other heavier axis (e.g. the portal Y), it can accelerate freely without coordinating with the other, more sluggish axis. The other way around because the Y axis has a shorter way it does not need to wait for the X axis to travel all the long way. Put both together an you get a faster move.

But again: Smoothie does not support that and everything is as it should be.

_Mark

Marek T.

unread,
May 18, 2019, 10:10:31 AM5/18/19
to OpenPnP
Thanks for info! So I know I don't need to dig in settings :-).

I was sure that PAXIS=3 means that only first three axes XYZ are coordinated, paxis=4 means xyza, etc. But it looks it's something other...

My Philips originally gets XY in coordinated move and wait until C achieves a position. C motion can be finished by the xy is got or after. So feed and acceleration of XY is never tuned to the C properties.
Heard to say what is better, I'm used to the Philips way. Maybe C can be made as extruder module and G0 XYE let get E move not related to XY? Maybe I'll try but it probably means "farewell rotation axis endstop"...

Mark

unread,
May 18, 2019, 12:40:16 PM5/18/19
to ope...@googlegroups.com

PAXIS only determines how the feedrate is determined.

 

Usually when you give a feedrate using the F value, it only accounts for the XYZ distance i.e. the Euclidean distance.

https://en.wikipedia.org/wiki/Euclidean_distance

 

If an A, B or C axis is also given, it is not accounted for. In these cases the axis turns in coordination with the XYZ axes. If the X, Y, Z move is small and the rotation move is large, the actuator/stepper limit may be reached. It then slows the whole move down in order not to stall the rotation stepper. That's what we fixed now.

 

If A, B or C move alone (without any X, Y or Z) the given federate is interpreted for these axes (again the Euclidean Distance, but degrees instead of millimeters).

 

Now if you set PAXIS to a value higher than 3, the Euclidean distance is spanned over so many axes. This only makes sense if the additional axes are linear, not rotary axes. For instance if you have a controller with X, Y and Z1, Z2, Z3 for nozzles. Then you would best compile with PAXIS=5.

 

_Mark

 

-----Ursprüngliche Nachricht-----
Von: ope...@googlegroups.com [mailto:ope...@googlegroups.com] Im Auftrag von Marek T.
Gesendet: Samstag, 18. Mai 2019 16:11
An: OpenPnP
Betreff: Re: [OpenPnP] Re: Smoothieware mixed axis acceleration bug becomes apparent with nozzle runout compensation

--

You received this message because you are subscribed to the Google Groups "OpenPnP" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.

Marek T.

unread,
May 18, 2019, 1:58:31 PM5/18/19
to OpenPnP
I love the way you explain the things with every details, you should be a teacher :-).
Coordinated move XYZ is understandable.
C, in my oppinion, could easy live with its own life and finish the move how possibly can no looking on other axes. But understand - no way with Smoothie.

W dniu sobota, 18 maja 2019 18:40:16 UTC+2 użytkownik ma...@makr.zone napisał:

PAXIS only determines how the feedrate is determined.

 

Usually when you give a feedrate using the F value, it only accounts for the XYZ distance i.e. the Euclidean distance.

https://en.wikipedia.org/wiki/Euclidean_distance

 

If an A, B or C axis is also given, it is not accounted for. In these cases the axis turns in coordination with the XYZ axes. If the X, Y, Z move is small and the rotation move is large, the actuator/stepper limit may be reached. It then slows the whole move down in order not to stall the rotation stepper. That's what we fixed now.

 

If A, B or C move alone (without any X, Y or Z) the given federate is interpreted for these axes (again the Euclidean Distance, but degrees instead of millimeters).

 

Now if you set PAXIS to a value higher than 3, the Euclidean distance is spanned over so many axes. This only makes sense if the additional axes are linear, not rotary axes. For instance if you have a controller with X, Y and Z1, Z2, Z3 for nozzles. Then you would best compile with PAXIS=5.

 

_Mark

 

-----Ursprüngliche Nachricht-----
Von: ope...@googlegroups.com [mailto:ope...@googlegroups.com] Im Auftrag von Marek T.
Gesendet: Samstag, 18. Mai 2019 16:11
An: OpenPnP
Betreff: Re: [OpenPnP] Re: Smoothieware mixed axis acceleration bug becomes apparent with nozzle runout compensation

 

Thanks for info! So I know I don't need to dig in settings :-).

 

I was sure that PAXIS=3 means that only first three axes XYZ are coordinated, paxis=4 means xyza, etc. But it looks it's something other...

 

My Philips originally gets XY in coordinated move and wait until C achieves a position. C motion can be finished by the xy is got or after. So feed and acceleration of XY is never tuned to the C properties.

Heard to say what is better, I'm used to the Philips way. Maybe C can be made as extruder module and G0 XYE let get E move not related to XY? Maybe I'll try but it probably means "farewell rotation axis endstop"...

 

--

You received this message because you are subscribed to the Google Groups "OpenPnP" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ope...@googlegroups.com.

Trampas Stern

unread,
May 20, 2019, 4:41:22 PM5/20/19
to OpenPnP

The thing about coordinated moves is that if you do 

G1 X2 Y2 Z2 A360  and the A axis is the slowest then the entire move takes the time it takes to rotate A360. 

Now if you go
G1 A360
G1 X2 Y2 Z2

then move takes longer as it takes time to rotate A 360 and then time to move XYZ in coordinated fashion. 

Hence no matter if do the move of each axis coordinated or not it takes the same time.  There are some restrictions to this when the maximum velocity is limited by the Euclidean distance.  For example if you maximum velocity for each axis is 100mm/min and you move from 0,0 - 100,100 then the Euclidean distance is 141.4mm, so should the move take 1 min or 1.414 mins?  
The way I see this implemented is that the move should take 1 min with feed rate being the 141.4 mm/min, unless you have a Maximum feed rate set to less than 141.4 mm/min.  If the maximum feed rate was set to 110mm/min then the coordinated move would take more than 1min, while an uncoordinated move could in theory move faster, might follow the same path but ignore the Euclidean speed limit as it is not a machining operation. 

ma...@makr.zone

unread,
May 20, 2019, 4:59:26 PM5/20/19
to OpenPnP
Trampas you're seeing it exactly right.

One caveat is that OpenPNP has only one feedrate for both degrees and millimeters. So if you move the rotation axes separately you might get an even slower rotation due to the Euclidean "distance" over degrees being quite large numerically.

_Mark


Marek T.

unread,
May 20, 2019, 9:48:04 PM5/20/19
to OpenPnP
Because of different problems with my servos tuning I don't like have XY slowed down too much.

And it is not as you say in case of my original machine.
XYA start at THE SAME moment there (not first A and then XY) but just XY are coordinated and A is finishing after them. So XY move is fast, not slowed down by slower A.

Mark

unread,
May 21, 2019, 1:34:01 AM5/21/19
to ope...@googlegroups.com

Marek,

 

like I explained these are uncoordinated moves. Either reprogram Smoothieware :-) or simply change your MOVE_TO_COMMAND in OpenPNP simply doing the X, Y, (Z?) and the C on separate lines of G code.

 

 

 

G0 {X:X%.4f} {Y:Y%.4f} {Z:Z%.4f} F{FeedRate:%.0f} ; Send standard Gcode linear move

G0 {Rotation:E%.4f}; Send standard Gcode rotational move

M400 ; Wait for moves to complete before returning

 

 

_Mark

 

Marek T.

unread,
May 21, 2019, 2:36:44 AM5/21/19
to OpenPnP
Yes Mark, It is clear about the moves coordination. Just answered to Trampas.
Planned to test settings like you say, but I think Smoothie will start rotate A after when finish with previous command XY(I don't use Z) service.
Reply all
Reply to author
Forward
0 new messages