Advanced Motion Control in OpenPnP

946 views
Skip to first unread message

ma...@makr.zone

unread,
Oct 9, 2020, 5:29:39 PM10/9/20
to OpenPnP
Hi all

this is a continuation of the already bursting thread here:

If have just created a new Pull Request, naturally based on the previous work.


I will now start writing instruction, directly in the Wiki (unlinked pages). Once there is a minimal set of instructions, it will make sense to provide a new testing version.

Or I can create it now, if Jason is ok with that and you guys feel adventurous. ;-)

_Mark

Duncan Ellison

unread,
Oct 13, 2020, 5:09:08 PM10/13/20
to OpenPnP
Hi _Mark,

I've been out of the loop for a couple of weeks and just updated the test code using the updater and something else broke :-(

I can HOME / JOG / MOVE, but running a job causes a Smoothie crash as soon as the pick tries to raise the nozzle.  It's ending an invalid feed rate to the Smoothie, like this:

2020-10-13 21:39:37.040 Scripting TRACE: Scripting.on Nozzle.AfterPick
2020-10-13 21:39:37.053 AbstractHeadMountable DEBUG: N1.moveToSafeZ(1.0)
2020-10-13 21:39:37.054 ReferenceNozzle DEBUG: N1.transformToHeadLocation((8.768939, -380.376596, 7.760000, 0.000000 mm), ...) runout compensation: (-0.024939, -0.093404, 0.000000, 0.000000 mm)
2020-10-13 21:39:37.054 AbstractHeadMountable DEBUG: N1.moveTo((-6.712000, -379.951000, 0.000000, 0.000000 mm), 1.0)
2020-10-13 21:39:37.054 ReferenceNozzle DEBUG: N1.transformToHeadLocation((8.768939, -380.376596, 7.760000, 0.000000 mm), ...) runout compensation: (-0.024939, -0.093404, 0.000000, 0.000000 mm)
2020-10-13 21:39:37.058 GcodeDriver DEBUG: [serial://COM13] >> G1   Z0.0000   F0, 6000
2020-10-13 21:39:37.079 GcodeDriver$ReaderThread TRACE: [serial://COM13] << ok
2020-10-13 21:39:37.079 GcodeDriver TRACE: [serial://COM13] confirmed G1   Z0.0000   F0
2020-10-13 21:39:37.080 GcodeDriver DEBUG: [serial://COM13] >> M400 ; Wait for moves to complete before returning, 6000
2020-10-13 21:39:37.080 GcodeDriver$ReaderThread TRACE: [serial://COM13] << Error: Undefined feed rate
2020-10-13 21:39:37.080 GcodeDriver$ReaderThread TRACE: [serial://COM13] << Entering Alarm/Halt state
2020-10-13 21:39:37.081 GcodeDriver$ReaderThread TRACE: [serial://COM13] << !!
2020-10-13 21:39:43.080 ReferenceActuator DEBUG: TOWER FINISHED.actuate(false)
2020-10-13 21:39:43.080 GcodeDriver DEBUG: [serial://COM13] >> M400 ; Wait for moves to complete before returning, 6000
2020-10-13 21:39:43.081 GcodeDriver$ReaderThread TRACE: [serial://COM13] << !!
2020-10-13 21:39:49.080 SystemLogger ERROR: java.lang.Exception: Timeout waiting for response to M400 ; Wait for moves to complete before returning

I know there's been a ton of discussion around this and I can't sort out the problem from the noise.

For reference, I've tried a couple of the motion models with the same results and this is my current  default move command as we've discussed a few times before :

G1 {X:X%.4f} {Y:Y%.4f} {Z:Z%.4f} {A:A%.4f} {B:B%.4f} {FeedRate:F%.0f}  

Also ....  did I read somewhere in the posts that you determined that 3rd Order Control was just too much for Smoothie ??

Arthur Wolf

unread,
Oct 13, 2020, 5:44:02 PM10/13/20
to ope...@googlegroups.com
On Tue, Oct 13, 2020 at 11:09 PM Duncan Ellison <duncan_...@colnewater.com> wrote:
Hi _Mark,

I've been out of the loop for a couple of weeks and just updated the test code using the updater and something else broke :-(

I can HOME / JOG / MOVE, but running a job causes a Smoothie crash as soon as the pick tries to raise the nozzle.  It's ending an invalid feed rate to the Smoothie, like this:

2020-10-13 21:39:37.040 Scripting TRACE: Scripting.on Nozzle.AfterPick
2020-10-13 21:39:37.053 AbstractHeadMountable DEBUG: N1.moveToSafeZ(1.0)
2020-10-13 21:39:37.054 ReferenceNozzle DEBUG: N1.transformToHeadLocation((8.768939, -380.376596, 7.760000, 0.000000 mm), ...) runout compensation: (-0.024939, -0.093404, 0.000000, 0.000000 mm)
2020-10-13 21:39:37.054 AbstractHeadMountable DEBUG: N1.moveTo((-6.712000, -379.951000, 0.000000, 0.000000 mm), 1.0)
2020-10-13 21:39:37.054 ReferenceNozzle DEBUG: N1.transformToHeadLocation((8.768939, -380.376596, 7.760000, 0.000000 mm), ...) runout compensation: (-0.024939, -0.093404, 0.000000, 0.000000 mm)
2020-10-13 21:39:37.058 GcodeDriver DEBUG: [serial://COM13] >> G1   Z0.0000   F0, 6000
2020-10-13 21:39:37.079 GcodeDriver$ReaderThread TRACE: [serial://COM13] << ok
2020-10-13 21:39:37.079 GcodeDriver TRACE: [serial://COM13] confirmed G1   Z0.0000   F0
2020-10-13 21:39:37.080 GcodeDriver DEBUG: [serial://COM13] >> M400 ; Wait for moves to complete before returning, 6000
2020-10-13 21:39:37.080 GcodeDriver$ReaderThread TRACE: [serial://COM13] << Error: Undefined feed rate
2020-10-13 21:39:37.080 GcodeDriver$ReaderThread TRACE: [serial://COM13] << Entering Alarm/Halt state
2020-10-13 21:39:37.081 GcodeDriver$ReaderThread TRACE: [serial://COM13] << !!
2020-10-13 21:39:43.080 ReferenceActuator DEBUG: TOWER FINISHED.actuate(false)
2020-10-13 21:39:43.080 GcodeDriver DEBUG: [serial://COM13] >> M400 ; Wait for moves to complete before returning, 6000
2020-10-13 21:39:43.081 GcodeDriver$ReaderThread TRACE: [serial://COM13] << !!
2020-10-13 21:39:49.080 SystemLogger ERROR: java.lang.Exception: Timeout waiting for response to M400 ; Wait for moves to complete before returning

I know there's been a ton of discussion around this and I can't sort out the problem from the noise.

For reference, I've tried a couple of the motion models with the same results and this is my current  default move command as we've discussed a few times before :

G1 {X:X%.4f} {Y:Y%.4f} {Z:Z%.4f} {A:A%.4f} {B:B%.4f} {FeedRate:F%.0f}  

Also ....  did I read somewhere in the posts that you determined that 3rd Order Control was just too much for Smoothie ??

We are planning to attempt to implement it in Smoothie v2, however so far, we have found no Open-Source 3rd-order code in the Open-Source CNC world that is actually good enough to use as a basis for this, therefore we have to do our own, and that's quite a big project.
We could in theory do this on Smoothie v1 too, it's just a matter of actually programming it.



On Friday, 9 October 2020 at 22:29:39 UTC+1 ma...@makr.zone wrote:
Hi all

this is a continuation of the already bursting thread here:

If have just created a new Pull Request, naturally based on the previous work.


I will now start writing instruction, directly in the Wiki (unlinked pages). Once there is a minimal set of instructions, it will make sense to provide a new testing version.

Or I can create it now, if Jason is ok with that and you guys feel adventurous. ;-)

_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/93447263-30b8-4f84-a1c6-fb7a0da39114n%40googlegroups.com.


-- 
勇気とユーモア

Duncan Ellison

unread,
Oct 13, 2020, 5:58:32 PM10/13/20
to OpenPnP
@_Mark
p.s.  In the same pick, the Z move DID work OK with seemingly valid feedrates:

2020-10-13 21:39:36.400 AbstractHeadMountable DEBUG: N1.moveTo((-6.712000, -379.951000, -19.500000, 0.000000 mm), 1.0)
2020-10-13 21:39:36.400 ReferenceNozzle DEBUG: N1.transformToHeadLocation((8.768939, -380.376596, -11.740000, 0.000000 mm), ...) runout compensation: (-0.024939, -0.093404, 0.000000, 0.000000 mm)
2020-10-13 21:39:36.403 GcodeDriver DEBUG: [serial://COM13] >> G1   Z-57.9760   F12198, 6000
2020-10-13 21:39:36.404 GcodeDriver$ReaderThread TRACE: [serial://COM13] << ok
2020-10-13 21:39:36.416 GcodeDriver TRACE: [serial://COM13] confirmed G1   Z-57.9760   F12198
2020-10-13 21:39:36.417 GcodeDriver DEBUG: [serial://COM13] >> M400 ; Wait for moves to complete before returning, 6000
2020-10-13 21:39:36.839 GcodeDriver$ReaderThread TRACE: [serial://COM13] << ok
2020-10-13 21:39:36.839 GcodeDriver TRACE: [serial://COM13] confirmed M400 ; Wait for moves to complete before returning
2020-10-13 21:39:36.839 GcodeDriver DEBUG: [serial://COM13] >> M400 ; Wait for moves to complete before returning, 6000
2020-10-13 21:39:36.841 GcodeDriver$ReaderThread TRACE: [serial://COM13] << ok
2020-10-13 21:39:36.841 GcodeDriver TRACE: [serial://COM13] confirmed M400 ; Wait for moves to complete before returning
2020-10-13 21:39:36.841 ReferenceNozzle DEBUG: N1.pick()
2020-10-13 21:39:36.842 Scripting TRACE: Scripting.on Nozzle.BeforePick

It was when it came to raise the head that it sent the faulty feed rate, I'm a bit confused as to why one Z move would work, but not the other (this was the nozzle DOWN command)

Duncan

ma...@makr.zone

unread,
Oct 14, 2020, 3:01:41 AM10/14/20
to ope...@googlegroups.com

Hi Duncan

I didn't know there was an updater ;-)

I first wanted to document things in the Wiki before announcing the new testing version.

While it should still be the case that machines are automatically migrated from the current develop version of OpenPnP 2.0, there are some things that need to be tweaked for the early adopters, i.e. those that already have migrated using the earlier testing versions.

The first thing to check would be the Motion Control Type on the GcodeDriver:

MotionControlType

The choice is up to you.

Then you need to increase the precision of the F word and add the acceleration control. I also reduced the precision for the axes down to two digits after the point (10 µm), assuming mm units. But you can increase that if you like:

{Acceleration:M204 S%.2f} G1 {X:X%.2f} {Y:Y%.2f} {Z:Z%.2f} {A:A%.2f} {B:B%.2f} {FeedRate:F%.2f} ; move to target

NOTE: if you choose ToolpathFeedRate the acceleration will be automatically omitted from the command.

It probably warned you about missing Safe Z, right? This is lost for the early adopters, but it will be automatically migrated for those coming directly from develop OpenPnP 2.0.

I'm not sure whether you already have the new Backlash Compensation set from before? The new DirectionalCompensation is really making a big difference on my machine.

That's what I remember for early adopters to tweak.

Some things are already documented but that's still work in progress:

_Mark

Wolfgang Lienbacher

unread,
Oct 14, 2020, 11:59:01 AM10/14/20
to OpenPnP

this looks extremely nice! Would love to test this! 
Is there a way other than compiling it to get a binary for mac? If not I guess it's time to set up a dev environment for java ...

Jason von Nieda

unread,
Oct 14, 2020, 12:00:08 PM10/14/20
to ope...@googlegroups.com
Binaries are available from the test downloads at https://openpnp.org/test-downloads/

Jason


To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/a6d5008b-3f21-4807-b5f2-4adb1b5e213cn%40googlegroups.com.

Duncan Ellison

unread,
Oct 14, 2020, 12:11:14 PM10/14/20
to OpenPnP
Hey _Mark,

Thanks for the guidance, I'm still getting some seemingly random F0.00 feedrates which are crashing Smoothie, like this :

2020-10-14 15:43:05.129 GcodeDriver TRACE: [serial://COM13] confirmed M204 S577 G1   Z-47.66   F100000.00 ; move to target
2020-10-14 15:43:05.129 GcodeDriver DEBUG: [serial://COM13] >> M400 ; Wait for moves to complete before returning, 6000
2020-10-14 15:43:05.293 GcodeDriver$ReaderThread TRACE: [serial://COM13] << ok
2020-10-14 15:43:05.293 GcodeDriver TRACE: [serial://COM13] confirmed M400 ; Wait for moves to complete before returning
2020-10-14 15:43:06.001 AbstractHeadMountable DEBUG: N1.moveTo((244.084000, -463.343000, -16.000000, 0.106000 mm), 1.0)
2020-10-14 15:43:06.002 ReferenceNozzle DEBUG: N1.transformToHeadLocation((259.434536, -463.906240, -8.240000, 0.106000 mm), ...) runout compensation: (0.105464, 0.044240, 0.000000, 0.000000 mm)
2020-10-14 15:43:06.005 GcodeDriver DEBUG: [serial://COM13] >> M204 S563 G1   Z-44.08   F0.00 ; move to target, 6000
2020-10-14 15:43:06.007 GcodeDriver$ReaderThread TRACE: [serial://COM13] << ok
2020-10-14 15:43:06.007 GcodeDriver TRACE: [serial://COM13] confirmed M204 S563 G1   Z-44.08   F0.00 ; move to target
2020-10-14 15:43:06.007 GcodeDriver$ReaderThread TRACE: [serial://COM13] << Error: Undefined feed rate
2020-10-14 15:43:06.008 GcodeDriver DEBUG: [serial://COM13] >> M400 ; Wait for moves to complete before returning, 6000
2020-10-14 15:43:06.008 GcodeDriver$ReaderThread TRACE: [serial://COM13] << Entering Alarm/Halt state
2020-10-14 15:43:06.009 GcodeDriver$ReaderThread TRACE: [serial://COM13] << !!
2020-10-14 15:43:12.009 MessageBoxes DEBUG: Error: java.lang.Exception: Timeout waiting for response to M400 ; Wait for moves to complete before returning

Seems to be affecting only the Z moves at this time.

I'm now using this MOVE_TO command :

{Acceleration:M204 S%.0f} G1 {X:X%.2f} {Y:Y%.2f} {Z:Z%.2f} {A:A%.2f} {B:B%.2f} {FeedRate:F%.2f} ; move to target

NOT using Backlash or non-squaredness compensation.

Z Axis set up like this :



Still not sure what to do with all this Soft Limit and Safe Zone stuff though, I'm not sure my machine really needs a Safe Z,  I've just got everything set to Safe Z = zero.

Could this be a computational error in the Feedrate when using the cam transform ?

Duncan 

Wolfgang Lienbacher

unread,
Oct 14, 2020, 12:43:18 PM10/14/20
to OpenPnP
very nice, thank you Jason! 

ma...@makr.zone

unread,
Oct 14, 2020, 1:16:04 PM10/14/20
to ope...@googlegroups.com

Hi Duncan

What is your driver Motion Control Type? If you have ToolPathFeedRate (the old way) you must set a feed-rate in the Driver. I will add a check.

For other Motion Control Types, feed-rates should always be maxed against a fixed minimum feedrate of 6mm/min.

Could you send me the machine.xml?

_Mark

Duncan Ellison

unread,
Oct 14, 2020, 1:33:04 PM10/14/20
to OpenPnP
Hi _Mark,

Using (trying to use) Full3rdOrderControl,  seems to be giving a nice smooth, jerk free experience.

Machine.xml attached.

Duncan
machine.xml

Duncan Ellison

unread,
Oct 14, 2020, 1:34:44 PM10/14/20
to OpenPnP
(I've set a MAX feed rate of 100000 mm/min in the driver)

ma...@makr.zone

unread,
Oct 14, 2020, 1:57:35 PM10/14/20
to ope...@googlegroups.com

Hi Duncan

Smoothie is not a Full3rdOrderControl controller, unfortunately. There is currently no such controller (Open Source) AFAIK, but hopes are, that some will be available soon, there are multiple people currently developing one.

Smoothie will ignore any jerk limit. Try ModeratedConstantAcceleration:

MotionControlType

I'm not there yet with the Wiki, but the next step for Smoothie would be Simulated3rdOrderControl.

Are you still having the Feedrate issue?

_Mark

ma...@makr.zone

unread,
Oct 14, 2020, 5:07:10 PM10/14/20
to ope...@googlegroups.com

Duncan Ellison

unread,
Oct 14, 2020, 5:30:10 PM10/14/20
to OpenPnP
Yes, getting late for me too :-)  But just ran a test board with the parameters as you suggested and it looked good.

I'll be sure to give this a thorough reading tomorrow.  I think this was really necessary as there have been so many changes recently, if you weren't following along, it would be difficult to figure out some of the parameters.

I'll let you know if I find anything in the docs that needs correction / further explanation.

Get some sleep !!

Wolfgang Lienbacher

unread,
Oct 15, 2020, 5:39:29 AM10/15/20
to OpenPnP
Amazing work mark! Love the documentation! Just went through and set up my machine for simulated 3rd order control using a Duet3. I've gone through the docs point by point, changed machine.xml to reflect the async driver. Now the homing process would not finish. Last thing happening is the driver asking for the position. This is what the log says:

2020-10-15 11:33:17.301 ReferenceMachine DEBUG: setEnabled(true)
2020-10-15 11:33:20.313 GcodeAsyncDriver DEBUG: serial://tty.usbmodem142101 commandQueue.offer(G21 ; Set millimeters mode, 2000)...
2020-10-15 11:33:20.314 GcodeAsyncDriver DEBUG: serial://tty.usbmodem142101 commandQueue.offer(G90 ; Set absolute positioning mode, 2000)...
2020-10-15 11:33:20.314 GcodeAsyncDriver DEBUG: serial://tty.usbmodem142101 commandQueue.offer(M82 ; Set absolute mode for extruder, 2000)...
2020-10-15 11:33:20.314 GcodeAsyncDriver DEBUG: serial://tty.usbmodem142101 commandQueue.offer(M42 P3 S1, 2000)...
2020-10-15 11:33:20.315 GcodeAsyncDriver$WriterThread TRACE: [serial://tty.usbmodem142101] >> G21 ; Set millimeters mode
2020-10-15 11:33:20.315 GcodeAsyncDriver$WriterThread TRACE: [serial://tty.usbmodem142101] >> G90 ; Set absolute positioning mode
2020-10-15 11:33:20.316 GcodeAsyncDriver$WriterThread TRACE: [serial://tty.usbmodem142101] >> M82 ; Set absolute mode for extruder
2020-10-15 11:33:20.316 GcodeAsyncDriver$WriterThread TRACE: [serial://tty.usbmodem142101] >> M42 P3 S1
2020-10-15 11:33:20.325 GcodeDriver$ReaderThread TRACE: [serial://tty.usbmodem142101] << ok
2020-10-15 11:33:20.340 GcodeDriver$ReaderThread TRACE: [serial://tty.usbmodem142101] << ok
2020-10-15 11:33:20.347 GcodeDriver$ReaderThread TRACE: [serial://tty.usbmodem142101] << ok
2020-10-15 11:33:20.357 GcodeDriver$ReaderThread TRACE: [serial://tty.usbmodem142101] << ok
2020-10-15 11:33:21.444 ReferenceMachine DEBUG: homing machine
2020-10-15 11:33:21.444 ReferenceMachine DEBUG: setHomed(false)
2020-10-15 11:33:21.450 GcodeAsyncDriver DEBUG: serial://tty.usbmodem142101 commandQueue.offer(G28 ; Home all axes ;G0 Z0, -1)...
2020-10-15 11:33:21.450 GcodeAsyncDriver$WriterThread TRACE: [serial://tty.usbmodem142101] >> G28 ; Home all axes ;G0 Z0
2020-10-15 11:33:21.464 GcodeAsyncDriver DEBUG: serial://tty.usbmodem142101 commandQueue.offer(M114 ; get position, -1)...
2020-10-15 11:33:21.465 GcodeAsyncDriver$WriterThread TRACE: [serial://tty.usbmodem142101] >> M114 ; get position
2020-10-15 11:33:27.160 GcodeDriver$ReaderThread TRACE: [serial://tty.usbmodem142101] << ok
2020-10-15 11:33:27.173 GcodeDriver$ReaderThread TRACE: [serial://tty.usbmodem142101] << X:20.000 Y:0.000 Z:0.000 A:0.000 B:0.000 E:0.000 E0:0.0 Count 1600 0 0 0 0 Machine 20.000 0.000 0.000 0.000 0.000 Bed comp 0.000
2020-10-15 11:33:27.173 GcodeDriver$ReaderThread TRACE: [serial://tty.usbmodem142101] << ok
2020-10-15 11:38:21.466 MessageBoxes DEBUG: Error: java.lang.Exception: Timeout waiting for response to M114 ; get position


Wolfgang Lienbacher

unread,
Oct 15, 2020, 6:04:35 AM10/15/20
to OpenPnP
The position regex command is 1:1 from the docs: ^ok C: X:(?<X>-?\d+\.\d+) Y:(?<Y>-?\d+\.\d+) Z:(?<Z>-?\d+\.\d+) A:(?<A>-?\d+\.\d+) B:(?<B>-?\d+\.\d+).*

I am also noticing the timeout takes ages, not sure why.

ma...@makr.zone

unread,
Oct 15, 2020, 8:24:19 AM10/15/20
to ope...@googlegroups.com

Hi Wolfgang

Thanks!

The regex is for Smoothieware (I should note that in the Wiki).

Duet has a different report (from the log):

X:20.000 Y:0.000 Z:0.000 A:0.000 B:0.000 E:0.000 E0:0.0 Count 1600 0 0 0 0 Machine 20.000 0.000 0.000 0.000 0.000 Bed comp 0.000

You must adjust the regex accordingly. I'm not a regex expert, there are online tools to check it.

Just a guess:

^X:(?<X>-?\d+\.\d+) Y:(?<Y>-?\d+\.\d+) Z:(?<Z>-?\d+\.\d+) A:(?<A>-?\d+\.\d+) B:(?<B>-?\d+\.\d+).*

_Mark

Wolfgang Lienbacher

unread,
Oct 15, 2020, 8:30:43 AM10/15/20
to OpenPnP
ahh indeed, that was the issue! Thanks mark!

Wolfgang Lienbacher

unread,
Oct 15, 2020, 9:07:36 AM10/15/20
to OpenPnP
Also having really slow feedrates now when set to Simulated 3rd order ... what was that solution again?

Wolfgang Lienbacher

unread,
Oct 15, 2020, 9:22:28 AM10/15/20
to OpenPnP
Ah, is it possible that the new motion planning has an effect on the speed modifiers in the feeders? I've now tested a blinds feeder, if I set the push speed modifier to 1 it moves normally (fully speed), with the previous modifier (0.02) it moves extremely slow. 

ma...@makr.zone

unread,
Oct 15, 2020, 9:24:01 AM10/15/20
to ope...@googlegroups.com

Hmmm, need a bit more info.

log? machine.xml?

One thing: on the Axis it is units per second ¹  ² ³ but on the driver it is units per minute for historical reasons. Should I change the latter?

For Simulated3rdOrder I recommend deleting the Driver limit.

_Mark

ma...@makr.zone

unread,
Oct 15, 2020, 9:35:09 AM10/15/20
to ope...@googlegroups.com

Yes!

That small number was needed, because it was relative to the theoretical top speed of the machine that is only reached for a very long move.

But if you have a very short move (like in the BlindsFeeder), you needed to use a very small number.

Now the speed factor is relative to the time needed at full speed. If you put 0.5 it takes 1/0.5 = 2 times as long in time. Both small and long moves can be scaled easily and usefully.

_Mark

Wolfgang Lienbacher

unread,
Oct 15, 2020, 3:43:52 PM10/15/20
to OpenPnP
everything seems to work fine now! The speed factor changes may be worth a note, i've run into moves that wont finish before timeout numerous times during configuration. think i have them all now. 
It's not being used for jog moves right? I've bumped up the acceleration of my machine and the jogs have very strong "bumps" at the start and end, when the machine does coordinated moves everything feels exceptionally smooth. i'm really impressed! very nice work mark!

ma...@makr.zone

unread,
Oct 15, 2020, 3:57:06 PM10/15/20
to ope...@googlegroups.com

Hi everybody

The Wiki is mostly useful now. New or largely changed pages (since the last post) are marked with *

Start with the first page and then "hyperlink" from there as needed.

    The testing version can be downloaded here:

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

    One impression:

    Motion Planer Diagnostics

    I will still refine these pages in the coming days.

    ALL FEEDBACK WELCOME!
    (including Language related)

    Enjoy,
    _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/GtCDy2p8Pbg/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/d876d6bb-b394-d259-944c-2857833ff769%40makr.zone.

    ma...@makr.zone

    unread,
    Oct 15, 2020, 4:05:20 PM10/15/20
    to ope...@googlegroups.com

    > It's not being used for jog moves right?

    It definitely should!

    I really have to call it a day, so please read the Wiki and see if you find the culprit. it should be everything in there now.

    Note that Motion Blending is really just experimental and while it can be demonstrated at reduced speed and for short moves, it will not be practical overall on Smoothieware.

    But I have high hopes for Duet 3D 3!

    As you might recall, dc42 of Duet3D kindly donated one to me and I will start experimenting with it as soon as I got the courage to dig out my crimping tool to make the plugs required for the steppers. I hate those things, and I'm sure I will botch half of them ;-)

    Erm... any tips & tricks for the crimping?

    _Mark

    Arthur Wolf

    unread,
    Oct 15, 2020, 4:17:40 PM10/15/20
    to ope...@googlegroups.com
    On Thu, Oct 15, 2020 at 10:05 PM ma...@makr.zone <ma...@makr.zone> wrote:

    > It's not being used for jog moves right?

    It definitely should!

    I really have to call it a day, so please read the Wiki and see if you find the culprit. it should be everything in there now.

    Note that Motion Blending is really just experimental and while it can be demonstrated at reduced speed and for short moves, it will not be practical overall on Smoothieware.

    But I have high hopes for Duet 3D 3!

    As you might recall, dc42 of Duet3D kindly donated one to me and I will start experimenting with it as soon as I got the courage to dig out my crimping tool to make the plugs required for the steppers. I hate those things, and I'm sure I will botch half of them ;-)

    Erm... any tips & tricks for the crimping?

    To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/d6242da8-7302-b4c1-ae97-d28c9ec34f50%40makr.zone.


    -- 
    勇気とユーモア

    ma...@makr.zone

    unread,
    Oct 15, 2020, 4:19:37 PM10/15/20
    to ope...@googlegroups.com
    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/GtCDy2p8Pbg/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/CAMHZkm5Vmrtpxc%3DJ2-Rpyuo4R54eGwaa%3DeW_hDYZLqh%3DQgSdvg%40mail.gmail.com.

    Mike Menci

    unread,
    Oct 16, 2020, 4:29:23 AM10/16/20
    to OpenPnP
    Mark - you might avoid crimping by using this cables with connectors for tests: https://www.ebay.de/itm/Mini-Micro-JST-1-25-1-0-PH2-0-2-54MM-Stecker-Stecker-mit-Drahten-Kabel-20-SETs/142305579860?hash=item212212d354:g:tooAAOSw-kdX1leT

    Wolfgang Lienbacher

    unread,
    Oct 16, 2020, 5:26:35 AM10/16/20
    to OpenPnP
    crimping really comes down to using the right tool, then it's easy. That said, I was able to get a good crimp with the wrong tool on my duet 3, so I can absolutely feel you. Those connectors for the duet3 are huge compared to what I usually crimp.

    Wolfgang Lienbacher

    unread,
    Oct 16, 2020, 6:06:17 AM10/16/20
    to OpenPnP
    A question regarding the new safe-z settings in the axes. Using a dual nozzle peters head, there is nothing in the way of the nozzles if they are at -20, but I'd go for -10 for the start. Do I read the documentation right it would be best to set high and low both to -10?

    ma...@makr.zone

    unread,
    Oct 16, 2020, 7:20:18 AM10/16/20
    to ope...@googlegroups.com

    > Do I read the documentation right it would be best to set high and low both to -10?

    No, assuming Z=0 is at the balance point (both nozzles at same height), that would be -10 and 10.

    Because I don't own a multi-nozzle machine, could you please test this for me:

    1. Jog the Z of the left nozzle to the appropriate height (above the tallest obstacle)
    2. Use the capture button to get the lower limit:
    3. Jog the Z of the right nozzle to the appropriate height (above the tallest obstacle)
    4. Use the capture button to get the upper limit:
    5. If the limits are inverted (Low is higher than High), repeat steps 1. - 4. with swapped nozzles.

    Does this work as intended?

    _Mark

    Wolfgang Lienbacher

    unread,
    Oct 16, 2020, 8:24:25 AM10/16/20
    to OpenPnP
    yes it works as intended! Moving both nozzles to -10 results in -10 low and 10 high. 

    ma...@makr.zone

    unread,
    Oct 16, 2020, 5:15:22 PM10/16/20
    to OpenPnP
    Hi everybody

    I just merged another testing  Pull request. Available as a new testing version:

    This basically fixes some issues noticed during documentation (GUI cosmetics, a few extra improvements and some bug-fixes too).

    Read the pull request for the details:

    The real Testing Challenge has begun! ;-)

    Thank you for your help!

    _Mark

    Wolfgang Lienbacher

    unread,
    Oct 16, 2020, 5:27:57 PM10/16/20
    to OpenPnP
    Nice, thank you mark!
    I have run my very first board on my machine to day - yes I know, I'm completely nuts running the test version on my first board - however it worked much much better than I was hoping my first board would go!

    I did have a few occasions where some moves produced a timeout, like changing the nozzle. The move despite running at the desired speed caused a timeout on the nozzle calibration long before the first nozzle was even unloaded. I assume this is an issue with the motion planner. I'll post my machine.xml tomorrow, I'm sure you'll find a few wrong settings. 

    ma...@makr.zone

    unread,
    Oct 17, 2020, 5:15:15 AM10/17/20
    to ope...@googlegroups.com

    Hi Wolfgang

    > I have run my very first board on my machine to day - yes I know, I'm completely nuts running the test version on my first board - however it worked much much better than I was hoping my first board would go!

    Cool! I'm really grateful for your spirit there!

    > ... where some moves produced a timeout

    I've found and fixed a stupid typo-bug that would generate a near-zero or even zero feed-rate when using any of the Motion Control Types other than ModeratedConstantAcceleration or Simulated3rdOrderControl.

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

    This should no longer happen with the current testing build. All Motion Control Types should now work.

    _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/GtCDy2p8Pbg/unsubscribe.
    To unsubscribe from this group and all its topics, send an email to openpnp+u...@googlegroups.com.

    Wolfgang Lienbacher

    unread,
    Oct 17, 2020, 6:13:38 AM10/17/20
    to OpenPnP
    I was using Simulated3rdOrderControl. The feedrate was actually not the issue, from what I can tell the problem seems the calibration started right after the moves were sent to the motion planner, not after the nozzle change was finished (at least thats what it seemed). 
    Also, I think I don't have the motion planner set up correctly. I'll grab my machine.xml and post it now. 

    Wolfgang Lienbacher

    unread,
    Oct 17, 2020, 6:15:53 AM10/17/20
    to OpenPnP
    Here it is.
    machine.xml

    ma...@makr.zone

    unread,
    Oct 17, 2020, 7:16:00 AM10/17/20
    to ope...@googlegroups.com

    Hi Wolfgang

    @dc42 are you reading this? Question/discussion for you in the text. Thanks!

    > I was using Simulated3rdOrderControl.

    Ahh, ok. Do you use jerk control on the nozzle rotation axes?

    If yes, there is an open issue. :-(

    I can solve it on Smoothie, but don't know about Duet (yet). I'll try to explain (this is also thought as a documentation of that issue):

    When you have nozzle runout compensation, doing rotations will also generate very small adjustments in X/Y. If you have a (relatively) large rotation, then the X/Y will move veeeeery slowly in coordination with the angular move.

    Now the jerk control  interpolation will break up the movement into many time steps and these already tiny X/Y movements will be divided into truly microscopic step-wise movements. Some of those will then collapse below one micro-step/resolution tick, i.e. become zero for some of the interpolation steps.

    Side note: We need to handle this "collapse to zero" due to the G-code decimal output with limited digits and due to the fact, that some controllers will swallow tiny moves and then behave unpredictably, for similar reasons as described below.

    Consequently, the X/Y axes will sometimes be included in an interpolation segment and sometimes not. Only the C axis will always be included. Now we're in big poodoo because of the NIST RS274/NGC Interpreter - Version 3 standard:

    https://www.nist.gov/publications/nist-rs274ngc-interpreter-version-3

    More specifically section "2.1.2.5 Feed Rate":

    A. For motion involving one or more of the X, Y, and Z axes (with or without simultaneous
    rotational axis motion), the feed rate means length units per minute along the
    programmed XYZ path, as if the rotational axes were not moving.

    B. For motion of one rotational axis with X, Y, and Z axes not moving, the feed rate means
    degrees per minute rotation of the rotational axis.

    C. For motion of two or three rotational axes with X, Y, and Z axes not moving, the rate is
    applied as follows. Let dA, dB, and dC be the angles in degrees through which the A, B,
    and C axes, respectively, must move. Let D = . Conceptually, D is a
    measure of total angular motion, using the usual Euclidean metric. Let T be the amount
    of time required to move through D degrees at the current feed rate in degrees per
    minute. The rotational axes should be moved in coordinated linear motion so that the
    elapsed time from the start to the end of the motion is T plus any time required for
    acceleration or deceleration.

    As you see, the meaning of the feed-rate changes completely, between when X/Y are or aren't included in the interpolation step. In the case of Smoothie this will force the internal move planner to zero junction speed between these segments. This probably explains the timeout you saw, OpenPnP was going on with calibration, while the nozzle was still turning veeeery slowly elsewhere. 

    On Smoothie I made a new firmware built with PAXIS=6, i.e. switching off the NIST RS274/NGC rule and handling all feed-rates simply as Euclidean distance related, over all the axes:
    http://smoothieware.org/6axis#compiling-6-axis

    I don't know (yet) about Duet. The remedy for now, unfortunately, is to set Jerk to zero on the rotation axes.

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

    But maybe there is a similar setting for Duet?

    @dc42 are you reading this? (I will explore the source code, but I assume you'd know directly)

    With "PAXIS" or similar, the C axes now need to be treated as linear by OpenPnP and this can be done using the Switch Linear ↔ Rotational checkbox here:

    https://github.com/openpnp/openpnp/wiki/Machine-Axes#controller-settings

    My goal is to find a solution that is standards compliant. The idea is to do the tiny X/Y move first, then the rotation alone. This will work without much of a speed penalty for runout compensation but not for motion blending, where a rotation axis is involved. So a "PAXIS" style solution would be best!

    I will also make the new Smoothieware firmware available for download soon... 

    _Mark

    Wolfgang Lienbacher

    unread,
    Oct 17, 2020, 7:29:29 AM10/17/20
    to OpenPnP
    Ah yes that sounds reasonable to me. I was also trying to speed up the rotation (especially when no parts are on the nozzle), but since it uses the same feedrate setting but in a different unit (degrees instead of mm) there's only little options. Kind of falls into the same hole as the issue you describe. 
    I'll check my settings! Or if you have a chance, because you know the system better, maybe you could even have a quick check on my machine.xml and I'll run another test. The board I assembled works and I'm going to assemble another one soon. 

    ma...@makr.zone

    unread,
    Oct 17, 2020, 8:00:24 AM10/17/20
    to ope...@googlegroups.com

    Hi Wolfgang

    > maybe you could even have a quick check on my machine.xml

    No, the open issue I was suspecting does not apply. In fact, you have no Jerk set anywhere.

    In order to exploit the benefits of Simulated3rdOrderControl, you really need to set Jerk on X and Y. 

    I hope I explain this understandably here:

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

    https://github.com/openpnp/openpnp/wiki/GcodeAsyncDriver#interpolation

    > I was also trying to speed up the rotation (especially when no parts are on the nozzle), but since it uses the same feedrate setting but in a different unit (degrees instead of mm) there's only little options.

    Not anymore! That's one of the reasons, I moved the feed-rate, acceleration (jerk) limits to the individual axes.

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

    In fact, I recommend setting the Max Feed Rate on the driver to zero (i.e. switching it off) and only using the axes limits.

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

    Note: this would be completely wrong for milling, laser cutting or 3D-printing, but it is best for Pick & Place.

    _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/ff252b26-0dde-4241-a65d-8fd78c38a471n%40googlegroups.com.

    Wolfgang Lienbacher

    unread,
    Oct 17, 2020, 10:12:07 AM10/17/20
    to OpenPnP
    Ahh there you go! Getting closer to the full picture :) What kind of values would you recommend for jerk? Something like 200? 1000? I assume the lower the smoother (but slower)?

    ma...@makr.zone

    unread,
    Oct 17, 2020, 12:10:41 PM10/17/20
    to ope...@googlegroups.com

    No, much higher values, I'm using 30000mm/s3 on a Liteplacer (which is terrible in terms of vibrations).

    I expect you can use three, four times as much on a stiffer machine.

    > I assume the lower the smoother (but slower)?

    Correct ;-)

    _Mark

    ma...@makr.zone

    unread,
    Oct 17, 2020, 12:26:54 PM10/17/20
    to ope...@googlegroups.com

    Hi

    For the Smoothieware users: I've made a new firmware required for the OpenPnP 2.0 testing version.

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

    Not recommended for the regular OpenPnP 2.0 version.

    _Mark

    Duncan Ellison

    unread,
    Oct 17, 2020, 1:51:24 PM10/17/20
    to OpenPnP
    Hi Mark,

    Making some progress here with your new motion control.   I'll upload the new firmware.bin to my Smoothie -  Does this version definitely include the mod-homing mod?

    General XYZ motion is looking good, But I'm finding an issue where the fiducials are failing whereas they were rock solid before, they go 'wandering off' and fail to recognise and video jogging is really off, it like the jogging is in the wrong direction- is there any interdependency here?

    Duncan

    ma...@makr.zone

    unread,
    Oct 17, 2020, 2:29:17 PM10/17/20
    to ope...@googlegroups.com

    >  Does this version definitely include the mod-homing mod?

    Yes, everything in there is documented here:

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

    > But I'm finding an issue where the fiducials are failing whereas they were rock solid before

    Strange. From which version have you upgraded?

    > video jogging is really off, it like the jogging is in the wrong direction- is there any interdependency here?

    Jogging has changed a while back:

    https://www.youtube.com/watch?v=0TvqQBkTGP8

    Relative to you previous (productive) version, is this new for you?

    But I'll also have a look at it on my machine now. There were some changes there (virtual axes), maybe I introduced a bug.

    https://github.com/openpnp/openpnp/wiki/Machine-Axes#referencevirtualaxis

    _Mark

    ma...@makr.zone

    unread,
    Oct 17, 2020, 3:20:36 PM10/17/20
    to ope...@googlegroups.com

    Hi Duncan

    > But I'll also have a look at it on my machine now. There were some changes there (virtual axes), maybe I introduced a bug.

    I see no anomalies. In fact jogging is now really much better on my shaky Liteplacer.

    Can you be more specific?

    _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/b4a988c8-c596-e579-8085-d917b3f1112b%40makr.zone.

    Duncan Ellison

    unread,
    Oct 17, 2020, 4:06:14 PM10/17/20
    to OpenPnP
    Hi Mark,

    Just uploaded the new 6 Axis to Smoothie  [Actually not sure why I'm using SIX axis as I'm actually only running five, but it's been that way for ages now],  boots up OK, seems to run fine, in fact I cant see any obvious changes from the previous version.

    Jogging and Fiducial checking is still way off though, it's as though there's a co-ordinate sign error.  Fiducials are set to three passes and after the first recognition, the head seems to move the wrong way (i.e. AWAY from the centre of the fiducial circle).  Camera jogging seems to go right in some directions or 45 or 180 degrees off in others.

    Manual jogging is fine and the general co-ordinates of other things on the bed seem to be where I expect them to be.

    Maybe I messed up some other setting somewhere, I'll need to take a deeper dive tomorrow. 

    Machine seems to be attempting to do simulated3DMotionControl.  It's nice and smooth now anyway :-)

    As a side note, whilst it's related to motion control,  I seem to be running up against the maximum travel speed of the motors, the speed is pretty good, but not quite as zippy as I expected with beefy 240V 5-Phase steppers.   I'm not sure if this is a Smoothie limitation or the (separate) stepper drivers, I do have a very high microstepping rate configured and I have noticed that the lower I set the microstepping rate, the faster the 'raw' speed when jogging.

    I've set max feedrate in the driver to zero and ridiculously high rates in smoothie and the kinematic settings.  I'm imagining that will give the motion planner free reign to go as fast as it can.  In the 'Motion Tester', the 'planned speed' is always larger than the 'actual speed' by a factor of about 4.  Does this mean that the 'planned speed' uses the kinematic rates the calculate the time, but I never make it becuase the motors won't run that fast?

    Duncan

    ma...@makr.zone

    unread,
    Oct 17, 2020, 4:32:40 PM10/17/20
    to ope...@googlegroups.com

    Hi Duncan

    Smoothie has a step rate limit of I think ~100kHz. You'll reach that easily with typical configurations, if you don't limit the micro-stepping. I use 16 micro-steps and that's already borderline on a 2mm belt, 20 tooth pulley, 1.8° stepper.

    As to the Kinematic settings, it is very important to match or be lower than the config.txt rates. Otherwise the planning will be totally off and you will get very strange movement.

    > Jogging and Fiducial checking is still way off though

    You mean visual jogging only, right?

    Bottom or Top camera?

    Have you checked the Flip Transform in the camera?

    You should typically have one of them enabled in the Bottom Cam (it is a mirror image!) and none in the Down looking Cam.

    But I see no way how this could have been botched by the migration, really!!!

    _Mark

    bert shivaan

    unread,
    Oct 18, 2020, 10:47:49 PM10/18/20
    to OpenPnP
    Hey Mark I've been thinking about your "safe Z range".Am I correct thinking I could set the range to be my entire  Z stroke, like min to max, then the machine would always be at safe Z so it could just start moving?


    To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/1541c608-dbe6-82d0-f7d7-b86d16709b09%40makr.zone.

    ma...@makr.zone

    unread,
    Oct 19, 2020, 2:13:24 AM10/19/20
    to ope...@googlegroups.com

    Hi Bert

    I 'm not sure I understand the question right. The following is just a general explanation, so don't feel offended, if you know all that ;-)

    The Safe Zone is a zone where OpenPnP can move without any risk of collisions. By defining it, you are telling OpenPnP that there are no feeders, nozzle tip changers etc. anywhere in that zone. You always have a Save Zone in the Z axis. The other axes (X, Y) can also have a Safe Zone, but for another purpose, namely to allow uncoordinated i.e. curved motion rather than just straight lines from location A to B. OpenPnP always had a Safe Z, think of it as a Safe Z Zone that happens to be compressed flat.

    The typical move in OpenPnP is the moveToLocationAtSafeZ() pattern.

    It first moves all HeadMountables (Nozzles etc.) that are currently outside the Safe Zone vertically up to the nearest limit of the Safe Zone of the Z axis. Note: on multi-nozzle shared axis machines this can be from either side of the Z axis.

    Then it is free to move anywhere in X/Y. No collisions.

    Then it goes back down in Z to the target location.

    If you were to extend your Safe Z Zone down all the way, it would just never lift the nozzle and scratch it over the table (and worse) going to the target location.

    _Mark

    ma...@makr.zone

    unread,
    Oct 19, 2020, 2:29:18 AM10/19/20
    to ope...@googlegroups.com

    This might help others who read this understand why I made it:

    Having the Safe Z Zone allows the motion planner to do Motion Blending, avoiding 90° corners that slow down the machine (experimental).

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

    It also helps for multi-nozzle machine that have a lot of Z head-room, i.e. where lifting up the Nozzle to the balance-point (where the nozzles are at same height) is a waste of time. Using the Zone, you can let the machine optimize this. Assuming you can live with the asymmetry of "limping nozzles" ;-).

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

    _Mark

    bert shivaan

    unread,
    Oct 19, 2020, 4:47:48 AM10/19/20
    to OpenPnP
    thanks Mark, that sounds perfect :)

    To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/1e4c7fbe-7ce5-568d-8a78-a0d7b0c0849f%40makr.zone.

    Duncan Ellison

    unread,
    Oct 19, 2020, 11:34:48 AM10/19/20
    to OpenPnP
    Hi _Mark,

     I'm still not quite there yet.

    I've had a couple of instances where OpenPnP has just trashed all 3 configuration files leaving them blank :-(   So I've gone back to an earlier config and attempting to start again from there.  Anyone else seen this?

    FWIW, I also went back to the stepper drivers and reconfigured them for a 20% lower step angle (now an effective 0.036° per step, which is a 1/20th microstepping on a 0.72° Motor), this gives 400 steps per mm on my machine, which should be plenty. 

    Here's my next problem, A/B Rotation moves are giving me quite different results.  Here is a commanded 100° rotation on Nozzle 1, them nozzle 2.  As you can see, Nozzle 1 has crazy low speed parameters and includes XY, but Nozzle 2 is as expected.

    2020-10-19 16:04:14.167 GcodeDriver DEBUG: [serial://COM13] >> M204 S3.42 G1 X149.91 Y-209.81  A-220.00  F45.83 ; move to target, 6000
    2020-10-19 16:04:19.613 GcodeDriver DEBUG: [serial://COM13] >> M204 S2000.00 G1     B60.00 F26832.82 ; move to target, 6000

    Net result is that Smoothie goes off for around 5 minutes trying to execute the A move, but doesn't actually crash.

    What could I have configured wrong to achieve this?

    Axis C1 and C2 are configured identically. 



    Move to looks like this :

    {Acceleration:M204 S%.2f} G1 {X:X%.2f} {Y:Y%.2f} {Z:Z%.2f} {A:A%.2f} {B:B%.2f} {FeedRate:F%.2f} ; move to target

    ma...@makr.zone

    unread,
    Oct 19, 2020, 12:25:42 PM10/19/20
    to ope...@googlegroups.com

    Hi Duncan

    > I've had a couple of instances where OpenPnP has just trashed all 3 configuration files leaving them blank :-(  

    I've never had that, even while constantly messing around in the debugger, killing processes etc. Are you sure the drive is ok? What OS is that?

    Also: whenever I do a significant config change, I backup these files. Not for fear of malfunction, but for fear of being stupid, myself ;-)

    > FWIW, I also went back to the stepper drivers and reconfigured them for a 20% lower step angle (now an effective 0.036° per step, which is a 1/20th microstepping on a 0.72° Motor), this gives 400 steps per mm on my machine, which should be plenty.

    I've never heard that you can configure the step angle of a stepper in the driver. Step angle is a profoundly physical property of the motor. Are you sure about this?

    https://youtu.be/VMwv4XFZ2L0?t=160

    > Here's my next problem, A/B Rotation moves are giving me quite different results.  Here is a commanded 100° rotation on Nozzle 1, them nozzle 2.  As you can see, Nozzle 1 has crazy low speed parameters and includes XY, but Nozzle 2 is as expected.

    Sounds exactly like this problem, triggered through runout calibration.

    https://makr.zone/smoothieware-problems-with-mixed-axis/356/

    Obviously only one of your nozzles has enough of it to trigger a X/Y move along with the rotation (Advanced Motion Control will suppress runout compensation, if it below axis resolution). Have you flashed my firmware?

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

    _Mark

    Duncan Ellison

    unread,
    Oct 19, 2020, 1:05:44 PM10/19/20
    to OpenPnP
    Hi _Mark

    > I've had a couple of instances where OpenPnP has just trashed all 3 configuration files leaving them blank :-(   

    No idea why this is happening, but I had it three times now - Will take EVEN MORE care of taking backups until I identify what's causing it.

      > FWIW, I also went back to the stepper drivers and reconfigured them for a 20% lower step angle (now an effective 0.036° per step, which is a 1/20th microstepping on a 0.72° Motor), this gives 400 steps per mm on my machine, which should be plenty. 

    Sorry, I didn't explain this well at all - and it was a bit of a side note.  I have 5 Phase Steppers (VEXTA from Oriental Motor) which are driven via their own dedicated 240V AC Driver which in turn is supplied pulses from Smoothie.  By setting a rotary switch on the driver you can go from 0.72° per (Smoothie) pulse all the way down to 0.00288° per pulse.  In the manual, they call it 'Step Angle', but I guess internally, it's just microstepping with 1/250 being the largest.

      > Here's my next problem, A/B Rotation moves are giving me quite different results.  Here is a commanded 100° rotation on Nozzle 1, them nozzle 2.  As you can see, Nozzle 1 has crazy low speed parameters and includes XY, but Nozzle 2 is as expected. 

    I had (just) noticed that this behaviour is influenced by run out in some way.   Yes, I do have the new firmware loaded in Smoothie, but re-reading your notes, I saw :

    CAUTION: With PAXIS= or similar, the rotational axes must be treated as linear by OpenPnP. You have to use the Switch Linear ↔ Rotational checkbox, as explained in the Wiki. 

    Which I did not have set.  So BOTH C1 and C2 axes need this set, right?

    Duncan

    ma...@makr.zone

    unread,
    Oct 19, 2020, 2:32:21 PM10/19/20
    to ope...@googlegroups.com

    > Which I did not have set.  So BOTH C1 and C2 axes need this set, right?

    Yes, correct.

    And Yes that would also explain the effects observed ... it's the same thing caused for two different reasons  ;-)

    _Mark

    Duncan Ellison

    unread,
    Oct 20, 2020, 10:27:42 AM10/20/20
    to OpenPnP
    Hi _Mark,

    Sorry to say, I'm not making much progress whilst testing the new motion control.  I've gone back to a known good (pre-new stuff) configuration and tested it.  

    I have a test job which reads 4 fiducials and then places 8 x 0603 resistors in a circular pattern from auto feeders including an alignment check, thus testing top and vision, rotation axes and placement accuracy.  With this config, they are being placed within a whisker of the intended spot.  

    I then took this same config and :

      1. Set up AsyncGcodeDriver by adjusting the machine.xml
      2. Changed C1 and C2 to include "Switch Linear <> Rotational"
      3. Added M114.2 ; get position to the GET_POSITION_COMMAND
      4. Changed the SET_GLOBAL_OFFSETS_COMMAND to G92 {X:X%.4f} {Y:Y%.4f} {Z:Z%.4f} {A:A%.4f} {B:B%.4f} ; Send G92 to reset the motion controllers co-ordinates after homing
      5. Set the Position Regex to :  ^ok MCS: X:(?<X>-?\d+\.\d+) Y:(?<Y>-?\d+\.\d+) Z:(?<Z>-?\d+\.\d+) A:(?<A>-?\d+\.\d+) B:(?<B>-?\d+\.\d+).* [Tested with a Regex Checker]
      6. Set Flow Control to RST/CTS and also set DTR and RTS on (it seemed to need this)
      7. Changed Motion Controller to 'ReferenceAdvancedMotionController'
      8. Continuous Motion = Off, Allow Un-Coordinated = Off, Interpolation Retiming = On

    Despite all of this, it seems to breaks the machine in some odd ways

    I did the following :

    Home - Seemingly OK
    N1 Rotate left - Nozzle jumps once forward and right about 15mm then rotates as commanded
    N2 & N2 - Various rotations - seemingly OK, no more jumps
    Fiducial check - goes initially straight to the fiducial, then wanders off trying to refine the match, goes to second fid, same story etc.

    I've attached the log and the good and bad machine.xml's to see if you can diagnose anything from this.  It feels like there's some co-ordinate mis-match going on between the Smoothie and OpenPnP, so commanded moves are not coming out as inteded, but I could be off track with that.

    I'd love to be using this new code, but I just can't get it stable enough to trust not having (yet another) head wreck.



    good machine.xml
    Log.txt
    bad machine.xml

    ma...@makr.zone

    unread,
    Oct 20, 2020, 11:37:27 AM10/20/20
    to ope...@googlegroups.com

    > I've gone back to a known good (pre-new stuff) configuration and tested it.

    To make sure: with that you are referring to the new OpenPnP version with auto-migrated config? And it worked flawlessly?

    That alone is still a very important intermediate goal for me. ;-)

    Checklist for the new stuff:

    1. Most likely culprit: M114.2 (wrong) instead of just M114 (correct) in GET_POSITION_COMMAND
      Sorry, the instructions in the Wiki were simply wrong, it should have been M114.1 on the old firmware, but with the new firmware the plain M114 works too, i.e. I made it reporting axes A B C too.
    2. You must then adjust the Regex. I suggest just using the following wildcard prefix, which is also compatible with other controllers (Duet3):

      ^*.X:(?<X>-?\d+\.\d+) Y:(?<Y>-?\d+\.\d+) Z:(?<Z>-?\d+\.\d+) A:(?<A>-?\d+\.\d+) B:(?<B>-?\d+\.\d+).*

    3. For others reading this: If Switch Linear <> Rotational is on on rotational axes, then you must have my newest "PAXIS" firmware and vice versa!
    4. Unless you have a Warp Speed machine, your feedrates on the Axes are in (wrong) mm/min instead of mm/s. Please divide by 60. Should I mark it like this?
    5. You have no Jerk set on the X, Y axes, but a relatively low Jerk of 10000mm/s3 on the Z axis. Usually you don't need Jerk control on Z but you probably want it on X/Y, even if you only use the ModeratedConstantAcceleration mode on the driver.
    6. You have resolution 0.001 on the axes, even 0.0001 on Z, but only 2 floating point digits (%.2f) in MOVE_TO_COMMAND. The formatting specifier should always at least suffice to express the resolution. I suggest reducing the resolution to 0.01 or the true micro-step.
    7. About the Serial DTR/RTS on, I have no idea, what this does. It works without on my Smoothie.
    8. Once the basics work, try the Simulated3rdOrderControl on the driver with some Jerk on X and Y. Try 30000mm/s3 and go up from there.
    9. You can probably increase the Rotational axes acceleration and speeds (but in mm/s).

    I'm sure we get this working better than before!

    :-)

    _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/GtCDy2p8Pbg/unsubscribe.
    To unsubscribe from this group and all its topics, send an email to openpnp+u...@googlegroups.com.

    Duncan Ellison

    unread,
    Oct 21, 2020, 6:47:30 AM10/21/20
    to OpenPnP
    Mi _Mark,

    Success!

    You were correct, the bad position report was clearly confusing the co-ordinate system.

    Yes, this was based on an auto-migrated config, that part went flawlessly for me.

    Here's some more feedback

    Most likely culprit: M114.2 (wrong) instead of just M114 (correct) in GET_POSITION_COMMAND

    I can confirm this is the correct command

    You must then adjust the Regex. I suggest just using the following wildcard prefix, which is also compatible with other controllers (Duet3)
    ^*.X:(?<X>-?\d+\.\d+) Y:(?<Y>-?\d+\.\d+) Z:(?<Z>-?\d+\.\d+) A:(?<A>-?\d+\.\d+) B:(?<B>-?\d+\.\d+).*

    This didn't work for me.  In fact I couldn't get it to work with a regex checker.  I ended up having to use :
    ^ok C:.X:(?<X>-?\d+\.\d+) Y:(?<Y>-?\d+\.\d+) Z:(?<Z>-?\d+\.\d+) A:(?<A>-?\d+\.\d+) B:(?<B>-?\d+\.\d+).*

    but I think this should also work as I think Regex just looks for matches within the presented string  :
    X:(?<X>-?\d+\.\d+) Y:(?<Y>-?\d+\.\d+) Z:(?<Z>-?\d+\.\d+) A:(?<A>-?\d+\.\d+) B:(?<B>-?\d+\.\d+).*

    For others reading this: If Switch Linear <> Rotational is on on rotational axes, then you must have my newest "PAXIS" firmware and vice versa!

    This is super important and a point I think others might miss, so worth really pointing it out in the docs.  It's not hard, you simply put your super nice prepared firmware on the Smoothie flash drive, rename it as 'firmware.bin', then reboot.  It's a shame this is deviating further and further from the Smoothie base code, but it seems that Arthur & Co. aren't putting any further effort into Smoothie V1 code now anyway, so I think yours is really the gold standard as far as PNP is concerned.

    Unless you have a Warp Speed machine, your feedrates on the Axes are in (wrong) mm/min instead of mm/s. Please divide by 60. Should I mark it like this?

    Well, despite reading this several times, I still missed the importance of this.  It does feel a little counter intuitive to have different units for Smoothie config and OpenPnP though.  

    You have no Jerk set on the X, Y axes, but a relatively low Jerk of 10000mm/s3 on the Z axis. Usually you don't need Jerk control on Z but you probably want it on X/Y, even if you only use the ModeratedConstantAcceleration mode on the driver.

    On my machine, I can tolerate a MUCH higher jerk on the X axis than on the Y, so this is one of the most important things for me.

    You have resolution 0.001 on the axes, even 0.0001 on Z, but only 2 floating point digits (%.2f) in MOVE_TO_COMMAND. The formatting specifier should always at least suffice to express the resolution. I suggest reducing the resolution to 0.01 or the true micro-step

    I now have a real world step rate of 400 per mm on the axis, what would you suggest is reasonable?  2 or 3 decimals?

    About the Serial DTR/RTS on, I have no idea, what this does. It works without on my Smoothie.
    This is a legacy thing relating to real serial ports.  In the 'old days' if the DTR (Data Terminal Ready) and RTS (Ready To Send) lines were not active, no data could be sent.  Some USB drivers just ignore this others don't, I suspect the mileage may vary depending on which USB dongle you are using. 

    Once the basics work, try the Simulated3rdOrderControl on the driver with some Jerk on X and Y. Try 30000mm/s3 and go up from there.

    This appears to be working pretty good now :-)  With the diagnostics, I can see that the driver is actively trying to ramp up and down the speed/acceleration on each movement and the planned versus actuals are getting closer now. 

    I have to admit to being completely in the dark regarding these parameters from a practical experience point of view.  30,000 mm/s3 sounds like a huge number and you say that's a starting point.  

    You can probably increase the Rotational axes acceleration and speeds (but in mm/s).

    OK, I'm using trial and error to see what works here as I can't get my head around this rotational to linear thing, I'm just glad it works(!)

    I think the biggest concern left here is understanding what numbers work for acceleration and jerk in the real world, It feels a little like PID tuning, where you can have completely unintended consequences by changing a single parameter, but yet the numbers themselves feel meaningless.  I'm not sure how to make this more accessible to newcomers apart from offering some starting guidance for an 'average' hobby machine.

    Here's what I'm using at the moment 

    X Axis
    Smoothie
    alpha_max_rate                               150000           # Maximum rate in mm/min
    alpha_acceleration                           50000            # mm/sec^2
    x_axis_max_speed                             60000            # mm/min

    Kinematic
    Feedrate = 600 /S
    Acceleration = 10,000/S2
    Jerk = 30,000/S3

    Y Axis
    Smoothie
    beta_max_rate                                150000       # Maxmimum rate in mm/min
    beta_acceleration                            50000            # mm/sec^2
    y_axis_max_speed                             60000            # mm/min

    Kinematic
    Feedrate = 600 /S
    Acceleration = 10,000/S2
    Jerk = 10,000/S3

    C1/C2 Axis
    Smoothie
    delta_max_rate                               20000.0          # mm/min
    delta_acceleration                           500.0            # mm/sec2

    Kinematic
    Feedrate = 2000/S
    Acceleration = 4,000/S2
    Jerk = 0/S3

    I have set the driver Max Feed Rate to 0 and left interpolation at the defaults offered.

    Right now, long moves are very impressive with virtually no jerk at the end, but smaller moves from the feeder to the board are rather slow, this could be due to the rotational speed slowing the overall move, not sure yet.

    I have one other question.  The whole Safe Z thing still has me confused especially the new 'Safe Zones' (these are all set at 0 and not enabled at the moment).  During testing, I noticed one setting which moved in Z along the X/Y travel.  On my machine this is very dangerous.  I have only a small amount of headroom (+-22mm) before I hit things, so my question is what settings do I now need to ensure that a NEVER have any Z movement at <0 during X/Y traverses?

    Sterling work _Mark ... you are a real asset to the group.

    Duncan

    ma...@makr.zone

    unread,
    Oct 21, 2020, 8:47:09 AM10/21/20
    to ope...@googlegroups.com

    Hi Duncan

    Wow, a large reply, hop you are reading all this ;-)

    > Success!

    Yippee!

    > I now have a real world step rate of 400 per mm on the axis, what would you suggest is reasonable?  2 or 3 decimals?

    I would set the axis resolution to 0.01 (4 micro-steps) and use 2 decimals. It does not make sense to use finer resolution in electronics PnP, IMHO.

    Note, setting the resolution to a pragmatic value like this will filter out non-sensical microscopic axis adjustments especially those due to runout compensation. This in turn will prevent extra backlash compensation moves (if you have backlash compensation at all).

    > This didn't work for me. 

    Strange. I have exactly this working, for both Smoothie and Duet. Are you sure? (I just like to know, so I can adapt the Wiki)

    ^.*X:(?<X>-?\d+\.\d+) Y:(?<Y>-?\d+\.\d+) Z:(?<Z>-?\d+\.\d+) A:(?<A>-?\d+\.\d+) B:(?<B>-?\d+\.\d+).*

    > This is super important and a point I think others might miss, so worth really pointing it out in the docs.

    Yes. I have some ideas about how to even enforce it in OpenPnP.

    M115 is an interesting command, even though it is undocumented for Smoothie  ;-) (I will improve that message to point to my repo and report PAXIS. )

    FIRMWARE_NAME:Smoothieware, FIRMWARE_URL:http%3A//smoothieware.org, X-SOURCE_CODE_URL:https://github.com/Smoothieware/Smoothieware, FIRMWARE_VERSION:feature/best-for-pnp-13bbd1fa, X-FIRMWARE_BUILD_DATE:Oct 17 2020 17:17:54, X-SYSTEM_CLOCK:120MHz, X-AXES:5, X-GRBL_MODE:0, X-CNC:0, X-MSD:1
    ok

    On Duet:

    FIRMWARE_NAME: RepRapFirmware for Duet 3 MB6HC FIRMWARE_VERSION: 3.2-beta2+1 ELECTRONICS: Duet 3 MB6HC v1.01 or later FIRMWARE_DATE: 2020-10-17b1

    Discovering the controller will allow me to point the user to mistakes and potential problems.

    >  I think the biggest concern left here is understanding what numbers work for acceleration and jerk in the real world, It feels a little like PID tuning, where you can have completely unintended consequences by changing a single parameter, but yet the numbers themselves feel meaningless.  I'm not sure how to make this more accessible to newcomers apart from offering some starting guidance for an 'average' hobby machine.

    Acceleration can be grasped if you think of earth's gravity g. That would be 9'810mm/s2, so if you held you machine 90° turned so that the axis must move against gravity with all its weight, it would be the same extra load. With your whopping 10'000mm/s2 you're even slightly over! For comparison: my Liteplacer can only take 5'000mm/s2 in X, 2'500mm/s2 in Y despite stepper upgrade :-(

    Jerk is almost impossible to grasp physically. Just realize that using a classic constant acceleration controller (such as Smoothie) you apply infinite jerk (at least in theory)! So 30'000mm/s3 seems like a lot, but it is a lot less than infinite ;-)

    It may help to think about the 7-segment ramps. With your X acceleration of 10'000mm/s2 and jerk 30'000mm/s3 it takes a/j = 1/3 s to ramp the acceleration up (or down). It takes 2/3 s to ramp up and then down again, before max feed-rate is hit. So if you ever want to achieve your max acceleration in real moves, that's to be considered. Your Y jerk is almost certainly too low. Just define a realistic test move in the Motion Planner tab and use the Motion Planner Diagnostics to check the ramps out.

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


    Simulated Jerk Control


    > but smaller moves from the feeder to the board are rather slow, this could be due to the rotational speed slowing the overall move, not sure yet.

    Again, your Y jerk of 10'000mm/s3 is certainly too low.

    > these are all set at 0 and not enabled at the moment

    This should not be possible. Should throw an exception, as soon as you try to Safe Z your nozzle. Are you sure?

    All set at 0 and enabled is fine.

    > During testing, I noticed one setting which moved in Z along the X/Y travel. 

    If you defined a Safe Z zone with some room in it, this is normal and wanted. To quote myself:

    If there is a switch of nozzles (one going up, move in X/Y, the other going down), OpenPnP will even exploit the time in transit to move the Z axis over to the other limit of the Safe Zone, readying the other Nozzle at the exit point for the quickest/shortest descent to the target location.

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

    > I have only a small amount of headroom (+-22mm) before I hit things, so my question is what settings do I now need to ensure that a NEVER have any Z movement at <0 during X/Y traverses?

    Proceed as follows and you should be safe

    1. Jog the Z of the left nozzle to the appropriate height (above the tallest obstacle)
    2. Use the Z Axis capture button to get the lower limit:
    3. Jog the Z of the right nozzle to the appropriate height (above the tallest obstacle)
    4. Use the capture button to get the upper limit:
    5. If the limits are inverted (Low is higher than High), repeat steps 1. - 4. with swapped nozzles.

    _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/9bf98386-e7f9-45ed-b0f3-37b1ee52fab4n%40googlegroups.com.

    ma...@makr.zone

    unread,
    Oct 21, 2020, 7:41:04 PM10/21/20
    to ope...@googlegroups.com

    Hi everybody,

    @Bill, one question for you further down.

    to ease the entry into the complexities or Advanced Motion Control there is a new Troubleshooting Wizard on the machine.

    The most important settings are scrutinized, the firmware version of the controller detected, issues listed and a resolution suggested. You can then check the checkbox and (most of the time) the resolution will directly be applied in OpenPnP:

    Once applied you can still uncheck the checkbox to undo the resolution:

    Even G-code fragments are generated based on the Machine Setup (Axes with their Letters, mapped to Drivers etc.):

    If no remedy can directly be applied, it will open the right Wiki page to guide you to a solution. In the course of this I added this one:

    https://github.com/openpnp/openpnp/wiki/Motion-Controller-Firmwares

    @Bill, are you OK with that for Marlin 2.0?

    The framework is completely open i.e. not specific to Motion Control, so other troubleshooting methods can be added in the future.

    This needs some further work and then I'll create a new testing version.

    _Mark             

    Wolfgang Lienbacher

    unread,
    Oct 22, 2020, 3:47:12 AM10/22/20
    to OpenPnP
    Oh this is a really nice introduction Mark! 
    I'm still not 100% there with my configuration, so will run that troubleshooting wizard asap. I cannot see it in the test download yet though, the latest download is from the 18th. 

    ma...@makr.zone

    unread,
    Oct 22, 2020, 5:35:21 AM10/22/20
    to ope...@googlegroups.com

    Hi Wolfgang

    Like I said :

    > This needs some further work and then I'll create a new testing version.

    It was 01:41 and I needed some sleep, and now I'm back at (real) work, so it may take a day or two, sorry ;-)

    _Mark

    Wolfgang Lienbacher

    unread,
    Oct 22, 2020, 6:02:30 AM10/22/20
    to OpenPnP
    Haha no worries! 
    Still having issues with simulated 3rd order, the moves are not smooth but rather janky and take longer than estimated. If I switch to moderated everything moves fine. I've tried different x-y values for speed/accel/jerk but did not find a sweet spot.

    ma...@makr.zone

    unread,
    Oct 22, 2020, 6:22:26 AM10/22/20
    to ope...@googlegroups.com

    Hi Wolfgang

    > the moves are not smooth but rather janky and take longer than estimated

    Yeah I know. I have my Duet 3 now running as a bench contraption.

    dc42 of Duet3D and I are in exchange about this. It seems to primarily be a USB serial lag issue. He has already improved some other things and has announced a fix for the USB issue soon.

    I'm afraid you need to use ModeratedConstantAcceleration for now.

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

    One must realize that all the other common NC applications (3D-printing, milling, laser cutting etc.) work with fully prepared Gcode, sometimes worth hours of uninterrupted execution.  Simple to stream, lags have no effect.

    OpenPnP is completely different. Small time step/high volume motion interpolation in combination with stop-and-go operation i.e. needing just-in-time motion planning interactively governed by vision, vacuum sensing, feeder faulting etc. is very hard in deed. It must be said that Smoothie does it superbly, if only it had (much) more RAM.

    But it seems that dc42 is very much on to it for Duet.

    _Mark

    Duncan Ellison

    unread,
    Oct 22, 2020, 4:08:17 PM10/22/20
    to OpenPnP
    Hi _Mark,

    Thought you might like to see the results of your hard work:

    Capture.PNG

    This is with Simulated3rdOrderControl on a Smoothie with your special firmware.  It's very nicely controlled with minimal apparent jerk and I'm able to run a full job including fiducials.
    I tried switching to the regular FeedRate motion, but keeping all other factors the same and it nearly shook the head off (!!)
    BTW, I'm loving the idea of the 'check wizard', that goes a long way to addressing my concerns about how newcomers will easily be able to get running. 

    Outstanding job.

    ma...@makr.zone

    unread,
    Oct 22, 2020, 4:19:10 PM10/22/20
    to ope...@googlegroups.com

    8-D

    _Mark

    Wolfgang Lienbacher

    unread,
    Oct 23, 2020, 11:01:59 AM10/23/20
    to OpenPnP
    These are great news mark! I'd love to volunteer testing that new firmware one @dc42 has it ready! :)

    Bill Ruckman

    unread,
    Oct 23, 2020, 4:35:23 PM10/23/20
    to ope...@googlegroups.com
    Hi Mark,

    Sorry for the late reply.  I'm just catching up on emails.


         @Bill, are you OK with that for Marlin 2.0?  

    Yes, that is fine with me.

    --Bill


    To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/aed2df9a-3d55-4f78-a1e4-a307ddb456dcn%40googlegroups.com.

    Duncan Ellison

    unread,
    Oct 25, 2020, 7:27:38 AM10/25/20
    to OpenPnP
    @_Mark  - Just to let you know that I assembled the first 3 production board yesterday using the new Motion Control on my PM460 modified machine.

    All 3 turned out 100%, motion was smooth and about as fast as I would expect (considering I put my bottom camera about a mile away from the board origin - doh!)

    I had another instance of losing the config files though - all blank, nothing in them at all.  So I'm being super diligent for the moment about backups.  Could be related the the PC I'm using, so I don't want to panic anyone yet.

    Only slight issue I'm having still is with rotation, sometimes it's 100%, sometimes it seems to do odd things like 90 degrees off.  Sometimes I get an effect where the part is presented to the camera and it just 'wobbles' - can't think of a better way to describe it - the rotation just jigs round and back about 20 degrees in fast succession, haven't got to the bottom of this yet, it could be a camera artefact or a motion issue.

    Duncan
     p.s. I read that you are updating the test branch again (anything I need to watch for?)

    ma...@makr.zone

    unread,
    Oct 25, 2020, 8:31:25 AM10/25/20
    to ope...@googlegroups.com

    Hi Duncan

    appreciate the good testing!

    > I had another instance of losing the config files though

    Just to make this clear: has this ever also happened with the regular OpenPnP 2.0 version?

    When it happens next time, look at the ~/.openpnp2/log subdirectory and send me OpenPnP.log, OpenPnP.0.log, OpenPnP.1.log. They might contain something.

    > 90 degrees off.

    Hmmm, are you sure you got the parts all on Adjust and none on Full?

    > the rotation just jigs round and back about 20 degrees in fast succession

    Sounds like pipeline detection failure. You should see that in the "bv_result" images in the ~/.openpnp2/org.openpnp.vision.pipeline.stages.ImageWriteDebug subfolder, assuming you have the corr. ImageWriteDebug stage in the pipeline enabled.

    _Mark

    Duncan Ellison

    unread,
    Oct 26, 2020, 4:41:21 PM10/26/20
    to OpenPnP
    Hi _Mark,

    Quick Update.  I updated to the latest test branch with the configuration checker.  

    All worked OK, this is looking good!

    Wrongly detected my other GCode Driver for ancillaries and flagged it as a 'fail' - maybe add to the comment to clarify this is actually OK?
    Move commands were flagged up because they had different comments, which is to be expected, I suppose.
    Position Regex flagged up as we've discussed before,  I accepted your suggestion and it seems to work, but I don't see any confirmation of this in the logs

    The Regex issue still has me puzzled as my go to Regex checker regex101.com rejects it.

    Ran a Motion Test and all seems OK.

    No further config losses yet and I still need to investigate the pipeline failure as a possible cause of the wobbling.

    Duncan

    ma...@makr.zone

    unread,
    Oct 27, 2020, 3:32:50 AM10/27/20
    to ope...@googlegroups.com

    Thanks Duncan,

    > Wrongly detected my other GCode Driver for ancillaries and flagged it as a 'fail' - maybe add to the comment to clarify this is actually OK?

    Could you elaborate on this? What exactly is it saying?

    Is it the bug joël reported?

    --> I have 2 auxiliary gcode controllers that will never support the M115 command , the dismiss command checks it, fails and then let the issue opened.

    I already fixed that for the next update.

    Plus I removed some irrelevant issue reporting (pre-move-commands, axis letter variables) for drivers that have no axes assigned to them. This will be in the next update.

    Btw. please use the new thread for posts about the new version, thanks :-)

    https://groups.google.com/d/msg/openpnp/j7fuo0e9VVM/wFDu65I0BAAJ

    Thanks again for all your testing, much appreciated, Duncan!

    _Mark

    ma...@makr.zone

    unread,
    Oct 27, 2020, 3:39:32 AM10/27/20
    to ope...@googlegroups.com

    > Position Regex flagged up as we've discussed before,  I accepted your suggestion and it seems to work, but I don't see any confirmation of this in the logs
    > The Regex issue still has me puzzled as my go to Regex checker regex101.com rejects it.

    I since found the bug in the Wiki version of it. I must somehow have swapped the * and . characters at the beginning. Don't know how the heck this happened. I was convinced I used copy&paste both ways with no issues, but there it was!

    The good news: the Issues & Solutions system will never have this type of behind-the-keyboard problem again ;-)

    _Mark

    Yevhenii Shcherbakov

    unread,
    Oct 28, 2020, 3:52:35 AM10/28/20
    to OpenPnP
    Hallo Mark.
    I am download OpenPnP test version from https://openpnp.org/test-downloads/  (it is v. 2020-04-21_0233-13.10ede59)
    but there are no have "Axes" (Machine Setup).

    Upgrading to the developed version (it is v. 2020-10-13_01-06-13.7у18341) gave an even worse result: Axes did not appear.

    Which version of Openpnp has Axes and Advanced Motion Control, where can I download it?  


    вторник, 27 октября 2020 г. в 10:39:32 UTC+3, ma...@makr.zone:

    Wolfgang Lienbacher

    unread,
    Oct 28, 2020, 4:11:52 AM10/28/20
    to ope...@googlegroups.com
    Yevhenii, that test-version you downloaded is from April (2020-04-21), try the one from octoper 25th: https://openpnp.s3-us-west-2.amazonaws.com/index.html?prefix=test/
    how to find: on the bottom of the test-download site is a link that says „Click here“, then find the "test/" folder in the top right below develop. It’s a bit hard to find and a bit impractical to haven no version numbers in the filename …


    ma...@makr.zone

    unread,
    Oct 28, 2020, 4:47:15 AM10/28/20
    to ope...@googlegroups.com

    Yes. And I should write a CHANGES entry, so everybody knows it's the right one from the About.

    _Mark

    Reply all
    Reply to author
    Forward
    0 new messages