Some new changes in test branch

[Toby Dickenson]

Hi all,

Today I have merged a bundle of changes which are all oriented around
reducing the need for operator intervention while running a job:

* Retries of the full pick/vision/place cycle for parts that fail
vision check, or have some other problem during that cycle.
* Each feeder records a tally of whether its parts led to successful
placements, or have problems such as failing the vision check. The
default configuration is for a feeder to get disabled if it fails 3
out of 6 placements. This tally is shown in a new column on the
Feeders page.
* Feeders have a new Priority field (Low/Normal/High). It picks from
the highest priority if there are multiple feeders enabled for one
part. This is for using up the tail end of an old tape, and having the
machine automatically swap over to the new tape when empty.
* If there are multiple feeders (for one part) at the same priority it
will use the closest.

All those changes really only apply if using "defered" error
reporting. With "alert" error reporting openpnp will always show an
error message and require the operator to fix every problem.

Toby

[Jorropo]

Thanks I'll try on next's week job.

--
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/CAH35urfJ6fy17U2evGWeKgTKqTYtM%2BjTazcz%2BbtyX1bHxCdb3Q%40mail.gmail.com.

[Jan]

Hi Toby!
Many thanks for implementing this features. They have been
requested repeatedly over a very long time and will boost OpenPnP
usability and performance a lot!

I don't get that, could you please elaborate:- if I configure
pick/vision/place retry, aren't thus retries executed first before
throwing an error? And aren't thus errors that are covered by retries
accounted to the respective feeders disabling it after hitting the
trigger anyhow?
- the feeder priority shall work regardless of error handling setting
taking the feeder with higher priority first. correct?
- choosing the best feeder among multiple shall also work regardless of
the error handling setting. correct?
Sounds to me like all your new features will be beneficial for all
users.

Jan

[Toby Dickenson]

Hi Jan,

 

Toby wrote:

>>> All those changes really only apply if using "defered" error reporting

Jan wrote:

I don't get that, could you please elaborate:- if I configure
pick/vision/place retry, aren't thus retries executed first before
throwing an error?

"before throwing" may be ambiguous here, because all these retry loops involve throwing, catching, and swallowing exceptions.

Versions 2.4 and 2.5 have separate retry loops for feed, pick, "feed&pick" and vision. These retries are performed immediately. If the retry is successful then the exception is swallowed, the job continues, and there is no external sign of any error. There are no changes here.

If one of those steps is not successful (after all configured retries) then an exception reaches the top level of the Job Processor. There are two possible options:

a. For "Alert" error reporting mode, it records the exception in the error log, shows an error message, and expects the operator to fix the problem. Restarting the job will redo the step which caused the error, so this is effectively infinite retries with an operator in the loop. The operator has to fix the problem to make actual progress. On reaching the end of the job all placements are necessarily 100% complete. This behaviour is unchanged between version 2.4 and  2.5

b. For "Defer" error reporting mode, version 2.4 would clean the nozzle by discarding any parts and continue running the job. The job will finish with those placements unfulfilled. This is the logic which has changed; these are the errors which lead to a feeder getting disabled.

 

And aren't thus errors that are covered by retries
accounted to the respective feeders disabling it after hitting the
trigger anyhow?

No.

The default configuration is to disable a feeder if 3 out of 6 placements fail.

Suppose we have configured one pick retry; the first attempt fails then the second succeeds. This picked part then passes a vision check and goes on to complete a successful placement. This is a successful outcome and the feeder records this placement cycle as a success.

 

- the feeder priority shall work regardless of error handling setting
taking the feeder with higher priority first. correct?

Correct, it works. It will pick from the High priority feeder, and swap to the Normal priority feeder if the operator **manually** disables the High priority one.

It works, it is not particularly useful because the operator has always had easier ways to achieve the same thing.

- choosing the best feeder among multiple shall also work regardless of
the error handling setting. correct?

Yes! That is one feature that has equal usefulness in both "alert" and "deferred" error reporting modes.

Thank you for the questions.

Toby

[Jan]

Hi Toby!

