Advanced Motion Control - Testing Version - Update 6
ma...@makr.zone
scott.t...@gmail.com
scott.t...@gmail.com
jdlv
yesterday i ran a small job with update 6 , no problems all went smooth.
Now i am trying the simulated 3th order driver but I should have missed
something, no ways...
I can't see any change when switching from ModeratedConstantAcceleration
to Simulated3rdOrderControl.
Gcode controler is smoothie with your latest firmware
Attached some config screenshot.
Thanks again for your awesome work!
joël
Le 08/11/2020 à 14:25, ma...@makr.zone a écrit :
> Hi Everybody
>
> Update 6 of the Advanced Motion Control package is available!
>
> As always, download the newest testing version here:
>
> https://openpnp.org/test-downloads/
>
> Details in the Pull Request:
>
> https://github.com/openpnp/openpnp/pull/1074
>
> Most of the goodies are under the hood, the biggest improvement is that the
> GUI log no longer slows down operation. In my measurements the logging
> level no longer matters for the speed of machine operation, even with the
> finest Advanced Motion Control move interpolation which generates a high
> volume of log output.
>
> While I was at it, I made some visible improvements;-)
>
> [image: grafik]
>
> The other big addition is the Axis Interlock
>
>
> [image: grafik]
>
> _Mark
>
ma...@makr.zone
Hi Scott
I just looked at the code again, and I think it is correct. Could
this be a misunderstanding?
The Directional method works differently, there is no "final
move". Unlike the other backlash compensation methods it does no
extra moves and no direction change, hence it is much faster and
can be used together with motion blending etc.
https://github.com/openpnp/openpnp/wiki/Backlash-Compensation
BUT: You must calibrate your backlash to the real
physical backlash of your machine. You can no longer over-compensate
as with the other methods. If you don' calibrate, positioning will
be wrong.
I doubt your machine has a full 0.5mm backlash in reality! I had less than 0.05 on my simple belt driven Liteplacer.
https://github.com/openpnp/openpnp/wiki/Backlash-Compensation#backlash-offset-calibration
This is probably one place, where the the Issues&Solutions
suggestion is too easily adopted... hmmm.
_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/da5b7663-ce9a-42df-b6ef-7d60e1322ff9n%40googlegroups.com.
ma...@makr.zone
Hi joël
Thanks!
What does the Diagnostics say?
Don't you get these acceleration steps?
https://github.com/openpnp/openpnp/wiki/Motion-Planner#motion-interpolation
https://github.com/openpnp/openpnp/wiki/Motion-Planner#motion-planner-diagnosticsOr look at the log. Just one G1 command issued? Or many?
Does the Issues&Solutions system say anything?
https://github.com/openpnp/openpnp/wiki/Issues-and-Solutions
_Mark
ma...@makr.zone
Ahh, and don't forget to set a Jerk limit on the axes where you want it:
https://github.com/openpnp/openpnp/wiki/Machine-Axes#kinematic-settings--rate-limits
If it is left at 0mm/s2, no Jerk limit is applied i.e. it works without interpolation.
_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/cd03f064-1308-b997-ac02-2298a7d34b87%40makr.zone.
jdlv...@gmail.com
ma...@makr.zone
> looks like acceleration goes to 0 between each step
No, that's just the graphics. I made it to emphasize the
interpolation, as it is hardly visible on top of the planning
curve. Btw. you can also click on the graph to cycle between
curves.
> But moves are quite shaky
Please elaborate.
I know it is very important to have very fast USB ping-pong and I only have experience under Windows.
Could you switch to TRACE logging level and then also post the log of the actual serial comm?
You might also have to play around with these settings:
https://github.com/openpnp/openpnp/wiki/GcodeAsyncDriver#interpolation
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/5b3c79a3-bdd4-4f92-98a4-e37bc6b3dc50n%40googlegroups.com.
jdlv...@gmail.com
scott.t...@gmail.com
ma...@makr.zone
This seems even faster than under Windows. Strange ...
Well, it is expected that the first move segment may
prematurely decelerate, but if the subsequent segments arrive in
time, it is expected to work. It does on my Smoothieware
controller.
For OpenPnP most motion paths have a Safe Z move at the beginning
and if you set Jerk to zero on the Z axis, this should give the
controller the time needed to plan this properly. Could you please
create a realistic Test Motion with two enabled Locations and Safe
Z enabled between the Locations? Maybe a bit more than
10mm distance.
https://github.com/openpnp/openpnp/wiki/Motion-Planner#settings
I do plan to address this in Smoothieware etc. this was also
already discussed with dc42 of Duet3D. There should be a grace
period where it waits for further command before rushing into
premature deceleration. It should only start executing the moves
when either a M400 has been received or the input/Gcode stream has
paused (or the buffers are getting full).
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/03e5540e-137c-4caa-81c5-77ea74dc02b3n%40googlegroups.com.
ma...@makr.zone
And this is with the newest Firmware? And you have an
original MCU Smoothieboard or Azteeg X5 GT with
the 120Mhz
NXP LPC1769 ?
https://makr.zone/smoothieware-new-firmware-for-pnp/500/
Really very strange. Could you send the log?
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/28811647-1ea4-4719-b610-a5f1def78ee7n%40googlegroups.com.
jdlv...@gmail.com
ma...@makr.zone
> I read somewhere in the wiki about junction_deviation but I don't know if it's only for motion blending. In my config file it is set at 0.
That explains it!
My config is here (towards the end):
https://makr.zone/choosing-a-motion-controller-the-panucatt-azteeg-x5-gt-32bit/455/
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/6dee0366-b3b1-4d9f-a8e0-a33e04ea7e93n%40googlegroups.com.
jdlv
Thanks a lot!
joël
Le 10/11/2020 à 21:18, ma...@makr.zone a écrit :
> /> //I read somewhere in the wiki about junction_deviation but I don't
> know if it's only for motion blending. In my config file it is set at 0./
> That explains it!
>
> Theoretically, junction deviation is only used for curved trajectories,
> but a zero value switches off junction speeds completely, even for
> straight junctions:
>
> https://github.com/Smoothieware/Smoothieware/blob/2ef08c902d870d1cc61e46cef571087bde9bd72d/src/modules/robot/Planner.cpp#L150
>
> <https://github.com/Smoothieware/Smoothieware/blob/2ef08c902d870d1cc61e46cef571087bde9bd72d/src/modules/robot/Planner.cpp#L150>
>
>
> My config is here (towards the end):
>
> https://makr.zone/choosing-a-motion-controller-the-panucatt-azteeg-x5-gt-32bit/455/
> <https://makr.zone/choosing-a-motion-controller-the-panucatt-azteeg-x5-gt-32bit/455/>
>
>
> _Mark
>
>
> Am 10.11.2020 um 20:09 schrieb jdlv...@gmail.com:
>> Smoothieboard is an original. Firmware date is
>> X-FIRMWARE_BUILD_DATE:Oct 22 2020 21:21:58 .
>>
>> Maybe there is something wrong with my smoothie config file? I read
>> somewhere in the wiki about junction_deviation but I don't know if
>> it's only for motion blending. In my config file it is set at 0.
>> Could you send your smoothie config?
>>
>> joël
>>
>>
>> Le mardi 10 novembre 2020 à 19:02:32 UTC+1, ma...@makr.zone a écrit :
>>
>>
>> https://makr.zone/smoothieware-new-firmware-for-pnp/500/
>> <https://makr.zone/smoothieware-new-firmware-for-pnp/500/>
>>
>> Really very strange. Could you send the log?
>>
>> _Mark
>>
>> Am 10.11.2020 um 18:43 schrieb jdlv...@gmail.com:
>>> Made a short video with this test motion :
>>>
>>>
>>> joël
>>> Le mardi 10 novembre 2020 à 17:23:42 UTC+1, ma...@makr.zone a
>>> écrit :
>>>
>>> This seems even faster than under Windows. Strange ...
>>>
>>> in time, it is expected to work. It does on my Smoothieware
>>> controller.
>>>
>>> For OpenPnP most motion paths have a Safe Z move at the
>>> beginning and if you set Jerk to zero on the Z axis, this
>>> should give the controller the time needed to plan this
>>> properly. Could you please create a realistic Test Motion
>>>
>>> https://github.com/openpnp/openpnp/wiki/Motion-Planner#settings
>>>
>>> <https://github.com/openpnp/openpnp/wiki/Motion-Planner#settings>
>>>
>>> I do plan to address this in Smoothieware etc. this was also
>>> already discussed with dc42 of Duet3D. There should be a
>>> grace period where it waits for further command before
>>> rushing into premature deceleration. It should only start
>>> executing the moves when either a M400 has been received or
>>> the input/Gcode stream has paused (or the buffers are getting
>>> full).
>>>
>>> _Mark
>>>
>>> Am 10.11.2020 um 16:44 schrieb jdlv...@gmail.com:
>>>> I can clearly see 3 or 4 independent moves, accelerate, slow
>>>> down, accelerate, slow down ..., ... not a smooth and
>>>> continuous move.
>>>> Attached is a 100mm full trace log. Looks like USB transfers
>>>> are all done within 3ms.
>>>>
>>>> joël
>>>> Le mardi 10 novembre 2020 à 15:00:18 UTC+1, ma...@makr.zone
>>>> a écrit :
>>>>
>>>> No, that's just the graphics. I made it to emphasize the
>>>> interpolation, as it is hardly visible on top of the
>>>> planning curve. Btw. you can also click on the graph to
>>>> cycle between curves.
>>>>
>>>> Please elaborate.
>>>>
>>>> I know it is very important to have very fast USB
>>>> ping-pong and I only have experience under Windows.
>>>>
>>>> Could you switch to TRACE logging level and then also
>>>> post the log of the actual serial comm?
>>>>
>>>> You might also have to play around with these settings:
>>>>
>>>>
>>>> https://github.com/openpnp/openpnp/wiki/GcodeAsyncDriver#interpolation
>>>>
>>>> <https://github.com/openpnp/openpnp/wiki/GcodeAsyncDriver#interpolation>
>>>>
>>>>
>>>> _Mark
>>>>
>>>>
>>>> Am 10.11.2020 um 11:27 schrieb jdlv...@gmail.com:
>>>>> Ok got some progress, Acceleration was set at 0m/s². I
>>>>> mixed it up with jerk unlimited if set at 0...
>>>>> Now multiples gcode for a move and diagnostics shows
>>>>> steps. Acceleration is set at 5000mm/s² same value as
>>>>> smoothie config.
>>>>> But moves are quite shaky, looks like acceleration goes
>>>>> to 0 between each steps:
>>>>>
>>>>>
>>>>>
>>>>> attached is a log for a 10mm X axis move.
>>>>>
>>>>> Vielen dank!
>>>>>
>>>>> joël
>>>>> Le mardi 10 novembre 2020 à 07:53:46 UTC+1,
>>>>> ma...@makr.zone a écrit :
>>>>>
>>>>> Ahh, and don't forget to set a Jerk limit on the
>>>>> axes where you want it:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> <https://github.com/openpnp/openpnp/wiki/Machine-Axes#kinematic-settings--rate-limits>
>>>>>
>>>>>
>>>>> If it is left at 0mm/s^2 , no Jerk limit is applied
>>>>> i.e. it works /without /interpolation.
>>>>> _Mark
>>>>>
>>>>> Am 10.11.2020 um 07:45 schrieb ma...@makr.zone:
>>>>>>
>>>>>> Hi joël
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>> What does the Diagnostics say?
>>>>>>
>>>>>> Don't you get these acceleration steps?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> <https://github.com/openpnp/openpnp/wiki/Motion-Planner#motion-interpolation>
>>>>>>
>>>>>>
>>>>>>
>>>>>> https://github.com/openpnp/openpnp/wiki/Motion-Planner#motion-planner-diagnostics
>>>>>
>>>>> -- 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/5b3c79a3-bdd4-4f92-98a4-e37bc6b3dc50n%40googlegroups.com?utm_medium=email&utm_source=footer>.
>>>>
>>>> -- 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/03e5540e-137c-4caa-81c5-77ea74dc02b3n%40googlegroups.com?utm_medium=email&utm_source=footer>.
>>>
>>> -- 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/28811647-1ea4-4719-b610-a5f1def78ee7n%40googlegroups.com?utm_medium=email&utm_source=footer>.
>>
>> --
>> 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
>> <https://groups.google.com/d/msgid/openpnp/6dee0366-b3b1-4d9f-a8e0-a33e04ea7e93n%40googlegroups.com?utm_medium=email&utm_source=footer>.
>>
>
greg.hj...@gmail.com
ma...@makr.zone
Hi Greg
There is currently improved firmware being developed. With the
standard firmware, the Simulated3rdOrderControl is not
yet working. You should use ModeratedConstantAcceleration
for now.
https://github.com/openpnp/openpnp/wiki/GcodeAsyncDriver#gcodedriver-new-settings
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/8ea83445-e9e5-4cff-be39-e0e8918a68f8n%40googlegroups.com.
greg.hj...@gmail.com
ma...@makr.zone
Hi Greg
Thanks a lot for the thorough documentation and the videos!
> I'm getting an error “Visual homing is missing the FIDUCIAL-HOME part”
Yes, it seems you had Visual homing enabled in the previous
version. This version silently skipped Visual Homing when the
fiducial part was missing, despite the "enabled" switch. Very hard
to diagnose for the user, so I changed it.
Now you will know what is missing. You can switch off Visual
homing (on the Head) if you really don't want it.
Btw, I just documented Visual Homing in the Wiki:
> Enabling G-Code compression made everything stop working for me
Yes, Duet3D had this issue. It is already fixed by dc42 (along
with many other things)! I'm currently conversing with him about
some remaining issues but I guess we will be able to make a new
firmware available soon.
> I have the z-axis very slow (acc of 40mm/s^2) because I'm
mostly using tapes in a static 'channel' and have a lot of
problems with the parts bouncing out when I pick a part.
No kidding! You really need to fix these feeders then. But I'm
sure you already know that ;-)
> My machine is 200 usteps per mm with 16x microstepping
so I set my resolution to 0.005
> *Can I improve precision if I use more microsteps?
IMHO, 0.005mm is ample precision for OpenPnP even down to 0201
parts. There is a difference between resolution (what the motors
can address) and actual precision (the repeatable absolute
positioning accuracy). I'm no mechanical engineer but I guess with
0.005mm you're already beyond the point where true precision can
be improved with more resolution. Also one should realize that
microsteps are proportions of magnetic fields and frankly I doubt
there will be much to be gained beyond 16 microsteps.
> I noticed the new backlash compenstation but I need to find out how to set its value correctly.
You could try and follow this guide and tell me if it works with
your machine. It would really much improve the speed of your
machine to use DirectionalCompensation .
https://github.com/openpnp/openpnp/wiki/Backlash-Compensation#backlash-offset-calibration
Btw, is this the new Peter Betz head? So compact, I love it!
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/8ef72a93-1f18-4c18-89ce-1bce415d9bc5n%40googlegroups.com.
greg.hj...@gmail.com
ma...@makr.zone
> Without micro-stepping, my resolution is 12 steps/mm or 0.0833mm. I have the ability to use Nema23 steppers now so I could switch to those if their micro-steps might have enough torque to hold position. Maybe there are other places I need to look to improve the precision/repeatablity - maybe visual homing.
Could you explain what issues you actually see? Is the
positioning not repeatable without this huge 1mm OneSided
compensation?
Does this not work?
https://github.com/openpnp/openpnp/wiki/Backlash-Compensation#backlash-offset-calibration
The machine looks very nice. Something like this* is what I would
try to build if I were to start from scratch: 3D-printed but bulky
brackets, linear rails, the new light Peter's head. It looks very
light and well-balanced overall.
I can't spot the problem, this machine should be able to fly!!!
(The feeders aside ;-)
_Mark
*I would probably stick with the CP40 nozzle tips, they seem less
problematic for vacuum sealing etc.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/4411e6a9-fd47-449a-849b-1e40dd295273n%40googlegroups.com.
greg.hj...@gmail.com
ma...@makr.zone
> When manually aligning things like feeder holes, the 0.01mm jog doesn't always actually move ... due to the fact that we're micro-stepping at this level and there isn't enough torque
Hmmm... I think it should. You should not post-pone these
basic motion issues. It's not only about speed. If positioning is
so weak that you need a 1mm one-sided compensation, then the
machine will not make you happy in the next steps. For both bottom
vision and the fiducial locator, you need to be able to adjust the
machine position in tiny increments. It should definitely not have
to do 1mm excursions on each move! These "excursions" will also
conflict with the nozzle tip changer you surely also have on your
TODO list.
First double-check your micro-step calculation. You said you had
0.005mm micro-steps (200 steps/mm), but that seems odd as it does
not match the usual step angle, belt and pulley factors. For
instance I have 20 teeth pulley on 2mm belt and 1.8° steppers with
16 micro-steps, so I get 20*2mm*1.8°/360°/16 = 1mm/80 = 0.0125mm
per step. If you have the same, it is perfectly
normal to not have a step on each 0.01mm Jog! Only 4 out
of 5 Jogs actually move.
Once double-checked, set the verified value in your axis as the Resolution.
https://github.com/openpnp/openpnp/wiki/Machine-Axes#controller-settings
Maybe you can attach a long, thin "needle" to one of the pulleys
like a very long chimney match, bicycle spoke, broom twig whatever
;-). Now jog 0.01mm and observe if it rotates.
If not, check your controller's motor current settings. In Duet
you can easily set this with the M906 command:
https://duet3d.dozuki.com/Wiki/Gcode#Section_M906_Set_motor_currents
I would definitely set it to the full rated current of
your X and Y steppers. They won't go up in flames so easily! It is
also normal for them to become quite hot. Plus Duet has an idle
factor.
Speaking of which: You might also have to experiment with the M906 I word, controlling the idle factor. The motor might lose position if too low. Unfortunately I have no real machine experience with the Duet yet, so this is all theory. ;-)
My Liteplacer
is very "maker style" with simple sandwiched plastic wheels on
maker slot, everything is clamped together using hand-guesstimated
ex-center tensioning. Yes, ugly. The construction is also quite
unbalanced, the head is huge, with the cable chain janking
off-center. But it moves precisely enough for 0402. No problems.
https://makr.zone/pick-place-machine-first-simulated-small-test-run/66/
So it is is simply unthinkable that your machine, sporting linear
rails etc. should not perform much better!
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/8b723bed-a393-4d8e-ace1-d6acec3262ean%40googlegroups.com.
greg.hj...@gmail.com
ma...@makr.zone
> 16-tooth pulleys
Ahh, that explains it.
> I replaced the 200step motors with 400step motors
Funny, I did the opposite ;-) The 0.9° steppers of the Liteplacer
kit did limit the max. speed too much (halved it more or less).
> I just tried the estimation of backlash and I cant see any backlash on my machine now
Excellent!
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/d8a5bd8d-37ef-413b-be93-c05ee61c7585n%40googlegroups.com.
greg.hj...@gmail.com
ma...@makr.zone
IMHO you need visual homing anyway, so you can start with this guide and simply exclude any end-switch inaccuracies from the equation.
https://github.com/openpnp/openpnp/wiki/Visual-Homing
If this resolves the issue, fine.
If not, you should probably also look at the belt tension.
People often have them too tight. Guidance is rare. I was pretty
lost when I built my machine. Most guides are uselessly
theoretical or require special (expensive) instruments or tools.
Finally, I found a good and most importantly, a practical guide
after a very long search. But stupid me hasn't bookmarked it
and I can't find it again :-(.
What I remember from the good guide (applicable to a typical PnP
machine X, Y belt length): If you pluck the belt it should sound
with a very low tone, something like the lowest piano key
(whatever that is). The belt feels surprisingly lose. You can
easily deflect it, almost no deflection tension felt. Certainly
not like bow and arrow. At first it feelt wrong, but it turned out
to perform very well.
If you had it very tight you probably need to replace the belt.
Apparently, it is not so hard to damage it permanently through
over-tensioning.
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/1a4a9b65-f148-4ddf-9636-7ebbb9037257n%40googlegroups.com.
greg.hj...@gmail.com
greg.hj...@gmail.com
Harjit Singh
ma...@makr.zone
Hi Greg
this is only with the OpenPnP Testing Version/Advanced Motion Control:
https://makr.zone/openpnp-advanced-motion-control/553/
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/f783ffd0-0c88-4e99-9b47-35c019ab994cn%40googlegroups.com.
ma...@makr.zone
No, it was specifically for pragmatic DIY machine belt
tensioning. But with similar practical outcome as your examples.
It was a long time ago, I don't remember exactly. At the time I've
looked at many such guides and theories so everything blends
together.
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CAEm8oEQWOB6UtTYDFiY4%2BxVGG1MyDmjiyzOLzBfDV0zzHLB%3D_A%40mail.gmail.com.
ma...@makr.zone
bert shivaan
--
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/3ad3dd8f-3ff9-05cd-ff8e-024378f9d868%40makr.zone.