How to speed-up OpenPnP

[Kim Lindberg]

Hi all, hope someone can help.
I have been working on some production PCBs the last few days, and would like to optimize my machine for better speed.
I have tweaked acceleration and max speed for all axes, but it seems like the machine is waiting alot between actions.
Is it possible to have the machine move simultaneously when a feeder is actuating? Right now, the machine is actuating the feeder, waits until it is done feeding and the starts the move.

I'm running on a modyfied Charmhigh CHMT-528 with a Smoothieboard controller by Arthur Wolf. Feeders are pheumatic Yamaha CL-feeders.

Running OpenPnP develop 2023-03-15_00-30-21.460d8aa

[Mike Menci]

Hi Kim 

Can you send a screen shot of your feeders OpenPNP settings? 

[Kim Lindberg]

Sure. Is this what you need?

[Mike Menci]

Check " Move before feed" and test few feeders with slow PnP speed - 

Does it do what you wanted now ? 

[Kim Lindberg]

I already tried this option. The only thing that changes is that instead of waiting before moving to the feeder, it moves and then waits for the feeder the same amount of time.

It seems like OpenPnP is not able to do both movement and feeder actuaton simultaneously. Is this just a setting or is it not implemeted?

[Mike Menci]

Is in this video the same as you have it? https://www.youtube.com/watch?v=nBnfRhdnPks

[Mike Menci]

Feeding on Yamaha should go match faster ; see here ; https://www.youtube.com/watch?v=hi8R8TRDwfU

[Mike Menci]

See this ; 

[Kim Lindberg]

That looks a lo t like how my machine is runnig, except I only have one single feed action. The video show two actions.

[Kim Lindberg]

This speed would be VERY much appreciated. That is how I'd expect thing to work :)
How is this obtained?

[Mike Menci]

Kim - please explain how you trigger the air pressure valves on feeders - do you have a separate controller and which valves you use ?

[Kim Lindberg]

I use a custom controller running on an Arduino to trigger the stock valve controller. The valves are stock on the machine (CHMT-528). When the machine was running the original Charmhigh hardware and firmware, the speed was way higher. More like the speed shown in the videos you sent.
Could it be due to the feeder controller not answering to a feed command, and the maybe a timeout happens??
Can this be debugged and displayed in the log?

[M. Mencinger]

Run a Job and send a Log in Trace level - to see 

--
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/f4f21034-b8b2-4958-bd35-9437de41361dn%40googlegroups.com.

--

Mike

"--

 **************************************************************************************************************

This e-mail may be confidential and it may also be legally privileged. If you are not the addressee you may not copy, forward, disclose or use any part of it. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return e-mail. Internet communications cannot be guaranteed to be timely, secure, error or virus-free. The sender does not accept liability for any errors or omissions. 

 SAVE THE NATURE - SAVE PAPER - THINK BEFORE YOU PRINT!  "

[Kim Lindberg]

I did a small job with only 10 resistors. Video and TRACE-level log attached.

[mark maker]

You have to combine the Move before feed with the feeder actuator Before Actuation coordination disabled. Then they run in parallel, provided you have the drivers set up asynchronously, as recommended by Issues & Solutions in the Advanced milestone.

See this thread (and linked stuff):

https://groups.google.com/g/openpnp/c/7EstsvVsCqU/m/iLI12e-kBgAJ

_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/d07dccf6-d8e4-435f-a51d-8f61331da881n%40googlegroups.com.

[Kim Lindberg]

I just tried your suggestions, enabling Move before feed and disabling Before Actuation on the driver. It does give a small speed increase but not as much ascould be expected.
I did the sam job with the same 10 resistors, giving aprrox. 700 CPH instead of the previous 540 CPH.