On 16.10.2025 14:21, Toby Dickenson wrote:
> Jan wrote:
>
> I don't get that, could you please elaborate:- if I configure
> pick/vision/place retry, aren't thus retries executed first before
> throwing an error?
>
>
> "before throwing" may be ambiguous here, because all these retry loops
> involve throwing, catching, and swallowing exceptions.
>

Ok, so do you swallow *all* exceptions on retry or just some specific
ones? Does manual nozzle tip changing still works (haven't tried that
myself set)? It uses exceptions to interrupt the job.

[...]> And aren't thus errors that are covered by retries

> accounted to the respective feeders disabling it after hitting the
> trigger anyhow?
>
>
> No.
>
> The default configuration is to disable a feeder if 3 out of 6
> placements fail.
>
> Suppose we have configured one pick retry; the first attempt fails then
> the second succeeds. This picked part then passes a vision check and
> goes on to complete a successful placement. This is a successful outcome
> and the feeder records this placement cycle as a success.
>

Do I understand that correctly, that only the final result is counted?
I'd expect that also intermittent failures shall be counted. So in your
example we would record one failure and one success, disabling the
feeder after three such cycles...

> - the feeder priority shall work regardless of error handling setting
> taking the feeder with higher priority first. correct?
>
>
> Correct, it works. It will pick from the High priority feeder, and swap
> to the Normal priority feeder if the operator **manually** disables the
> High priority one.
>
> It works, it is not particularly useful because the operator has always
> had easier ways to achieve the same thing.
>

Hm... I thought I could make use of the fact, that some feeders disable
themself if they are empty. I also though that would be your primary use
case, consume parts from an almost empty feeder before switching over to
a brand new.
I personally like to get informed immediately if something goes wrong.
I prefer to fix it before it causes addition problems. Therefore I'd
love to allow passives to be retried, but I don't like that a passive
could get retried multiple times for the entire job. Suppose my default
cap is badly setup or its nozzle suffers from a defect and it needs
multiply retries per placement. With 500 per board, you might easily
waist half a spool... If you'd record each miss pick and disabled the
feeder at a certain limited, I would get informed quickly (with
"Alert"), and you would see at the end that some placements are still
open ("Defer").

Jan

[bert shivaan]

I am not following as close as I should most likely, but I have a question.

Does a feeder get disabled after a user defined number of consecutive fails?

In the past I sometimes had issues with every other part in a 0402 feeder. So it would get the board done but I may have wasted double parts. I never cared since a 0402 resistor is stupid cheep. I am hoping this is how the new stuff will work? 

--
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/4262ddb2-ffce-4bc0-bb34-825bf90da72c%40googlemail.com.

[Toby Dickenson]

Hi Jan,

 

Ok, so do you swallow *all* exceptions on retry or just some specific
ones?

There have been no changes to any exception handling, so I'm sure nozzle tip changing is ok

 

Do I understand that correctly, that only the final result is counted?

I think there is some misunderstanding here. It counts once per part.

* If a retry allows it to continue handling the same part and ultimately the part is placed correctly, then it counts as a success.

* If the cycle does not result in a successful placement (maybe it loses the part during feed, or maybe we have to drop a part in the discard bin) then it counts negatively.

* If a retry means feeding a second part, then it counts for a second time.

Hm... I thought I could make use of the fact, that some feeders disable
themself if they are empty.

Aha, yes, thats true. I had forgotten about those, thank you for the correction. Having feeders that disable themselves when empty makes feeder priority useful in Alert mode too.

         I personally like to get informed immediately if something goes wrong.

I prefer to fix it before it causes addition problems. Therefore I'd

love to allow passives to be retried but I don't like that a passive

could get retried multiple times for the entire job. Suppose my default
cap is badly setup or its nozzle suffers from a defect and it needs
multiply retries per placement. With 500 per board, you might easily
waist half a spool...

