Component dropped just after alignment (OpenPnP-test)

[vespaman]

Hi all,

I'm having problems related to vacuum valve being closed (vacuum off) too early.

This happens on current test version, so I wonder if there's any kind of change that I need to do on my machine, that I have missed?

The problem only seems to happen when I don't use vacuum check on placement, which I have on some of my nozzle tips, which is why I haven't seen this during my testings this fall. But yesterday, I was going to do a full job, and the components started to drop off before reaching the place destination. 

I thought this was a consequence of my dual bottom vision, so I started to test more but could not find any thing on my part.

This morning I therefore built the clean test version, and saw the exact same behavior.

I didn't see this problem with the spring edition of 'test', but during summer I started to use vacuum detection when placing, so maybe I did something wrong in my setup? I just can't see if. 

One clue, is that I now see "Scripting.on Job.Placement.BeforeAssembly" in my logs. I never had them before, so that indicates some change that might be related(?).

I could, of course enable vacuum on place on all nozzle tips, now that I found this to be the reason, and I suppose I should anyway. But I find it a bit mysterious...

It is very obvious when looking in the log. (log is populating one component). Just after scripting BeforePlace, vacuum is off, but the machine isn't even at the placement destination yet, so it's like there's a step missed before 'BeforePlace'?

2025-11-18 10:23:49.708 Scripting TRACE: Scripting.on Nozzle.BeforePlace
2025-11-18 10:23:49.708 ReferenceActuator DEBUG: AVAC1.actuate(false)

 - Micael

[Toby Dickenson]

I havent checked your log, but it sounds like you are missing machine coordination on the vacuum actuator. It is switching the vacuum as soon as openpnp thinks about visiting the placement location, rather than waiting for the machine to actually get there.

This would be the desired behaviour, for example, on a light. But not a vacuum valve.

--
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 visit https://groups.google.com/d/msgid/openpnp/f267a87a-8e1e-4e03-81da-e3506937ed75n%40googlegroups.com.

[vespaman]

Well, I can honestly say that I have sometimes struggled to understand the coordination stuff. But why would it work if I enable vacuum sensing in this case? 

The setup looks like this (and this is also what I had half a year ago, before I started with vacuum sensing during place);

[Toby Dickenson]

Well that looks correct. "Before Actuation: WaitForStillstand" means that openpnp waits for the machine to finish moving (and any axes on a different controller to finish moving) before switching the vacuum valve on or off.

--
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 visit https://groups.google.com/d/msgid/openpnp/4c505bf2-d758-4f19-b2c8-8ac620518b61n%40googlegroups.com.

[Jan]

Hi Micael!
WaitForStillstand is the default (conservative) setting. It means that
OpenPnP instructs the/all controllers to finish/drain its/their motion
queue/s and report back before it instructs the controller to close the
valve. You could switch to CommandStillstand in which case OpenPnP would
not wait for the controller to confirm. This provides a better jitter
tolerance and is hence slightly faster.
If you enable vacuum part-off detection, the coordination of the vacuum
sensor is evaluated. This is usually WaitForStillstand as everything
else would not make sense.
According to your logs, I can't see a "M400" before "M801"
(AVAC1.actuate(false)). This indicates, that machine coordination is not
enabled.

Jan

On 18.11.2025 12:12, Toby Dickenson wrote:
> Well that looks correct. "Before Actuation: WaitForStillstand" means
> that openpnp waits for the machine to finish moving (and any axes on a
> different controller to finish moving) before switching the vacuum valve
> on or off.
>
> On Tue, 18 Nov 2025 at 10:59, vespaman <micael....@gmail.com
> <mailto:micael....@gmail.com>> wrote:
>
> Well, I can honestly say that I have sometimes struggled to
> understand the coordination stuff. But why would it work if I enable
> vacuum sensing in this case?
> The setup looks like this (and this is also what I had half a year
> ago, before I started with vacuum sensing during place);
>

> Screenshot_20251118_114608.png
>
>
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "OpenPnP" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to openpnp+u...@googlegroups.com

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

> To view this discussion visit https://groups.google.com/d/msgid/
> openpnp/4c505bf2-d758-4f19-b2c8-8ac620518b61n%40googlegroups.com

> <https://groups.google.com/d/msgid/openpnp/4c505bf2-d758-4f19-
> b2c8-8ac620518b61n%40googlegroups.com?
> utm_medium=email&utm_source=footer>.

>
> --
> You received this message because you are subscribed to the Google
> Groups "OpenPnP" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to openpnp+u...@googlegroups.com

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

> To view this discussion visit https://groups.google.com/d/msgid/openpnp/

> CAH35urdbTy0GOmyfbhZsOh4rw8oO_nacqw6r%3DMP5d%3DDZRgsMoA%40mail.gmail.com
> <https://groups.google.com/d/msgid/openpnp/
> CAH35urdbTy0GOmyfbhZsOh4rw8oO_nacqw6r%3DMP5d%3DDZRgsMoA%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[vespaman]

Hi Jan,

 

WaitForStillstand is the default (conservative) setting. It means that
OpenPnP instructs the/all controllers to finish/drain its/their motion
queue/s and report back before it instructs the controller to close the
valve. You could switch to CommandStillstand in which case OpenPnP would
not wait for the controller to confirm. This provides a better jitter
tolerance and is hence slightly faster.

 

I should probably print this explanation out and put on the wall in front of me. I  always forget which is which. :-)

If you enable vacuum part-off detection, the coordination of the vacuum
sensor is evaluated. This is usually WaitForStillstand as everything
else would not make sense.

! Stupid me, I looked at the sensor AVACS1 rather than the valve AVAC1!

Thanks for pointing this out!

 

According to your logs, I can't see a "M400" before "M801"
(AVAC1.actuate(false)). This indicates, that machine coordination is not
enabled.

That must be the case! Strangely it had the same settings during spring. Probably I am not remembering exactly what I did back then.

 - Micael

[Jan]

Hi Micael!

On 18.11.2025 13:06, vespaman wrote:
> Hi Jan,
>
> WaitForStillstand is the default (conservative) setting. It means that
> OpenPnP instructs the/all controllers to finish/drain its/their motion
> queue/s and report back before it instructs the controller to close the
> valve. You could switch to CommandStillstand in which case OpenPnP
> would
> not wait for the controller to confirm. This provides a better jitter
> tolerance and is hence slightly faster.
>
> I should probably print this explanation out and put on the wall in
> front of me. I  always forget which is which. :-)
>

It shall be in the Wiki (and expert details only)...

[...]>

> That must be the case! Strangely it had the same settings during spring.
> Probably I am not remembering exactly what I did back then.
>

You may consider putting the config files into a version control system.
This allows to track changes (thanks to the verbose XML style).
Unfortunately feeder settings and parameters are also stored in
machine.xml, which causes each feed operation to generate a difference.
But you can still see the relevant parts as changes in feed count are
easy to skip over.

Jan