Added possibility to disable ContactProbeNozzle actuator temporarily..

[gitchrisfr]

to avoid probing with every pick and place command by scripting.

Description

A ContactProbeNozzle probes with every pick an place command. If one will avoid these we can now set a flag by script. If not set the machine behaves as before.

Justification

Probing has an impact on speed and can cause errors. Probing with discard devices e.q. makes no sense.

Instructions for Use

Setup a ContactProbeNozzle for your machine as descriped here in detail #859.
After that the machine will probe with every pick and place command. To avoid these for certain action we can use https://github.com/openpnp/openpnp/wiki/Scripting. Job.BeforeDiscard.js to disable and Job.AfterDiscard.js to enable e.g. with discard devices action. The script could be similar to this example:

Job.BeforeDiscard.js:

// Import some OpenPnP classes we'll use to disable probing
var imports = new JavaImporter(org.openpnp.spi.machine);
var head = machine.getHead("H1");   // Your machine head's name
var nozzle = head.getNozzle("N1");   // Your machine nozzle's name
print("##################################################################");
nozzle.disableContactProbeActuator(true);   // We disable probing
print("##################################################################");

The same code in a Job.AfterDiscard.js but with:

nozzle.disableContactProbeActuator(false);   // We enable probing

Implementation Details

1. I made several tests with my machine and run the virtual job of OpenPnP
2. I did follow the coding style.
3. No changes were made in the org.openpnp.spi or org.openpnp.model packages.
4. After downgrade to JDK 11.0.2 (before machine.xml was not found) the maven test run without error.

[vonnieda]

@markmaker This looks okay to me, but I am not very familiar with the ContactProbeNozzle. Do you have any thoughts on this?

[markmaker]

Hey @gitchrisfr, @vonnieda

My comment here is under the assumption that a merge should be for the benefit of more than one user, so I'm assuming other users will want to use this too and perhaps be less aware of problematic side effects than the author.

From a design stand-point, this is obviously a bit of a dangerous pattern. If the second script isn't called due to an exception, due to misconfiguration etc. pp., the boolean may be left switched on and then spoil all further (normal) operation of the ContactProbeNozzle without a chance for the user to know what's wrong.

It would obviously be best to have this behavior change targeted at the real purpose i.e. at disabling probing on discard (I'm just assuming that's the underlying use case from the PR's description, correct me if I'm wrong).

For instance, you could add a boolean to the probing GUI that says "Disable on discard" and then, inside the code, compare the place location with the discard location (perhaps with a few mm tolerance, to allow for any compensations applied, etc.) and then skip the probing. This would benefit all users, even those that might have trouble setting up scripts properly (or those that try to avoid scripting altogether, like me).

I would find this a very useful addition!

If there are additional use cases at any pick/place location intended, at the very least, the boolean should have "one-shot" logic, i.e. always disable it immediately after having skipped the probing for one time.

_Mark

[gitchrisfr]

Hi Mark,
starting point was this https://groups.google.com/forum/#!topic/openpnp/zlw-Ys58lPQ. I assume you know. It ended with Marek's comment "should be used only.. PR - as soon as I know "how to". So I did.

Regarding your first paragraph:
If we say this is dangerous, scripting is dangerous, why is it implemented. If one turn off the lights by script they are off until turning it on again. Is it with probing more dangerous?

Second:
The discard position was the initial situation for this - right. As you are the author of #859 you know best, that as long "probed part Z height is not yet used within OpenPNP" and probing is done with every pick and place command hardly anyone will use it. Am I wrong?

I agree with you it would be very useful. But unfortunately I have to admit that I can't. Due to Jason's "granulate code" recommandation I started with this small code modification to keep what I promised.

One should have the comfort to probe PCB height, part height with every first feeder pick.. right, but it's not me to do this in one PR not just the change for discard - shame on me.

[markmaker]

@gitchrisfr

Your response sounds offended, that was not my intention. It's hard to write diplomatically in a foreign language, Sorry.

starting point was this https://groups.google.com/forum/#!topic/openpnp/zlw-Ys58lPQ. I assume you know. It ended with Marek's comment "should be used only.. PR - as soon as I know "how to". So I did.

