hmmmmmmm, that looks to be a very good way of doing it - will it only enqueue the text once? I can't test now as i'm home but that looks a very good way of doing it - it did seem daft having two enqueue functions for sort of opposite results
I reckon I could use that same approach for the second section actually
It will enqueue only once per part because it waits until the IR beam is unbroken before ending the subvi. The while loop only executes once, which is why I am saying that the loop can be eliminated. The next enqueue will happen only after the subvi is called again and the beam is broken again.
the approach you took there is pretty cool actually
that won't work for the next bit as far as i can see - as on the next bit, the capacative sensor is high and will ONLY be activated if the passing object has a plastic top (the base can be anything)
but i don't think i need the same complexity
assuming nothing else is put in the system, if a plastic ring goes through the first part, it's got to be rejected regardless - so i can just preview the head of inspection queue 1, if it's 'reject' then add the same to inspection queue 2 - if a metal base has passed part 1 and then the top capacative sensor isn't set off on part 2 it means it's incomplete and i can add reject to inspection queue 2 again - if inspection 1 says metal base and both part 2 sensors go off, it's a pukka assembly and i can add that to inspection queue 2
cool man - cheers - think i'm there - just 'verbalising' like I am now makes me think more about it and brings up issues to bear in mind 🙂
Re-read my response in reply #10. I talked about the event structure. Using the event structure will allow you to perform other things while waiting for the IR beam broken/unbroken event. It won't halt the vi execution like a waiting loop would. That is one of the big advantages of the event structure. See the attached vi. Look at the note in the timeout event. Using a timeout value will prevent your vi from freezing until an event occurs. If you use the timeout so that you can perform other things, you will have to periodically call the subvi to check if an object is passing through the sensors. Another thing you could do is not use the timer and call this subvi by reference. You can then set the Wait Until Done property to False. Doing so will call the vi and immediately return to the main. The subvi will run in the background. You will need to use reference nodes to get the values from the queues in the subvi when using this method.
Just thought of something else. If you use the event structure, you don't need subvi's at all. Just put the event structure into your main vi loop. The loop will continue executing and won't freeze while waiting for the event. The event is like an interupt. When the event occurs, the actions inside the event structure will take place. So while waiting for the event, your vi still runs. The IR beam gets broken and the proper string gets queued. The rest of your vi is still running. The IR beam gets unbroken and the event fires again, but nothing is done since there is no code in the event's false case. The rest of the vi is still running.
I wish NI would change the look of this forum to make the attach button close to the Submit Post button so that I (and others) would remember to put the attached file before submitting the post. The way it looks now, the Browse button for attachements is off the screen to the bottom so I don't see it unless I scroll down. Anyway, here is the attached vi that I was talking about. Sorry for the confusion.
Yeah I get frustrated that you can only edit a post once - bit annoying at times - and I'd prefer a forum that displays posts in date order and lets your quote...........but heh! This site is an invaluable resource so who am I to complain 😄
I'll take a look over that code in a bit with a cuppa and see what's what 😄