ShaunR

No, probably not, in which case yours is the simpler solution. I would agree based on the question that is the more likely scenario. But it could also possibly be that he is monitoring multiple controls for value change in the same event case, which starts to favor a producer-consumer or some similar design.

Well. If that is the case then there should be an event case for each control or set of dependent controls. Still don't see the need to complicate it further.

And it's a personal preference of mine that I try to avoid using timeouts in the event structure unless really necessary. There are times when it makes sense, and it's still superior to polling. But it still *feels* like I'm resorting to polling before we got the event structure. Man, doesn't that seem like ages ago.

Me too. and re-reading what I posted I did say they should be checked there. What I was really getting at was to add a timeout so that his vi doesn't "hang". I think once he posts more, we will probably see that his issue is understanding how and why an event structure works the way it does rather than a design implementation. After all there are a few unintuitive things like having the control inside the event case.

Yes you can.

What do you have so far? If you post your vi, we can see the direction you are taking and advise better.

In my opinion, the best way to approach long term graphing is to continuously log the data and provide "views" of that data. To prevent files getting too large (and therfore taking ages to load in the views), you can save the data log in a number of files (either using the date in the filename, or directory name). This would give you a file (or set of files) for each day or month which can be loaded "raw" and processed to provide whatever analysis you require.

Why would you say that? I think Mark's proposal is valid, as is yours. When I first read the question, the first thoughts that came to my mind were both of your solutions. Ultimately, it is a design decision for the developer to make and he doesn't offer up enough additional information to make a choice.

-Scott

My reply wasn't a design proposal. It was to get his events working properly. Like you said. theres not a lot of detail, but its likely its a control with a couple of cases checking a value. Do you really need a Consumer-Producer design pattern with state machines to see if a value is higher or lower than zero for example?

Certified 10-16-09

Placed in the LabVIEW IDE section

Many thanks.

Labview IDE? I thought it would have gone in the UI section.

I think its a case of emphaisis.

Matlab is a mathematics package with some language features.

Labview is a programming language with some mathematics features.

It sounds like your application could benefit from using a producer consumer architecture. Use a single event structure in one while loop that will detect the value change and have the event notify the consumer of the new value. A state machine in the consumer could process the data as required and if necessary repeat over the action until a new value is detected.

A bit excessive dont ya think?

Hi,

I am having a bit of a problem getting my program to work properly. As I have it set up right now, I have a while loop as the outer-most structure. Inside the while loop, I have an event structure (on Value Change). Inside the event structure I have a case structure. The different cases in the case structure correspond to the possible value changes that the event structure detects.

Is there any way to constantly repeat events in a certain case structure until the event structure detects a different value (a value change)? I tried putting a while loop inside one of the case structures, but the program just waits in the while loop and ignores any input that is supposed to cause the event structure to detect a value change (and thus execute events inside a different case). I also tried having an external boolean wired to the stop button of the while loop inside a certain case but that did not seem to work either.

Any ideas are greatly appreciated. Thanks!

Well a Value Change(signl) property node will programmatically fire an event but you can end up with race conditions. You ought to be wiring a timeout to the event case (say 100ms the, default is -1....wait indefinately) and checking the controls in the timeout case.

If you are seeing the event execute only once, then it is likely that you do not have the control inside that event case. This is required for the control to be "reset".

Why would it? This is a patch, made to fix relatively urgent bugs. If NI's schedule of recent years is indicative (and it should be, according to NI) you can probably expect the minor release around January or February.

Don't see why it couldn't have been included. They realesed F1 just to fix 1 minor bug that very few people would have suffered from. I've actually given up using probes now and just create indicators on the front panel 'cos its such a pain.

Thank you!

I already noticed that this byte must have something to do with the Refnum type

but I was unsure. Is there any documentation about that? The LV documentation tells something about TDs of plain types but not much about Refnum TDs...

Refnum Data Types

I'm not following. Why would you send a User Event Refnum from the caller to the xctl if the goal is simply to get a cluster of the xctl's User Events? I don't want the xctl to control when the calling code registers for events.

