Advanced Motion Control Testing Version - Update 3

[ma...@makr.zone]

Hi everybody

Just made a new Pull request and merged it into the testing version. All information there:

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

Also, a new video available:

https://youtu.be/VVaZo6BfhOM

Enjoy!

_Mark

[jdlv...@gmail.com]

Hi Mark

amazing, thank you!

I have an issue with a script that tries to move the camera calling : cam.moveTo(loc);

It doesn't move at all. Corresponding log :

2020-10-26 18:49:06.207 AbstractHeadMountable DEBUG: N1.moveToSafeZ(1.0)
2020-10-26 18:49:06.209 ReferenceNozzle DEBUG: N1.transformToHeadLocation((618.730000, 260.100000, 0.000000, -180.000000 mm), ...) runout compensation: (-0.051254, 0.058290, 0.000000, 0.000000 mm)
2020-10-26 18:49:06.210 ReferenceNozzle DEBUG: N1.transformToHeadLocation((618.730000, 260.100000, 0.000000, -180.000000 mm), ...) runout compensation: (-0.051254, 0.058290, 0.000000, 0.000000 mm)
2020-10-26 18:49:06.293 AbstractHeadMountable DEBUG: Top Camera.moveTo((668.574000, 79.049000, 0.000000, 0.000000 mm), 1.0)
2020-10-26 18:49:06.527 OpenCvUtils DEBUG: houghCircles(Top Camera, 0.990mm, 1.010mm, 5.000mm)
2020-10-26 18:49:06.527 Scripting TRACE: Scripting.on Camera.BeforeCapture
2020-10-26 18:49:06.545 Scripting TRACE: Scripting.on Camera.AfterCapture
2020-10-26 18:49:06.546 OpenCvUtils DEBUG: houghCircles(Mat, 65.24158828340155, 66.55960016791472, 329.50297112829065)
2020-10-26 18:49:07.333 AbstractHeadMountable DEBUG: Top Camera.moveTo((668.376436, 78.245969, 0.000000, 0.983299 mm), 1.0)
2020-10-26 18:49:07.975 OpenCvUtils DEBUG: houghCircles(Top Camera, 0.990mm, 1.010mm, 5.000mm)
2020-10-26 18:49:07.976 Scripting TRACE: Scripting.on Camera.BeforeCapture
2020-10-26 18:49:08.002 Scripting TRACE: Scripting.on Camera.AfterCapture

And a 1mm jogging moves :

