This won't help in the general case, because the arc is either in the XZ plane (G18) or in the YZ plane (G19). Only if you have completely orthogonal moves in X or Y would this be a smooth path. But such moves almost never happen in OpenPnP, most are at arbitrary diagonals.
Even if you were to select the closer of the two planes, you get
a corner in the path, at the top. The corner angle would be
blunter than 90°, so maybe it would allow going through that
corner a bit faster (junction
deviation), but your overall path is longer, so I don't
think this will gain much.
The real solution is supporting something like G64:
https://linuxcnc.org/docs/2.6/html/gcode/gcode.html#sec:G64
And then calculate the blending dynamically, i.e. large blending
for long moves, only little blending for short moves.
_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 view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/2091949c-a319-4aac-99dc-4757fd69c09bn%40googlegroups.com.
Mark,
IMO this gcode:
G18;
..
G03 X3 Z15 Y3 R5;
Is an arc in a plane at 45 degree to the XZ plane and orthogonal to XY.
So using G18 and G19 arc in any vertical plane is possible. (I think the video proves that)
However I have no Idea whether blending is better than arcs.
But definitely I want to ask why arc was not considered so long, when it is already available.
R
--
You received this message because you are subscribed to a topic in the Google Groups "OpenPnP" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openpnp/PxliLkN6JBU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openpnp+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/f0a6e78d-b5f7-aee5-a351-bd0402fd2e6b%40makr.zone.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/f0a6e78d-b5f7-aee5-a351-bd0402fd2e6b%40makr.zone.
勇気とユーモア
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CAMHZkm4%2BTxYz%2Bw5RM3zjSd1%3D0nFimMp959_DL2uV1tkm1Dyraw%40mail.gmail.com.
> IMO this gcode: G18; G03 X3 Z15 Y3 R5; Is an arc in a plane at 45 degree to the XZ plane and orthogonal to XY.
I don't think that is an arc in the 45° plane. It is a helix
(like a screw thread) with 3mm climb in the Y axis.
As the helix climb is constant per angle, this means there are even two corners, one at the base of the arc, and one at the top. Two corners means this is certainly slower than rectangular motion.
https://www.cnccode.com/4132/siemens-cnc-milling-g02-g03-turn-helix-interpolation
Grbl is no exception, you can see here, there's only 2D math :
https://github.com/grbl/grbl/blob/9180094b72821ce68e33fdd779278a533a7bf40c/grbl/gcode.c#L676
and btw. what would be the point of G18 and G19 if the command could specify the plane 😉?
> You *could* generate the arc as a series of small gcodes (do the full 3D math in openpnp)
OpenPnP can do that!
See here:
https://github.com/openpnp/openpnp/wiki/Motion-Planner#motion-blending
Unfortunately, after having programmed all this, it turned out the USB serial speed of the tested controllers is not fast enough. It takes more time to send these fine-grained paths, than what it saves in motion time
😭.
In theory it all worked nicely, I'll try to find the simulated
illustration.
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CAMHZkm4%2BTxYz%2Bw5RM3zjSd1%3D0nFimMp959_DL2uV1tkm1Dyraw%40mail.gmail.com.
> IMO this gcode: G18; G03 X3 Z15 Y3 R5; Is an arc in a plane at 45 degree to the XZ plane and orthogonal to XY.
I don't think that is an arc in the 45° plane. It is a helix (like a screw thread) with 3mm climb in the Y axis.
As the helix climb is constant per angle, this means there are even two corners, one at the base of the arc, and one at the top. Two corners means this is certainly slower than rectangular motion.
https://www.cnccode.com/4132/siemens-cnc-milling-g02-g03-turn-helix-interpolation
Grbl is no exception, you can see here, there's only 2D math :
https://github.com/grbl/grbl/blob/9180094b72821ce68e33fdd779278a533a7bf40c/grbl/gcode.c#L676
and btw. what would be the point of G18 and G19 if the command could specify the plane 😉?
> You *could* generate the arc as a series of small gcodes (do the full 3D math in openpnp)
OpenPnP can do that!
See here:
https://github.com/openpnp/openpnp/wiki/Motion-Planner#motion-blending
Unfortunately, after having programmed all this, it turned out the USB serial speed of the tested controllers is not fast enough. It takes more time to send these fine-grained paths, than what it saves in motion time
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/26919260-9ccf-e9f7-fcef-75385d856b89%40makr.zone.
勇気とユーモア
Well said Mark. What really matters is that angle. Worst case this angle is 22.5 degree.
IMO this helix could still be considered and the practical results might be appealing compared to the development effort.
I will give this one also a try….
From: ope...@googlegroups.com <ope...@googlegroups.com> On Behalf Of mark maker
Sent: Thursday, December 2, 2021 11:05 PM
To: ope...@googlegroups.com
Subject: Re: [OpenPnP] Arc Motion
> IMO this gcode: G18; G03 X3 Z15 Y3 R5; Is an arc in a plane at 45 degree to the XZ plane and orthogonal to XY.
--
You received this message because you are subscribed to a topic in the Google Groups "OpenPnP" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openpnp/PxliLkN6JBU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openpnp+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/26919260-9ccf-e9f7-fcef-75385d856b89%40makr.zone.
Hi Arthur,
Here is a gcode fragment to make a diagonal pick and place from 0,0 to 100,100
using interpolated arcs.
Z plane is 15mm.
Safe height is 10mm (i.e the minimum height the head retracts up before making any horizontal component move.
G01 X0 Y0 Z0 F10000
Z10.
X0.0141 Y0.0141 Z10.4467
X0.0564 Y0.0564 Z10.8897
X0.1265 Y0.1265 Z11.3257
X0.2239 Y0.2239 Z11.7511
X0.3478 Y0.3478 Z12.1624
X0.4971 Y0.4971 Z12.5565
X0.6707 Y0.6707 Z12.9302
X0.8673 Y0.8673 Z13.2804
X1.0851 Y1.0851 Z13.6043
X1.3226 Y1.3226 Z13.8995
X1.5778 Y1.5778 Z14.1635
X1.8486 Y1.8486 Z14.3941
X2.1329 Y2.1329 Z14.5897
X2.4284 Y2.4284 Z14.7485
X2.7328 Y2.7328 Z14.8694
X3.0436 Y3.0436 Z14.9514
X3.3583 Y3.3583 Z14.9937
X3.5355 Y3.5355 Z15.
X6.9773 Y6.9773
X96.4645 Y96.4645
X96.6417 Y96.6417 Z14.9937
X96.9564 Y96.9564 Z14.9514
X97.2672 Y97.2672 Z14.8694
X97.5716 Y97.5716 Z14.7485
X97.8671 Y97.8671 Z14.5897
X98.1514 Y98.1514 Z14.3941
X98.4222 Y98.4222 Z14.1635
X98.6774 Y98.6774 Z13.8995
X98.9149 Y98.9149 Z13.6043
X99.1327 Y99.1327 Z13.2804
X99.3293 Y99.3293 Z12.9302
X99.5029 Y99.5029 Z12.5565
X99.6522 Y99.6522 Z12.1624
X99.7761 Y99.7761 Z11.7511
X99.8735 Y99.8735 Z11.3257
X99.9436 Y99.9436 Z10.8897
X99.9859 Y99.9859 Z10.4467
X100. Y100. Z10.
Z0.
--
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 view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/000301d7e7ec%24f641e250%24e2c5a6f0%24%40gmail.com.
勇気とユーモア
> Could I get some sample gcode for this?
First let me tell you that Grbl hardly has a planner queue that
is long enough, even the 32bit controller like Smoothie and Duet
are quite challenged by that (RAM-wise, and processing wise). Grbl
will not be able to look ahead until the end of the segment
sequence and therefore it will conservatively decelerate way
too early. You will get very strange, stuttery moves!
Furthermore: this only works if you have an acceleration control
command like M204.
But just to get the G-code as an academic exercise, enable the
feature in OpenPnP as follows. Please take the time to really
follow this carefully step by step (however no guarantee that I
didn't miss something):
Then try it 😎
_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 view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/000301d7e7ec%24f641e250%24e2c5a6f0%24%40gmail.com.
I have to be more specific:
I have to say that I don't know if Smoothie would be performant enough (in terms of processing power) to handle a larger queue, even if the RAM was large enough.
When does Smoothie 2 finally come out? 😛
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CAMHZkm7486hSwqn0zMX4WWKDNLmmpT4J5w%2BQq%2BjtH5MO7yr6Yg%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/c07eaf9c-018d-f342-7437-fb23c3a9eafb%40makr.zone.
勇気とユーモア
> Could I get some sample gcode for this?
Sorry just saw that it is you who is asking, Arthur, not Ravi.
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/96671a92-8b17-6666-8381-fdbd4f677686%40makr.zone.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/3badf620-6475-a229-aa1e-273426d6525c%40googlemail.com.
勇気とユーモア
Hi Jan
OpenPnP can already compress the Gcode:
All this was used in my tests with regular Smoothie and Duet 3 to
no avail.
There is currently no support for relative motion. That would
probably help a bit here, but create other problems.
Regular Smoothie has not enough RAM, I was able to increase the queue to 48 before it stopped working. But that's not enough. For fully smoothed operation you probably need 100-300 segments. Regular Smoothie has very fast native USB serial and flow control, but I still don't know whether it would be fast enough.
> 19 characters transfered at 115200 baud with 8N1
would require 1.65ms.
> Would that provide enough speed and space for
smooth motion blending?
The CHM-T36VA serial bridge to the STM32F407 is slow and shaky, flow control seemed not to work properly. Experiments, I think done by Nélio, did not work. Maybe there would be an option to connect native USB serial?
Duet 3 seems to have enough RAM, but its serial USB serial, while
being improved lately, is still way too slow. The last experiments
(I think by Wolfgang) did not really work out.
One problem is also to let the planner wait until it has received the whole sequence for look-ahead planning. If the planner starts planning/executing motion too quickly, it will rush into premature deceleration, not yet seeing the sequence to the end. We added some new grace period support to Duet, i.e. it would wait longer, or until an M400 is received, which typically signals the end of a sequence. I'm not sure we tested the latest incarnation of that. Any controller supporting such paths would have a grace period+release feature too.
Here is a simulations with the OpenPnP Motion Planner (dual
nozzle machine, i.e. see the nozzle switch in the back row,
showing as inverted Z moves):
The gains are moderate (-16.6% time). All that planning as true 3rd order motion also requires solving time (in Java). Add to that the serial communication time and the gains were gone. 😭
I'm now quite convinced that controller side support for
smoothing is the way to go.
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CAMHZkm4Lz%3DdHzfzpuBB1AVXXwzS1zNKo%3DD4DtqNX_mVqu_2c1g%40mail.gmail.com.
> flow-control is not needed.
This is not usually true. It takes considerable time to interpret
the G-code, put the motion segments in the queue, and plan the
ramps. These controllers are usually simple in that they always
re-plan everything after receiving a new motion segment. Also
there is usually no such thing as multi-threading and/or smart
queue locking, this stuff is done in interrupt handlers that do
one whole thing at a time. This means that
locking/blocking times are large, the serial receive buffer can
overflow and it must be flow controlled.
And that is also what was observed on every controller
so far: unless flow control is done right, you get erratic
behaviour or even hangs.
> a) I've read that USB interfaces might cause trouble because of ground loops.
That's the same for serial. It won't work without either
isolation or grounding.
> Yes, USB isolators are easy to add.
Yes, and IMHO they are a MUST for any fast NC machine. My Azteeg
Smoothie clone controller has one built-in, as it should.
> b) Fitting USB-serial into the existing firmware would be some work and - to my understanding - only make sense if we would gain significant benefits.
These gains would certainly be significant. We're talking a whole
different category of performance!
> why not try to optimize the queue/memory layout...
Improving the comms speed or enlarging the queue is just treating the symptoms. Like I said: the real solution IMHO lays in supporting that stuff natively on the controller. Support motion blending (G64) and true 7-segment 3rd order control. But I would go for a more performant MCU, like the Teensy 4.1 and a separate driver board, like @billsef did:
https://github.com/bilsef/teensy4_pnp_controller
https://groups.google.com/g/openpnp/c/79hyOIzmnxY/m/Bczl2T3QAgAJ
_Mark
junction_deviation that is currently Grbl is not to be confused with real curving. The Grbl junction_deviation pretends that there is a "virtual" curve, but does not actually make one. This is an optimization so the machine does not have to decelerate to zero velocity in junctions, instead it pretends there is a curve and therefore can move through the corner at speed. This is only tolerable because the machine and the motors (electromagnetic fields) are flexible to a degree, they will just be banged through. AFAIK, for stepper motors it can only tolerate deviations that don't threaten to lose steps, i.e. in the order of a half-step, typically sub-millimeter.
https://onehossshay.wordpress.com/2011/09/24/improving_grbl_cornering_algorithm/
"Lastly, keep in mind this method is a virtual path deviation that is only used for robustly computing the junction speed and does not actually mean there is a physical path deviation in your CNC machine."
To plan true physical curves would be an altogether different
matter.
_Mark
junction_deviation that is currently Grbl is not to be confused with real curving. The Grbl junction_deviation pretends that there is a "virtual" curve, but does not actually make one. This is an optimization so the machine does not have to decelerate to zero velocity in junctions, instead it pretends there is a curve and therefore can move through the corner at speed. This is only tolerable because the machine and the motors (electromagnetic fields) are flexible to a degree, they will just be banged through. AFAIK, for stepper motors it can only tolerate deviations that don't threaten to lose steps, i.e. in the order of a half-step, typically sub-millimeter.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/481bc813-d230-d7c3-0e66-d8b882cd39f3%40makr.zone.
勇気とユーモア
> This is obvious if you have a flimsy machine, high acceleration and strong junction deviation, you'll see the machine "rock" as the inertia from the movement is transferred to the frame.
> If however your machine is very sturdy, that energy is transformed in other ways: heat, sound etc. This is one reason why more expensive machines tend to be heavier/have sturdier frames
I do agree that heavier, stiffer machines with the corresponding
much more powerful motors to drive the heavier rig, do allow for
higher accelerations, while retaining positioning accuracy.
But I'm not sure it is actually an advantage in terms of
allowable pretend junction deviation: If the machine does
not give way, this means that exceedingly higher accelerations
(and jerk etc.) will take place. Acceleration/jerk are obtained by
essentially dividing the momentum by the flex, i.e. a
machine with near zero flex would have near infinite
acceleration/jerk, i.e. no motor can hold that! Of course, if you
have closed loop servos, it will correct any deviation after the
fact, but then your stiffness and accuracy is effectively
gone too, and you might get ringing, again due to the stiffness.
A flimsier/softer machine might take these deviations more
"naturally". It will just give way and ride through the bumps like
on suspension, with a lot of damping too. Even with open loop
steppers it remains practicable. Every cheap but still damn good
3D printer is a testimony of that balance, that after years of
tuning may be "just right". This sometimes becomes visible, such
as
when Thomas Sanladerer "upgrades" his PRUSA with linear rails,
making it much stiffer, and then sees how the prints get worse,
not better. I'm sure that true motion blending (instead of
just pretend junction deviation) could make that ringing
go away.
So I would say that a stiffer machine does not necessarily
benefit less from advanced motion control (like true
motion blending), it may sometimes even be the other way around.
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CAMHZkm7o1Ydz9%3DXBppV1fynRL9dx1e7zhr_kYXO3_qokFhiUJA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/d0a0ca6e-ced6-856b-c768-6f5ab32218e5%40makr.zone.
Hi Harjit,
The way I did it in OpenPnP is linked below. The idea
is somewhat described in the comment here.
But today/in a controller I would probably do it differently. Rather than "overshoot" into an uncoordinated move at Safe Z, I would follow the G64 idea/NIST standard, to smooth one motion into the next, i.e. not necessarily reach the corner point.
Code parts:
Single Motion (interface to use):
https://github.com/openpnp/openpnp/blob/develop/src/main/java/org/openpnp/model/Motion.java
Single Motion Profile (3rd order ramps, uncoordinated moves etc.). That's the hardest part:
https://github.com/openpnp/openpnp/blob/develop/src/main/java/org/openpnp/model/MotionProfile.java
Motion Path (Handling multiple Motions, putting things together):
Motion Planner (interface to use the whole thing): https://github.com/openpnp/openpnp/blob/develop/src/main/java/org/openpnp/machine/reference/driver/ReferenceAdvancedMotionPlanner.java_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CAEm8oET_%3DJW_M%3DZAUW1g69MMPqJ4usA8RT7is49bJccEUNLvPg%40mail.gmail.com.
Hi Jan
Sorry, what you are describing is not what junction_deviation does in Grbl and descendants, including Smoothie.
These controllers are only capable of planning straight lines. Even if you send them G2, G3 arcs, they internally break it up into a polygon. The planner can only handle straight segments.
Now imagine sitting in one of these small mining rail cars. You
are driving at speed through a curve in the rails. Now imagine the
rails are not smooth but approximated by a polygon. Certainly you
can now "feel" the jerks and bumps in your imagination 😁
When driving over a polygon corner, even at a very shallow angle,
the rail car would need to change its velocity (vector) in zero
time. Due to inertia, that is physically impossible.
Instead everything in and on it will flex, including you. Ouch,
right?!
The remove all jerking and bumping, you would need to decelerate
to zero velocity before the corner. Then re-accelerate again after
the corner. Obviously this is very slow and unacceptable for many
NC application. You'd burn a mill's drill bit, shoot big holes
with a laser, or make blobs with a 3D printer.
So these controllers make a compromise. They pretend there is a curve through the corner. Then they calculate what speed would be acceptable to go through the corner, if there were such a curve (limited by the acceleration). The shallower the corner angle, the faster they can go through. Then they calculate the segment entry/exit speeds according to that speed. But they still drive the steppers in straight lines (red vectors). This junction_deviation does not remove the "jerk or bump" when going through the corner, it only limits it to a tolerable amount!
That's why these are called virtual curves. They are not real!
https://onehossshay.wordpress.com/2011/09/24/improving_grbl_cornering_algorithm/
In reality the machine will not move along that dark blue virtual
curve, instead it will move something like the
orange curve here,
i.e. overshoot and then settle back onto the exit vector. It's all
in the flex and dampening of the machine:
Obviously it would be much less extreme on a shallow angle, and
that's what interpolation, including OpenPnP's tries to
do. This is OK for many applications, on the sub-millimeter scale
and with mostly shallow polygon angles, but it is in no way
motion path smoothing or G64.
Therefore, unfortunately what you are describing in the rest of your text "does not compute". 😬
If you don't believe me: set your Smoothie junction_deviation
to some multi-millimeter value:
https://smoothieware.org/configuration-options
junction_deviation | 0.05 | Similar to the old “max_jerk”, in millimeters. Defines how much the machine slows down when decelerating proportional to the vector angle of change of direction. See here and here. Lower values mean being more careful, higher values means being faster and have more jerk |
Try running a simple two-legged angled move. But no guarantees as to the survival of your machine!!!
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/0aa51ae4-a0b8-4ef9-973a-33b59a578d77n%40googlegroups.com.
Hi dc42 / all,
this topic had me thinking for quite some time now. The solution
could be something like the following:
See the animation (click to open):
https://makr.zone/motion_blending_animation.html
It has a higher acceleration on the second segment to demonstrate
that G64 calculation is not trivial (5). But note that the demo
simply has the same overlap time for all the examples, i.e. there
is no "real G64" applied.
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/0aa51ae4-a0b8-4ef9-973a-33b59a578d77n%40googlegroups.com.
Added both symmetric and asymmetric acceleration for better illustration:
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/f4ace535-fbb4-cb07-0177-462dbb0fdd01%40makr.zone.
High precision stepper movement. Klipper utilizes an application processor (such as a low-cost Raspberry Pi) when calculating printer movements. The application processor determines when to step each stepper motor, it compresses those events, transmits them to the micro-controller, and then the micro-controller executes each event at the requested time. Each stepper event is scheduled with a precision of 25 micro-seconds or better. The software does not use kinematic estimations (such as the Bresenham algorithm) - instead it calculates precise step times based on the physics of acceleration and the physics of the machine kinematics. More precise stepper movement translates to quieter and more stable printer operation.
Klipper uses an "iterative solver" to calculate precise step times from simple kinematic equations. This makes porting Klipper to new types of robots easier and it keeps timing precise even with complex kinematics (no "line segmentation" is needed).
Hi John,
Conceptually, this is certainly a possible approach.I don't know if Klipper specifically is a valid approach
for OpenPnP, because it seems to address use cases that are
different. In 3D Printing or CNC Milling etc. you have a
NC-Program that is prepared from beginning to end. It then statically
runs for hours.
This means that latency is of no concern whatsoever.
However, in OpenPnP we have a highly interactive system: Vision,
Vacuum Sensing, Contact Probing, Drag-pin sensing, Feeder sensing
etc. are all sensory inputs that are interpreted by OpenPnP, and
subsequent G-code can only be generated with the knowledge
obtained from that sensory input. Because of that, OpenPnP runs in
close step-by-step synchronization with the controller. I improved
that a bit by introducing the GcodeAsyncDriver, but at
least in case of vision, the round-trip time is still very
important.
There has been talk about Klipper before. A user said it has 100ms latency, which would not be catastrophic but still bad. Unfortunately, that conversation was deleted by the user.
_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 view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/7a5a74d4-3f39-453b-b1b2-4d06921a2383n%40googlegroups.com.
Just FIY, I found some mistakes in my reasoning.
Assertions in (8) and (9) about 90° and blunter angles are wrong
in terms of axis limits. For axis limits, the
angle is irrelevant, it is the axis motion flipping its sign
between the two segments that is the relevant criteria.
The angular reasoning is valid for toolpath limits, and
would have to be treated too, similar to what I said before, but
applicable to the toolpath instead of the axis.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/ad49e6f4-61ff-7ad3-7c69-7a7a0c2758ff%40makr.zone.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/186f92b6-f1f8-16c4-a7b8-6fc578d5e094%40makr.zone.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CAKFrckraRqK-zgnAg2RT2sdYEfJh8Z8s1sb8mDDk4ViNLdUnRw%40mail.gmail.com.
Hi Harjit,
I assume that the Safe Z promise must be kept. So the curve can only begin at Safe Z, the path must still overshoot into the Safe Z Zone.
The motion planner in OpenPnP would have to determine what the
optimal curve is, given the distance in X, Y and the available
headroom in the Safe Z Zone. For shorter distances in X, Y only a
small overshoot is optimal, i.e. the limit is given by the ramps
of the X/Y move, which then becomes one fluid curve. For large X,
Y moves, you would probably use the full Z head-room, i.e. there
are two curves on either side of a straight move . If the
head-room is large, it also depends on how far down the Z started,
i.e. how fast (and for 3rd order motion, how
accelerated) the nozzle is, when it crosses Safe Z, i.e. how
much head-room it needs to (jerk and) decelerate to still-stand,
i.e. the limit is then given by the Z off-ramp.
Note: if the lifting of Z at the start is not the same as
lowering of Z at the target, the Z overshoot will become
asymmetric. This is especially the case, when we have a dual
nozzle shared Z axis machine, an the other nozzle is
lowered at the target. The Z overshoot is then inverted from the
top of the Safe Z Zone, the resulting move is wave-shaped, instead
of inverted-U-shaped. Is like with the previous method in the
demo's back two rows:
Once the OpenPnP motion planner has the Z overshoot, it can form the curve as follows:
With the rules (1) and (9)/(13) from my previous post, the
blending/curve can only be between the ramps of two segments. So
breaking up the Z moves, we can make sure that's the case, without
any difficult "reverse G64" calculations on the OpenPnP side.
Overall, this system is much, much simpler than what I've (only partially!) implemented before, i.e. allowing overshoot into uncoordinated moves. Plus, this system seems to conform to the NIST G-code standard. The down side is that the driving system now needs to calculate the overshoot target points. But that's simple in the case of PnP.
https://makr.zone/motion_blending_animation.html_Mark
@mark - to simplify the discussion:
Instead of doing the "upside down U moves" that you have shown, imagine Z axis goes up and down with X and Y at zero velocity i.e. "rectangular" moves.
a) Then compute the time for the X and the Y movement.
b) Then slow down the faster axis to finish at the same time as the slower one by reducing the maximum velocity. This means, we get a movement in a straight line with both axes moving at the same time.
The current controllers that have jerk limited motion can support this. This is slower in that the Z axis motion and the X and Y axis motions aren't blended.
Where I haven't formed a full mental model is around the Z axis blending. I keep thinking, the motion needs to be broken into three segments for the general case:
A) Raise Z to safe Z and accelerate X and Y while ensuring the nozzle/component doesn't crash into an obstruction. At the end of this move, Z will have zero velocity but X and Y will be non-zero.
B) Move X and Y at new motion parameters (max. acceleration, max. velocity and distance).C) Lower Z to target Z and decelerate X and Y to zero while ensuring the nozzle/component doesn't crash into an obstruction. At the end of this move, X, Y and Z will have zero velocity.
Steps #1 and #3 need a 3D path solution. I looked at the code you pointed me to but I got lost because I don't have a mental model of the architecture.
1) Do you compute a "safe Z for when X and Y can start moving" - corresponds to "A" and a "safe Z for when X and Y must not be moving" corresponds to "C"?
____
Hi Mark,
"Currently, there is no function to set the maximum deviation
allowable in CANON_CONTINUOUS mode."
That section of the report does not describe G-code per se, but a possible "canonical" implementation of a controller. It is based on code they apparently wrote (not very clear, see 4.1.2.). IMHO that sentence is just describing shortcoming of their implementation at the time of the report. It does not mean there must not be such a function.
I think we should lean on LinuxCNC here:
http://www.linuxcnc.org/docs/2.6/html/gcode/gcode.html#sec:G64
_Mark