- Posts: 27
- Thank you received: 114
New Trajectory Planner - Testers/programs wanted
- Rick G
- Offline
- Junior Member
-
I think the problem was that the original was the master with Robs stuff added, whereas this is all in his fork of the master
I just cloned Robs fork, checked out the experimantal branch and built it
Should installation instructions be changed?
Rick G
Please Log in or Create an account to join the conversation.
- ArcEye
- Offline
- Junior Member
-
- Posts: 22
- Thank you received: 240
Rick G wrote:
I think the problem was that the original was the master with Robs stuff added, whereas this is all in his fork of the master
I just cloned Robs fork, checked out the experimantal branch and built it
Should installation instructions be changed?
Rick G
No I think they are fine as they are Rick.
This was in his experimental, Alpha branch, which he wanted confirmation on before pushing over to the Beta that everyone is being asked to test.
I just assumed that they were different branches of the same repo originally, which is where the (my) confusion came from
regards
Please Log in or Create an account to join the conversation.
- Rick G
- Offline
- Junior Member
-
- Posts: 27
- Thank you received: 114
Thanks, I will give it a try this week.
Rick G
Please Log in or Create an account to join the conversation.
- Rick G
- Offline
- Junior Member
-
- Posts: 27
- Thank you received: 114
It is useless code but might show some differences and offers an easy way to try different variables.
The NGCGUI sample configuration was used.
To exaggerate the differences the acceleration of the X and Y axis was set to an extremely low rate of .05
Set for inches.
Use MDI to set G64 Pn Qn before running.
This test was done with G64 P.001 Q.001
There is a move to the start location, a lead in Arc then a circular path made of segments and finally a lead out arc.
The velocities
Original TP...
Lead in arc max 4.74 slows at end to enter circular path.
Circular path max 3.82 - 3.32
Lead slows to 1.5
New TP...
Lead in arc max 3.32 slows at end .04 to enter circular path.
Circular path max 5.24 - 5.02
Lead out slows to .05
Highest circular path speeds at 45/135/225/315 deg when X and Y are both moving closest to the same rate.
There appears to be a dramatic increase in the circular path speed 3.82 vs 5.24.
The transition from arc to segment and back again appears to cause more of a slow down.
To try some text samples NGCGUI and true type tracer might be used.
As a side note auto homing seems to ignore the acceleration settings on some moves in both cases.
Rick G
Please Log in or Create an account to join the conversation.
- skunkworks
- Offline
- Moderator
-
- Posts: 351
- Thank you received: 153
You can see it if you would run a program like
if you run this the second time (to be sure the tool is starting at the begining of the line segment) - you can see it slow down at the start of the first line-arc transistion and then again at the last line-arc transistion.
I know Rob has talked about this on the list and is looking at rectifying it. ah - found it
That's by design, though it's not optimal. I abort optimization if a
segment is already in progress , to prevent stepping on tp 's toes. Also,
the optimization doesn't run on the last segment in the queue, because that
segment has the potential to be shortened by a future blend arc.
Both of these problems are fixable. I was looking into how to detect "end
if file" in the code, and it seems that the interp_waiting state
corresponds to the interpreter running out of valid moves (rather than just
having a full queue). If this is the case, then a simple check should be
enough to flag the last move. Similarly, I could make blend arc creation
work on the unchanged portion of a segment in progress.
As far as homing - can you give more info? I have not seen constraint violations in quite a while. (homing and otherwise)
sam
Please Log in or Create an account to join the conversation.
- Rick G
- Offline
- Junior Member
-
- Posts: 27
- Thank you received: 114
As far as homing - can you give more info? I have not seen constraint violations in quite a while. (homing and otherwise)
I just took the sim NGCGUI ini and reduced the acceleration to the extremely low rate for X and Y. Left Z alone.
When you hit home all there is a combination of slow and fast moves.
O.K. I will add a extra move at the start and an extra move at the end to see what happens.
However the main path shows a substantial improvement in speed, and thus the possibility of maintaining a more constant cut speed during a program. A big deal.
Rick G
Please Log in or Create an account to join the conversation.