irVision failing on GET_OFFSET

I'm here. I'm running irVision on an R30ib+ running V9.3. And I had this irVision task working yesterday, on this same target. The only thing I've changed since then is opening up the Scale tolerance on the GPM tool.

The thing that has me confused is that the GPM is succeeding, but the GET_OFFSET command in my TP program is jumping to the "failed" LBL. By the manual, this should only happen if the find fails, or if the limit check is exceeded, and I don't have a limit check set up.

In fact, my VR in the robot is getting the same values I see in the irVision page. So, I'm a bit stumped as to why my GET_OFFSET is failing.

...excuse me, I need to now.

As I mentioned, I had opened up the Scale limits on the GPM. Know what I didn't do? Hit the SAVE button.

So when I clicked Snap&Find in the irVision web page, everything worked perfectly. But when the robot ran RUN_FIND and GET_OFFSET, it was still accessing the last saved version of that vision task.

Which I found right after I posted the previous post, when I hit Exit and got the "This job is not saved yet" prompt.

Quote from Doctor_C

Have you ever tried the Gedit tool. you can draw your own stuff.

So that's what that button does!

Hm... I'm going to have to get a feel for how this handles. Does it tell the GPM tool to look for the drawn edges, rather than the auto-found edges? Does it come into play before or after the Training Mask?

Well, trying the GEdit got me about 10% higher score, ~55% or so. Still playing with it. But now I've got a slightly different problem.

I have another vision process looking for the same part, but not for guidance, just for a simple part-present detection. I pass the GPM Score value into an Evaluation Tool which has a single rule: Pass if Score>(value). My TP program runs VISION GET_PASSFAIL and then checks the value in Register.

But what I'm getting on an irregular basis is not a 0 (Fail) or 1 (Pass) value, but a 2. Which the manual says means "could not be determined", but doesn't really explain that. When I run the job manually from the browser, I get a Result:Undetermined and Not Evaluated. When this happens, the GPM tool upstream is not finding any matches above the score threshold (in fact, I'm getting a false find with a score of ~50% of the Threshold value)

So, the Evaluation tool is running a simple yes/no, and the Score of the only thing the GPM shows in the "almost found" group is well below the test value in the Evaluation tool. So the Eval tool shouldn't be able to pass back anything but Pass/Fail. The "Not Evaluated" message makes me think something is stopping the Eval tool from running, but I have no idea what could be doing that.

But why don't I get a reliable 1 or 0 from the Eval tool? What's causing the "indeterminate" return value? That's the part I'm getting hung up on now.

Part of the reason for this is that I use the task as a simple present/absent check, but when I look at an empty area where there's no part present, I sometimes get this "Undetermined" and "Not Evaluated" result. I'd like to eliminate the ambiguity.

Opening up the Elasticity is definitely increasing my Score, though -- thanks.

Also, I'm not looking at an angle -- that image was me trying to deliberately create the "Undetermined" test result so I could get a screenshot.

Carboard cylinders. With varying oval-ness and various ragged edges. Also, may have gauzy tissue paper floating around clinging to the cylinders at random locations.

I will say, though, the combination of Pixel Elasticity and the GP Edit has boosted my scores considerably, such that I've been able to raise my score threshold from 40 up to 65-70 without missing parts.

I only took the Elasticity to 3. And the big issue with the filters is that there's very little greyscale contrast between the cylinder end and the background.

Definitely going to need some time and lots of parts to fine-tune this one.

Quote from HawkME

That setting should be used very sparingly.

The elasticity? Yes, I'm not planning to go wild with it.