What you are describing here is a disadvantage of the 2.4 "defer" workflow which was the motivation for this feature. (See the first bullet point number 1 at https://github.com/openpnp/openpnp/issues/1891   The 2.5 "defer" no longer does this.

Maybe we need to improve the "alert" workflow for your usage. Consider the scenario of a nozzle reaching the alignment step but the nozzle is empty. Today "alert" shows a message box reporting the error and a single "OK" button. Maybe it would be better to show three buttons:

"Pause job and let me investigate" - this is the same as OK today

"Retry Vision step" - this is the same as pressing OK and restarting the job. Of course it is likely to show the same error message again if you have not fixed the underlying problem.

"Discard and try again with a new part" - this is the same as what "defer" will do silently and automatically.

Toby

[vespaman]

Hi Toby,

I have my machine setup as Jan, I believe; I have alert on all components - I want to fix my problems when they happen.

Maybe we need to improve the "alert" workflow for your usage. Consider the scenario of a nozzle reaching the alignment step but the nozzle is empty. Today "alert" shows a message box reporting the error and a single "OK" button. Maybe it would be better to show three buttons:

"Pause job and let me investigate" - this is the same as OK today

"Retry Vision step" - this is the same as pressing OK and restarting the job. Of course it is likely to show the same error message again if you have not fixed the underlying problem.

"Discard and try again with a new part" - this is the same as what "defer" will do silently and automatically.

So "Discard and try again with a new part" is discarding any part, then pick a new and continues? 

That is exactly how I would like this to be, and I have seen many requests for this feature.

Would these three options also get keyboard short cuts? 

 

Another somewhat related wish... If we run out of a component, and get the alert - there's no way to continue - now we cannot set defer on the panel, the only way out is to stop the job. So in fact discarding any parts on the other nozzle(s). Maybe this is not in the same area of the code, but it is annoying, since these parts tends to be the more expensive ones. And whatever you want to do with your last precious components is absolutely not to discard them! I understand that maybe the job planning needs to be started all over, if the component has to be left out, but if if would be possible to at least continue with the good ones on the other nozzle(s).

 - Micael

[Toby Dickenson]

I have my machine setup as Jan, I believe; I have alert on all components - I want to fix my problems when they happen.

You guys have nothing better to do than nurse your machine all day?

 

Maybe we need to improve the "alert" workflow for your usage. Consider the scenario of a nozzle reaching the alignment step but the nozzle is empty. Today "alert" shows a message box reporting the error and a single "OK" button. Maybe it would be better to show three buttons:

"Pause job and let me investigate" - this is the same as OK today

"Retry Vision step" - this is the same as pressing OK and restarting the job. Of course it is likely to show the same error message again if you have not fixed the underlying problem.

"Discard and try again with a new part" - this is the same as what "defer" will do silently and automatically.

So "Discard and try again with a new part" is discarding any part, then pick a new and continues? 

Yes, but interleaved with other tasks.

On a machine with 2 nozzles it will complete the placement on the other nozzle before discarding.

The current implementation is that the retry is not necessarily immediate. It puts the placement back into the pool of pending placements, allowing the job planner optimiser to do the retry in its own time. It might select it next, or it might do something else first. I'm not yet sure whether I like that characteristic. It has some advantages.... see below.

Another somewhat related wish... If we run out of a component, and get the alert - there's no way to continue - now we cannot set defer on the panel, the only way out is to stop the job. So in fact discarding any parts on the other nozzle(s). Maybe this is not in the same area of the code, but it is annoying, since these parts tends to be the more expensive ones. And whatever you want to do with your last precious components is absolutely not to discard them! I understand that maybe the job planning needs to be started all over, if the component has to be left out, but if if would be possible to at least continue with the good ones on the other nozzle(s).

What you are requesting is exactly what you get today with "defer". Or with the suggested "discard and try again with a new part". The job planner optimiser prioritises parts with feeders over parts that do not. So the machine will carry on running, placing what it can, and will only show a "no feeders enabled" error message when it has placed everything that can be.

My current machine setup is:

* "defer" and discard into the large bin for passives. The actual quantity that gets discarded is a fraction of what we saw in version 2.4

* "defer" and discard into the small bin for most ICs. I sometimes have to tweezer a couple of parts back into the tape at the end of a job. "skip next feed" takes care of this.

* "alert" for the most fragile or the tiniest parts where I would rather interrupt the job than have to handle it with tweezers.

Toby

[vespaman]

I have my machine setup as Jan, I believe; I have alert on all components - I want to fix my problems when they happen.

You guys have nothing better to do than nurse your machine all day?

For me, I can run maybe 10 panels on a day, say each panel is 10 boards. 

So I do;

Morning paste the 10 panels,

Put them one after the other into the pnp, then let it run until after lunch, a quick optical inspection after each panel. put them into a rack.

While machine is running, I clean the screen plate, and tidy stuff up. Read some mail, have coffe etc etc.

Before lunch, I start the oven, it takes about 45 minutes for it to warm up.
After lunch I put the panels in that has been done (I know they are good, since I have alert).

Then for each remaining panel that is ready, I put onto the oven.

I don't want to have a step where I would manually add any missing component out of the batch of panels - I don't really want to mess with the panels at all, once done. I mainly nudge a component here or there.

And, I rarely have any alerts, apart from maybe the first panel, so I'm not really babysitting :-) And anyway, the machine has to have an empty panel every now and then, so it's not like I can leave anyways.

 

So "Discard and try again with a new part" is discarding any part, then pick a new and continues? 

Yes, but interleaved with other tasks.

On a machine with 2 nozzles it will complete the placement on the other nozzle before discarding.

Yes, ok. This is way better than now, for sure. Even if the dangling component issue would worry me. I'd probably un-dangle (discard) it myself before pressing "Discard and try again..".

 

The current implementation is that the retry is not necessarily immediate. It puts the placement back into the pool of pending placements, allowing the job planner optimiser to do the retry in its own time. It might select it next, or it might do something else first. I'm not yet sure whether I like that characteristic. It has some advantages.... see below.

Another somewhat related wish... If we run out of a component, and get the alert - there's no way to continue - now we cannot set defer on the panel, the only way out is to stop the job. So in fact discarding any parts on the other nozzle(s). Maybe this is not in the same area of the code, but it is annoying, since these parts tends to be the more expensive ones. And whatever you want to do with your last precious components is absolutely not to discard them! I understand that maybe the job planning needs to be started all over, if the component has to be left out, but if if would be possible to at least continue with the good ones on the other nozzle(s).

What you are requesting is exactly what you get today with "defer". Or with the suggested "discard and try again with a new part". The job planner optimiser prioritises parts with feeders over parts that do not. So the machine will carry on running, placing what it can, and will only show a "no feeders enabled" error message when it has placed everything that can be.

Yes, I know defer has some advantages, but, then I'd be left with a panel that might need manual component placement, I have to document that this particular panel need this, and perhaps which board/boards on the panel. Then I need to find the missing components put them onto the PCB. An alert intervention means that I go to the machine and click some buttons and it continues. Takes much less time, and no risk of smearing paste accidentally etc.

This is how I have done it so far; cancel the job (loose remaining to discard), set the component to defer or disable it, then restart the job. Then find the last part and put it on manually. Not the end of the world, but not super-duper.

 

My current machine setup is:

* "defer" and discard into the large bin for passives. The actual quantity that gets discarded is a fraction of what we saw in version 2.4

* "defer" and discard into the small bin for most ICs. I sometimes have to tweezer a couple of parts back into the tape at the end of a job. "skip next feed" takes care of this.

* "alert" for the most fragile or the tiniest parts where I would rather interrupt the job than have to handle it with tweezers.

Yes, I like the concept of multiple discard bins! I might take after that. Also, I'll move my primary discard next to the camera pit - now it has to travel way too far away.

/ Nurse Micael

[bert shivaan]

Toby,

Does openPNP give a report of unplaced parts and allow to complete the job so that none would need to be placed manually if missed on the first round?

--
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/25a57980-752f-4ec6-a52c-294b9ed39c42n%40googlegroups.com.

[vespaman]

OK, so maybe that is what you deferring-guys are doing? Restart the boards until they are fully equipped?

That is also a way, of course. (But I still prefer Alert)

/ Nurse Micael

[Toby Dickenson]

The 2.4 "defer" experience is that it simultaneously does too many retries, and too few. Our typical boards have 500 small passive parts. Say 2 or 3 of those are edge picks, so the job gets to the end with those 2 or 3 missing. You get a report in the error log at the end of the job, and you need to restart the job to get those finished.

Or maybe you have configured part size checking, and this new reel is slightly different to your previous. Then you get 400 parts placed, 100 placements listed in that error log, and 100 parts dumped in the discard bin. Of course these are not technically "retries"; these are 100 separate placements failing once each.

Our 2.5 "defer" experience is that the quantity of discards is reduced. Most boards end at 100% complete. We only need to restart the job if a feeder ran out or had some other problem. We have a script that sends a google chat message when a feeder gets disabled, so we can often fix a feeder problem while the machine is working on other parts and get the feeder back into service without interruption.

To view this discussion visit https://groups.google.com/d/msgid/openpnp/8433a87a-9f48-41cd-8054-327e7f8bef01n%40googlegroups.com.

[Jan]

Hi Toby!

On 17.10.2025 17:11, Toby Dickenson wrote:
> Hi Jan,
>
> Ok, so do you swallow *all* exceptions on retry or just some specific
> ones?
>
>
> There have been no changes to any exception handling, so I'm sure nozzle
> tip changing is ok
>

You said earlier "all these retry loops involve throwing, catching, and
swallowing exceptions." As manual nozzle tip changing also generates
exceptions I just wonted to express my concern that thus shall not be
swallowed by a retry counter. I'm confident you took that into account!

[...]> * If a retry means feeding a second part, then it counts for a
second time.
>
That's how I think it shall be.

> Hm... I thought I could make use of the fact, that some feeders disable
> themself if they are empty.
>
>
> Aha, yes, thats true. I had forgotten about those, thank you for the
> correction. Having feeders that disable themselves when empty makes
> feeder priority useful in Alert mode too.
>

That reminds me, that we (I!) wont all feeders to use a common Feed
Count handling with the option to extend it to a common maximum (as some
feeders already have). That we could easily have multiple feeders for
the same part prepared and ready for use.

>          I personally like to get informed immediately if something
> goes wrong.
>
> I prefer to fix it before it causes addition problems. Therefore I'd
> love to allow passives to be retried but I don't like that a passive
> could get retried multiple times for the entire job. Suppose my default
> cap is badly setup or its nozzle suffers from a defect and it needs
> multiply retries per placement. With 500 per board, you might easily
> waist half a spool...
>

[...]> Maybe we need to improve the "alert" workflow for your usage.

Consider
> the scenario of a nozzle reaching the alignment step but the nozzle is
> empty. Today "alert" shows a message box reporting the error and a
> single "OK" button. Maybe it would be better to show three buttons:
> "Pause job and let me investigate" - this is the same as OK today
> "Retry Vision step" - this is the same as pressing OK and restarting the
> job. Of course it is likely to show the same error message again if you
> have not fixed the underlying problem.
> "Discard and try again with a new part" - this is the same as what
> "defer" will do silently and automatically.
>

Yes, thus options are likely helpful and I think others have requested
them too and with the exception chaining patch we now have they can be
implemented easily today (Manual Nozzle tip changing uses the same
technique). Maybe it would be advantageous to add a new exception class
that adds the three buttons you mentioned...
However^2: due to your new error handling facility in the feeder I will
likely try to switch some of the passives to defer mode. We'll see how
many parts are getting wasted...

Jan

[Jan]

Hi Toby!

On 17.10.2025 19:45, Toby Dickenson wrote:
[...]> Our 2.5 "defer" experience is that the quantity of discards is

reduced.
> Most boards end at 100% complete. We only need to restart the job if a
> feeder ran out or had some other problem. We have a script that sends a
> google chat message when a feeder gets disabled, so we can often fix a
> feeder problem while the machine is working on other parts and get the
> feeder back into service without interruption.
>

That sounds like an opportunity for more optimizations: if Feed Count is
turned into a generic property for all feeders and if a feeder can
provide a Max Feed Count property (like most can) one could extend
preFlights prepFeeders() method to alert if a feeder will run out of
parts within the job. With an "Accepted" and "Oh, I'll fix that first"
button the user has to decide how to continue.

Jan

[Jan]

Hi Toby!

On 17.10.2025 18:17, Toby Dickenson wrote:
[...]> What you are requesting is exactly what you get today with

"defer". Or
> with the suggested "discard and try again with a new part". The job
> planner optimiser prioritises parts with feeders over parts that do not.
> So the machine will carry on running, placing what it can, and will only
> show a "no feeders enabled" error message when it has placed everything
> that can be.
>

How is an empty feeder, that can not disable itself (like
ReferencePushPullFeeder which has no Max Feed Count property) handled?
It's feed/pick/align/discard until the 3/6 errors ration is hit?

> My current machine setup is:
> * "defer" and discard into the large bin for passives. The actual
> quantity that gets discarded is a fraction of what we saw in version 2.4
> * "defer" and discard into the small bin for most ICs. I sometimes have
> to tweezer a couple of parts back into the tape at the end of a job.
> "skip next feed" takes care of this.
> * "alert" for the most fragile or the tiniest parts where I would rather
> interrupt the job than have to handle it with tweezers.
>

That's an interesting setup. Sounds like it covers problems with
passives by just "throwing money on them", which is probably the best
you can due if they cost like 5 bugs/10k.
Concerning the discard bins: wouldn't it be a very easy task to just
duplicate the bin location in the machine setup wizard and add a
drop-down on the parts setup wizard? Then one would only need to take
the parts discard location rather then the default. Shall be easier to
maintain then the list of parts in your discard script...

Jan

[vespaman]

Hi Jan & Toby,

måndag 20 oktober 2025 kl. 12:56:58 UTC+2 skrev Jan:

Concerning the discard bins: wouldn't it be a very easy task to just
duplicate the bin location in the machine setup wizard and add a
drop-down on the parts setup wizard? Then one would only need to take
the parts discard location rather then the default. Shall be easier to
maintain then the list of parts in your discard script...

 

Not knowing how hard this would be to implement, but that would be a very nice feature.

It would make for a much more flexible setup if dealing with a lot of different components.

- Micael

[Toby Dickenson]

> with the suggested "discard and try again with a new part". The job
> planner optimiser prioritises parts with feeders over parts that do not.
> So the machine will carry on running, placing what it can, and will only
> show a "no feeders enabled" error message when it has placed everything
> that can be.
>
How is an empty feeder, that can not disable itself (like
ReferencePushPullFeeder which has no Max Feed Count property) handled?
It's feed/pick/align/discard until the 3/6 errors ration is hit?

Yes, exactly that.

 

        Concerning the discard bins: wouldn't it be a very easy task to just
duplicate the bin location in the machine setup wizard and add a
drop-down on the parts setup wizard? Then one would only need to take
the parts discard location rather then the default.

Yes, that is the plan eventually but the script implementation is a good prototype. It lets us see if two discard bins is enough, or if someone finds a use for three. There was a request a while ago for having separate discard bins for each nozzle, to avoid wasting precious space in the middle of the machine by putting bins at the extremities where each bin can only be reached by one nozzle. So maybe we need part/bin and nozzle/bin compatibility matrix in the gui. Lets see what people find useful.

 

Shall be easier to
maintain then the list of parts in your discard script...

I hope for most users it might be:

if part.getId().startswith('R-') or part.getId().startswith('C-'):

[Jan]

Hi Toby! Hi Micael!
I just pushed PR #1908 which contains a basic implementation of four
discard bins. It might serve as a starting point or concept for thus
that might need it and are willing to finish it up.

Jan

> --
> 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/

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

[vespaman]

Hi Jan, 

That was quick!

I like this more and more, didn't know I needed it before :-) :-) 

Passives can go to a smaller/deeper bin and then costly stuff in its own, and finally, the easily recyclables (large components like push buttons etc) can have its own also deep area.

I'll do a drawer style recycle station just next to my camera now.

Micael