Looking at the log it seems like it take approx. two seconds to pick a part from the feeder, making the head wait although the feeder is actuated :(

I also noticed that the bottom camera is very slow :( what am I missing??? I really hope I can get speed up on this machine.

[mark maker]

Hi Kim,

(numbered for easy referencing)

1. "700 CPH instead of the previous 540 CPH" that's not nothing. 😉
2. You have a 100ms dwell time (G4) in the vacuum read G-code. Get rid of it. Smoothie already does the settling necessary for the ADC internally and caches the last read value to immediately return.
   
3. And where it is really necessary to settle for a transitioning vacuum level, OpenPnP has means to wait itself (the "Dwell" or better the "Establish" settings).
   
4. While you're at it, you may want to increase the ADC sampling frequency in Smoothie.
5. You have "Part Off Check" Before Pick enabled. Get rid of it. IMHO that's a non-sensical function, as it errors out the wrong placement (namely the next) .
   
6. Note: the Before Pick check also spoils the parallel feed operation, because it actuates the valve, which does not allows uncoordinated actuation.
   
7. I cannot see the two seconds at the feeder you mention. At what log time do you see that?
8. Your camera is as fast as can be expected (I wish mine would settle that fast).
   
9. The time wasted come from the G6 100ms dwell I mentioned in point 2.
   

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/3ed54f1e-1484-4b92-949b-8970671c2f01n%40googlegroups.com.

[Kim Lindberg]

1. Tried your suggestions and got to about 800 CPH 
2. Removed dwell time on both nozzle and head
3. Please explain? not sure where to find this.
4. Not sure where to find this setting. I can't seem to find it in Smoothie config.txt ?
5. Removed Part Off Check Before Pick.
6. Noted.
7. I filtered the log for COM4 (FeedUino controller) It seems like there is approx two seconds from advance to retract?   
8. Maybe its not settling time that is the problem with the camera. Could be something else. Sometimes it takes a couple of seconds to align the part. if this could be optimized, speed would increase significantly.
9. noted.

I've attached a new log with the settings changed as mentioned above.

[mark maker]

Re 2. No, you need to leave the dwell times intact, they are used as timeouts when using "Establish level", see next point.
--> What I really meant is the G-code. You need to go to the GcodeDriver and remove the G4 line there. I still see those 100ms G4 dwells in the new log.

Re 3. See the Wiki: https://github.com/openpnp/openpnp/wiki/Setup-and-Calibration_Vacuum-Sensing#dwell-times--establish-level

Re 4. Look for the readings_per_second documentation here: http://smoothieware.org/temperaturecontrol. On my machine I'm using 320 (per second). https://makr.zone/vacuum-sensor/192/

Re 7. I see the second feed & pick at 2023-08-18 12:23:20.210 in your new log (needed no X/Y motion, so that's the minimum time), where this is a mere ~700ms apart. And 200ms of those are from the superfluous G4 (see point 2). So you have ~500ms left for feed and pick including Z motion (down and up) and vacuum establishing and all (subject to point 2). You consider this bad?

Re 8. I see ~110ms computer vision time, which could be better, but hardly explains your two seconds. Could you point me to such an example in the log?

Send the machine.xml, maybe I'll find something else.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/4f59be1a-397c-4916-a1a3-a2a8a585ffc1n%40googlegroups.com.

[Kim Lindberg]

2. I found the G4 in the Nozzle Vacuum sense and removed this. Put back the 100ms in the nozzle dwell.

3. Noted

4. Found this option. My config is set to 500 readings per second.

7. if parts could be placed at this speed (500ms / part) I would be VERY happy. This would equate to ~7200 CPH :) Something else must be slowing down the overall speed. After tweeking axis speeds and acc. including removal of the G4 in VAC sense, it's now improved to approx 840 CPH. I still see a substantial amount of time over the bottom camera (video attached). Where does this come from? Camera settling ans computer vision is pretty fast?

8. The two seconds mentioned before was between feeder advance and feeder retract. Not sure how to interpret this though.

new log file, Machine.xml and smoothie.config attached.

[mark maker]

Re 7: > This would equate to ~7200 CPH :)

I specifically sought out this case because the nozzle was already positioned above the feeder pick location. So there was no X/Y motion involved. This shows us the minimum time for just feed & pick. But obviously is not realistic for the real case where the nozzle must first move to the feeder (at least when it takes longer than the parallel feed). And as you surely know 😁, one can't derive CPH from just feed & pick, the move to the camera, the alignment, and then the move to the PCB, and the placement come in addition!

Re 8: How did you generate this log? Why is there no pick in between?

Re 9:  The main problem is the way you have limited the rotation N1/N2 axis articulation to ±180°. If the placement orientation happens to be near 180° chances are high that the Alignment will find a small rotation offset, and then send the nozzle all the way around from say -179° to +175° i.e. a full 360° pirouette (this is what happens in log at 2023-08-20 11:20:54.157).

• If your tubes can rotate freely (decoupler), enable Wrap Around. Then it will never do any pirouetting.
  
• If your tubes are fixed, set the Rotation Mode on the nozzle to LimitedArticulation:
  https://github.com/openpnp/openpnp/wiki/Nozzle-Rotation-Mode#rotation-modes
  
• Alternatively, you could at least give the rotation axes more freedom, i.e. Enable the Soft Limits and set them to -200° to 200° or similar, so what I described above will not happen. You are then free to continue using the MinimalRotation rotation mode you currently have set. Although please read in the Wiki what this mode is intended for, it is a rather special use case.
  

Regardless of the above, your rotation axes are set to a very low acceleration limit at only 2000°/s². Remember, these are degrees, not millimeters! Currently, your rotation axis takes 840ms just to rotate 360°. This will also slow down placement as we can see in the video.

Further optimization:

Consider increasing the angular offsets to 10° and decreasing the linear offsets to 1mm. These are the current "factory" defaults. Read the tooltips to understand. Also see the Wiki:

https://github.com/openpnp/openpnp/wiki/Bottom-Vision#global-configuration

Once this is fluid, you certainly want to increase your feedrates on all axes. Your machine looks solid with linear rails and all. Even my Liteplacer with cheap DIY components has eight times the feed-rates! Be sure to also allow these rates on the Smoothie side.

Then also carefully increase the acceleration limits. But have an eye on camera settling. Report back when this starts acting up. Again, be sure to also allow these rates on the Smoothie side.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/03e39d57-3657-4444-88e5-239eef1de554n%40googlegroups.com.

[mark maker]

Oops, made a mistake interpreting the feedrates on the axes (confused "per second" with "per minute"). Your axis feedrates are actually gigantic (300 m/min).

But they are limited on the Smoothie side. Check your config.txt I recommend setting the "absolute maximum" limits there (just before the machine really starts having problems), then tune them down to reasonable values in OpenPnP.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/c3bed188-6468-7ba6-f131-27b9623f95b6%40makr.zone.

[Mike Menci]

@ Mark - I was checking my PnP Machine setup for axis and

how-come I do not see here option - Smoothie ? 

[Kim Lindberg]

7 RE: I know this 7200 PCH is not realistic :)