I missed that one. Your first thought of comparing the locations was the right one! Instead of equals() use linearDistanceTo() convert to Millimeters and compare to a maximum distance of say 4mm.

Regarding your first paragraph:
If we say this is dangerous, scripting is dangerous, why is it implemented.

Scripting per se is not dangerous, just slow. Storing the boolean on the nozzle with the risk of it remaining switched on is.

If one turn off the lights by script they are off until turning it on again. Is it with probing more dangerous?

There are some differences:

1. The lighting script is called on every image capture i.e. in normal operation, so if the LEDs stayed on after the last capture, nothing bad happens when you enable a light that is already on. This is different as the discard operation is not the normal operation and the situation does not correct itself in the next normal operation.
2. The user sees the light and can correct the situation, whereas the skipped probing is hard to spot and trace back to a hidden boolean or to the discard that happened some time earlier.
3. The code calling the lighting scripts uses a try-finally pattern, to guarantee that the second script is called, even in case of exception. I added that in the last PR for the newest way to do lighting scripts (compatible with auto camera settling). See https://github.com/openpnp/openpnp/pull/999/files

Second:
The discard position was the initial situation for this - right. As you are the author of #859 you know best, that as long "probed part Z height is not yet used within OpenPNP" and probing is done with every pick and place command hardly anyone will use it. Am I wrong?

I don't know. It seems you do :-)

I must admit that I didn't think of discarding+probing as a problem, because I do probing on discard. My reasoning is this: Discard happens in different cases, one of them being a stuck part i.e. after the PartOff vacuum sensing test failed. A stuck part remains on the nozzle even though the vacuum was switched off. Switching the vacuum off again at the discard location will not help. So I thought, there must be some way to make sure the part comes off. Therefore, at my discard-location the nozzle does probe down onto an uneven/slanted ground to pivot/brush the part off for sure. At the moment I have a piece of foamy packaging material there that seems to do the job, but I plan to build a spring-suspended "seesaw" metal ramp (ESD safe) that will let parts slide down after discard, so I could recover the more expensive ones.

I agree with you it would be very useful. But unfortunately I have to admit that I can't. Due to Jason's "granulate code" recommandation I started with this small code modification to keep what I promised.

You mean you don't know how to do GUI code? Yeah, it took me a while too. Turned out to be easier than it looked in the code. Follow the video guide to add WindowBuilder:
https://www.youtube.com/watch?v=bOiI6bGpINY
Then use it to add the checkbox and then copycat code from other checkboxes to do the binding.

But you could leave the GUI out for now and just add the boolean to the Nozzle with the @Attribute marker to add it to machine.xml. Then, if the boolean is on, compute the discard location distance, skip the probing if it is within the tolerance distance.

One should have the comfort to probe PCB height, part height with every first feeder pick.. right, but it's not me to do this in one PR not just the change for discard ...

I do intend to add the code to use the probed Z for adjusting part height one day. The problem there is mapped axes and the way position reports are handled now. It works on a single nozzle machine, but I want it to work on a multi-nozzle shared Z axis machine. I'm currently stuck in a PR on axis mapping etc. and one of the goals is making this ready for the said extension.

_Mark

[gitchrisfr]

Offended? No, not at all. I'm just trying to be polite - maybe the foreign language too. Why should I? I see all the postings and work you do for this project - there is only one Mark Maker for sure? ;-)
I'm not using probing but one says "When you start, you finish" that was the intention. If this PR is skipped - OK.

[markmaker]

@gitchrisfr

I'm not using probing but one says "When you start, you finish" that was the intention. If this PR is skipped - OK.

Not using probing? I don't understand. Are you saying this PR is no longer actually useful to you?

I'm also interested how you intend to handle stuck part discard i.e. whether you can follow my reasoning of wanting to probe down there too.

_Mark

[gitchrisfr]

Yeap. I thought it could be usefull for the community. I got to much problems with the implementation "as is" due to 0402 parts as descriped. But that's maybe only me. I never though about probing for stuck parts, so no suggestion to this.

[vonnieda]

I don't see any harm in merging this. It doesn't affect anything outside allowing a runtime property so if it's useful for one person I think that's okay. Thanks @gitchrisfr!

[gitchrisfr]

Thanks a lot!
Chris