Hi Bobbe,
I don't know anything about Python scripting of Java and its data type mapping, so I can't help you.
Plus I wanted you to know, that rather than trying to jury-rig
missing functionality with scripts, I'm always aiming to solve the
underlying problem, especially for such a routine operation as a
blow-off would be, i.e. literally in the name-giving Pick &
Place cycle. So please state what you are missing with the OpenPnP
functionality.
If this is only about that paper test object, see my other e-mail, and be a bit patient.😎
_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/03460a64-6ace-44de-b323-9570c7c346e9n%40googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/0b1713e9-3391-49a4-b439-f44998fed4c4n%40googlegroups.com.
Hi Bobbe,
I'm not sure I understand your explanation, so lets first see, if I see such a system right.
Now, 5, 6, 7 must be modeled as one G-code sequence, as
the Blow-off is a Pulse actuation, i.e. there is only one
ACTUATE_DOUBLE_COMMAND, and no "Off" command. One example
(not actual M-codes):
M802 ; switch on Blow-off valveG4 P{DoubleValue} ; dwell for the Blow-Off Value millisecondsM803 ; switch off Blow-off valve
However, please do not mix in other actuators in your
G-code, i.e. do not actuate the pump or the vacuum valve.
If you do, OpenPnP will be mistaken about the state of the
Actuator, which might cause malfunction later. And this will also
not work with multiple nozzles where OpenPnP must keep track of all
the valves.
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/0b1713e9-3391-49a4-b439-f44998fed4c4n%40googlegroups.com.
Hi Wayne,
I don't see where or how "we are mixing systems", but I agree
that the blow valve can be shared.
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/ded92b90-bac6-49f8-a2de-ca7afebc70d2n%40googlegroups.com.
Hi Bobbe,
Sorry, I still don't really understand.
> The pump gets activated/deactivated constantly, because its set as the vacuum actuator.
That doesn't make sense to me. Why would you do that? Do you have
two nozzles? If yes, what happens if there is a second part on the
other nozzle?
> The problem in my case is, when I activate the valve, disable the pump and disable the valve again..
Why would you "disable" the valve again? assuming you mean switching it back to vacuum/pump?
> ... the remaining pressure in that small piece of tubing is enough to suck the part back onto the nozzle...
You should not "disable" the valve. After the blow-off,
it must be switched to atmospheric pressure, not to vacuum/pump.
And btw. where is your blow-off pressure coming from?
I can see how you could use a 3-way valve for
vacuum/atmospheric/blow-off, but you would still have to conceptually
model it as two actuators in OpenPnP. This should not
be a problem, because OpenPnP will only pulse-actuate the conceptual
blow-off, while the conceptual vacuum valve is
closed, i.e. you can be sure that it will always pulse from
atmospheric to blow-off and back, and not from vacuum to blow-off
and back, i.e. you do not need to know the initial state or how to
restore it (which would not be possible in plain G-code). As the
blow-off is only a pulsed actuator, it will only temporarily switch
the 3-way into its third state, and then revert it back to
atmospheric, i.e. it will restore the OpenPnP conceptual vacuum
actuator to its correct state.
(Obviously this will not be assured if you manually play around
with the actuators on the GUI, but we can ignore this "use case")
> So because my case is relatively special, I guess the approach via solving it via a script might be the way to go.
Like I said, I may still not understand it correctly, but from
how this sounds, your "vastly different from the standard" system
does not seem to be right. You should fix the hardware, not the
software. 😁
And if you can move the valves to the head, that's much better,
because the long part of the tube (through the drag chain to the
head) will otherwise slow down pressure transients dramatically,
and force you to use long dwell times. These matter a lot for
machine speed.
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/6564b1f7-4a73-4fab-a2ce-2460fb98547en%40googlegroups.com.
> Just to make it super clear again: "I have a small air pump and a single three way valve per nozzle."
> I got 2 heads, thus 2 pumps and 2 nozzles ^^
You mean 2 nozzles, not 2 heads, right? 😎😎
That explains, why you switch the pump with the vacuum actuator,
but you should still also switch the 3-way valve to atmospheric,
not to vacuum/pump.
OpenPnP Vacuum Valve ON:
OpenPnP Vacuum Valve OFF:
OpenPnP Blow-off ACTUATE_DOUBLE:
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/afbe83d1-d561-416a-b37d-ca2e5f059ac9n%40googlegroups.com.

That's not 3-way in my book.
You just need to reverse the valve, and I would also swap NC/NO:

You do not have positive pressure blow-off after all, right?
I was assuming you had, because of this post:
> Bobbe Feb 16, 2022, 2:18:50 AM (2 days ago)
> Sorry if I crash into this conversation randomly, but this might be related:> I actually also noticed a potential nuisance with that calibration step: From what I can tell (I'm not on testing though), it doesn't seem to be possible to use blowoff functionality for picking the piece of paper.> This resulted in me having to temporarily adjust the place dwell time of my nozzle to 15000ms.
https://groups.google.com/g/openpnp/c/BzX9kAWO5mo/m/y_HV8gqABQAJ
_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/6e6ecbfb-1cbd-4fba-8155-a36c1a12c525n%40googlegroups.com.
> Ah okay, so then I'd not be using "blowoff" at all and just configure both, the valve and the pump as my vacuum actuator, right? I guess that'd make sense.
Yep, as laid out before:
OpenPnP Vacuum Valve ON:
OpenPnP Vacuum Valve OFF:
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/fa3eceb7-7b3b-4571-ac8c-849e08aa54f1n%40googlegroups.com.
Hi Wayne
That's good to have as a reference. I think readers understand
that this is just another example, i.e. not the OP's design.
Some questions:
Are the valves on the head?
Is the blow-off pump a separate pump? And is it fast enough to
start and fill the tube to the head, so the blow-off will be
effective in due time?
I'm a bit astonished that they do not use the vacuum pump exhaust
(with a bleeder), and that they do not use a (head side) valve for
blowing. I would expect it to be even more time sensitive to
switch than the vacuum (you wouldn't want to blow the placed part
off the solder paste, right?).
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/ecf8f53a-f39b-4136-bb77-91e69ed5a302n%40googlegroups.com.

> Both are operated 100% of the time while a job is
running, started at job start and stopped when the job ends.
Very important information. I think a "constant" (but see below)
over pressure is all that design can reasonably do.
Operating it on-off dynamically would be rather slow, I guess,
right? It would therefore have to be started as soon as (both?)
parts were picked, not only after placement, i.e. after the vacuum
valve has switched off, as is implemented in OpenPnP now.
Furthermore, any PWM setting is affected by whether the other
nozzle has a part on or not, and what the nozzle tip bore
diameters are (flow cross section), right?
I will make the Test Object blow-off value available, so one can
switch it OFF there, as an exception.
But I fear it will not be practical to vary dynamically in production, i.e. on regular packages.
_Mark


