Boolean Logic Issue

[Michael Burgess]

I have 2 sensors in a system.

Items pass these sensors.

First is an inductive sensor and only activated by a passing metal object, which is what we want.

Second is an IR Through Beam - if the Inductive sensor activates it means a metal object has passed so the second IR Through beam is redundant in that case

If the IR Through Beam is broken and the Inductive HASN'T been activated, it means the passing object isn't metal (in this case it's plastic).

So if Inductive is (A) and IR is (B)

Metal:

(A) will activate on its own very briefly
(B) activates also
(A) deactivates
(B) still activated on its own for a very brief period
(B) deactivates

Plastic:

(B) activates on it's own
(B) deactivates

I've knocked up a VI and Metal is easy enough - if (A) is activated, using an implies and not gate, I can make sure only once it enqueues 'metal'

But for the Plastic on, it works most of the time, but sometimes puts 'reject' onto the queue when a metal passes - i'm assuming that because of the subVI iterating quickly and the period when (B) remains on alone, this somehow picks it up as plastic.

Can anyone see where i'm going wrong?

Cheers 🙂

without getting this first bit right I can't sort the second inspection part as it relies on a successful decision from the first section to fully assertain what to do at the reject area following - nightmare! 😞

[chilly_charly]

You need to have a latch when you are detecting a metal object : detect the rising edge of the A signal, and memorize it until you detect the falling edge of the B signal.
Need sometime to translate that in LV. I suppose that you will do that faster than me ?
Let me know...

CC

[Michael Burgess]

thanks for the swift reply.

that's sort of what i've tried to achieve with a while loop and shift registers in labview, but my limited experience has left some logical errors in there evidently!

what you said is what i've tried to achieve though - a latch on A that remains until the object fully passes B, where it is reset, ready for the next passing object - just translating that to LV is my issue :S

cheers 🙂

[chilly_charly]

Try that ! I use an OpenG trigger detect function. Could probably be optimized, but...

CC

[Michael Burgess]

cheers - i'll take a look in a little bit - at first glance it's a wee bit confusing for me 😄 but the proof of the pudding is in the testing....................:D

that will be activated by the metal edge and stay on until the object has passed the IR beam then?

sweet 🙂

[chilly_charly]

---

@Michael Burgess wrote:
...that will be activated by the metal edge and stay on until the object has passed the IR beam then?

sweet 🙂

---

Weellll...
That's supposed to be ! Unfortunately my own portable metal/plastic detector is under repair and I could not test the vi 😄

CC

[Michael Burgess]

I can't get my head round that attached VI - it won't pick up a metal object and the reject works ok, except if I have the conveyor belt set to quick, where it picks up metal as reject 😞

The one I did is v v nearly right, except that it sometimes picks up a metal as both metal AND reject if the conveyor is set to quick sometimes, but it always gets plastic as reject once and metal as metal on all other speeds.

I really don't understand Boolean Logic like I should 😞

[tbob]

Could you explain what is your desired end result? Do you want to put reject in the first queue if the object is non-metal, and put metal base in the second queue if the object is metal? Also, does the conveyor belt run such that one object passes both sensors before the next object gets to the first sensor, or can you have a case where you have objects at both sensors at the same time. This will make a difference in the logic. Another thing, your loop does not have any delay time so it is running at full speed and is chewing up all the CPU time. If you can answer the above questions, I may be able to suggest some logic that will work for you.

[Michael Burgess]

Hi there tbob 🙂

the VI is a subVI in a while loop, along with other subVIs, so the frequency of the code running has been ok - it's in a loop with a 100ms delay - all these 6 subVIs seem to run as expected and are doing ok in that respect (as far as I know :D)

I'll try to answer your questions now........:)

' Could you explain what is your desired end result?'

Basically, there are 4 sensors along a conveyor belt, split into 2 groups of two. The first two are an inductive and infra-red through beam, the second two are an infra-red reflective sensor and a large capacitive sensor (I have attached a photo of the two sections in question to get a feel for it - conveyor goes left to right - if, as you can see, a metal based object passes the left section, it activates the inductive sensor (the blue one), then the infra-red beam (the bit under the blue frame) is broken shortly after (so now both sensors are active), then the trailing edge of the metal peg leaves the field of the inductive sensor and the inductive sensor deactivates - and now the infra-red through beam is still broken momentarily before the metal object fully passes. If it was a plastic ring passing (a plastic ring can just be seen in the assembly hopper on the far left of the picture), the inductive sensor would not be activated, with only the IR through beam being broken. One problem I was getting is that sometimes a passing metal is getting put down as both metal and plastic - presumably due to the last part where only the IR through beam is broken.

'Do you want to put reject in the first queue if the object is non-metal and put metal base in the second queue if the object is metal?'

Yes and no...............either 'reject' or 'plastic base' (the wording is inconsequential I suppose) onto the first queue for non-metal and 'metal-base' onto the first queue instead for metal (I am using the second queue for the second stage of the inspection as can be seen just after on the picture.

'Also, does the conveyor belt run such that one object passes both sensors before the next object gets to the first sensor, or can you have a case where you have objects at both sensors at the same time.'

The way it works with the spacing of objects as they are fed into the machine (there is a chain conveyor with uniform spacing, as can be seen in the background), only one object should be in the field of these sensors at a time BUT there is always the risk that something could be placed on manually and cause that situation to be true - that's all part of a final critical evaluation I suppose - not being able to properly identify anything in the system, only 'assuming'.

I think the question about the loops shouldn't be an issue - the profiling suggests not 🙂

sorry, i've waffled a bit there - think that answers everything! 🙂

thanks 😄

[tbob]

Here is a simple vi that should do what you want. Since this is a subvi, and is called periodically, I see no reason for the outer while loop. It runs only once anyway. I suppose you were using it before because of shift registers. My attached version does not use shift registers. It simply waits until the IR beam is broken, then it checks the metal detector and causes the proper string to be placed onto the queue, then it waits for the IR beam to be unbroken. Now the subvi is done. I like to keep the delays in the while loops just so that the CPU can do other things while waiting for the IR beam action.
A problem might arise if you are wanting to do other things while waiting for the IR beam action. If so, then a whole new strategy is needed. You might want to use an event structure. The IR beam change can be the event. Inside the IR beam change event, put a case structure to check the IR Beam boolean. In the case of the beam being broken, put the code to enqueue the string. In the other case, do nothing. When the beam is broken, the event will fire and the string will be queued. When the beam becomes unbroken, the event will fire and nothing else will happen. The next part that comes around will repeat the event sequence. You can then do other things while waiting for the next event.
This whole strategy is based on the fact that the metal detector is still activated by a metal part when the IR beam gets broken. If this is not so, then a new strategy is needed. According to what you described, the metal detector is still activated when a metal part breaks the IR beam, so this should work.