I was referring to the Option B where a create method was used. It is identical the what ShaunH describes (using the bundle to integrate events) but from within the control instead of external.

Your new best friend in 2009.1:

openProbesInOwnWindows=True

As with all NI features that haven't shipped, I'm not promising anything, but we've been listening and the developer that owns the probe watch window has added the ini token.

-Brady

Back on topic

Just downloaded and installed 2009.F2.

Doesn't work .....bugger

Virgin In?

Virtually Incapable of?

Very Inconsistent?

Bet you wish you hadn't asked now...lol

Windows update ran last night while I was running an experiment, and restarted the computer while LabVIEW was running. If you run overnight experiments with LabVIEW, you may want to consider this. I found some instructions for how to disable automatic restart on XP

http://www.aviranspl...windows-update/

Here's the skinny:

Windows XP Pro users can tell Windows never to restart the computer automatically. In order to do that follow these steps.

• In the
  Start Menu
  go to
  Run
  type “
  gpedit.msc
  ” and press
  Enter
• Now a Group Policy editor will open. In this window navigate to:
  Computer Configuration -> Administrative Template -> Windows Components -> Windows Update
• Double click on
  No auto-restart for scheduled Automatic Updates installations
• In the settings window Choose
  Enabled
  and click
  OK
• Close Group Policy Editor

Hope this helps someone else! Or if there are other/better suggestions for keeping Windows Update at bay, I'd love to hear them.

Pat

You can also pull the network plug out while your running tests

I agree with everything you said except this. I believe the user event queue exists at the event structure, not the the user event refnum or event registration refnum. If there are no registered event structures, there is no queue to fill up.

Ooooh. I didn't realise this. I knew windows event queues can be swamped with messages if there is no sink and if you can get enough in before the message managerr times them out. I assumed (obviously wrongly) that it worked in a similar fashion

Since the user event refnums and event registration refnums are strongly typed, you can only put them in an array if they have the same data type. What's the recommended technique for dynamically registering/unregistering for events that have different data types?

Thinking about this. If you are going to supply an event refnum from the caller (I prefer encapsulated but what the hell), the Xcontrol can bundle its events onto it. Then when you wire the resultant event cluster through a register to an Event case, you can choose not only the calling vis events, but the Xcontrols as well. It would give the Xcontrol tight integration to the callers events and a fairly close approximation to how real other event driven langueages operate.

If you notice. After the initial flurry, reputations are increasing at a massively slower rate. I put this down to the fact that people (like me) didn't know what that little green number meant and kept clicking on it to see what happened. It took me ages to figure out that it was for the reputation system and not in fact, to add the post to a multiple reply

I also think its a bit misleading, since those that help newbies are unlikely to get better reputations since a newbie generally doesn't realise a) they can vote, or b) what it is for. However, those in the "old boys network" will get tremendous reputations.

I finally got it working. It's looks a little 'hacky' and it's most likely not the most efficient way to do it. But it's good enough for me atm.

Thanks again Shaun and Ton

Cool. Glad its working Looks like you've been through the string pallet and now know every function .

(You can replace everything up to the "Array to Cluster" with a "Spreadsheet String To Array")

I have a labmate. He just finished B.S.; and thinks himself is a smart person . He is lazy (Only see him 12hrs a week.) . The things I teach him need to teach him again and again (e.g. sensors are needed to connect gounds; how PCI board connection. I even need to download the same data sheet again and again for him). 10 questions a day. Make a only 5 transistors circuit take a week and a few hours of my time to do problem solve for him . OK! fine (I am just too nice)

My boss may want to motivate him, so tell him that his project is very important. The stupid labmate came to talk to me and tell me that my project is not the lab direction; and don't work too hard . I am just thinking to take over his small project after I finish up my stuff.

Nope. If you do that, his project will succeed and he will get the credit. He might even get a promotion since, after all, he may not be technically bright, but he sure can manage YOU! He'll end up as your manager Let his project struggle then when the boss is in dispair offer advice to the boss on how to bring it back on course. Then the boss will probably GIVE you the project. Your labmate will have demonstrated his incompetence, you will have shown your helpfullness and he will end up working for you

