LabVIEW

cancel
Showing results forΒ 
Search instead forΒ 
Did you mean:Β 

Boolean Logic Issue

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

thanks in advance tbob πŸ™‚
0 Kudos
Message 11 of 27
(745 Views)
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.
- tbob

Inventor of the WORM Global
0 Kudos
Message 12 of 27
(742 Views)
ah cool that makes sense

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 πŸ™‚
0 Kudos
Message 13 of 27
(734 Views)
hey tbob

there's an issue i've found with using that loop to halt the queue until the object sensor is true. It halts the overall VIs execution on that 'wait' loop............

using this method I think I'm going to have to move each VI into its own parallel process so that it doesn't matter if a certain subVI needs to halt until active πŸ™‚

could do with doing that anyhow as I need to add some waits into 2 of them and that will pull down my performance overall using just the one while loop to house all my subVI subsections!

cheers πŸ™‚
0 Kudos
Message 14 of 27
(716 Views)
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.
- tbob

Inventor of the WORM Global
0 Kudos
Message 15 of 27
(705 Views)
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.
- tbob

Inventor of the WORM Global
0 Kudos
Message 16 of 27
(704 Views)
by the attached VI do you mean the one from last night?

the event structure sounds like a good idea - i'd still need to house it in a subVI really for visual on the block diagram - bit miffed but I'll try to work something out later πŸ™‚ ta
0 Kudos
Message 17 of 27
(698 Views)
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.
- tbob

Inventor of the WORM Global
0 Kudos
Message 18 of 27
(696 Views)
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 πŸ˜„

Cheers tbob πŸ˜„
0 Kudos
Message 19 of 27
(688 Views)
do you reckon a timeout of 50ms is too little or too much in the scheme of things tbob?

the subvi is in a while loop that iterates with 100ms delay and needs to react fairly quickly
0 Kudos
Message 20 of 27
(674 Views)