Jump to content

Trapped Variable Problem


Recommended Posts

Hi guys

just a quickie..............

doing a piece of work in labview @ the moment............

got a problem i've encountered in the past and it's seriously annoying me!

ok.............

I have an 8-bit boolean array - i'm taking each bit and storing it into a boolean variable

the actual variables themselves on the block diagram are elsewhere outside of this loop and i'm writing to a local variable from the 8-bit array

so the bit from the array stores into the local variable no worries

i have another local variable elsewhere on my VI in a differing while loop that reads the value of this and will react to a change in an event structure

the local variable that is reading is not getting the value from the array, despite it storing into the local variable ok there in another while loop

i was under the impression that local variables were a reliable way of getting info in and out of running loops?

my tutor has suggested it may be thrashing, but my loops are all set with a uniform 'wait until next ms multiple' value in them - he also suggested it may be race conditions and i'm setting a differing value to this variable elsewhere, but there is only the variable itself and the 2 local variables related to which I have mentioned

does anyone have any suggestions or things to try please? really stuck :(

sorry my description is a bit poor, i'll knock up a small VI to illustrate what I mean when I get home shortly if necessary?

cheers,

Mike

Link to comment

If you think you missing some data, you can use a queue for communicate between your two loops.

Have a look at the Producer/Consumer Design Pattern.

You find it by selecting new in the file menu and then ->VI from Template->Frameworks->Design Pattern.

Good luck

and weekend :)

Alex

Link to comment
i have another local variable elsewhere on my VI in a differing while loop that reads the value of this and will react to a change in an event structure

4112[/snapback]

This statement doesn't make sense. An event structure cannot react to a change in a local variable. Event structures only react to front panel events.

It should be ok to use a local variable to pass data, however there is no synchronization. You have no guarantee that the loop has read the old data in the local before new data has become available.

Link to comment
This statement doesn't make sense. An event structure cannot react to a change in a local variable. Event structures only react to front panel events.

It should be ok to use a local variable to pass data, however there is no synchronization. You have no guarantee that the loop has read the old data in the local before new data has become available.

4128[/snapback]

In this context using the PropertyNode->Value(signalling) will trigger ValueChange event for that control.

Link to comment
This statement doesn't make sense. An event structure cannot react to a change in a local variable. Event structures only react to front panel events.

It should be ok to use a local variable to pass data, however there is no synchronization. You have no guarantee that the loop has read the old data in the local before new data has become available.

4128[/snapback]

Hi Michael.

what is a good way to pass data then? I'm still really new to Labview and always looking for new ways to work, providing it's within my capabilities!

RE the event structure - I was trying to set it to react to the change in value of a boolean object on the front panel

cheers :)

Link to comment
Hi Michael.

what is a good way to pass data then? I'm still really new to Labview and always looking for new ways to work, providing it's within my capabilities!

RE the event structure - I was trying to set it to react to the change in value of a boolean object on the front panel

cheers :)

4133[/snapback]

the best way to exchange data between 2 parallel structures (e.g. while loops) is using queues.

Link to comment

hey guys,

knocked up a VI using a queue to get my head round them and must agree it's a very efficient way of handling large amounts of incoming data and passing them about

however....................

I want multiple while loops to all read the same piece of data from the queue - so if I dequeue an element in one while loop and using another dequeue in another while loop, the second while loop will get a different set of data, the second in the queue - can anyone see a way round this please? I do like the idea of avoiding local variables at all costs :)

cheers for your help guys

Link to comment

also just had this thought

the input data will be changing very often - it could theoretically change a few times in a second

I've just seen that there's a preview queue function, so I could theoretically have all loops preview the front of the queue and when they have done so, flag this, then have a loop that checks when all loops have checked the head and dequeue's the head if they have

hmmmmmmmmm - a bit stuck here - I think queues may be too advanced for the problem at hand

Link to comment

Hi Michael:

For a similar problem (lots of different Vi's running sort of independently, but all reading data from the same source) I've been very happy using Notifiers. Notifiers are sort of like a broadcast equivalent of a queue.

Check: labview\examples\general\notifier.llb, as well as the help system discussion of notifiers. If this doesn't answer the question, let me know & I'll try and strip down one of my applications to serve as an example for you.

Best Regards & Hope I've been of help, Louis

Link to comment

Hi Louis - thanks for that suggestion - I am attempting to use queues and notifiers.

Basically, Port B on a 3x8-bit port interface card provides input. This is given as a figure between 0 and 255. Differing values = differing combination of sensors, so I need to pass the current input value to each section (I have identified 6 or 7 subsystems, each of which I will house in their own while loop) and act accordingly.

I am using 2 queues to identify the number of pegs and rings in the system (the application is to control a production line simulation that sorts and assembles rings onto pegs and checks for correct assembly, rejecting the incorrect ones.

I am also using a notifier to pass the Port B input value around the system.

Here is a screenshot of what i've been working on tonight - I can't test it until I get into University tomorrow - best head to bed - it's 02:25 here in the UK!

Cheers guys :)

Link to comment

in that attached image, the top loop which contains 'input' as a sub-VI doesn't appear to be working

this subVI reads from port B, the input port

I have tried putting input in a while loop to constantly read from the port, but the usual happens - as the loop is running, it will not release the input data to the notifier.

I really am at the end of my tether with this - getting nowhere :( work mounting up - arggggggggggh! :(

Link to comment

In a particular application I've got a few queues that fill up until the end of a test - then all data is dequeued. I wanted to add queue monitoring so a new loop gets all queued elements (from Get Queue Status) and displays as required. To keep the displayed data persistant, I use a shift register and 'filter from 1d array' to catch new values (see image). This was too dependent on timing.

I use a single subvi to enqueue data from anywhere in the app. I changed the vi to put the data in two different queues instead of one. The second queue can dequeue data without affecting the persistant queue.

post-107-1110319026.gif?width=400

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.