Boolean Logic Issue

[tbob]

I don't know the timing of your conveyor or what else you have running in your main vi. You will have to make that call. You can experiment with different times. If need be, you can eliminate the delay, but beware that it will use up all your CPU time while the loop is running. Even a 5ms delay is better than none. Good luck.

[Michael Burgess]

good stuff dude

using your approach for the first part on the second, I think I've cracked it 😄

but only testing will tell tomorrow 😄

thank you 🙂

[Michael Burgess]

I've just a question relating to queues............

I think i've just muddled something up in my head

I have an inspection area one - an item passes that and I enqueue the result of that inspection onto queue 1 (let's say this is the first item since it was started, so it goes @ the head of the queue)

then it moves onto inspection area two - here I use the decision from area one's queue and also work something extra out, before enqueueing that onto another queue - so as before, if this was first, it goes on the head of the queue.

then it moves to the reject area, but the chances are another item will be passing these inspection areas again by the time it gets to the reject area

as it stood, I was using the head of the queue in the reject area, which is ok

so i can enqueue the next inspection area 1 onto the queue (now it will be second)

then when I come to inspection area 2, I can't look at the head of inspection queue 1 as it may still be the old item there - so I'm a bit miffed as to how i'm gonna do it - thinking maybe two queues is a bad idea - of course, if the first item reached the reject area before the second item got there it would be fine, as when an item passes, I remove it from the queue whether it's rejected or accepted

don't know whether I should be enqueuing at the other end - or is there a way to preview an item at the back of the queue?

just had this thought before I got up and it's causing me bother - does that make sense?

Cheers 🙂

[tbob]

Are you using the function to preview the queue element? You should be using Dequeue Element. When you need data from the queue, you can dequeue the element in to a variable. That way it is no longer in the queue. The proper way to use queues is to enqueue as the data comes in, then dequeue when you need the data. Old data should not remain in the queue unless you have a specific purpose for doing that. One of the purposes of queues is to not miss any data if it is coming in faster than it is being processed. Another is to hold states for a state machine. If you dequeue, there won't be any chance of using the wrong data with an object.

[Michael Burgess]

Hi tbob - yeah I was previewing the head of the queue as you can see in the VI

the first section with the IR through beam works a treat and then the second bit works a treat - but 2 diff queues - what I was doing is at the reject area after, is dequeuing both the heads and either firing the reject solenoid or not dependant on if it's a good assembly or not.

Had to switch to case statements but using your idea still (Cheers for that!) as the event structures would not activate for me, even after 4hrs fiddling and adjusting timeouts etc - couldn't get them to activate 😞 this does pretty much the same though!

In testing today though I saw the issue I suspected may happen - this method is fine until two things are in there at once

In fact, I think by typing it out, coupled with what you just said I've sussed it

Assembly enters inspection area 1 - decision made and enqueued on inspection queue 1 - item moves on to inspection area 2 - just as it is doing so, another assembly hits inspection area one and a decision is made and enqueued - inspection area 2 dequeues and looks at the head of inspection queue 1, makes a decision based on that and it's own sensors, then enqueues a final decision onto inspection area 2!

so as long as 1 enqueues, 2 dequeues that and enqueues onto it's own queue and reject dequeues queue 2, then it should all flow nicely!

cool - writing stuff out definitely helps me get my head round them 😄

I'm going to alter this VI now to do what I've just described 😄

[tbob]

Glad you are able to solve your problem. It is OK to preview the element at the front of the queue, just as long as you dequeue it at some point before you take on the next object. Just to be safe, you might consider dequeueing the element into a variable instead of previewing it. Then you can check the variable wherever need be. Or just use wires instead of a variable. Sort of like wire from the dequeue function to decision 1, and same wire extended to decision 2.

[Michael Burgess]

cheers for your help tbob 🙂

I reckon this should do it.............

the reason i'm steering clear of a variable or wiring the decision through is that if a second object enters inspection area 1 whilst inspection area 2 is looking at an object, this could overwrite the previous correct decision from inspection area 1 for inspection area 2's current object

I can't test until monday, but this should work a treat now 🙂

I've put the dequeue function inside the case statement which only becomes true when the sensor changes from false to true (false on all other cases), so it will not dequeue everything unnecessarily as the loop iterates 🙂

good stuff - this *should* be bob on now - awesome!

really loving Labview!!!!!