Liteplacer intial setup

[Peter Chaisty]

Hi

I am having two main issues which may be related.

I am testing just by moving the camera from part to part on the demo board V2

Mechanical homing works

Visual homing works

Fiducial checks work

I have the motion controller set to Toolpathfeedrate after previously trying simple Scurve

1/  during a move from component to component the pickup head rotates (A axis)

During a check fiducial its fine .

I think  I saw this issue years ago but I can't remember or find anything online.

2/ Speed

The speed seems variable and the the feed rate seems to vary as I move around the board .

It varies from a crazy low feedrate to something that's OK at F258 but still slow .

But moving between components on the board it seems to vary every time .

Can anyone offer any suggestions ?

Peter

[ma...@makr.zone]

Re 1.

If you are referring to the "Position the tool at the placement't location" button, it does include the rotation. So the nozzle rotating is normal.

Re 2.

Some of your moves are likely slowed down by the rotations. Why?

Toolpathfeedrate is problematic, because there is only one feedrate setting (on the driver) for both the linear and the rotational motion. But millimeters are not the same as degrees. Moving the hole machine in Y by 180mm is much more "physical" than rotating a nozzle by 180°.  This means that while a feedrate limit may be ok for linear moves, it is too slow for rotations.

Therefore I recommend using a more modern control type like ModeratedConstantAcceleration:

https://github.com/openpnp/openpnp/wiki/GcodeAsyncDriver#gcodedriver-new-settings

