VI Performance Issue

[Michael Burgess]

Doh!

Just me being stupid!

It didn't look like a build array for some reason!

I need more tea me thinks 😄

[Michael Burgess]

I've taken out those waits in the Conveyor (that was just a test - not needed @ the moment) and Assembly areas and performance has definitely improved - it's still not ideal, but it's definitely better!

The only issue is I need some kind of a wait in there - after the sort area uses a solenoid to push the ring down a chute, I need to wait at least half a second before the Assembly area solenoid opens to let the just sorted ring into the Assembly hopper (assuming there's not already a ring in there!).

Without adding a delay and thereby lagging my performance, I can't really think of a way to make the sections wait :S

[Michael Burgess]

in true coding style, an annoying niggle has just started

when I have more than 2 rings in the chute, the functional global for decrementing this value goes down by two at a time instead of one when a ring is released into the assembly hopper

annoying as you like!

[Michael Burgess]

Just hit a new issue that I feared may rear its ugly head!

If you look at Run.vi, you can see that each section passes an output value, which is then passed by local variable to the other parallel process (while loop), where it is output to the card.

This output requires an 8-bit unsigned integer (the output port is 8-bit) between 0 and 15 (only the bottom 4 bits of the 8-bits are used, with values 8, 4, 2 & 1). I have identified the necessary binary value for each component (motor, solenoid etc) and this value being passed from each section will fire the necessary component when passed to the other parallel structure.

The issue i'm now encountering, is that the top loop sometimes never gets the output value for the sporadic outputs, as the value I pass for output is part of a sequence diagram within a case structure (in the Assembly area for instance) and the sequence diagram executes so quickly, then the case becomes false and the output value will be set to 0 again for that section, meaning the top loop never received the output value.

Can anyone think of an efficient way to ensure that any output I need definitely reaches the top loop? Bear in mind I need to output differing values constantly - it may just need 2 motors on at some point, then it will need to fire a solenoid, so it will still need to run the motors AND fire the new solenoid, then another solenoid may need activating at a similar time. Basically, a way to ensure that any 4-bit combination I need between 0 and 15 is output when I request it and it doesn't get overlooked.

Cheers guys 🙂

[shoneill]

Hi Michael,

use queues to make sure the sent data is received instead of setting local variables. What you're experiencing is the famouns "race condition" where the setting and reading of variables isn't properly synchronised.

Look up the NI examples on how to use queues. They're actually quite easy to use. You can think of them an program-internal messaging. If yor reading loop is "late", it doesn't matter, the message is stored until it's read. You can set the maximum queue size to whatever you need (I usually leave it unlimited).

Edit: adding text

Making sure something is done exactly WHEN it should is basically impossible on anything other than a real-time OS. Your loop for setting the values will always lag a little, but this is something which almost all methods will share. I still think the Queue is the best bet (With the queue read in a loop).

End edit:

Hope this helps

Shane.

Message Edited by shoneill on 03-24-2005 01:14 PM

[Michael Burgess]

Hi Shane,

I'm already using queues in the program so familiar with their workings

Perhaps I could enqueue the output value of each section when it is requested (e.g. 0 or 8, 0 or 4, 0 or 2 etc), then when I dequeue it, change that output bit to the new value.

On the walk in before I thought about using queues. I still fear though that I may get issues then - let's say I enqueue a value to fire a solenoid to release a component, so that goes onto the queue, but then the case statement switches and the value 0 is also enqueued - so then the value to fire gets dequeued and activated, but then the value to cancel that is dequeued shortly after, meaning the solenoid is not open long enough to let the component through.

I'll certainly give it a try - but yeah you're totally right about the race conditions - they suck!

Cheers Shane - top man 🙂

Message Edited by Michael Burgess on 03-24-2005 12:26 PM

[shoneill]

Hi Michael,

typically a single loop will ony either write to or read from a particular queue. If you need to send a "signal" to more than one loop, simply use more than one queue, one for each "target". This should solve the problem.

By the way, I'm getting the impression you're based in Ireland, is this correct? 😛

Shane.

[Michael Burgess]

Cheers Shane, I'll give it a look!

I'm in England, in the Midlands right now @ uni - normally from just South of Manchester!

I am 1/4 Irish though! 😄

[shoneill]

Yeah, the tea and the "top man" kind of gave me the idea. I've never actually heard anyone not irish say "top man". There you go. You learn something new every -er- now and then.

Sounds like an interesting University. Where is it when it's not just south of Manchester? 😄 😉

Shane.

[Michael Burgess]

Ha!

Staffordshire Uni!

To be honest 'top man' is more of a geordie (newcastle upon tyne) dialect!

I've spent time in the north, midlands and the south with all kinds of different people, so my dialect is a strange one!

Tea - definite British thing (I'm assuming you're not from the UK? Maybe i'm wrong! :D) - you won't catch anyone British undertaking any kind of work without a cup of tea nearby!!!!!! I've got one right now! Fairtrade, 1.25 sugars! ha ha 😄

'top man'