problems in lighting
ma...@makr.zone
Hi Cees
it seems that this PR...
https://github.com/openpnp/openpnp/pull/999
https://github.com/openpnp/openpnp/pull/999/files?diff=unified&w=1
...somehow fell out of the branch after the merge.
Must have happened when I resolved some artificial conflicts that
git sometimes seems to produce after merging PRs from multiple
parallel running branches back. Some git expert out there know how
to avoid that?
Will fix it ASAP.
Thanks for the report and sorry about that.
_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/0a1bc788-aead-4128-9c2c-cfdd4671c200n%40googlegroups.com.
Marek T.
ma...@makr.zone
Yes, but Jason's got (much) more advanced plans for that.
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/b685eb42-5633-41e6-b052-718d585a07f0n%40googlegroups.com.
Marek T.
ma...@makr.zone
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/57264240-9ae7-bca5-9f29-7d27b323cd0e%40makr.zone.
Jason von Nieda
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/8d1247e5-63be-45dd-a100-e474689e02e9n%40googlegroups.com.
Cees Leeuwinga
Marek Twarowski
You received this message because you are subscribed to a topic in the Google Groups "OpenPnP" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openpnp/j4ucK1JuyH0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openpnp+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BQw0jwb8xB2nxEvFOyysxLupES_rrMANbsAfUXGsEZ-HtyjDA%40mail.gmail.com.
Jason von Nieda
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CAJDP_hfP3GC3KqCLVwmm70uwJ6tp1hRTNv6KtBobBnDV4oNNsg%40mail.gmail.com.
Marek Twarowski
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BQw0jx%3DQefeVN5CMen1Nn3cKM0OFZ2ifMFB4QeDVAR02-%3DSEQ%40mail.gmail.com.
ma...@makr.zone
Hi Jason, Marek
I started thinking about how to provide a solutions that can be
both simple to use for the ON/OFF use case and extensible.
But it always exploded into complexity that seemed over-the-top.
The user would have to be able to define a number of custom
labeled parameters (at least doubles and perhaps bools) that
dynamically generate the GUI required to then define lighting
parameter-sets (similar to the OpenPnPCaptureCamera's property
sliders, perhaps). Then multiple such parameter-sets could be
defined in the Machine Setup tree, one for each lighting solution.
This requires quite a lot of GUI plumbing for adding/deleting etc.
in the tree. Then these parameter-sets could be selected in the
pipeline ImageCapture stage (Drop Down). For advanced use cases
they only make sense there, IMHO, as they work hand-in-hand with
the pipeline.
But how would the parameters out of the set be assigned to
actuators? One actuator per parameter? This won't work, if
multiple params must be specified in one command to the
controller. And what if the params are somehow encoded? Such as an
RGB code made out of a "Red", "Green" and "Blue" slider, for
instance? Some RGB controllers probably require such composite
params. Do we create a new multi-parametric actuator? With
scaling/composing/hexcoding? It seems endless.
Then I remembered there is the ScriptRun pipeline stage.
The user can choose a script file and set arguments. The whole
complexity of the parameter-sets and their plumbing can either be
packed into a script, so the user simply chooses "SideLightHard",
"FrontalMidLevel", "DiffuseBright" etc. or she can use one Script
and set the lighting solution as an argument (in the required
syntax).
I think this is a much more versatile and reasonable solution for
those with complex lighting setups.
And the rest of us can simply use a boolean actuator on the
camera. This one can then also be used to switch OFF any ScriptRun
driven lighting solution (by using {False} Gcode or by using a
ScriptActuator if not single-driver/Gcode controlled).
If you're ok with that, I'll add the
boolean actuator.
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BQw0jwb8xB2nxEvFOyysxLupES_rrMANbsAfUXGsEZ-HtyjDA%40mail.gmail.com.
Jason von Nieda
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/e9dd7dd7-d29f-49a5-a272-f51f7add3872%40makr.zone.
ma...@makr.zone
> I have struggeld so much with this failure,...
Have you seen my email that it should be fixed now?
> ... that the programm OPENPNP was damaged and would not be running again.
I don't understand. Haven't you backed up everything, when I told
you, after you had no backup the last time? Btw. your almost-good
machine.xml is still somewhere here in the user group discussion.
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/4867ec09-f5a9-4c31-af9c-2d89cadaa8b3n%40googlegroups.com.
ma...@makr.zone
> - job finished
> - job start
- Off
- On
- Capture
- Automatic
- settleAndCapture is called.
- user moves the mouse over the camera view
- Machine thread is finished with user action or Job Runnable
and a camera was moved, or if a tool was moved over a bottom
camera. This should cover both the Job end/pause/failure and
all GUI camera positioning actions. It should only light up
the camera that was moved (to), so the other lights don't
blind the active camera.
- settleAndCapture is done.
- the light is ON, after a configurable timeout. Using a short
timeout this should also cover machines with LEDs that must
not be turned on continuously (overheating etc.).
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/e9dd7dd7-d29f-49a5-a272-f51f7add3872%40makr.zone.
Marek Twarowski
You received this message because you are subscribed to a topic in the Google Groups "OpenPnP" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openpnp/j4ucK1JuyH0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openpnp+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/b6557b83-3e67-57fd-c9d4-1fef38c7f47d%40makr.zone.
Yevhenii Shcherbakov
ma...@makr.zone
Hi Marek
First: Personally I don't switch lights. They are just always ON.
And on my machine I don't see a reason for them to switch. But....
Some machines may have the down-looking camera so close to the nozzles that its light blinds the up-looking camera, so it then makes sense to switch it ON only when used. (English speakers: or do you say "blinds" or "glares"?)
Some lights may overheat or damage the LEDs if continuously on.
> If it will be on when "settleAndCapture is called" ...
That's how it works today using scripts AFAIK.
> ... it forces to use long settle time for the image
stabilization, isn't it?
In theory: No. If you switch off auto-exposure and all other
"auto" settings, as is absolutely necessary anyway, it
should not matter.
In practice: Maybe. Some cameras may still do some adaptive image processing, despite setting everything to manual.
I will think about one more setting:
- Off
- On
- ExclusiveCapture
- Capture
- Automatic
In this setting it would keep all the camera lights always ON except when another camera that looks the other way (down vs. up) is in settleAndCapture().
Do you think that would help?
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CAJDP_he5PPr9_xFWstXxb5CwAcBEyV4z0HVXCiCvtJTsD5Uh4A%40mail.gmail.com.
Marek Twarowski
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/bc687a10-665e-f54c-8680-c309c27f6262%40makr.zone.
ma...@makr.zone
The right way is using the CameraBeforeSettle and CameraAfterSettle scripts.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CAJDP_heajpcmHZSnw6XjcUiDRMbH4fMz6BuRCCKGLM-BGVioiw%40mail.gmail.com.
Duncan Ellison
Marek Twarowski
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/d7e42447-54ff-905e-11db-9265bb1f3ac2%40makr.zone.
Mike Menci
ma...@makr.zone
Thanks Duncan :-)
Learning heaps of stuff in this community!
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/41b0f04d-de2e-495a-b969-d99732eba5f2n%40googlegroups.com.
ma...@makr.zone
> Before align and after align is much better IMO.
> The same before nozzle calibration and after it.
For the bottom camera, maybe.
But for the down-looking camera? Many DIY feeders use vision too.
It is not generally foreseeable (i.e. a lengthy machine move in
advance), when the next vision operation will take place.
But: having the enum, will allow us to add other patterns later.
Btw, for pro machines the lights often act like a flash, LEDs can
take much higher currents momentarily. So blinking is not per se
bad.
...is it just because I'm Swiss that I like these Swiss machines?
;-)
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CAJDP_hdmPH9SZfPRs%3D9T%3DAT%2Bt5gwFbX0DpcT9UufFABPUEeeUA%40mail.gmail.com.
Marek Twarowski
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/f0a7dfb9-1ac7-4157-5148-82afac53c54a%40makr.zone.
Jason von Nieda
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CAJDP_hcSHmuGddDwtCXiwL8eBF%2BBbMthNvpsfkYRcoa7%2Bko%3DDg%40mail.gmail.com.
ma...@makr.zone
With Advanced Motion Control the light switching in the proposed settleAndCapture() trigger can now use the new uncoordinated actuation, by switching off the Before Actuation coordination on the Light actuator:
https://github.com/openpnp/openpnp/wiki/Motion-Planner#actuator-machine-coordination
The BeforeSettle trigger (as the Script trigger today) happens before
the waitForCompletion() on the move to the camera or camera
subject location:
This means the uncoordinated
actuation
will not yet trigger motion
planning, execution and waiting, but it is immediately sent to the
controller. This in turn means the light will already be switched
ON, when the move is finally executed. If the move is substantial,
even a bad camera has time to adapt. It will be more or less the
same timing as BeforeAlignment. But it will equally work for
calibration, fiducial recognition, any feeder vision etc. pp.
provided there is a pending move in front.
Having said that, is can also make sense to keep the Before
Actuation coordination switched on, if for instance the LEDs
must not be ON too long due to overheating.
> Mark - rather than an enum where single values encapsulate a number of operations, I think it would be better just to have checkboxes to turn on features. The features would be as you've described, and as I've mentioned above
I agree for the mousing-over option and other timeout triggers to
be separate checkbox options.
But otherwise, IMHO that's not so easy as it sounds ;-)
Some of these triggers may at one time be and at another time not
be nested into one-another. E.g. a Capture can be nested inside an
Alignment. Or not. So the user needs to switch on both triggers
for proper operation. The ON triggers must also balance the OFF
triggers (like parentheses in a math formula).
GUI/usability: Unless I'm mistaken you end up with a row of
checkboxes that need to be switched on or off in a
nested&balanced pattern to be correct i.e. you effectively end
up with the same few valid choices that the enum provides. Only
the user can shoot him- or herself in the foot much easier. :-/
Implementation: To cover the nesting of triggers, a naive
approach could be to use a counter, increment it on the
selected ON-triggers, decrement it on the selected OFF-triggers
and switch the light according to the predicate counter > 0.
In case of exceptions we can probably make this robust using
finally {} i.e. make sure we balance the counter correctly in all
cases.
Today, each PlannedPlacementStep only handles one placement
i.e. one nozzle alignment per step and each one of
these switches the light ON and then OFF.
@Marek, you have a multi-nozzle machine, so it will blink between
nozzles! This may happen so fast, you don't notice it (look into
the log). But if no blinking is noticeable there, the same is true
for multi-pass alignment and fiducial drill-down. Blinking will be
so short (few ms), humans don't see it and any camera
auto-exposure will equally not be affected (if it was, it would be
equally fast to recover).
If you wanted to avoid all blinking in a multi-nozzle machine, you'd need to introduce two new JobProcessor steps "preAligment" and "postAligment". And the same bracketing would be needed for fiducials, etc.
With the ON-trigger being in a different step in the JobProcessor than the OFF-trigger, plus exception handling and retries etc., it would become much more complicated to keep the counter balanced. Imagine what could happen to the rest of a Job if the JobProcessor ever got this wrong!
I'll also admit: I absolutely and resolutely hate any form of reference counting. If you ever "worked" with Microsoft OLE/COM, you know this is utter ***** ;-)
Frankly, this all seems too much. Even if the above-mentioned asynchronous operation of the lights is not enough (or not available), I see these valid scenarios:
- User has the recommended camera (ELP) or better: AFAIK, it has
no problems settling with rapid light changes when all the
"auto" options are OFF, as recommended. Switching the lights can
even be seen as an advantage, because it creates a definitive
starting point for Camera
Settling and especially the Debounce Frames logic. It is
then hard-synced to the controller and therefore to
motion and unaffected by any kind of video lag.
- User has a crap camera with only auto-exposure: He/she can use
always-ON or the new ExclusiveCapture (detailed earlier). Or
live with longer settle times. Or buy a better camera and keep
more hair down the road, because a crap camera will make
vision unreliable as hell in more ways than this one.
;-)
Finally, the ExclusiveCapture option (anti-glare) does
not fit into the multi-option checkboxes pattern, as it
effectively inverts the logic.
So: I propose sticking to the enum, plus extra checkbox option
for mouse-over et al, plus timeout. :-)
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BQw0jxf%3DH%3DmBgVzC7T1x_EcRpETCdrDXmVk86Y0dXy1yzKD-g%40mail.gmail.com.
Jason von Nieda
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/91801e13-dde9-2d77-5fdf-8a889ae6943b%40makr.zone.
Marek Twarowski
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/91801e13-dde9-2d77-5fdf-8a889ae6943b%40makr.zone.
Marek Twarowski
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BQw0jx_KRT2xhMPUx84feZ4QA7m6psXVzJ4kL0E5iC7sCH23A%40mail.gmail.com.
ma...@makr.zone
Hi Jason
I feel my message was misunderstood. I must have formulated it badly, and I agree it was too long and too "twisted". I was speaking out against over-complication and what I documented was in-deed the complication that I feared, as a justification for not doing it that way!
Therefore, I humbly ask to re-read my message and try to
understand why I still want the simple enum instead of a growing
number of checkboxes. Why I can't implement what you ask for
(especially the "Optionally" points).
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BQw0jx_KRT2xhMPUx84feZ4QA7m6psXVzJ4kL0E5iC7sCH23A%40mail.gmail.com.
Jason von Nieda
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/bbb1f067-928b-b175-def1-96fdd6d77fac%40makr.zone.
ma...@makr.zone
Hi Jason
90% of what you say is equivalent to what I meant to describe. And if we assume, we can "forever" leave it at the functionality listed in the last mail, I'd be OK with it.But with the Optionally points and one of my ideas this is no longer the case. I don't know if I can describe it better this time. I'll try with a more concrete example:
- We start with the "before/after settle & capture" checkbox.
- In my view, this is already not such a clear user interface:
If the checkbox is off, does that mean that OpenPnP will turn
the light always ON with the machine enable? Or do we leave that
to the ENABLE_COMMAND, effectively having to duplicate the
actuator Gcode and changing the actuator state behind its back?
- Or do we add another checkbox "enable with machine"?
- If yes, the user is given the impression that she has 4
options now (binary: two bools). But it is easy to see that
there are only three sensible choices.
- Now we add the mentioned (Optionally) ReferenceBottomVision "before/after alignment" checkbox.
- The user is given the impression that she has 4 [or 8] options now (binary: two [or three] bools).
- But that's wrong: before/after settle must remain switched on,
for those cases of bottom vision that don't run through
alignment, like e.g. calibration.
- Now you could argue, that we need to add a further "before/after calibration" checkbox.
- But again, the extra freedom of degree makes no sense: I see
no realistic scenario, where one wanted to switch the light on
in alignment but not in calibration or vice versa. There is no
real choice here, either you have the lights always on, or you
switch them in camera settle or you absolutely need to switch
all the operation-level "outer bracket" checkboxes on.
- Plus this add an eternal burden onto every future bottom
vision application, to add one more checkbox, to handle
the trigger etc. And this would be even worse for all the
down-looking (e.g. feeder) vision applications. Plus one for
pipeline editing...
- Now you could argue, OK, let's only add the most important/performance critical vision operation checkboxes and let the rest be handled by the "before/after settle & capture" checkbox.
- Having only some of these "outer bracket" checkboxes
means we need to keep track of trigger nesting. If the user
selects both the outer bracket "before/after alignment" and the
inner bracket "before/after settle" options (as she must), then
the "after settle & capture" trigger must not switch
off the light!
- I won't start the "over-complication" essay again. In my previous message I tried to explain why there are very valid reasons why truly eliminating blinking with multiple nozzles in the JobProcessor is not so easy as it sounds and if you really wanted to implement it (by adding extra state machine steps), then keeping track of the nested trigger brackets is very hard in the face of exceptions and retries.
Having many checkboxes seems to add much freedom of choice. But
if you really think about it, only a few "semantic" combinations
make sense. You're effectively back to these exclusive choices:
- Don't switch at all (leave it to Gcode or Scripts etc.)
- Switch ON with machine enable.
- Switch early/late, bracketing whole vision operations.
- Switch before/after camera settle & capture.
I detailed in my message, how I can effectively cover option 3
with uncoordinated actuation, sneaking in the actuation
command before the motion command, as this is typically
still queued in the motion planner. This will work for all vision
applications that I can think of, both bottom and down-looking.
This will also effectively eliminate blinking due to correctional
moves between vision passes of both alignment and fiducial
location. Blinking will technically still be there (as it is
today!), but it will be so short neither a human, nor the
auto-exposure of a camera will be affected.
Plus I proposed an extra ExclusiveCapture choice. For this one
the trigger is kind of inverted towards other cameras.
Therefore it doesn't naturally mix with checkbox options.
All in all I'm back to an enum choice. Plus the mouse-over and
other GUI related checkboxes.
Hope it makes more sense this time.
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BQw0jxTAuyX7d7e50Y-OePeqaLfWDjRGU%3DwJBuyMB0rTDRoeA%40mail.gmail.com.
Marek Twarowski
ma...@makr.zone
Hi
This topic somehow seems to escape succinct writing down by me.
Sorry about that. :-/
When I said "I can effectively cover option 3 with uncoordinated actuation", I meant there is no option 3 to choose after all. Instead, you switch off the Before Actuation coordination checkbox on the Light actuator:
https://github.com/openpnp/openpnp/wiki/Motion-Planner#actuator-machine-coordination
In combination with option 4 this then acts like option
3.
Adding the "anti-glare" option (what I called ExclusiveCapture
before) we have:
- Don't switch at all (leave it to Gcode or Scripts etc.)
- Switch ON/OFF with machine enable/disable.
- - ? -
- Switch ON/OFF before/after camera settle & capture.
- Switch ON/OFF with machine enable/disable, but in addition switch OFF while another camera pointing into the other direction is inside settle & capture (anti-glare).
> Or it could be opt3 ("bracketing" in simple
Jason/mine meaning) and opt3a (Mark proposal) ?
Nested bracketing has the problems I described. I see no robust
way.
But I could simply add the ON-trigger and ignore nesting in the OFF-trigger, so the light would be switched ON earlier, but switched OFF after the first settle & capture and then switched back ON before the next settle & capture. Again the blinking is probably so fast, it does not matter. Tried to visualize it, with the "Nested" showing the theoretical optimum that I believe can't be implemented easily:
If this is all bad: The scripts still exist and you could run
your lights at whatever script trigger you like. I guess you
learned to arrange yourself with the nested bracketing problems,
like having to switch on the lights manually for pipeline editing
etc. And I guess your lights blink more than you think, but so
fast you don't notice. A log would show this.
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CAJDP_hdhCWqPyWpgayVCTKZ8GMMCxOOdL2V9QSD1GeGSHGgpBQ%40mail.gmail.com.
Marek Twarowski
ma...@makr.zone
Yes I see. With no bottom camera light switching in play and only
fiducial vision (no feeder or any other down-looking vision), your
solution can be quite simple.
If my previous explanation was not understandable, then I guess
you just have to trust me when I say it is not so simple for the
universal general case. :-)
_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/CAJDP_heWbo-E9MDTR2ZEsWeQW7f-qpqpqrAjLWZkcuLgYp8vpQ%40mail.gmail.com.
Marek Twarowski
Jason von Nieda
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/3934f659-deb0-fb22-4dc5-769e061f705a%40makr.zone.
ma...@makr.zone
Hi Jason
Think I'm starting to see where the differences in our judgment
originate. Especially if we start talking about custom
lighting profiles again.
(I'm not sure I get this out properly in English).
In my judgment the correct entity that should determine
the lighting profile is the Pipeline. It often contains
hard-wired properties that only work with a specific lighting
setup e.g. a specific threshold setting vs. the brightness of the
shot. If you go further with "Ring, Coaxial, Angle" and start
customizing detection methods between pipelines e.g. canny
detecting edges in conjunction with "Angle" lighting for a
particularly difficult low-contrast subject, as an alternative to
the usual threshold detection in conjunction with "Coaxial"
lighting, then this is even more true.
This is also usability oriented: Imagine you're editing the
Pipeline, trying to get a grip on that "Annoying White Body IC".
Wouldn't it be super nice to be able to go to the ImageCapture
stage and adjust the lighting profile interactively, in tight
interplay with the other stages of the pipeline?
Let's say it bluntly: If I ever build adjustable lights into my
machine, I would absolutely want it that way!
That's why I'm so obsessed with settle & capture as the one
and only trigger. It is called right from the Pipeline
ImageCapture stage and it could carry the lighting profile as a
parameter in the future.
Of course one could assign the lighting profile outside the
Pipeline on the Wizard where the Pipeline is actually managed. But
IMHO, this would just complicate editing. It would also require a
lots of work for the extra GUI plumbing for each and every
pipeline carrying Wizard. From a design stand-point, to burden and
duplicate this responsibility onto that many different objects
also feels wrong for me.
Btw. if one day we rework Pipelines to be managed globally and referenced rather than copied, i.e. you select one from a drop-down of known good ones, rather than edit/copy/paste, this solution would be compatible.
> For my (Optionally) settings, I meant that the control
(and the setting) would be on the calling object, primarily
meaning the vision operation itself. In other words,
ReferenceBottomVision, ReferenceFicudialLocator,
ReferenceStripFeeder, etc..
For ReferenceBottomVision, ReferenceFicudialLocator I
disagree. It is the Part/Fiducial [should be Package] in question
that carries the knowlegde whether it is the "Annoying White Body
IC" in BottomVision or not, whether it is a Homing Fiducial, a PCB
fiducial (HASL or ENIG?) or a SlotSchultzFeeder fiducial. And for
the ReferenceStripFeeder I'd again prefer to handle it as
a tight interplay of lighting and detection in the pipeline, e.g.
how to light and detect black/transparent plastic or white paper carrier
tape. The same for the countless other feeder classes where we can
adjust the Pipeline individually.
Sometimes the information about the specifics (Part/Fiducial/Feeder) and even the question whether Vision is needed at all, are not known where I think you would place the lighting trigger. For instance, if you want to bracket the lighting for the whole of locateBoard(), you don't know which type of fiducials there are, if any. Plus you need to care about bracketing, because getFiducialLocation() can be called directly (homing/SlotSchultzfeeder) or indirectly by locateBoard().
For feeder vision it is particularly bad: some feeders (mine and others) perform location calibration (and OCR) as a side effect of getPickLocation(). Whenever some calling code wants to know for the first time where exactly the pick location is, it will effectuate the vision (btw. that's why I introduced the job preparation cycle, to make this less awkward and more efficient). In the Job this can happen from feed or pick step or both. Often as a lazy evaluation one-time per feeder operation.
The example shows how unpredictable vision calling can be. A
solution that works in all cases, without posing any burdens on
the calling code, has a huge advantage in my view.
Of course we could also refactor half of OpenPnP and make
Lighting a first class citizen. With up-front planning, querying
the lighting profile(s) from the upcoming Part/Fiducial/Feeder,
carefully anticipating lazy evaluations, and storing all those in
the Placement. Then adding separate steps in the JobProcessor to
trigger them. We'd need to touch most of the GUI triggered vision
too ... I don't think so.
Finally I'd like to ask, whether my explanation about the uncoordinated
actuation is understandable and whether you agree that it
solves most of the "proper-time-for-auto-exposure" problem.
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BQw0jxCNMD8s5KMgvp4LceEAoq3cCnUDFLr9d732eOYah0Yqw%40mail.gmail.com.
Marek Twarowski
Jason von Nieda
Jason von Nieda
Finally I'd like to ask, whether my explanation about the uncoordinated actuation is understandable and whether you agree that it solves most of the "proper-time-for-auto-exposure" problem.
ma...@makr.zone
Hi Jason
yes, I've seen the answer, and of course I'm fine with it. I just haven't found the time to implement it yet.
And yes, your description of uncoordinated actuation is correct.
The remaining blinking will be irrelevant for most machines (FET
switching over USB: I estimate a <1ms glitch i.e. completely
invisible).
I have some ideas about how to eliminate even this blinking in
the future. But let's not complicate it now.
--
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/CA%2BQw0jwMmUG2JKAW9-PUOe5-jganUHej8YtGUaQNXBMbpyj%2BMQ%40mail.gmail.com.