2020-10-26 18:53:32.901 AbstractHeadMountable DEBUG: N1.moveTo((538.332800, 197.463600, 0.000000, -180.000000 mm), 1.0)
2020-10-26 18:53:32.901 ReferenceNozzle DEBUG: N1.transformToHeadLocation((559.699968, 249.848316, 0.000000, -180.000000 mm), ...) runout compensation: (0.034285, -0.018546, 0.000000, 0.000000 mm)
2020-10-26 18:53:32.905 GcodeAsyncDriver DEBUG: serial:///dev/serial/by-id/usb-Uberclock_Smoothieboard_0A00B01DAF1C202759CAD65AF50020C7-if00 commandQueue.offer(M204 S854.99 G1 X559.7000    F1754.41 ; move to target, 5000)...
2020-10-26 18:53:32.905 GcodeDriver TRACE: Compressed Gcode: M204S854.99G1X559.7F1754.41
2020-10-26 18:53:32.906 GcodeDriver TRACE: [serial:///dev/serial/by-id/usb-Uberclock_Smoothieboard_0A00B01DAF1C202759CAD65AF50020C7-if00] confirmed G92A-180
2020-10-26 18:53:32.911 GcodeAsyncDriver$WriterThread TRACE: [serial:///dev/serial/by-id/usb-Uberclock_Smoothieboard_0A00B01DAF1C202759CAD65AF50020C7-if00] >> M204S854.99G1X559.7F1754.41
2020-10-26 18:53:32.912 GcodeDriver$ReaderThread TRACE: [serial:///dev/serial/by-id/usb-Uberclock_Smoothieboard_0A00B01DAF1C202759CAD65AF50020C7-if00] << ok

Looks like Camera.move doesn't call GcodeAsyncDriver and so.

I should have missed something but can't figure out what...

joël

[ma...@makr.zone]

Hi joël

assuming you have enabled the ReferenceAdvancedMotionPlanner, you now need to tell OpenPnP when you want to complete your motion.

So use

    cam.waitForCompletion(MotionPlanner.CompletionType.WaitForStillstand);

I don't  know exactly how Java translate into the script syntax, so this is a guess.

The reason is that the motion planner wants to execute moves as an uninterrupted sequence and maybe even blend them together, if possible, so they are first queued and only planned and executed, when the need arises. There are no interruptions between moves any more, the controller is free to optimize. You should see a more fluid motion sequence on your machine, that takes less time overall.

Experiment to showcase: Set Speed [%] to a very low value. Set Jog to 10mm. Now Jog many times, klicking very rapidly. It should now do a continuous motion, with no deceleration between jogs (except for the first one, because you can't possibly be fast enough as a human being ;-).

If it does not work, check your Backlash Compensation. It only works if None or Directional is set.

Usually OpenPnP will now only complete motion...

• After homing
• Before Camera settle
• Before actuating an Actuator (that's an option that is enabled by default)
• After actuating an Actuator (that's an option that is disabled by default)
• Before reading an Actuator (that's an option that is enabled by default)
• Between moves that contain axes from different and/or multiple drivers (interlock).
  
• Once the Machine Thread finishes a task.
  

However, if you just want to queue the command and are happy to let it happen, when the next need arises, it should already work now, just not in the sequence you expect. Does it not appear later in the Log?

Btw, there are different CompletionTypes (from the source code):
        /**
         * The motion plan is sent to the drivers, assuming an unfinished motion sequence (e.g. when Jogging).
         * More specifically, the motion planner's deceleration to still-stand will not be enforced, it is entirely
         * up to the controller. If a subsequent motion command arrives soon enough, there might be no (or less) deceleration
         * between the moves.
         * If the driver supports asynchronous execution, this does not wait for the driver to physically complete.
         */
        CommandJog,

        /**
         * The motion plan is sent to the drivers, finishing in still-stand.<br/>
         * If the driver supports asynchronous execution, this does not wait for the driver to physically complete.
         */
        CommandStillstand,

        /**
         * The motion plan is executed with the drivers, finishing in still-stand.<br/>
         * This does always wait for the driver to complete i.e. the caller can be sure the machine has physically arrived
         * at the final location. 
         */
        WaitForStillstand,

        /**
         * Like WaitForStillStand but the wait will also be done, if no motion is thought to be pending (used when it is though
         * that the machine might have moved through custom Actuator Gcode (the ContactProbeNozzle is one example).
         */
        WaitForUnconditionalCoordination,

        /**
         * Like WaitForFullCoordination but wait "forever" i.e. with very long timeout. Used e.g. for homing.
         */
        WaitForStillstandIndefinitely;

_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/3a450346-1f61-4c95-9332-e77fda822241n%40googlegroups.com.

[ma...@makr.zone]

Added some of these explanations to the Wiki:

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/b05de7fa-dea0-3245-4b50-386d620a8bc2%40makr.zone.

[jdlv...@gmail.com]

Thank you, solved with :       

cam.moveTo(loc);

cam.settleAndCapture();   

Another small issue with  Issues & Solutions, 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.

Thanks.

joël

[ma...@makr.zone]

> Thank you, solved with :       
> cam.moveTo(loc);
> cam.settleAndCapture();   

OK, but could you please test the

    cam.waitForCompletion(MotionPlanner.CompletionType.WaitForStillstand);

or possibly

    cam.waitForCompletion(org.openpnp.spi.MotionPlanner.CompletionType.WaitForStillstand);

for me?

I could then add it to the Wiki. Thanks!

> the dismiss command checks it, fails and then let the issue opened.

Ah yes. Thanks for pointing this bug out. Fixed it. Will be in the next update.

_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/j7fuo0e9VVM/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/0eae2d51-2a87-45ec-a72e-66f3a6e40406n%40googlegroups.com.

[jdlv]

cam.waitForCompletion(MotionPlanner.CompletionType.WaitForStillstand);
makes OpenPnp unhappy but

cam.waitForCompletion(org.openpnp.spi.MotionPlanner.CompletionType.WaitForStillstand);
works perfectly but of course doesn't wait for the camera to settle.

joël



Le 27/10/2020 à 08:18, ma...@makr.zone a écrit :
> />////Thank you, solved with : //
> //> cam.moveTo(loc); //
> //> cam.settleAndCapture(); /

>
> OK, but could you please test the
>
> cam.waitForCompletion(MotionPlanner.CompletionType.WaitForStillstand);
>

> or possibly/
> /
>
> cam.waitForCompletion(org.openpnp.spi.MotionPlanner.CompletionType.WaitForStillstand);//

>
>
> for me?
>
> I could then add it to the Wiki. Thanks!
>

> /> the dismiss command checks it, fails and then let the issue opened./

>
> Ah yes. Thanks for pointing this bug out. Fixed it. Will be in the next
> update.
>
> _Mark
>
> Am 26.10.2020 um 21:14 schrieb jdlv...@gmail.com:
>> Thank you, solved with :
>>
>> cam.moveTo(loc);
>> cam.settleAndCapture();
>>
>> Another small issue with  Issues & Solutions, 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.
>>
>> Thanks.
>>
>> joël
>>
>>
>>
>> --
>> 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/j7fuo0e9VVM/unsubscribe

>> <https://groups.google.com/d/topic/openpnp/j7fuo0e9VVM/unsubscribe>.

>> To unsubscribe from this group and all its topics, send an email to
>> openpnp+u...@googlegroups.com

>> <mailto:openpnp+u...@googlegroups.com>.

>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/openpnp/0eae2d51-2a87-45ec-a72e-66f3a6e40406n%40googlegroups.com

>> <https://groups.google.com/d/msgid/openpnp/0eae2d51-2a87-45ec-a72e-66f3a6e40406n%40googlegroups.com?utm_medium=email&utm_source=footer>.
>>
>

[ma...@makr.zone]

Thanks!

Now in the Wiki:

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

_Mark

[Duncan Ellison]

Hi _Mark,

I'm resurrecting my first machine and trying a complete auto-conversion, so far so good.

I'm having problems with M114 thought.  Please remind me how to get smoothie to report A and B rather than E (I'm using your latest Smoothie Firmware)

Duncan

[ma...@makr.zone]

That's strange. Have you configured any Extruders in config.txt?

_Mark

To unsubscribe from this topic, visit https://groups.google.com/d/topic/openpnp/j7fuo0e9VVM/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/a61d81af-26db-472c-9e5f-1ef1ace601d7n%40googlegroups.com.

[ma...@makr.zone]

Hi everybody

A new Update 4 of the Advanced Motion Control testing version is available ... even though this is Update 4, I keep it under this thread ;-)

As always, download the newest testing version here:
https://openpnp.org/test-downloads/

See the Pull request:
https://github.com/openpnp/openpnp/pull/1072

Watch the video:
https://youtu.be/6SBDApObbz0

_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/03f0ae7c-a2d9-304b-bbee-5908a490cd76%40makr.zone.

[ma...@makr.zone]

Hmmm.. it seems to take a while to auto-build the testing version. Be sure to take the one from right now and wait until it pops up.

Hope the auto-build is not broken. :-/

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/b26fecb1-fe4d-b5c5-900e-3f3dcac8616f%40makr.zone.

[Duncan Ellison]

Hi _Mark,

Seems like I had a default config.txt without the 'special' additional axes configured.  I had a quick look at the documentation while trying to figure this out, but it didn't jump out at me.  

Changing the E to A/B in the config is critical to the process, do you think we've made that clear enough to someone coming to this new when discussing the special smoothie firmware?

Duncan

[ma...@makr.zone]

Hi Duncan

Frankly, I'm not really the expert in Smoothie config.txt, so I don't actually know what makes the difference in "changing the E to A/B in the config". Could you elaborate?

On my Smoothie it just appeared as if both E and A B C can be used out of the box. But I was always using the new 6-axis endstop syntax, because I have my 5th axis prepared to be used as a PCB conveyor and it needs homing. Maybe that's the key?

http://smoothieware.org/6axis

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/bd8e0cd9-890d-4d8e-9d38-19b15ff264a0n%40googlegroups.com.

[Duncan Ellison]

Hi _Mark,

The default config.txt (i.e. the one noobs are going to gravitate to if just reading the Smoothie docs on the web)  has stuff like this :

## Extruder module configuration

# See http://smoothieware.org/extruder

extruder.hotend.enable                          true          # Whether to activate the extruder module at all. All configuration is ignored if false

extruder.hotend.steps_per_mm                    140           # Steps per mm for extruder stepper

extruder.hotend.default_feed_rate               600           # Default rate ( mm/minute ) for moves where only the extruder moves

extruder.hotend.acceleration                    500           # Acceleration for the stepper motor mm/sec²

extruder.hotend.max_speed                       50            # Maximum speed in mm/s

extruder.hotend.step_pin                        2.3           # Pin for extruder step signal

extruder.hotend.dir_pin                         0.22          # Pin for extruder dir signal ( add '!' to reverse direction )

extruder.hotend.en_pin                          0.21          # Pin for extruder enable signal

# Extruder offset

#extruder.hotend.x_offset                        0            # X offset from origin in mm

#extruder.hotend.y_offset                        0            # Y offset from origin in mm

#extruder.hotend.z_offset                        0            # Z offset from origin in mm

# Firmware retract settings when using G10/G11, these are the defaults if not defined, must be defined for each extruder if not using the defaults

#extruder.hotend.retract_length                  3            # Retract length in mm

#extruder.hotend.retract_feedrate                45           # Retract feedrate in mm/sec

#extruder.hotend.retract_recover_length          0            # Additional length for recover

#extruder.hotend.retract_recover_feedrate        8            # Recover feedrate in mm/sec (should be less than retract feedrate)

#extruder.hotend.retract_zlift_length            0            # Z-lift on retract in mm, 0 disables

#extruder.hotend.retract_zlift_feedrate          6000         # Z-lift feedrate in mm/min (Note mm/min NOT mm/sec)

In the expectation that the user will be using an actual extruder (of course!).  If you do this and still use your special firmware, you'll get a position report that shows the rotation axis as E:0000.00, which fails the Regex check.  The UI locks up for a (long) time then reports something like 'Failure to get position report - M114', which leaves you puzzled.

Of course, you need to be using the 6 Axis format in the config.txt described here http://smoothieware.org/6axis Mine now reads:

# A axis

delta_steps_per_mm                         17.7777          # may be steps per degree for example

delta_step_pin                               2.3              # Pin for delta stepper step signal

delta_dir_pin                                0.22             # Pin for delta stepper direction

delta_en_pin                                 0.21             # Pin for delta enable

delta_current                                0.6              # Stepper motor current

delta_max_rate                               30000.0          # mm/min

delta_acceleration                           50000.0          # mm/sec²

# B axis

epsilon_steps_per_mm                         17.7777          # may be steps per degree for example

epsilon_step_pin                             2.8              # Pin for delta stepper step signal

epsilon_dir_pin                              2.13             # Pin for delta stepper direction

epsilon_en_pin                               4.29             # Pin for delta enable

epsilon_current                              0.6              # Stepper motor current

epsilon_max_rate                             30000.0          # mm/min

epsilon_acceleration                         50000.0          # mm/sec²

and I've deleted all the superfluous extruder related stuff from config.txt.

I know you've made reference to this in the past, but in the documentation where you mention the need to use your special PAXIS firmware with the new motion control, it might be good to make it clear that you also need to amend your config.txt if you have previously been using the 'T0' / 'T1' Extruder format.

Also ....  I've completed the conversion of Machine 1.  I deliberately just blindly accepted the suggestions offered to see if that would lead to a happy place and it did.  The machine is nicely using Simulated 3D and the predicted and actual timings are coming out within around 5% of each other.

Comments :

1. It did trip me up a couple of times that the 'wizard' kept pointing out issues with the non-smoothie GCode driver that drives my feeders.  On a couple of occasions, I accidentally accepted a couple of the 'solutions' - oooops!

2. A by-product of 1. is that unsupported XML was added to the non-smoothie config in machine.xml and I had to hand amend it back out.  Things like interpolation etc.

3. I tried to dismiss the M115 report for the non-Smoothie driver and it ended up locking up OpenPnP which needed a reboot to fix :

4. You do need to be a bit careful when tuning up the machine especially when much of the parameters are educated guesses at the beginning.  I was easily able to set rates that caused so much acceleration the belts would jump off the drive cogs :-0  I found it was a good plan to tune at 50% then increase the speed to judge how far you can push it.

5.  I've been using the Test feature in the Motion planner to experiment with speeds.  I think the 'Test Motion' doesn't respect Safe Z - am I right about this?   This could be pretty dangerous if so as you can hit 'Test' and go crashing into something at top speed if you have a Z motion configured here.    On the upside, the motion blending seems cool, I have X Y Z and C1 all moving together is a very nice way.

Duncan

[ma...@makr.zone]

Hi Duncan

very valuable feed-back, thanks!

I guess I could do a M114 along with the M115 (firmware detect) and then advise the user if the A B C axes are missing, along with the link to  http://smoothieware.org/6axis 

Do you still have the logs? Usually the 100 last logs are saved in ~/.openpnp2/logs Could you send me the exact M114 report you got?

> Also ....  I've completed the conversion of Machine 1.  I deliberately just blindly accepted the suggestions offered to see if that would lead to a happy place and it did.  The machine is nicely using Simulated 3D and the predicted and actual timings are coming out within around 5% of each other.

Cool, that's great.

> 1. It did trip me up a couple of times that the 'wizard' kept pointing out issues with the non-smoothie GCode driver that drives my feeders.  On a couple of occasions, I accidentally accepted a couple of the 'solutions' - oooops!

Is that with the newest Update 4 testing version from yesterday? This latest version should avoid all motion and axis related suggestions, if you have no axes mapped to that driver.

However, if you do mistakenly accept the CONNECT_COMMAND suggestion (or if your driver already has a G90 in its CONNECT_COMMAND), then it will from this point on assume this to be a G-code speaking motion controller and suggest some generic Gcode commands.

> 2. A by-product of 1. is that unsupported XML was added to the non-smoothie config in machine.xml and I had to hand amend it back out.  Things like interpolation etc.

I see. But that's not the case if you can still use the Undo-Function, right? Undo will be available until you do one more "Find Issues & Solutions" or when you close OpenPnP.

> 3. I tried to dismiss the M115 report for the non-Smoothie driver and it ended up locking up OpenPnP which needed a reboot to fix :

Is that with the newest Update 4 testing version from yesterday? This latest version should not suffer from that. 

> 4. You do need to be a bit careful when tuning up the machine especially when much of the parameters are educated guesses at the beginning.  I was easily able to set rates that caused so much acceleration the belts would jump off the drive cogs :-0  I found it was a good plan to tune at 50% then increase the speed to judge how far you can push it.

Your machine seems to be extremely powerful! A bit over-motorized? Be careful and keep your limbs out!!

The Issues & Solutions system can only give you some help. There is obviously no way for it to guess the proper physical specs of your machine. ;-)

The idea is to shift the focus away from the (sometimes needlessly) cryptic internal technicalities (machine.xml/G-code) towards the conceptual machine components and parameters to be set up in the OpenPnP GUI. Those should be modeled as close as possible to their real-world counter-parts i.e. be parametrized with their true properties such as maximum feed-rates, accelerations etc. in an abstract, "physics lesson" way. 

One future vision could be to start with OpenPnP, set everything up conceptually, then automatically generate the config.txt (Smoothie), config.g (Duet) etc. and a wiring list.

> 5.  I've been using the Test feature in the Motion planner to experiment with speeds.  I think the 'Test Motion' doesn't respect Safe Z - am I right about this?   This could be pretty dangerous if so as you can hit 'Test' and go crashing into something at top speed if you have a Z motion configured here.  

Yes, good point. You can do everything with the Test motion, specifically a custom Safe Z movement. I added a warning Message.

>  On the upside, the motion blending seems cool, I have X Y Z and C1 all moving together is a very nice way.

;-)

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/ab3c59e6-31cc-4f1c-ab08-c0646526c698n%40googlegroups.com.

[Duncan Ellison]

Hi _Mark,

No that was with the previous version.  I'm uploading the new one now.  

I'm not sure by what magic the updater seems to automagically select the test branch and download the latest, but it's really helpful. 

>I guess I could do a M114 along with the M115 (firmware detect) and then advise the user if the A B C axes are missing, along with the link to  http://smoothieware.org/6axis 

Do you still have the logs? Usually the 100 last logs are saved in ~/.openpnp2/logs Could you send me the exact M114 report you got?

I checked the logs and couldn't see the Smoothie responding, just this:

2020-10-29 16:32:10.597 GcodeAsyncDriver DEBUG: serial://COM3 commandQueue.offer(M114 ; get position, -1)...

2020-10-29 16:33:10.599 MessageBoxes DEBUG: Error: java.lang.Exception: SmoothieBoard timeout waiting for response to M114 ; get position

However, I reverted back to the broken config and an M114, gives this :

ok C: X:0.0000 Y:0.0000 Z:0.0000 E:0.0000

With the changes, it sends :

ok C: X:206.5246 Y:-247.6492 Z:7.4947 A:0.0000 B:0.0000

>  It did trip me up a couple of times that the 'wizard' kept pointing out issues with the non-smoothie GCode driver that drives my feeders.  On a couple of occasions, I accidentally accepted a couple of the 'solutions' - oooops!

Is that with the newest Update 4 testing version from yesterday? This latest version should avoid all motion and axis related suggestions, if you have no axes mapped to that driver.

Tested - still gives a 'fundamental' error for the non-smoothie controller.  The solution offered (Convert to GcodeAsyncDriver) could still be misleading. 

 

Regarding the warning in Test Motion, that's a great idea.  Possibly move it to the top though so that someone who didn't scroll quite far enough down won't miss it??  Also re-emphasises that it relates to this specific section.

[ma...@makr.zone]

> I checked the logs and couldn't see the Smoothie responding

Responses are only logged with the Trace log level.

> Tested - still gives a 'fundamental' error for the non-smoothie controller. 

It is not a "Fundamental error" but a "Fundamental choice".

Is there a better word that is short enough for that narrow column? (this is where my being not native speaker shows the limits ;-)

Should I mark it in a different color? It is a "stopping" condition, so the "traffic-light" color would be red, but perhaps I should use a different color than Error's.

> The solution offered (Convert to GcodeAsyncDriver) could still be misleading. 

Actually, this solution per se would be a valid one. Even your feeders can benefit from asynchronous communication. But there is another issue there: the GcodeAsyncDriver then wants to use positions reports to implement hand-shaking. And that's not going to work with the suggested Gcode (no axes). So I'll have to fix either one or the other.

> Regarding the warning in Test Motion, that's a great idea.  Possibly move it to the top

Hmmm... I have another idea.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/95b5bc2d-e230-49f7-afe0-ad79f3d863d6n%40googlegroups.com.

[Wolfgang Lienbacher]

Mark, I'm still having the issue that on nozzle changes I would get a too many misdetecs error before the nozzle change has finished. Any idea what could cause that?

[ma...@makr.zone]

Hi Wolfgang

Have you used Issues & Solutions? No takers?

Have you used the newest testing version?

Please set logging to Trace level, redo it and send me the log, Thanks.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/98e993ea-c947-47ed-939b-f3b910ea1071n%40googlegroups.com.

[Wolfgang Lienbacher]

Hey Mark, sorry for the slow reply. Yes I have used Issues & Solutions, nothing in there. I have just tried running that job again and there you go, it did it. 

I have by the way also found that the Duet3 does not seem to like gcode compression. It wont do any move and also not send any error. I'm rather certain you are already aware of that. 

[ma...@makr.zone]

> I have just tried running that job again and there you go, it did it.

Is that with the latest version, Update 5?

> I have by the way also found that the Duet3 does not seem to like gcode compression. It wont do any move and also not send any error. I'm rather certain you are already aware of that.

Yes, we are aware. It only happens if there are multiple G and/or M commands on the same line. Duet needed a space character between those (which is not the standard). If you put them on separate lines, its ok (but slower).

dc42 already fixed that in the beta version, but there is another, following problem now. It responds with one "ok"s per G or M word on a line, so if you send M204 and G1 on the same line (as the suggested OpenPnP code does), it confuses the confirmation flow-control with two "ok"s. If you just use the Location Confirmation (which is now suggested by Issues & Solutions Update 5) there is no such problem.

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

I'll talk with dc42 to fix that one too. It is standards conformant to have an M and G word on the same line, as long as the two belong to different modal groups. It should only return one "ok" then.

Having multiple M or G words of the same modal group on the same line, is against the standard and I won't speculate what should happen with the number of "ok"s. OpenPnP will not use those.

See NIST RS274/NGC Interpreter – Version 3 standard:

3.3.5 Item Repeats

A line may have any number of G words, but two G words from the same modal group (see
Section 3.4) may not appear on the same line.

A line may have zero to four M words. Two M words from the same modal group may not appear
on the same line.

I don't think there is a single Open Source controller out there that is fully conformant.

For instance, did you know that this should work?

Y- 1X   0G        1.0000   Z0  ; same as G1 X0 Y-1

X10 Y2 0                       ; same as G1 X10 Y20

X 30Y + 5 0                    ; etc.

Y 7 0

Z8

Words may appear in any order on a line, i.e. the axes can appear in front of the G.

Spaces and tabs are allowed everywhere and they must not matter.

G1 is a modal command, i.e. you are switching "on" motion and all subsequent lines with axes mentioned will move, no G1 needed.

_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/924bcca7-7a08-4810-baf0-36e5e9e6c4ean%40googlegroups.com.

[Wolfgang Lienbacher]

Wow this is interesting! 

I tested it with both Version 4 and Version 5. It really seems to have been a weird glitch as after I tried to reproduce it to get the log for you it just never happened again, does not really make sense, but it's the way it is :)

Is the beta firmware for the duet3 publicly available yet? The latest beta release (3.2beta2)  is already 28 days old, which seems a bit too old to have those changes included ...

[ma...@makr.zone]

> Is the beta firmware for the duet3 publicly available yet?

Not sure, it is in the github v3.02-dev branch:

https://github.com/Duet3D/RepRapFirmware/blob/v3.02-dev/BuildInstructions.md

I could send you the .bin but frankly I think it is better to wait a bit more. dc42 is still on it, there are other issues with feed-rates and extra axes that need to be fixed.

In my own testing I had some strange behavior, sometimes, that I'd like to reproduce and pinpoint. There is also a Logging GUI issue in OpenPnP that needs fixing, so I'm not entirely sure it's actually Duet causing it (though it does not happen with Smoothie).

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/d7ee5617-5b8b-4b2d-8598-ebafd564ab8bn%40googlegroups.com.

[ma...@makr.zone]

Hi

I wrote> There is also a Logging GUI issue in OpenPnP that needs fixing...

The GUI log slows down operation a lot as the log grows in size (Marek T. pointed out how bad it is a while ago).

The GUI log is limited at 10000 entries but each addition of one line causes the entire log of 10000 lines to be re-filtered and copied in its entirety, so the computational cost grows to factor 10000² = 100'000'000 times that of an empty log.

Because the Advanced Motion move interpolation creates a very high volume of move commands (and accompanying log messages), the GUI log fills up quickly and will soon start to seriously block the motion (at TRACE and DEBUG levels). Plus it sometimes creates strange exceptions, probably caused by race conditions, again exposed by the multi-threaded and fast generation of log entries in Advanced Motion move interpolation and the GcodeAsyncDriver's writer thread.

If fixed that:

All new log entries are just added to a preliminary list. The list of new items will only be added/trimmed and filtered into the GUI list when a) the user switches over to the Log tab or b) while the Log tab is on top, every 500ms. Consequently, new log entries will be added/filtered/trimmed in larger and larger batches, keeping computation time per time unit more or less constant.

Test now show no slowing of interpolated motion even when the log is full at 10000 entries.

As a bonus: Log entries are now color-coded according to their level:

This will be available in the next Advanced Motion Testing version.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/ae1ea103-df98-339e-6297-8a30db04f849%40makr.zone.

[Bill Ruckman]

Hi Mark,

Can you make one more improvement to the Log tab?  When you use the Search function and highlight a particular line.  It should stay on that line when you clear the search criteria.  That will make debug easier.

Thanks for all the great work you are doing!

--Bill

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/e1881a6c-cc37-a554-db9e-f5e0e8abc55b%40makr.zone.

[Wolfgang Lienbacher]

Mark, you are a machine! 

[ma...@makr.zone]

done.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CALrF6L5NsLKC_-NKv%2BdHr4_jU0CfUPNy0e56hfzcnLiMiR6Ucw%40mail.gmail.com.

[ozzy_sv]

Hello mark

you did a great job, congratulations.

I emigrated for the test version and everything went smoothly except for one moment 

if motion controller type  is selected ConstantAcseleration or EuclidenAxisLimit  everything is fine.

when selecting other types of movements, the machine moves very slowly. What could be the problem ?  

понедельник, 2 ноября 2020 г. в 23:21:31 UTC+3, ma...@makr.zone:

[ozzy_sv]

I forgot to tell you, I have a  Smoothieware  controller, your firmware modified for 5 axes is the latest vesion

пятница, 15 января 2021 г. в 14:43:37 UTC+3, ozzy_sv:

[ma...@makr.zone]

First step: If you do Issues & Solutions, do you get any useful suggestions?

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

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/e323b3b3-de64-4a96-8403-fb40550cd2a9n%40googlegroups.com.

[ozzy_sv]

only with auto feeder controllers.

I solved all other problems with the main controller  

пятница, 15 января 2021 г. в 15:03:22 UTC+3, ma...@makr.zone:

[ma...@makr.zone]

Your machine.xml shows tiny jerk limits. They should either be zero or some large number like 50000mm/s³.

            <jerk-per-second-3 value="0.05" units="Millimeters"/>

Do you know how they came to be?

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/05125dfb-282a-42af-9603-545217c74403n%40googlegroups.com.

[ozzy_sv]

i copied this from smoothie config  :

junction_deviation                           0.002            # See http://smoothieware.org/motion-control#junction-deviation

I set the value to zero and the machine worked fine, thanks for pointing out where the error is 

What is the correct value there should be?  

and also, on additional controllers: is it possible to add a label to them that this is not a motion controller. because when converting the driver to asynchronous, your diagnostics starts looking for the firmware version, axes, and more ... in the end, the diagnostic program hangs completely and I have to return to the previously saved configuration archive.  

пятница, 15 января 2021 г. в 15:46:43 UTC+3, ma...@makr.zone:

[ma...@makr.zone]

> i copied this from smoothie config  :
> junction_deviation                           0.002            # See http://smoothieware.org/motion-control#junction-deviation

Ahhh, I see, junction deviation is not the same at all, but I know that some 3D printing guides and the Smoothieware doc unfortunately call it "max_jerk", which is completely wrong in physics terms.

> What is the correct value there should be? 

Normally, Smoothieware and most other controllers use a Constant Acceleration model, that is they instantly switch from zero acceleration to full acceleration. It is like sitting in an electric car and then slamming down the pedal instantly. In theory, this means you get an infinite amount of so-called jerk. 

Excessive jerk leads to vibrations of the machine, especially if the machine is not very well balanced and not very stiff (like my Liteplacer). Vibrations lead to long camera settling times and inaccurate picks and places, because not only the camera but also the nozzle tip swings around more than you might think.

https://makr.zone/wp-content/uploads/2020/04/Vibrations.gif

So the solution is to control and limit jerk.

1. If your machine is very stiff and well balanced you don't need it. Set to zero, done.
   
2. Otherwise switch the driver to Simulated3rdOrderControl to enable Jerk control on Smoothie.
   
3. OpenPnP then creates interpolated moves, to ramp up and down acceleration step-wise (this is not true/smooth 3rd order motion control, but a practical approximation).
   https://github.com/openpnp/openpnp/wiki/Motion-Planner#motion-interpolation
   
4. The effect can be visualized using fluids:
   https://makr.zone/wp-content/uploads/2020/04/SimulatedJerkControl.mp4
5. Like I said, we theoretically start from infinite jerk. Practically, you can start with something like 100'000mm/s³
6. Then use Camera Settling diagnostics to judge it.
   https://github.com/openpnp/openpnp/wiki/Camera-Settling
7. By changing the jerk limit up/down, find a setting where motion is still reasonably fast, but camera vibrations are clearly reduced.
   
8. For instance: on my Liteplacer (affordable maker style mechanical design) a setting of 25'000mm/s³ on Y and 40'000mm/s³ on X were found to be good.
9. For rotation I have 600'000mm/s³. This is much higher because of the unit scale i.e. for a PnP to rotate a nozzle 180 degrees is much "less physical" than to move a head 180 millimeters.
10. For the same reason, you should also have much larger feed-rate and acceleration limits on the rotation axes. It should really be a snap to rotate a part 180°. Limits may be about ten times higher than on linear axes. Most existing machines have a lot of potential there, because it was not possible to tune this before! Make sure to delete the feed-rate limit on the driver.
    https://github.com/openpnp/openpnp/wiki/Machine-Axes#kinematic-settings--rate-limits
    
11. Once you have tuned up the acceleration, you might need jerk control. You can use a your heaviest/largest part on the nozzle to test if you have rotation part slipping and set the jerk limit accordingly (only happens for weak pumps like the aquarium pump on the Liteplacer in combination with increased acceleration):
    https://makr.zone/wp-content/uploads/2020/04/PartSlipping.gif
    
12. Usually you don't have a jerk limit on Z.
    

See also:

https://groups.google.com/g/openpnp/c/bEVZvYoXO98/m/hl14FcspBwAJ

https://en.wikipedia.org/wiki/Jerk_%28physics%29

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/59817be7-7ab9-4449-b5da-e5a7d4884975n%40googlegroups.com.

[ozzy_sv]

thanks mark  for  the  your  detailed answer      
 

пятница, 15 января 2021 г. в 17:53:33 UTC+2, ma...@makr.zone:

[ozzy_sv]

I tune the machine  further and again the problem :

The actuator activation button does not work in the auto feeder setup menu and an error appears:  (actuator xxxx must not coordinate with machine when actuated outside mashine task)

if the actuator is activated by the top button "perform feed and pick" or manually activated the actuator in the menu on the left side, then everything works. 

Tell me how to fix this please. 

I made a short video    https://youtu.be/sQBU5HLd6HI

суббота, 16 января 2021 г. в 11:47:21 UTC+2, ozzy_sv:

[ozzy_sv]

I found what the problem is, I need to remove the selection of points from  items   "before action"  "after action" in section machine coordination  in the actuator properties section,  the error disappears 

but!

then the setting of the move selection before feed in the properties of the feeder ceases to affect the operation of the machine. (In this case, if the option is activated, the feeder first feeds the part and then the machine moves.)

This is not correct. !!  

суббота, 16 января 2021 г. в 14:42:06 UTC+3, ozzy_sv:

[ma...@makr.zone]

Hi ozzy

just to be sure: you are on the newest testing version, right?

If you just want the newest Advanced Motion Version, you can download the normal OpenPnP 1.0 develop version, the motion stuff has been merged there.

The testing version is brand new and out for the Camera light actuators built-in feature:

https://groups.google.com/g/openpnp/c/nOnmi3PyUbw/m/kfx0LRkACQAJ

I am of course happy if you help testing this!!!

I will therefore answer to your problem report in that thread over there. Just a moment...

https://groups.google.com/g/openpnp/c/nOnmi3PyUbw/m/LIZNtD7CCgAJ

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/da959427-ef62-4419-a804-dea9b7fe2c3cn%40googlegroups.com.

[ma...@makr.zone]

STOP: stupid typo...

OpenPnP 2.0 of course!

https://openpnp.org/downloads/

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/ee3f57c3-4d6f-83ab-e1f4-1bf786293a80%40makr.zone.

[Niclas Hedhman]

Today is a good day....

STOP: stupid typo...

Second "Smile of the day", after seeing this earlier today

[John Plocher]

So the solution is to control and limit jerk.

 A lesson for life in general ... :-)

  -John

[ma...@makr.zone]

8-D

--
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/j7fuo0e9VVM/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/CAKFrckr9J%3Dtb37aLKvJHbgj8HY-4Crusz4bAV22p5tPmtZ0vOw%40mail.gmail.com.