You should set the Driver limit to zero (deactivate) and instead configure rate limits individually on the axes, i.e. especially increase the limits on rotational axes (don't forget to configure the controller as well, OpenPnP's limits must always be the same or lower as the controller's!):

https://github.com/openpnp/openpnp/wiki/Machine-Axes#kinematic-settings--rate-limits

Btw. have you tried Issues & Solutions?

https://github.com/openpnp/openpnp/wiki/Issues-and-Solutions

_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/39174511-024b-49c1-8a4c-3040c3e650afn%40googlegroups.com.

[pcha...@gmail.com]

Hi Mark

Thanks for that , in fact the settings had got corrupted on the tinyG when I updated the firmware and it was in radians mode

Set axis mode to standard made the rotations normal.

Because it was in radians a rotation angle in degrees made for a lot of revolutions .

$aam = 1 fixed that

At the moment I am running simple S curve ,as the issues and solutions tab said I had to.

I am having more success with movements though still slow to what I had originally.

I will try ModeratedConstantAcceleration and update.

When I get the bare bones system running I plan to submit here for approval as a example of a basic liteplacer setup.

I still have a few issues to resolve after the motion control and speed.

Peter

[Peter Chaisty]

So these are the results using the diagnostics

Short travels still seem very slow but I guess in reality the trip from a feeder to the board is always going to be a relatively long travel.

[ma...@makr.zone]

Acceleration is set very low. I would expect it to be in the thousands (mm/s²)

Jerk is set ultra-low. I would expect it to be in the tens of thousands (mm/s³)

If you increase them, again be sure to also adjust the limits on the controller side (OpenPnP must be lower or equal).

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/424398fe-4561-4666-b5ba-315a960038bbn%40googlegroups.com.

[Peter Chaisty]

Thanks for the feedback and advice.

I'll give that a try in the morning.

Peter

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/VDQREbARMUs/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/89111289-c3b0-bdc0-b106-f690be96bed3%40makr.zone.

[Peter Chaisty]

Hi Mark

So I increased 

The acceleration to 5000 and jerk rate to accell=5000 and jerk to 25000 on x and Y

Its much much better.

Sometimes it runs really fast and I think pretty much perfect.

I'm very happy with long travels .

If however I move around the circle of 1206 on the demo board V2

If I use the crosshair to move position it's very very rapid, no missed steps I think as accuracy is maintained.

If I use the job and move component to component it only moves at a low feedrate .

Fiducial checking is at a high feed rate.

Trips to a feeder tape are high feedrate

I logged the moves below and I can't understand as the acceleration seems high etc how the planner chooses such a low feed rate ?

I must have something configured wrong still ?

What information should I supply to help solve this (machine.xml attached) ?

Peter

So using the job / move camera over part I get 

2021-02-05 10:04:30.058 ReferenceHead DEBUG: H1.moveToSafeZ(1.0)
2021-02-05 10:04:30.058 AbstractHeadMountable DEBUG: N1.moveToSafeZ(1.0)
2021-02-05 10:04:30.059 ReferenceNozzle TRACE: N1.transformToHeadLocation((38.498342, 38.619090, 0.000000, 134.631864 mm), ...)
2021-02-05 10:04:30.059 ReferenceNozzle TRACE: N1.transformToHeadLocation((38.498342, 38.619090, 0.000000, 134.631864 mm), ...)
2021-02-05 10:04:30.059 AbstractHeadMountable DEBUG: OpenPnpCaptureCamera.moveToSafeZ(1.0)
2021-02-05 10:04:30.059 AbstractHeadMountable DEBUG: OpenPnpCaptureCamera.moveTo((16.838654, 38.758259, 0.000000, 44.631864 mm), 1.0)
2021-02-05 10:04:30.061 AbstractHeadMountable DEBUG: OpenPnpCaptureCamera.moveTo((16.838654, 38.758259, 0.000000, 44.631864 mm), 1.0)
2021-02-05 10:04:30.062 Scripting TRACE: Scripting.on Camera.AfterPosition
2021-02-05 10:04:30.062 GcodeAsyncDriver DEBUG: serial://COM4 commandQueue.offer(M201.3 X683 Y4  A2713, 60000)...
2021-02-05 10:04:30.062 GcodeAsyncDriver DEBUG: serial://COM4 commandQueue.offer(G1 X15.8387 Y38.7583  A44.6319 F151.07 ; move to target, 60000)...
2021-02-05 10:04:30.063 GcodeDriver TRACE: [serial://COM4] confirmed G1  Y38.6191   F110.52
2021-02-05 10:04:30.063 GcodeAsyncDriver$WriterThread TRACE: [serial://COM4] >> M201.3 X683 Y4  A2713
2021-02-05 10:04:30.069 GcodeDriver$ReaderThread TRACE: [serial://COM4] << tinyg [mm] ok>
2021-02-05 10:04:30.069 GcodeDriver TRACE: [serial://COM4] confirmed M201.3 X683 Y4  A2713
2021-02-05 10:04:30.070 GcodeAsyncDriver$WriterThread TRACE: [serial://COM4] >> G1 X15.8387 Y38.7583  A44.6319 F151.07
2021-02-05 10:04:30.075 GcodeAsyncDriver DEBUG: serial://COM4 commandQueue.offer(M201.3 X25, 60000)...
2021-02-05 10:04:30.075 GcodeAsyncDriver DEBUG: serial://COM4 commandQueue.offer(G1 X16.8387    F110.52 ; move to target, 60000)...
2021-02-05 10:04:30.085 GcodeDriver$ReaderThread TRACE: [serial://COM4] << tinyg [mm] ok>
2021-02-05 10:04:30.085 GcodeDriver TRACE: [serial://COM4] confirmed G1 X15.8387 Y38.7583  A44.6319 F151.07
2021-02-05 10:04:30.086 GcodeAsyncDriver$WriterThread TRACE: [serial://COM4] >> M201.3 X25
2021-02-05 10:04:30.101 GcodeDriver$ReaderThread TRACE: [serial://COM4] << tinyg [mm] ok>
2021-02-05 10:04:30.101 GcodeDriver TRACE: [serial://COM4] confirmed M201.3 X25
2021-02-05 10:04:30.102 GcodeAsyncDriver$WriterThread TRACE: [serial://COM4] >> G1 X16.8387    F110.52
2021-02-05 10:04:30.117 GcodeDriver$ReaderThread TRACE: [serial://COM4] << tinyg [mm] ok>

Using the drag cursor I get 

2021-02-05 10:05:12.174 ReferenceHead DEBUG: H1.moveToSafeZ(1.0)
2021-02-05 10:05:12.174 AbstractHeadMountable DEBUG: N1.moveToSafeZ(1.0)
2021-02-05 10:05:12.174 ReferenceNozzle TRACE: N1.transformToHeadLocation((16.838654, 38.758259, 0.000000, 44.631864 mm), ...)
2021-02-05 10:05:12.175 ReferenceNozzle TRACE: N1.transformToHeadLocation((16.838654, 38.758259, 0.000000, 44.631864 mm), ...)
2021-02-05 10:05:12.175 AbstractHeadMountable DEBUG: OpenPnpCaptureCamera.moveToSafeZ(1.0)
2021-02-05 10:05:12.175 AbstractHeadMountable DEBUG: OpenPnpCaptureCamera.moveTo((27.760279, 43.127587, 0.000000, 44.631864 mm), 1.0)
2021-02-05 10:05:12.176 AbstractHeadMountable DEBUG: OpenPnpCaptureCamera.moveTo((27.760279, 43.127587, 0.000000, 44.631864 mm), 1.0)
2021-02-05 10:05:12.176 GcodeAsyncDriver DEBUG: serial://COM4 commandQueue.offer(M201.3 X25000 Y10002, 60000)...
2021-02-05 10:05:12.176 GcodeAsyncDriver DEBUG: serial://COM4 commandQueue.offer(G1 X27.7603 Y43.1276   F2500.00 ; move to target, 60000)...
2021-02-05 10:05:12.176 GcodeDriver TRACE: [serial://COM4] confirmed G1 X16.8387    F110.52
2021-02-05 10:05:12.177 GcodeAsyncDriver$WriterThread TRACE: [serial://COM4] >> M201.3 X25000 Y10002
2021-02-05 10:05:12.196 GcodeDriver$ReaderThread TRACE: [serial://COM4] << tinyg [mm] ok>
2021-02-05 10:05:12.196 GcodeDriver TRACE: [serial://COM4] confirmed M201.3 X25000 Y10002
2021-02-05 10:05:12.196 GcodeAsyncDriver$WriterThread TRACE: [serial://COM4] >> G1 X27.7603 Y43.1276   F2500.00
2021-02-05 10:05:12.212 GcodeDriver$ReaderThread TRACE: [serial://COM4] << tinyg [mm] ok>

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/VDQREbARMUs/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/89111289-c3b0-bdc0-b106-f690be96bed3%40makr.zone.

[ma...@makr.zone]

Hi Peter,

you may have Speed % set on your parts.

https://github.com/openpnp/openpnp/wiki/User-Manual#parts

The Speed [%] was often not effective in earlier version of OpenPnP, because the moves were not long enough for the speed limit to matter. Because the move is so short, the machine could not accelerate up to the set speed % limit before it had to start decelerating again. So in the past you had to set a very low speed % for it to matter.

And yet this low speed limit it did not really help for Pick and Place because the top speed is not relevant for vibrations, parts slipping, nozzles swinging, belts giving etc. it is the acceleration and jerk that matter. These create the forces and vibrations on the machine. Speed as such is mostly harmless, we're not reaching speeds where wind drag rips parts from nozzles, do we? ;-)

Demo with fluid:

https://youtu.be/6SBDApObbz0

The way the speed % now works is completely different. Now OpenPnP also controls acceleration and/or jerk. The effect is that if you set 50% speed, the move takes twice as long, regardless of its distance. Or at 25% it takes four times as long (time factor = inverse of speed %).

That is the reason you need to revisit these Speed settings in your machine. They're listed here:

https://github.com/openpnp/openpnp/wiki/GcodeAsyncDriver#control-of-speed-factors

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CAGLOruTr2o7k_6GsqsQP%3DfJfH9q_KUKWteS3S%2BGqvZmO-QG_fw%40mail.gmail.com.

[Chris Friday]

Is your rotational axis fast as before? IMHO it has nothing to do with Speed %. I had the same strange moves. While revive nozzle calibration I increased Jerk on the Axis configuration tab and tata.. speed comes back.

Chris

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/89cdf746-666b-b031-f1ef-333bf7842067%40makr.zone.

[Peter Chaisty]

Thanks Mark

In fact yes the speeds are all at 100% in the parts entries.

I also  backed off the accel now as I found it was having issues homing accurately .

I dropped the speed on fiducials And homing fiducial To 25%

I think I will live with it for now and move onto getting probing to work

I am a little in the dark when changing the jerk params etc though

Thanks for all your help .

Peter

Virus-free. www.avast.com

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/89cdf746-666b-b031-f1ef-333bf7842067%40makr.zone.

Virus-free. www.avast.com

[Peter Chaisty]

Hi Chris 

Some of it is still a mystery to me 

I'm going to leave movement alone for a while as it works well enough .

Move on with probing and nozzle change etc

Peter

Virus-free. www.avast.com

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/4252a158-e8be-a48b-0b9a-5bc5d3284585%40gmail.com.

Virus-free. www.avast.com

[ma...@makr.zone]

Christ might be right too.

I can only recommend to really adopt the new motion system. Best use the newest Testing Version and then follow the Issues & Solutions system.

https://github.com/openpnp/openpnp/wiki/Issues-and-Solutions

Once the Issues & Solutions system has setup the motion properly, you can use the graphical Motion Planner Diagnostics. Once enabled, it will show you the last motion sequence that was executed:

https://github.com/openpnp/openpnp/wiki/Motion-Planner#motion-planner-diagnostics

This will help you understand and diagnose how the various limits (feedrate, acceleration, jerk) affect the motion. For mixed axes moves with rotation, you should then see how the rotation limits the move.

In this example a low feedrate limit of 600°/s limited the linear axis at a mere 33mm/s:

See also the Test Motion you can define for repeatable tests:

https://github.com/openpnp/openpnp/wiki/Motion-Planner#settings

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/4252a158-e8be-a48b-0b9a-5bc5d3284585%40gmail.com.

[ma...@makr.zone]

Oops, I meant Chris :-}

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/730384e5-36e6-92e6-fb74-36d98f00fc92%40makr.zone.

[Chris Friday]

Yeap, thougt it :). Just to complete as Peter is working now with the ContactProbeNozzle and we had month ago some mails about:

With your latest TinyG Firmware  from 01/25/2021 and Tony's example code for probing and 28.3 with HOME_COMMAND it definitely works with the AsyncDriver - perfect!

It's working well with ALP Feeder and your PushPullFeeder. It might be tricky for tape feeders with free pockets like the Parametric-Tape-Feeder https://www.thingiverse.com/thing:2506053 . If one adjust the springs like JuHa recommend the Nozzle just pierce the device through the pocket. More play and the Nozzle wont come back to the starting position. Is there a way to say: Probe with this feeder but not with that?

Chris

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/df784416-5651-6960-22e6-3d4b37c78e5e%40makr.zone.

[pal...@gmail.com]

Hi Mark.

I have searched the "Motion Planner" section, but I can't find it.

It's in a Test version only ??

Thank's a lot.

[ma...@makr.zone]

> Is there a way to say: Probe with this feeder but not with that?

No.

But I'm working on probing... There are two operational probing tasks:

1. Calibrate feeder pick Z.
2. Determine part height.

Currently it just probes every time and does not record the Z. In the version I'm working on, you can set it to probe once per feeder (or not at all) and once per part (or not at all). Optionally "learning" the part height.

Switching it on/off per feeder is too difficult, because each feeder has it's own wizard and I certainly won't add a new checkbox to a gazillion feeder wizards. ;-)

Maybe I'll add a checkbox per feeder class.

Have you tried the Parametric-Tape-Feeder? I always wondered how it can cope with vibrations. Have you ever used with 0402, or at least 0603?

You do know the BlindsFeeeder, right? ;-)

https://makr.zone/new-openpnp-blindsfeeder/353/

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/e960ad78-16f2-789d-0175-4a4b1e55b04b%40gmail.com.

[ma...@makr.zone]

The "Motion Planner" is both in newer OpenPnP 2.0 (develop branch) versions and in the testing branch Version .

I recommend using the Testing Version because it addresses many TinyG specific quirks in Issues & Solutions. Plus we can react faster if bugs are found.

https://openpnp.org/test-downloads/

It has many other goodies. :-)

https://github.com/openpnp/openpnp/issues?q=label%3Atesting-round

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/f2af4f31-d72b-4f4f-9c83-ce0abae3145an%40googlegroups.com.

[Peter Chaisty]

Hi Mark

Is this still the current  Tiny G Firmware

 FIRMWARE_VERSION:0.97, FIRMWARE_BUILD:440.21, HARDWARE_PLATFORM:1.00, HARDWARE_VERSION:8.00

Peter

Virus-free. www.avast.com

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/730384e5-36e6-92e6-fb74-36d98f00fc92%40makr.zone.

Virus-free. www.avast.com

[Chris Friday]

> Maybe I'll add a checkbox per feeder class.

Would be really nice and sufficient  - for me of course.

> Have you tried the Parametric-Tape-Feeder

Yes, two types. One laser sintered PA12 (25mm overall height) because I used to have no 3D printers at that time. The second type is PETG (19mm height) printed after changing the frame size. Vibration? No, neither with 0402. I placed some today with "advanced motion" - I was about to kick the TinyG out short before - nothing. The machine is not as fast as yours but just placed with an ESD mat on the desk. Placing 0402 before the driver update was hmm.. so so but IMHO not because of the feeder. What I saw today was excellent. Thanks again for that.

BTW I had vibrations with PushPullFeeder fixed on the long front extrusion. An additional angle fixed that but there are only three feeder in place at the moment.

> BlindsFeeder?

Of course - I've seen the hint with the antistatic agent and thought that is not for beginners. There is a lot of room to improve..

Chris

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/cf852ec3-8c4c-f5d5-704c-d0abaa35a36c%40makr.zone.

[ma...@makr.zone]

Yes. Tony's probing fix is in there.

It should work. Could it be the end-switch-settings?

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CAGLOruR12T4mPZE7aNPHNnacdDTozBV5zhDWZcrA2jh3iV3UHA%40mail.gmail.com.

[ma...@makr.zone]

> An additional angle fixed that

What do you mean? I'm very interested. ;-)

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/6c66f60e-9077-8499-8df7-d04baba3ee2e%40gmail.com.

[Chris Friday]

You can see it in the video..okok not pro but helped.

Chris

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/bf4a8164-b118-4c71-0285-34588af84526%40makr.zone.

[Chris Friday]

Just to say you see no difference in the build number.

Flashing with build from 10/29/2020 - probing does not work

Flashing with build from 01/25/2021 - probing work


Both shows 440.21 build.

Chris

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/78a644d3-a48f-fc68-4ac5-1ef0f43af415%40makr.zone.

[ma...@makr.zone]

Ahh, you got the very first version. True, there is no difference visible. I was reluctant to increase the build number twice (or three times with the ADC), before the first PR got accepted.

There should probably be a git commit id and/or date in there as well. Does anybody know how to include git commit ids into C++ source code?

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/78468ae2-4484-b0fe-17f9-8bbfcd08f992%40gmail.com.

[Jarosław Karwik]

You need a script which launches git tools to create such info - as part of makefile or ide pre-build scripts. What system and tools do you use ?

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/01c6ca1a-cb8b-2b2d-aab4-589211637f86%40makr.zone.

[ma...@makr.zone]

It's the TinyG build system. AVRStudio something, someting. I'm only interested if its very easy ;-)

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CAC%2BEaohEuFyE%2BuqfpthSqNtcRB9ddUeUnEM8qM0CyewmSba%2BRA%40mail.gmail.com.

[Clemens Koller]

Hi, Mark!

On 05/02/2021 19.15, ma...@makr.zone wrote:
> Ahh, you got the very first version. True, there is no difference visible. I was reluctant to increase the build number twice (or three times with the ADC), before the first PR got accepted.

Hawww... please, use clear and unique versioning!
I believe I didn't get the latest build.

> There should probably be a git commit id and/or date in there as well. Does anybody know how to include git commit ids into C++ source code?

There are many ways to achieve that. The usual / recommended way:
$ git describe --always
1.1.0-2189-g3f3af9e4dd

So, we are currently on OpenPnP V1.1.0 with 2189 additional commits. 8-)
https://git-scm.com/docs/git-describe
If you add a version tag to the repo, the 1.1.0 could become v2.0.0


You can assemble your own branch + version + date thing, if you want to do that as well:

Branch name of HEAD:
$ git rev-parse --abbrev-ref HEAD
test

$ git rev-parse --short HEAD
3f3af9e4dd

Timestamp of last commit:
$ git log -1 --format=%cd

Feed those via your Makefile into the code.

There are some good ideas to include git commit ids into builds:
https://stackoverflow.com/questions/5694389/get-the-short-git-version-hash
https://stackoverflow.com/questions/44038428/include-git-commit-hash-and-or-branch-name-in-c-c-source


Regards,

Clemens

On 05/02/2021 19.15, ma...@makr.zone wrote:
> Ahh, you got the very first version. True, there is no difference visible. I was reluctant to increase the build number twice (or three times with the ADC), before the first PR got accepted.
>
> There should probably be a git commit id and/or date in there as well. Does anybody know how to include git commit ids into C++ source code?
>
> _Mark
>
> Am 05.02.2021 um 18:29 schrieb Chris Friday:
>> Just to say you see no difference in the build number.
>>
>> Flashing with build from 10/29/2020 - probing does not work
>>

>> Flashing with build from 01/25/2021 - probing work
>>
>>

>> Both shows 440.21 build.
>>
>> Chris
>>
>> On 05.02.2021 18:15, ma...@makr.zone wrote:
>>>
>>> Yes. Tony's probing fix is in there.
>>>
>>> It should work. Could it be the end-switch-settings?
>>>
>>> _Mark
>>>
>>>
>>> Am 05.02.2021 um 18:08 schrieb Peter Chaisty:
>>>> Hi Mark
>>>>
>>>> Is this still the current  Tiny G Firmware
>>>>  FIRMWARE_VERSION:0.97, FIRMWARE_BUILD:440.21, HARDWARE_PLATFORM:1.00, HARDWARE_VERSION:8.00
>>>>
>>>>
>>>> Peter
>>>>

>>>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> Virus-free. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>

>>>>
>>>>
>>>> On Fri, Feb 5, 2021 at 1:44 PM ma...@makr.zone <ma...@makr.zone> wrote:
>>>>
>>>> Christ might be right too.
>>>>
>>>> I can only recommend to really adopt the new motion system. Best use the newest Testing Version and then follow the Issues & Solutions system.
>>>>

>>>> https://github.com/openpnp/openpnp/wiki/Issues-and-Solutions <https://github.com/openpnp/openpnp/wiki/Issues-and-Solutions>

>>>>
>>>> Once the Issues & Solutions system has setup the motion properly, you can use the graphical Motion Planner Diagnostics. Once enabled, it will show you the last motion sequence that was executed:
>>>>

>>>> https://github.com/openpnp/openpnp/wiki/Motion-Planner#motion-planner-diagnostics <https://github.com/openpnp/openpnp/wiki/Motion-Planner#motion-planner-diagnostics>

>>>>
>>>> This will help you understand and diagnose how the various limits (feedrate, acceleration, jerk) affect the motion. For mixed axes moves with rotation, you should then see how the rotation limits the move.
>>>>
>>>> In this example a low feedrate limit of 600°/s limited the linear axis at a mere 33mm/s:
>>>>

>>>> See also the Test Motion you can define for repeatable tests:
>>>>

>>>> https://github.com/openpnp/openpnp/wiki/Motion-Planner#settings <https://github.com/openpnp/openpnp/wiki/Motion-Planner#settings>

>>>>
>>>> _Mark
>>>>
>>>>
>>>> Am 05.02.2021 um 13:08 schrieb Chris Friday:
>>>>> Is your rotational axis fast as before? IMHO it has nothing to do with Speed %. I had the same strange moves. While revive nozzle calibration I increased Jerk on the Axis configuration tab and tata.. speed comes back.
>>>>>
>>>>> Chris
>>>>>
>>>>> On 05.02.2021 11:42, ma...@makr.zone <mailto:ma...@makr.zone> wrote:
>>>>>>
>>>>>> Hi Peter,
>>>>>>
>>>>>> you may have Speed % set on your parts.
>>>>>>

>>>>>> https://github.com/openpnp/openpnp/wiki/User-Manual#parts <https://github.com/openpnp/openpnp/wiki/User-Manual#parts>

>>>>>>
>>>>>> The Speed [%] was often not effective in earlier version of OpenPnP, because the moves were not long enough for the speed limit to matter. Because the move is so short, the machine could not accelerate up to the set speed % limit before it had to start decelerating again. So in the past you had to set a very low speed % for it to matter.
>>>>>>

>>>>>> And yet this low speed limit it did not really help for Pick and Place because the top speed is not relevant for vibrations, parts slipping, nozzles swinging, belts giving etc. it is the *acceleration * <https://en.wikipedia.org/wiki/Acceleration>and *jerk * <https://en.wikipedia.org/wiki/Jerk_%28physics%29>that matter. These create the forces and vibrations on the machine. Speed as such is mostly harmless, we're not reaching speeds where wind drag rips parts from nozzles, do we? ;-)
>>>>>>
>>>>>> Demo with fluid:
>>>>>>
>>>>>> https://youtu.be/6SBDApObbz0 <https://youtu.be/6SBDApObbz0>
>>>>>>
>>>>>> The way the speed % now works is completely different. Now OpenPnP also controls *acceleration *and/or *jerk*. The effect is that if you set 50% speed, the move takes twice as long, regardless of its distance. Or at 25% it takes four times as long (time factor = inverse of speed %).

>>>>>>
>>>>>> That is the reason you need to revisit these Speed settings in your machine. They're listed here:
>>>>>>

>>>>>> https://github.com/openpnp/openpnp/wiki/GcodeAsyncDriver#control-of-speed-factors <https://github.com/openpnp/openpnp/wiki/GcodeAsyncDriver#control-of-speed-factors>

>>>>>>>> diagnostics output.jpgx axis setting .jpgmotion optionjpg.jpg

>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thursday, 4 February 2021 at 16:32:16 UTC Peter Chaisty wrote:
>>>>>>>>
>>>>>>>> Hi Mark
>>>>>>>>
>>>>>>>> Thanks for that , in fact the settings had got corrupted on the tinyG when I updated the firmware and it was in radians mode
>>>>>>>> Set axis mode to standard made the rotations normal.
>>>>>>>>
>>>>>>>> Because it was in radians a rotation angle in degrees made for a lot of revolutions .
>>>>>>>>
>>>>>>>> $aam = 1 fixed that
>>>>>>>>
>>>>>>>> At the moment I am running simple S curve ,as the issues and solutions tab said I had to.
>>>>>>>>
>>>>>>>> I am having more success with movements though still slow to what I had originally.
>>>>>>>>
>>>>>>>> I will try ModeratedConstantAcceleration and update.
>>>>>>>>
>>>>>>>> When I get the bare bones system running I plan to submit here for approval as a example of a basic liteplacer setup.
>>>>>>>> I still have a few issues to resolve after the motion control and speed.
>>>>>>>>
>>>>>>>>
>>>>>>>> Peter
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thursday, 4 February 2021 at 14:07:55 UTC ma...@makr.zone <mailto:ma...@makr.zone> wrote:
>>>>>>>>
>>>>>>>> Re 1.
>>>>>>>>

>>>>>>>> If you are referring to the "Position the tool at the placement't location" button, it *does *include the rotation. So the nozzle rotating is normal.

>>>>>>>>
>>>>>>>> Re 2.
>>>>>>>>
>>>>>>>> Some of your moves are likely slowed down by the rotations. Why?
>>>>>>>>
>>>>>>>> Toolpathfeedrate is problematic, because there is only one feedrate setting (on the driver) for both the linear and the rotational motion. But millimeters are not the same as degrees. Moving the hole machine in Y by 180mm is much more "physical" than rotating a nozzle by 180°.  This means that while a feedrate limit may be ok for linear moves, it is too slow for rotations.
>>>>>>>>
>>>>>>>> Therefore I recommend using a more modern control type like ModeratedConstantAcceleration:
>>>>>>>>

>>>>>>>> https://github.com/openpnp/openpnp/wiki/GcodeAsyncDriver#gcodedriver-new-settings <https://github.com/openpnp/openpnp/wiki/GcodeAsyncDriver#gcodedriver-new-settings>

>>>>>>>>
>>>>>>>> You should set the Driver limit to zero (deactivate) and instead configure rate limits individually on the axes, i.e. especially increase the limits on rotational axes (don't forget to configure the controller as well, OpenPnP's limits must always be the same or lower as the controller's!):
>>>>>>>>

>>>>>>>> https://github.com/openpnp/openpnp/wiki/Machine-Axes#kinematic-settings--rate-limits <https://github.com/openpnp/openpnp/wiki/Machine-Axes#kinematic-settings--rate-limits>

>>>>>>>>
>>>>>>>> Btw. have you tried Issues & Solutions?
>>>>>>>>

>>>>>>>> https://github.com/openpnp/openpnp/wiki/Issues-and-Solutions <https://github.com/openpnp/openpnp/wiki/Issues-and-Solutions>

>>>>>>>>
>>>>>>>> _Mark
>>>>>>>>
>>>>>>>>
>>>>>>>> Am 04.02.2021 um 14:14 schrieb Peter Chaisty:
>>>>>>>>> Hi
>>>>>>>>>
>>>>>>>>> I am having two main issues which may be related.
>>>>>>>>> I am testing just by moving the camera from part to part on the demo board V2
>>>>>>>>>
>>>>>>>>> Mechanical homing works
>>>>>>>>> Visual homing works
>>>>>>>>> Fiducial checks work
>>>>>>>>>
>>>>>>>>> I have the motion controller set to Toolpathfeedrate after previously trying simple Scurve
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 1/  during a move from component to component the pickup head rotates (A axis)
>>>>>>>>> During a check fiducial its fine .
>>>>>>>>> I think  I saw this issue years ago but I can't remember or find anything online.
>>>>>>>>>
>>>>>>>>> 2/ Speed
>>>>>>>>> The speed seems variable and the the feed rate seems to vary as I move around the board .
>>>>>>>>> It varies from a crazy low feedrate to something that's OK at F258 but still slow .
>>>>>>>>> But moving between components on the board it seems to vary every time .
>>>>>>>>>
>>>>>>>>> Can anyone offer any suggestions ?
>>>>>>>>>
>>>>>>>>> Peter
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> 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/39174511-024b-49c1-8a4c-3040c3e650afn%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/39174511-024b-49c1-8a4c-3040c3e650afn%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 <mailto:openpnp+u...@googlegroups.com>.
>>>>>>>> To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/424398fe-4561-4666-b5ba-315a960038bbn%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/424398fe-4561-4666-b5ba-315a960038bbn%40googlegroups.com?utm_medium=email&utm_source=footer>.

>>>>>>> --
>>>>>>> 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/VDQREbARMUs/unsubscribe <https://groups.google.com/d/topic/openpnp/VDQREbARMUs/unsubscribe>.
>>>>>>> To unsubscribe from this group and all its topics, send an email to openpnp+u...@googlegroups.com <mailto:openpnp+u...@googlegroups.com>.
>>>>>>> To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/89111289-c3b0-bdc0-b106-f690be96bed3%40makr.zone <https://groups.google.com/d/msgid/openpnp/89111289-c3b0-bdc0-b106-f690be96bed3%40makr.zone?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 <mailto:openpnp+u...@googlegroups.com>.
>>>>>>> To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CAGLOruTr2o7k_6GsqsQP%3DfJfH9q_KUKWteS3S%2BGqvZmO-QG_fw%40mail.gmail.com <https://groups.google.com/d/msgid/openpnp/CAGLOruTr2o7k_6GsqsQP%3DfJfH9q_KUKWteS3S%2BGqvZmO-QG_fw%40mail.gmail.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 <mailto:openpnp+u...@googlegroups.com>.
>>>>>> To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/89cdf746-666b-b031-f1ef-333bf7842067%40makr.zone <https://groups.google.com/d/msgid/openpnp/89cdf746-666b-b031-f1ef-333bf7842067%40makr.zone?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 <mailto:openpnp+u...@googlegroups.com>.
>>>>> To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/4252a158-e8be-a48b-0b9a-5bc5d3284585%40gmail.com <https://groups.google.com/d/msgid/openpnp/4252a158-e8be-a48b-0b9a-5bc5d3284585%40gmail.com?utm_medium=email&utm_source=footer>.

>>>> --
>>>> 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/VDQREbARMUs/unsubscribe <https://groups.google.com/d/topic/openpnp/VDQREbARMUs/unsubscribe>.
>>>> To unsubscribe from this group and all its topics, send an email to openpnp+u...@googlegroups.com <mailto:openpnp+u...@googlegroups.com>.
>>>> To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/730384e5-36e6-92e6-fb74-36d98f00fc92%40makr.zone <https://groups.google.com/d/msgid/openpnp/730384e5-36e6-92e6-fb74-36d98f00fc92%40makr.zone?utm_medium=email&utm_source=footer>.
>>>>
>>>>
>>>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> Virus-free. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>

>>>>
>>>> --
>>>> 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 <mailto:openpnp+u...@googlegroups.com>.
>>>> To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CAGLOruR12T4mPZE7aNPHNnacdDTozBV5zhDWZcrA2jh3iV3UHA%40mail.gmail.com <https://groups.google.com/d/msgid/openpnp/CAGLOruR12T4mPZE7aNPHNnacdDTozBV5zhDWZcrA2jh3iV3UHA%40mail.gmail.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 <mailto:openpnp+u...@googlegroups.com>.
>>> To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/78a644d3-a48f-fc68-4ac5-1ef0f43af415%40makr.zone <https://groups.google.com/d/msgid/openpnp/78a644d3-a48f-fc68-4ac5-1ef0f43af415%40makr.zone?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 <mailto:openpnp+u...@googlegroups.com>.
>> To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/78468ae2-4484-b0fe-17f9-8bbfcd08f992%40gmail.com <https://groups.google.com/d/msgid/openpnp/78468ae2-4484-b0fe-17f9-8bbfcd08f992%40gmail.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 <mailto:openpnp+u...@googlegroups.com>.
> To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/01c6ca1a-cb8b-2b2d-aab4-589211637f86%40makr.zone <https://groups.google.com/d/msgid/openpnp/01c6ca1a-cb8b-2b2d-aab4-589211637f86%40makr.zone?utm_medium=email&utm_source=footer>.

[ma...@makr.zone]

If this was my firmware, then yes, of course. But I'm merely trying to help TinyG users benefit from OpenPnP features. Usually if you make a Pull Request to somebody else's project you don't upend their versioning system, do you?

_Mark

Am 06.02.2021 um 11:46 schrieb Clemens Koller:

Hi, Mark!

On 05/02/2021 19.15, ma...@makr.zone wrote:

Ahh, you got the very first version. True, there is no difference visible. I was reluctant to increase the build number twice (or three times with the ADC), before the first PR got accepted.

Hawww... please, use clear and unique versioning!But it isn't
I believe I didn't get the latest build.

[Clemens Koller]

Hi, Mark!

I don't see an issue here. You forked the code and work on your own branch. How would that interfere with Alden Hart's stuff?
If he doesn't want to pull your changes in, there might be a reason, but his last commit was in 2015.

Did you talk to him, what his plans are regarding the codebase of TinyG?

Clemens

> To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/bd5d7bd5-6cba-a6c3-1fb9-506c83f42d51%40makr.zone <https://groups.google.com/d/msgid/openpnp/bd5d7bd5-6cba-a6c3-1fb9-506c83f42d51%40makr.zone?utm_medium=email&utm_source=footer>.

[ma...@makr.zone]

The idea is to get the PR accepted. I do not want to fork the project. The fact that Github calls your working clone a "fork" is misleading.

The ADC version is a different matter. I don't think it will ever be accepted, as it rededicates a pin. So I made this available as a branch on my repo, but again that does not mean that I want to be responsible for the entire TinyG project in any way. The last time the ADC hack was made available, somebody posted a patch in a forum post, so consider this "progress" ;-)

Like I said, I just wanted to make new OpenPnP feature available (and acceptable) to TinyG users. I made it without any personal benefit, I don't use a TinyG on my machine. If you still don't like how I made it, sorry to have to say it out loud, but in the end this is a "take it or leave it" offer. It is all Open Source and you are welcome to improve it.

Having said all that, I will add more info to the M115 output in future versions, so the feature set (if not the version) will be clear. After all, it was me who implemented this command on the TinyG in the first place ;-)

_Mark

[Peter Chaisty]

Mark 

Thanks for all your effort.

I realise it represents a lot of tears and many many hours of effort on your part.

On behalf of all Liteplacer / Tiny G people thank you.

Peter

To unsubscribe from this topic, visit https://groups.google.com/d/topic/openpnp/VDQREbARMUs/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/08ee1ad2-d078-d415-257f-6659e828557a%40makr.zone.

[james.edwa...@gmail.com]

Seconded!!!

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CAGLOruRHu25oSLagfr5g2FdSKJwUTc%2BoUfBr3V0wphjy7GV%3DvA%40mail.gmail.com.