8 RE: this log is filtered from the oiriginal log within OpenPnP only showing the COM4 (FeedUino) stuff.

9 RE: I changed the Rotation mode to LimitArticulation as suggested and raised acceleration to 5000 °/s²

I also changed Bottom Vision as you suggested to 10 ° and 1mm offsets. I increased overall axis speeds and acceleration, making sure Smoothie values are larger than the ones in OpenPnP.

These optimizations gave approx 1200 CPH which is double from the original and pretty acceptable for now :)

Thanks a lot for your suggestions. Now I need to firgure out why backlash comp. doesn't work. Will create a new thred for this though :)
Attached is the latest log and a small video of the progress.

[mark maker]

> how-come I do not see here option - Smoothie ?

Do you mean the Driver selection?

You can name the driver as you like. Just go to the driver an set the Name, and press Apply.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/ad0a2a6c-2d2b-4434-8619-d26afed7e083n%40googlegroups.com.

[mark maker]

Yes, that's more like it. 😎 Nice machine!

And placement is accurate, right?

Next steps:

Home the machine, go to Issues & Solutions and enable Include Solved.

Reopen these:

Why? Your Z motion still has potential to be optimized. 😁

Next:

Go to Issues & Solutions and enable Include Dismissed and Reopen these:

Fix them. Why? Look here:

https://github.com/openpnp/openpnp/wiki/Bottom-Vision#nozzle-tip-configuration

https://github.com/openpnp/openpnp/wiki/Camera-White-Balance

https://github.com/openpnp/openpnp/wiki/Nozzle-Tip-Background-Calibration

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/b0b56500-0fc6-48c9-bb6e-f4e0a9aaf9c2n%40googlegroups.com.

[Mike Menci]

I deleted my topic here and opened new  thread - sorry for jumping inhere and messing your lines.. 

Mike

[Kim Lindberg]

Thanks Mike, much easier kepping to the same topic :)

[grover]

With regards to point 7, where is "Part Off Check" in the menu system?

[grover]

Can I ask where the Move before feed and Before Actuation are that you're referring to?  I see them pop up in multiple places.  I see Move before feed under the Feeders tab> Configuration, and I see Before Actuation appear under every actuator for both head and general actuators.  Which instances are relevant?  

[mark maker]

You can search the OpenPnP Wiki for those words:

https://github.com/search?q=repo%3Aopenpnp%2Fopenpnp+Part+Off+Check&type=wikis

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/e17f091f-0ec2-436c-a062-63219a7ed993n%40googlegroups.com.

[mark maker]

This time the Wiki search is less clear  😉

https://github.com/search?q=repo%3Aopenpnp%2Fopenpnp++Move+before+feed+and+Before+Actuation&type=wikis

I guess the 3rd hit is what you're looking for, section "Actuator Machine Coordination":

https://github.com/openpnp/openpnp/wiki/Motion-Planner#actuator-machine-coordination

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/a0bb0f8b-f734-4f9d-95e6-b8bdada7828bn%40googlegroups.com.