Advanced Motion Control - Testing Version Update 7

[ma...@makr.zone]

Hi everybody

I've created a new pull request & OpenPnP 2.0 Testing Version. Only minor bug-fixes and cosmetics.

Pull request is here.

https://github.com/openpnp/openpnp/pull/1082

This also contains the latest changes from the develop Branch.

As always, the Testing Version can be downloaded here:

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

It seems to take a veeery long time to get built. Make sure to get the second version of today (commit e12b91a). Best wait a few hours.

@Florian Chende, please test this as soon as possible with the micron driver units you have. Don't forget to revert the workaround for the bug, as discussed here:

https://groups.google.com/g/openpnp/c/ObzQGzK5HW0/m/_N-e7Io1AwAJ

Big thanks!!

This should now be the last update in the Testing Version.

_Mark

[chende...@gmail.com]

Hi Mark,

I will test asap  but unfortunately right now the machine is in pieces because I started to install all electronics on its final position & configuration and there are some components which are still missing (some magnetic contactors, RCD, etc). Until now everything was spread on the table, power electronics without filters and protections, etc.  I don't think I will be able to test until next week.

Thanks,

Florian.

[chende...@gmail.com]

Hi Mark,

I am not able to move the machine but I was able to start just the controller so that I can perform tests. Imho there are still some problems.

My Gcode string is: C00 N{Name} X{X:%.0f} Y{Y:%.0f} Z{Z:%.0f} R{Rotation:%.2f} S{FeedRate:%.0f} *

Max speed is defined in my openpnp to 10, so slider at 100% is 10, at 0% is 0. My units are microns.

What I did:

1-rotate nozzle 10 degrees, CCW, at 100% speed.

2-rotate 1 degree at 100%

3-rotate 0.1 degree at 100%

4-rotate 10 degree at 10% speed

5-rotate 1 degree at 10%

6-rotate 0.1 degree at 10%

7-rotate 10 degree at 0% speed

8-rotate 1 degree at 0%

9-rotate 0.1 degree at 0%

What is not ok:

-when I move the machine with 0.1 degree, the coordinate is retained in openpnp but the gcode command is not sent

-when I move the machine with 0% speed, the FeedRate variable is empty, the output string is ...S... instead of ...S0...

Here is the log:

2020-12-03 09:09:32.578 Main INFO: Bienvenue, Bienvenido, Willkommen, Hello, Namaskar, Welkom, Bonjour to OpenPnP version 2020-12-03_00-20-11.e12b91a.

2020-12-03 09:09:32.578 Scripting TRACE: Scripting.on Startup

2020-12-03 09:09:32.594 OpenPnpCaptureCamera WARNING: No camera found with ID RYS HFR USB2.0 Camera \\?\usb#vid_15aa&pid_1555&mi_00#6&20f2edd&0&0000#{65e8773d-8f56-11d0-a3b9-00a0c9223196}\global for camera HCam

2020-12-03 09:09:32.634 OpenPnpCaptureCamera WARNING: No camera found with ID HD USB CAMERA \\?\usb#vid_32e4&pid_2214&mi_00#6&22448bc&0&0000#{65e8773d-8f56-11d0-a3b9-00a0c9223196}\global for camera TCam

2020-12-03 09:09:38.996 ReferenceMachine DEBUG: setEnabled(true)