If you use a DataGrid .Net control. It has a GdiVertical font attribute you can use.

We don't have engineers at V I Engineering, Inc. - we have imagineers

Maybe we should rename the company to "V I Imagineering, Inc."

Pop quiz: what does the "V" and "I" stand for in "V I Engineering"? (VIE employees are exempt from participating in this quiz).

Vociferously Incoherent?

Vehemently Intractable?

Veritably Incredulous?

Vaguely Interesting?

6?

Option B has another Pro, in that it's more consistent with standard events, where you create the event explicitly in the caller VI. I don't have any experience with either method, so I can't comment more.

Interesting. I view it the other way in that since it is a broadcast mechanism it doesn't matter where you create it as it is the reposibility of the receiver to register for it.

Here is a XControl design question:

If I want to use user events to generate events in the owning VI where should these events be created? (not generated)

Option A

Inside the XControl and with a read-only property a VI could get the user event and register for it.

Pro: you have a tight integration between the control and the event. Using the Init and Uninit abilities you can exactly define when to create and destroy the event references

- you can have multiple listeners

Con: you can create useless event references which get very much events which are never written.

Option B

Inside the owning VI, with a special 'Create Event Reference' VI and a write-only property.

Pro: only event references that are really used are created

Con: a special event typedef is needed.

After writing these things up I lean toward option A.

I only have used option B, does anyone have some experience with option A?

Ton

I would consider A more in line with event implementations not only in LV but in other languages too (for example in Delphi, control events are only available once you place that control on the FP).

In B, what if you create an event that doesn't exist in the XControl? B also requires external initialisers where as A is self contained and the events are available just by placing the control. However, in the case of A I think you need a backup plan for if you generate events and there are no registered recipients since you will just fill up the message queue.

C'mon, do you guys at VIE have nothing better to do than read LAVA and imagine stuff all day? I guess we need to get crelf to give you more stuff to do.

Whay do you think the "I" stands for in VI Engineering:P

Right. I had that in my head - just forgot to type it.

So does it work better now?

True, but it's good stuff to know.

So, just to beat a dead horse:

If I have the reentrant subVI set to Same as Caller, then each instance will be in the thread of the caller and will therefore not require a context switch when called?

BTW, just bought the book.

Only if set to clone! Oh. And if Labview decided to do a context switch because its run out of threads in that execution system The downside is all the dataspace allocated for each clone.

You've bought it? No printer then ...lol.

Thanks,

Looks like I ought to get a copy of that book.

I still don't think that addresses the topic of reentrant vi's, at least not that I saw. I think the crux of my question was whether making a VI reentrant somehow overrides the execution system setting.

We're already told to use reentrant VI's when reusing the same VI in two parallel processes. If the answer to the previous question is "no", then do we need to avoid calling reentrant VI's from different threads? Or am I overthinking?

Not at all.

Marking a vi as re-entrant means that a full copy of the "executing" code is instantiated in the calling process. This is for both types of re-entrant vi ("clone" and "same copy"). Since copies of the code exisit in the calling processes address space they can be run in parallel. The difference between "clone" and "same copy" is the datapsace. A re-entrant vi marked a "clone" has its own dataspace for every instance you lay down in a diagram. If marked as "same" then all the instancies have only 1 dataspace shared between them. In the case of a LV2 global. If you mark it as "clone" then if you call it from one location it will not contain the same data as if you call it from another, therefore it will only function as required when marked as "Same". However, in doing this you may cross execution system (ES) boundaries if the calling vis are in separate ones (if it is set to "same as caller") or you give it its own ES. And crossing an ES WILL cause a context switch.

By the way, this is all a bit moot if it doesn't resolve you problem

So, that leads me to a question: Do reentrant VI's that are not explicitly set to use the caller's thread involve context switches? Put another way, if a reentrant VI is set to use the caller's thread, does it avoid a context switch?

Gary

Have a read of this....

http://books.google....itching&f=false

In particular 9.2.3 and (replace the word "Process" with "Execution System") and ask me again.