2020-12-03 09:09:39.046 GcodeDriver DEBUG: [serial://COM4] >> C01 *, 6000

2020-12-03 09:09:39.046 GcodeDriver$ReaderThread TRACE: [serial://COM4] << OK

2020-12-03 09:09:39.046 GcodeDriver TRACE: [serial://COM4] confirmed C01 *

2020-12-03 09:09:44.354 AbstractHeadMountable DEBUG: 023D_N1.moveTo((135.900000, -27.800000, 0.000000, 10.000000 mm), 1.0)

2020-12-03 09:09:44.354 ReferenceNozzle TRACE: 023D_N1.transformToHeadLocation((0.000000, 0.000000, 0.000000, 10.000000 mm), ...)

2020-12-03 09:09:44.374 GcodeDriver DEBUG: [serial://COM4] >> C00 N023D_N1 X Y Z R10.00 S10 *, 6000

2020-12-03 09:09:44.374 GcodeDriver$ReaderThread TRACE: [serial://COM4] << OK

2020-12-03 09:09:44.374 GcodeDriver TRACE: [serial://COM4] confirmed C00 N023D_N1 X Y Z R10.00 S10 *

2020-12-03 09:09:48.803 AbstractHeadMountable DEBUG: 023D_N1.moveTo((135.900000, -27.800000, 0.000000, 11.000000 mm), 1.0)

2020-12-03 09:09:48.803 ReferenceNozzle TRACE: 023D_N1.transformToHeadLocation((0.000000, 0.000000, 0.000000, 11.000000 mm), ...)

2020-12-03 09:09:48.803 GcodeDriver DEBUG: [serial://COM4] >> C00 N023D_N1 X Y Z R11.00 S10 *, 6000

2020-12-03 09:09:48.813 GcodeDriver$ReaderThread TRACE: [serial://COM4] << OK

2020-12-03 09:09:48.813 GcodeDriver TRACE: [serial://COM4] confirmed C00 N023D_N1 X Y Z R11.00 S10 *

2020-12-03 09:09:53.722 AbstractHeadMountable DEBUG: 023D_N1.moveTo((135.900000, -27.800000, 0.000000, 11.100000 mm), 1.0)

2020-12-03 09:09:53.722 ReferenceNozzle TRACE: 023D_N1.transformToHeadLocation((0.000000, 0.000000, 0.000000, 11.100000 mm), ...)

2020-12-03 09:10:18.880 AbstractHeadMountable DEBUG: 023D_N1.moveTo((135.900000, -27.800000, 0.000000, 21.100000 mm), 0.1)

2020-12-03 09:10:18.880 ReferenceNozzle TRACE: 023D_N1.transformToHeadLocation((0.000000, 0.000000, 0.000000, 21.100000 mm), ...)

2020-12-03 09:10:18.890 GcodeDriver DEBUG: [serial://COM4] >> C00 N023D_N1 X Y Z R21.10 S1 *, 6000

2020-12-03 09:10:18.890 GcodeDriver$ReaderThread TRACE: [serial://COM4] << OK

2020-12-03 09:10:18.890 GcodeDriver TRACE: [serial://COM4] confirmed C00 N023D_N1 X Y Z R21.10 S1 *

2020-12-03 09:10:28.181 AbstractHeadMountable DEBUG: 023D_N1.moveTo((135.900000, -27.800000, 0.000000, 22.100000 mm), 0.1)

2020-12-03 09:10:28.181 ReferenceNozzle TRACE: 023D_N1.transformToHeadLocation((0.000000, 0.000000, 0.000000, 22.100000 mm), ...)

2020-12-03 09:10:28.191 GcodeDriver DEBUG: [serial://COM4] >> C00 N023D_N1 X Y Z R22.10 S1 *, 6000

2020-12-03 09:10:28.191 GcodeDriver$ReaderThread TRACE: [serial://COM4] << OK

2020-12-03 09:10:28.191 GcodeDriver TRACE: [serial://COM4] confirmed C00 N023D_N1 X Y Z R22.10 S1 *

2020-12-03 09:10:33.266 AbstractHeadMountable DEBUG: 023D_N1.moveTo((135.900000, -27.800000, 0.000000, 22.200000 mm), 0.1)

2020-12-03 09:10:33.266 ReferenceNozzle TRACE: 023D_N1.transformToHeadLocation((0.000000, 0.000000, 0.000000, 22.200000 mm), ...)

2020-12-03 09:10:38.554 AbstractHeadMountable DEBUG: 023D_N1.moveTo((135.900000, -27.800000, 0.000000, 32.200000 mm), 0.0)

2020-12-03 09:10:38.554 ReferenceNozzle TRACE: 023D_N1.transformToHeadLocation((0.000000, 0.000000, 0.000000, 32.200000 mm), ...)

2020-12-03 09:10:38.564 GcodeDriver DEBUG: [serial://COM4] >> C00 N023D_N1 X Y Z R32.20 S *, 6000

2020-12-03 09:10:38.564 GcodeDriver$ReaderThread TRACE: [serial://COM4] << OK

2020-12-03 09:10:38.564 GcodeDriver TRACE: [serial://COM4] confirmed C00 N023D_N1 X Y Z R32.20 S *

2020-12-03 09:10:45.935 AbstractHeadMountable DEBUG: 023D_N1.moveTo((135.900000, -27.800000, 0.000000, 33.200000 mm), 0.0)

2020-12-03 09:10:45.935 ReferenceNozzle TRACE: 023D_N1.transformToHeadLocation((0.000000, 0.000000, 0.000000, 33.200000 mm), ...)

2020-12-03 09:10:45.943 GcodeDriver DEBUG: [serial://COM4] >> C00 N023D_N1 X Y Z R33.20 S *, 6000

2020-12-03 09:10:45.943 GcodeDriver$ReaderThread TRACE: [serial://COM4] << OK

2020-12-03 09:10:45.943 GcodeDriver TRACE: [serial://COM4] confirmed C00 N023D_N1 X Y Z R33.20 S *

2020-12-03 09:10:49.204 AbstractHeadMountable DEBUG: 023D_N1.moveTo((135.900000, -27.800000, 0.000000, 33.300000 mm), 0.0)

2020-12-03 09:10:49.204 ReferenceNozzle TRACE: 023D_N1.transformToHeadLocation((0.000000, 0.000000, 0.000000, 33.300000 mm), ...)

Thanks,

Florian.

[ma...@makr.zone]

Hi Florian

There are configurations, where this behaviour is expected and normal:

1. A 0.1 degree step might be swallowed if the Resolution on the R axis is > 0.1. Remember, the bug I now fixed mistakenly converted the degrees from "millimeters" to "microns" i.e. 1 degree = 1000. So it is plausible you set the resolution to something larger on the Axis:
   https://github.com/openpnp/openpnp/wiki/Machine-Axes#controller-settings
   
2. The 0% speed setting behaviour is expected behavior, but only if you use the ToolPathFeedRate Motion Control Type (otherwise tell me!):
   https://github.com/openpnp/openpnp/wiki/GcodeAsyncDriver#gcodedriver-new-settings
   This is basically a "short-circuit" Motion Control Type, i.e. it simply does as instructed and leaves the behaviour to the controller.
   

However, you should change your G-code to the following form, basically moving the letters into the curly brackets:

C00 N{Name} {X:X%.0f} {Y:Y%.0f} {Z:Z%.0f} {Rotation:R%.2f} {FeedRate:S%.0f} *

This will ommit the letters/words completely when an axis does not move and/or when no (zero) feed-rate is given. In G-code a feed-rate of 0 is illegal, therefore this is prevented by removing the feed-rate completely. If you set your feed-rate in the driver to 0 or by setting speed to 0% you are telling the controller "do your own thing". There were discussions in the group where this (or something like this) was wanted/demanded.

But: it should not do that in any of the other Motion Control Types. If you use another one, like e.g. the recommended ModeratedConstantAcceleration, the 0% it should instead be limited to the built-in minimal planner feed-rate of 0.1mm/s or 6mm/min.

_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/44feeaef-6a17-4baf-8133-62229fed9142n%40googlegroups.com.

[chende...@gmail.com]

Hi Mark,

Thanks for clarification. I will check all these details and re-do the test asap.

Florian.

[Marek T.]

Hi Mark,

Sorry if it is off-topic, but very little if it s :-).

I'm not sure where it was, which thread, but I've seen your statement that after all these your changes (or maybe it is generally 2.0) having the sub-drivers is handled but not recommended as it is not optimal.

Can you explain how it relates to the feeders drivers/controllers? Is it at all or the statement is about the axes motion controllers only?

[greg.hj...@gmail.com]

I pulled the code and was able to pick a couple parts over lunch.  Also wanted to mention that after your previous update I set up visual homing and my machine is waaay more consistent now.  (it is honestly amazing to me lol!)  I have a duet controller, is there anything you'd like me to test?

[Shai]

@greg what do you mean by visual homing? I'm curious - sorry if I missed the explanation somewhere.

[greg.hj...@gmail.com]

Here is a link to the documentation:

https://github.com/openpnp/openpnp/wiki/Visual-Homing

Basically you put a fiducial or something you can recognize on the table of your machine somewhere.  After the machine homes using the endstops, it re-homes onto this using the camera and updates the coordinates.  I used a 3d printed shape with a hole in it and it works really well even though my hole isn't even perfectly circular.  The key is it is consistent every time and eliminates the minor variation that seemed to come from my endstops.

[chende...@gmail.com]

Hi Mark,

I changed the resolution of the rotation axis to 0.01 and all seem to be ok now.

My motion control type is ToolPathFeedRate , all the movement details are handled by servo drivers.

Thanks again,

Florian.

[ma...@makr.zone]

Hi Marek

It only concerns drivers/controllers with axes and strictly speaking, only the head+nozzle X, Y, Z, C axes i.e. it does not matter for other axes like those for separate feeder actuation, conveyors, machine doors etc.). 

You can read about the "Why" here:

https://github.com/openpnp/openpnp/wiki/Motion-Planner#motion-path-planning

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/755cad7d-e8da-4a63-9edb-6e62dfbdd63dn%40googlegroups.com.

[ma...@makr.zone]

> I set up visual homing and my machine is waaay more consistent now.  (it is honestly amazing to me lol!)

Cool! ;-)

> I have a duet controller, is there anything you'd like me to test?

At the moment, I'm just happy with you testing the overall normal operation and keeping a critical eye open. Thanks for that!

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/d0a089f3-e726-419d-8470-3c158a96157fn%40googlegroups.com.

[Marek T.]

Ok, thanks, so this is clear about the feeders sub-driver.

Now, what with the hardware option: On the head there are 6 motors (2xZ and 4xC).

So it is nice to place some small motion controller on the head and only USB+Strong_power leaded by the chain.

But in this case this ZC is on the driver separated from XY driver:

- is it breaking your control idea?

- will it not work at all, or will work but not so good as could do when every axes connected to the one driver?

[ma...@makr.zone]

> Now, what with the hardware option: On the head there are 6 motors (2xZ and 4xC).
> So it is nice to place some small motion controller on the head and only USB+Strong_power leaded by the chain.

Agree!

> But in this case this ZC is on the driver separated from XY driver...

In this case you can still use the main controller on the head and use step/dir lines back to X/Y with opto-couplers and drivers on the motors. These step/dir lines are only signal lines and can be very small.

Or even more professional: something like the Duet 3, i.e. a CAN bus with expansion boards but still coordinated control from the main controller on the head.

https://duet3d.dozuki.com/c/Duet_3_Mini_5
or
https://duet3d.dozuki.com/c/Duet_3_Mainboard_6HC
+
https://duet3d.dozuki.com/Wiki/Duet_3_Expansion_Hardware_Overview

Unfortunately, the Duet 3 controllers are extremely feature rich and powerful and therefore rather large (and expensive). The 6HC is physically huge and the Mini+ has only 5 axes, so neither one of them is a perfect match as an OpenPnP head mounted controller.

Maybe we could one day persuade Duet3D to produce a compact OpenPnP controller ;-)

> will it not work at all, or will work but not so good as could do when every axes connected to the one driver?

Even if you have multiple independent controllers, it will always work. It is only a matter of some optimizations that are then not possible.

Maybe one day we can even support separated controllers by timing them against each other using planner prediction. At least for rotation axes this could probably be risked, because if timing prediction turns out inaccurate or if communications lag, the worst that can happen is that a part might be still be rotating when the Z axis is [going] down. This may spoil one placement/one part but hardly damage the machine. 

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/012aa12c-6307-4859-a3eb-da214878bcffn%40googlegroups.com.

[ma...@makr.zone]

Hi everybody

I discussed this with Jason (last week), he had a look at the solution but doesn't currently find the time to integrate this himself, so he is OK for me to go forward and merge it into the develop branch a.k.a. OpenPnP 2.0.

Consequently, this is the last call for testing!

Everybody planning to keep up with the OpenPnP 2.0 version as it evolves should now backup everything and use the testing version to confirm that her/his machine still works after the migration.

If nothing bad pops up, I will be merging this next week-end.

Note that the migration is designed to create a working machine that almost completely behaves as before. It is only for those who want to benefit from the many new features that more work is required. For instance: if the documentation says you need new firmware, this is only the case for the new features.

Everything is linked/documented here:

https://makr.zone/openpnp-advanced-motion-control/553/

_Mark

[Yevhenii Shcherbakov]

Hi Mark! 

I am still on Upgrade 3, and the question has been discussed many times already, but ... 

I will ask again: Will the simultaneous movement (with XY) of the rotary C axes be enabled when using multiple controllers? 

I have the C axes on a separate controller, and when I need to rotate the components (without aligning to the camera), the performance drops by almost 25%.

_Yevhenii.  

четверг, 10 декабря 2020 г. в 09:58:34 UTC+2, ma...@makr.zone:

[Marek T.]

Sorry for my 3cents...

As I have understood it will be not. Simultaneous is possible within one motion cotroller only.

But Yevhenii, why do you loose performance when only rotation is done? Or do you mean XY and the rotation after it?

[Yevhenii Shcherbakov]

Marek T. ,  

Yes, I'm talking about XY and C movement (component rotation).   

The movement is simple, and it makes no sense to synchronize it with XY, just send a command to turn ... 

I understand it has to do with the "OK" response from the controller?  

четверг, 10 декабря 2020 г. в 16:54:05 UTC+2, Marek T.:

[tony...@att.net]

Oh, one thing I forgot to mention about TinyG - instead of using G92 to reset axis coordinates, its better to use G28.3 (see below) especially if you want probing to work (TinyG always probes in absolute coordinates so if you have set any offset via G92 they get ignored and the probe will not occur where you thought it would).  I do use G92 to set all axis offsets to zero in my connect command but that probably could be done as the first thing in the HOME_COMMAND as well.

            <command type="HOME_COMMAND">

               <text><![CDATA[G28.2 Y0 Z0]]></text>

               <text><![CDATA[G28.2 X0]]></text>

               <text><![CDATA[G28.3 X0 Y0 Z0 A0]]></text>

            </command>

            <command type="SET_GLOBAL_OFFSETS_COMMAND">

               <text><![CDATA[G28.3 {X:X%.4f} {Y:Y%.4f} {Z:Z%.4f} {A:A%.4f} ; reset coordinates]]></text>

            </command>

Tony

[ma...@makr.zone]

Hi Yevhenii

Yes it will be simultaneous, but OpenPnP will actively wait for the controllers to complete, before the next move command will be sent. This wait i.e. the communication ping-pong makes it a bit slower. For modern USB serial this is almost nothing (typically ~6ms), for old-style low baud-rate serial it might be more, for TCP/IP it might be much more, especially on Smoothie where TCP/IP implementation is rudimentary.

> have the C axes on a separate controller, and when I need to rotate the components (without aligning to the camera), the performance drops by almost 25%.

Drop by 25% as compared to what?

First I recommend updating to the latest Testing Version.

Then use the Issues & Solutions System to help you optimize the machine.

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

Especially make sure your axes are individually configured for feed-rate, acceleration [jerk]  limit, according to their units. Often the rotation axes can have much higher feed-rate and acceleration limits (in degrees) than the linear axes (in millimeters).  Remove the driver feed-rate limit (set to zero).

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

_Mark

--
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/R1YOUW9oLZM/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/0adc0587-aa40-43bb-aa15-c1d7ff6d4dfbn%40googlegroups.com.

[Jason von Nieda]

Hi all,

Sorry for my absence - regular life gets in the way :)

I just want to say I've briefly reviewed the test version and the code. I've not had time to do a full machine test but I've been keeping an eye on the test results in these threads and I think it's time to merge this feature. More importantly, I think this feature is critical for the advancement of OpenPnP as a platform, and I think Mark has done an excellent job making it production ready.

With any large new feature there's the possibility of problems, but I think we can address them quickly. So, consider this my seal of approval :)

As Mark said, it's important that you take a backup of your configuration directory, and preferably your application version before you install the update. This is critically important if you are using your machine for production jobs. If you need to download an older version, every version is archived at https://openpnp.s3-us-west-2.amazonaws.com/index.html.

A big thank you to Mark for all his hard work on this, and for taking the initiative to get it done. And thank you to all the testers that have tried each new version to make sure it will work for all our users.

Thanks,

Jason

On Thu, Dec 10, 2020 at 1:58 AM ma...@makr.zone <ma...@makr.zone> wrote:

Hi everybody

I discussed this with Jason (last week), he had a look at the solution but doesn't currently find the time to integrate this himself, so he is OK for me to go forward and merge it into the develop branch a.k.a. OpenPnP 2.0.

Consequently, this is the last call for testing!

Everybody planning to keep up with the OpenPnP 2.0 version as it evolves should now backup everything and use the testing version to confirm that her/his machine still works after the migration.

If nothing bad pops up, I will be merging this next week-end.

Note that the migration is designed to create a working machine that almost completely behaves as before. It is only for those who want to benefit from the many new features that more work is required. For instance: if the documentation says you need new firmware, this is only the case for the new features.

Everything is linked/documented here:

https://makr.zone/openpnp-advanced-motion-control/553/

_Mark

On Wednesday, December 2, 2020 at 8:43:22 PM UTC+1 ma...@makr.zone wrote:

Hi everybody

I've created a new pull request & OpenPnP 2.0 Testing Version. Only minor bug-fixes and cosmetics.

Pull request is here.

https://github.com/openpnp/openpnp/pull/1082

This also contains the latest changes from the develop Branch.

As always, the Testing Version can be downloaded here:

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

It seems to take a veeery long time to get built. Make sure to get the second version of today (commit e12b91a). Best wait a few hours.

@Florian Chende, please test this as soon as possible with the micron driver units you have. Don't forget to revert the workaround for the bug, as discussed here:

https://groups.google.com/g/openpnp/c/ObzQGzK5HW0/m/_N-e7Io1AwAJ

Big thanks!!

This should now be the last update in the Testing Version.

_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/f55b2d33-d8d6-4a93-a9c8-7122c3672ad6n%40googlegroups.com.

[ma...@makr.zone]

> As I have understood it will be not. Simultaneous is possible within one motion cotroller only.

Just to make it absolutely clear: what Marek says is not true.

See my other response to what is true.

No offense, Marek :-)

_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/9397875f-da18-4027-9ad9-b4c347c3a7ecn%40googlegroups.com.

[Marek Twarowski]

Not at all Mark !!!

I was not observing this your work progress and improvement assumptions too carefully. No offence:-). It's not because I don't appreciate your efforts, it's because that I think that this advanced motion control is not usable for my actual machine (with servomotors' drivers with their own PID and motion shapes). 

Also because 2.0 is not for me and it looks that it will be not for me still a long time.

Telling what I did I was probably (auto-)suggested with this your statement:

"Even if you have multiple independent controllers, it will always work. It is only a matter of some optimizations that are then not possible." THAT ARE THEN NOT POSSIBLE.

So it must be something other you've had on your mind that I thought that understood.

It looks I must definitely more carefully read your description how all this work!

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/R1YOUW9oLZM/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/ef02e624-0c31-d941-9298-a346140f382d%40makr.zone.

[ma...@makr.zone]

Thanks Tony,

I changed the SET_GLOBAL_OFFSETS_COMMAND suggestion.

Are you sure the line is needed/wanted in HOME_COMMAND? When I remember the TinyG code correctly, the axes will already be at zero after power-up or G28.2.

If you re-home with power still on, I don't think you want to reset the rotation axis in general. Any reason for that?

_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/6c7d287a-0abc-4252-9fe3-5fc496a746a5n%40googlegroups.com.

[ma...@makr.zone]

IMPORTANT: The new version is still always as fast or faster than current OpenPnP 2.0 and especially in case of sub-drivers, much faster than OpenPnP 1.0 where simultaneous motion across drivers was definitely not possible  (because of missing separated MOVE_TO_COMPLETE_COMMAND).

Some important optimizations of the new version are still enabled, even with multiple controllers! Most importantly the individual axis speed control and asynchronous communication with the controller.

> "Even if you have multiple independent controllers, it will always work. It is only a matter of some optimizations that are then not possible." ...

> So it must be something other you've had on your mind that I thought that understood.

For those interested: The optimizations I was talking about are described here:

https://github.com/openpnp/openpnp/wiki/Motion-Planner#motion-path-planning

> Also because 2.0 is not for me and it looks that it will be not for me still a long time.

The "Retry" problem?

Most of the other things, you once listed should be possible now. Pneumatic nozzles, for instance.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CAJDP_hd-BqAmNETb7nwRSsqfLNeXBhju2PgU%3DVQmxxUr0BhNXA%40mail.gmail.com.

[Marek Twarowski]

Yes Mark, missing of fully functional "retry" system is main reason why I don't go into 2.0.

As "fully" I mean implementation of everything we've discussed here a long time ago. Re-trying to pick when vacuum or vision fails.

I'm also not sure how/if exists in 2.0 the function of "ignore and continue", which is really very usable for everyday job. But I hope it's much less complicated to eventually add if it's not there...

I understand that there are many different code important improvements in 2.0. But above brokenings are for me personally (or my staff) critical, and I prefer have them working properly (because as you probably know I have it in my customized 1.0) than get 2.0's benefits. 

Unfortunately my skills are not enough to do with 2.0 what I did with 1.0 :-(. 

But finally even our Grand Master has a problems to do it since more than one year already - what gives me a clear pointer "don't touch it if someone like that has stuck with it".

I really appreciate all what you do, like everybody here probably. And btw thanks for pneumatics nozzles service adding. And sorry that I still had no time to test it, but I can't get access to the machines working almost nonstop. I hope for more time soon.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/7bf5ebb6-b521-2354-40e3-2f4cffb8caaf%40makr.zone.

[ma...@makr.zone]

> but I can't get access to the machines working almost nonstop.

I hope this means good business! ;-)

_Mark

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

[Yevhenii Shcherbakov]

Hi Mark.

>Drop by 25% as compared to what?  

Compared to stacking components without turning. I checked it simply: one board, just in the Feeder settings I set the initial position of the component to 0 or 90 degrees. In the case of no rotation, I get a performance of ~ 1200, and with a rotation of ~ 850. 

Turning speed limit 30000, acceleration 10000, jerk 0.

Install Upgrade 7 and try again. Maybe something will change.  

>Then use the Issues & Solutions System to help you optimize the machine.  

Done. The only warning concerns the C axes and goes something like this: "You can set limits for each axis separately.  

I will try to install Upgrade 7. Maybe something will change in speed. 

Thanks

_Yevhenii 

пятница, 11 декабря 2020 г. в 00:08:37 UTC+2, Marek T.:

[ma...@makr.zone]

> The only warning concerns the C axes and goes something like this: "You can set limits for each axis separately. 

And that's probably the solution ;-)

[Yevhenii Shcherbakov]

> And that's probably the solution ;-)  

I installed them. It's just that the limits are the same for all 4 axes of C. But the error remains. I don't understand how it can be "fixed".  

пятница, 11 декабря 2020 г. в 10:09:28 UTC+2, ma...@makr.zone:

[Marek Twarowski]

> I hope this means good business! ;-)

It's not bad :-)

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/61bfbacf-d878-4888-e6fe-67a46dd7dbe7%40makr.zone.

[ma...@makr.zone]

OK, there is a "heuristic" in place that when acceleration == 2x feed-rate, the Issues & Solutions system thinks you haven't yet tuned it. Because this is the migration default (assuming it takes 0.5s to fully accelerate a machine).

So if your axis has indeed exactly 0.5s acceleration time, then either dismiss the Solution or set slightly different values for acceleration or feed-rate on the axis.

Back to your problem:

Use Motion Planner Diagnostics to test and time the motion with and without rotation:

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

Look at the Actual time in both tests. Perhaps send me a screenshot:

_Mark

--

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/R1YOUW9oLZM/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/da2ea008-02bc-4b18-93d0-a3ede6140dccn%40googlegroups.com.

[ma...@makr.zone]

Hi everybody

The Global Axes and Advanced Motion Control feature set has finally been integrated into the develop branch a.k.a. OpenPnP 2.0.

It is identical to Update 7 (Testing Version) except for the improved Issues & Solutions SET_GLOBAL_OFFSETS_COMMAND suggestion for TinyG. Note, the Testing Version also has the Placement Training feature that is still not yet included in develop.

Download the latest OpenPnP 2.0 Version here:

https://openpnp.org/downloads/

See the PR:

https://github.com/openpnp/openpnp/pull/1086

Many thanks to all the testers, machine.xml contributors and sounding board members who have helped make this possible!

I will continue to do my best to quickly solve any issues that might still pop up.

Enjoy,

[Oz-Ron]

Hi Mark,

Wow!  You have done a monumental amount of work on this major upgrade!  I would guess twice as much again on all the documentation.

Thank you for your enormous contribution, I for one greatly appreciate it.

 

There is so much to absorb it is going to take quite a while to wrap my head around it, but I really like what you have achieved.  Very impressive. It broke my machine for a while today until I reverted to legacy settings where needed.  All good now.  Just need to run a job first and then I can afford some down time to upgrade to the various wealth of new features.

 

Thanks again,

Ron

[ma...@makr.zone]

Thanks, Ron

Just be sure not to miss Issues & Solutions to start optimizing or when things got broken.

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

The system also links to the Wiki contextually (using the button).

_Mark

--
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/R1YOUW9oLZM/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/a41f7822-4443-4e63-9d13-fa0181133f86n%40googlegroups.com.

[Shai]

Hi Mark,

First of all, great work. I just updated to latest but still have to go through everything to learn of all the new features. A few things though:

1. On my iMac latest version OSX, the tabs are highlighted weird where it's hard to see them. Not sure if this has to do with your update? See attached images.

2. For those that have a dual nozzle shared C setup like the Rapid Placer, do you still have to put 0 into the two fields? It was radius and bearing distance from nozzle. If these fields are always 0, perhaps just remove them?

[ma...@makr.zone]

Hi Shai

> 1. On my iMac latest version OSX, the tabs are highlighted weird where it's hard to see them. Not sure if this has to do with your update? See attached images.

Can't imagine how my changes could influence that.

> 2. For those that have a dual nozzle shared C setup like the Rapid Placer, do you still have to put 0 into the two fields? It was radius and bearing distance from nozzle. If these fields are always 0, perhaps just remove them?

You mean shared Z, right?

https://github.com/openpnp/openpnp/wiki/Transformed-Axes#referencecamcounterclockwiseaxis

Yes these two fields (Cam Wheel Radius/ Cam Wheel Gap) could be removed IMHO. Again, those only add a constant offset that must then be cancelled in the camera <-> nozzle offset Z.

But: my goal is still to have seamless migration, so maybe we'll only remove them on the GUI, but not internally.

@Jason, what do you think?

_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/ea00f7af-d44a-47f5-98f8-8bdb68d1032cn%40googlegroups.com.

[jack ma]

Hi Mark

I have just made an upgraded of Openpnp with advanced motion control.Great work and it's much easier for config. There are some question about.

1:When I tried to move c axis from jog panel the x and y axis will move or I should say a shake which will not happen in the old version.

2:When I want to move a small distance for x/y there will be an obvious shake and not caused by my controller.

And looks that the mechine.xml for old and new version are not compatible?

[ma...@makr.zone]

Hi Jack

it is hard to diagnose without machine.xml or log or further information.

Have you just migrated?

Or have you already enabled new features? If yes, have you already used the Issues & Solutions system?

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

The "shake" could come from runout compensation plus backlash-compensation. But it should be the same as before. 

> And looks that the mechine.xml for old and new version are not compatible?

The new machine.xml cannot be used with the old version, yes.

But the old machine.xml should be automatically migrated, once you start the new version the first time. Can you confirm this?

_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/9de555e5-b76c-45d2-a835-b37b5aa8a3d6n%40googlegroups.com.

[jack ma]

The old mechine.xml will transform automatically just as you said that's no problem. I just made an upgraded from old version and didn't make some changes.

I will try solutions system and see if that will be helpful
Thanks a lot

[Yevhenii Shcherbakov]

Thanks Mark

Digging through the settings - no errors. 

Fresh test showed 1210CPH and 1085CPH without / with component rotation.  

_Yevhenii.

вторник, 15 декабря 2020 г. в 03:29:41 UTC+2, wdd102...@gmail.com:

[Yevhenii Shcherbakov]

Hi Mark. 

Yesterday I had a crash with the machine. 

With Nozzle lowered, the Homing button was pressed into the feeder ... As a result, Nozzle was broken.

I have safe zones set in the axes settings, but this time they did not work for some reason. 

Bug?  

вторник, 15 декабря 2020 г. в 14:48:40 UTC+2, Yevhenii Shcherbakov:

[ma...@makr.zone]

And you still got the "shakes" you descriped?

And are you absolutely sure they were not present on the old OpenPnP Version?

Need the machine.xml and log (of both OpenPnP versions) and a description of your controller and connection.

_Mark

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/R1YOUW9oLZM/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/c2eb1c4e-9c9d-4675-9d26-61ea04371c63n%40googlegroups.com.

[Yevhenii Shcherbakov]

Hi Mark.

I installed Upgrade7 yesterday. Test version.

Here's another, I don't know, a bug or a feature. 

With the recommended set flags for the axes of rotation, I get the following bugg: 

at the beginning of the layout of the rotation components only by 180 degrees (as in the setting of the feeder). But in the process of work, the rotation all the angle of rotation increases, and at the end of the board, the machine rotates the axes most of the time. If all flags are unchecked, the layout is correct. I apologize for the quality of the video - I am not a blogger.  

https://youtu.be/yllUF3_zbjM

среда, 16 декабря 2020 г. в 09:56:55 UTC+2, ma...@makr.zone:

[ma...@makr.zone]

OpenPnP records all the logs (a 100 sessions back) here:

https://github.com/openpnp/openpnp/wiki/FAQ#where-are-configuration-and-log-files-located

Please send me the one that you think logged this.

_Mark

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/R1YOUW9oLZM/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/cea9d073-4494-486a-867a-dbd119367a0dn%40googlegroups.com.

[ma...@makr.zone]

Hi Yevhenii

> I installed Upgrade7 yesterday. Test version.

you should now install the regular OpenPnP 2.0 version. The Advanced Motion Control szuff has finally been merged.

> But in the process of work, the rotation all the angle of rotation increases, and at the end of the board, the machine rotates the axes most of the time.

What type of controller do you have? What firmware version? (you might have named it earlier, but sorry can't remember who has what for all of you ;-)

There is a requirement for the G92 command to work properly and maybe that this is not the case here (see Point 5):
https://github.com/openpnp/openpnp/wiki/Motion-Controller-Firmwares#key-features

Smoothie needs the new firmware for this to work correctly.

If your controller does not support it, you can use Wrap Around or Limit to ±180° bot not both at the same time:
https://github.com/openpnp/openpnp/wiki/Machine-Axes#controller-settings-rotational-axis

You could try to add a M400 line in front of the G92 of your SET_GLOBAL_OFFSETS_COMMAND. This might help but it may also slow the machine.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/f5bcca4f-496a-4496-91c9-0a9d98199ff0n%40googlegroups.com.

[Yevhenii Shcherbakov]

Hi Mark.

> you should now install the regular OpenPnP 2.0 version. The Advanced Motion Control szuff has finally been merged. 

I was installing the regular version but it got errors related to machine.xml on startup.

> What type of controller do you have? What firmware version? (you might have named it earlier, but sorry can't remember who has what for all of you ;-)  

Now I have 2 controllers: Sbase1.3 and SKR1.3. In both controllers, your "author's" firmware  

>For OpenPnP 2.0 testing version: Download the newest 5-axis firmware.bin and don’t forget Switch Linear ↔ Rotational as explained above.  

https://makr.zone/smoothieware-new-firmware-for-pnp/500/

>If your controller does not support it, you can use Wrap Around or Limit to ±180° bot not both at the same time:  

But the wiki says a little differently:

>Fortunately, if Limit to ±180° and Wrap around are combined, the axis coordinate is reset to its -180° ... +180° equivalent coordinate after the wrap-around move. Therefore the angle will not wind up. 

Log file in the application.  

среда, 16 декабря 2020 г. в 13:04:57 UTC+2, ma...@makr.zone:

[ma...@makr.zone]

With my newest Smoothie firmware you should be OK with Wrap Around and Limit to ±180°.

Unfortunately the attached log file only contains the welcome info.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/c8066551-d3b6-4e5c-bedf-5ccdc2a9216en%40googlegroups.com.

[Duncan Ellison]

Hey _Mark

Great job getting this through to production, I guess I should be moving over to the main branch now.

Is there anything special to watch out for here?

Do I just re-install the production code with no changes to the XML files?

Duncan

[ma...@makr.zone]

Hi Duncan

First: backup everything.

> Is there anything special to watch out for here?

The placement training feature is in test but not yet in develop. So the corresponding settings in the machine.xml must be removed. You will be prompted to do that on startup (message box).

> Do I just re-install the production code with no changes to the XML files?

AFAIK, yes. I'm always starting from Eclipse/Development so I'm actually a noob when it comes to how the regular installer works.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/f971076e-721f-4a67-b790-9ba63a1c4f7en%40googlegroups.com.