jgcode

I am not sure 100% what you are trying to do (why show the dialog if a button is to be programmatically pressed regardless?).

Having said that you could try checking the Key Focus property of the Ok Button on your dialog and if True then fire an event \ do something that is the same as a User pressing the Ok button.

nice option and i will do it immediatlly but the i want display a message to user in the case of limit exceeds dy displaying the popup message. For that i will take user dailogue Vis and implementation is bit unknown for me.

Well then you will have to precheck the input by performing your own logic, correct the response if invalid, then prompt the user with a dialog.

This seems like a lot of extra work and possibly intrusive from a User Interface point of view (repeatedly having to click on a dialog).

You may find taking advantage of the built in coercion couple with for example, a tip strip\help may be a more graceful response or something similar to this. Depends on your requirements I guess.

Cheers

-JG

More I want to block the controls(from 3rd event case on wards) with some range values i.e. User can enter values.only between in those ranges. Hope you can suggest me.

Hi Sjukheter

For any Control, you can pop-up (right click) on it and select Data Range...

This will load the Properties Dialog to that tab.

From here uncheck Use Default Range and then enter your own parameters.

A good tip is anytime you are looking to do things try popping up on stuff - there is heaps of functionality available there.

Cheers

-JG

Is there a way to determine the call stack in LabVIEW, I can't seem to find discussion of it anywhere.

My goal is for a subVI to know the name of his calling VI. I do know that you can access "Callers", but that doesn't tell me who specifically called the subVI.

Yep, sure can. There is a VI named Call Chain and its in the Application Control Functions Palette.

If you want a shortcut - OpenG has some great utilities, for example, in the OpenG Application Control Tools Palette:

Cheers

-JG

I headed to the IE and found these two ideas on the subject of Timers in the Event Structure.

Cyclic event for event structure ... a kind of timeout but cyclic !

Combine the event structure and the timed loop

Given we implement the functionality one way of another, it may be nice to have it native.

Also, there is (the start of) a few interesting comments in the above ideas.

Maybe there should be an option to unset this should be available (like an "allow unhandled events to be registered" checkbox in the event dialog if the dynamic event handles are shown).

As they are a few ideas that have come out of this thread, the authors should definitely post them up to the IE so we can vote them up!

I've also pinpointed the revision which introduced the bug. Interesting thing is the VI is not one of the changed ones, though the class did change.

Probably a good one to send to NI.

Different to your issue, but on the odd occasion I have had VIs that crash in the RTE but were fine in the Dev environment.

Once located, I simply recode them from scratch and the issue goes away.

I have no idea what makes them dirty but its not a pleasant thing to chase down!

On a recent thread I think alluded to a TimerSlave component I have partially finished. It's essentially a version of the timer loop in the image above, encapsulated in a slave loop object and exposing the timing and message name parameters as part of the creator method. I've been thinking about releasing it as part of LapDog. Would something like that be useful to you?

Always keen to have a look at your stuff

FWIW I still think it would be nice if Timers could be configured for an Event Structure and LabVIEW handled the implementation.

It is a common use-case, but it is also (IMO) an overused and misguided use case. In principle, anything that is in the timeout case (case structure or event structure) should be code that is entirely optional to the correct operation of the component. The component has no control over when it receives messages/events so there is no way to guarantee the timeout case will execute; ergo, putting code in the timeout case that "needs" to be executed is a flawed approach. The "correct" way to handle the situation is to create a parallel loop that sends messages/user events at regular intervals to trigger those other tasks. Using a timeout condition for necessary processing is a convenient shortcut--and I sometimes use it--but it shouldn't be considered a robust solution.

I think everyone would agree on that, except in this case here: we explicitly register and know the events the module will handle at run-time and accept that wrt the Timeout case. However, other events we did not expect now affect the behavior of our code.

All the more reason to use queues instead of user events.

Everything has pros and cons that influence our design decisions (Queues vs Events etc...) - its nasty surprises I don't like

Not sure if this is the best place to post but check our white paper for accelerating the FIX protocol using FlexRIO and LabVIEW FPGA

http://www.wallstree...a.com/fixcancel

Feedback and comments are appreciated.

Cool post - I never considered that NI technology would be used in that industry.

What version is this?

Man, if it not a display issue then it looks nasty!

Does a recompile fix it?

It seems that using OOP on an FPGA would be counter-intuitive. The paradigm for programming FPGAs and their end use make this hard to understand why this would be done.

That said, could more info be provided on why this is being done? Is there an algorithm that needs to be ported over? Also, most OOP code isn't parallelized to take advantage of the FPGA's parallel computing.

I haven't used it when programming FPGA so I can't comment there, but I have seen it used for creating the simulation FPGA code for debugging RT applications.

Thanks for the detailed review! I have read many of your posts and you have earned much respect.

No probs

It could have definitely been better but with the four hour time crunch and all. It's just not enough time. It took four and a half hours to do and I should have saved a copy away at the four hour mark and posted that. But it would have gotten about one point for functionality.

Preaching to the choir here - as Dave pointed out, the exams are larger so timing is more crucial. I made a conscious decision before going in not to use LVOOP (I was pretty sure given the examples I wouldn't have to, and I am no AQ ) - I am just too slow with it.

In practicing for the CLA I redid my CLD exam in LVOOP. I just made the 4-hr mark and it was done, but I still would have liked another 1/2hr to polish it up\off.

I used LVOOP for a couple of reasons. One was just for the sake of it because I want to get as much practice. Another is that it seems easier for me. You do end up with a lot more vis to document and make icons for. But documenting them is easier since they don't do much. I don't know if I will write code in a similar way for the CLD. It depends on what they throw at me.

I like LVOOP but wrt the exam I ended up with way too much stuff to document, and you will inevitably have to mash things around because of the time you spend on upfront design (none? ). I find it easier to change a module than a whole heap of VIs etc...

But alas, I do the opposite and use LVOOP in the real-world.

Cheers

-JG

I suggest sticking with the standard QSM implementation pattern.

QFT

...lol... sorry couldn't resist

Is it possible to use LabVIEW to write data, over an internet connection, to another computer?

Yes you certainly can e.g. TCP\IP or whatever flavor you prefer.

If you are using NI technology you might want to look at ni-psp too.

... and explains (IMO) a lot about problems people have seen with xControls.

Are you able to go into detail here? Thanks.

I would think twice before generalizing like that.

I think ShaunR is just shy too admit thats how he likes to program too

I really like the option of having a right-click menu toggle in the future that would allow you to enforce that you must have a case for every registered event. The default behavior should be as it is now. This way, anyone relying on the old behavior doesn't get screwed during an upgrade. However, I would also like an options switch to allow setting the default mode for event structures. Similar to the auto-grow option. At least, this way there would be a documentation entry which the user can browse to find out more

I have no idea what new use-cases may be, as this is all news to me as of today but the only issue I can see with the above is that, that option is now mutually exclusive. What if you wanted to react to both pieces of information in the same event structure (there has already been posts above on how users are considering using this new knowledge in their architectures)? You would be limited to one or the other.

Additionally, I use the timeout for polling stuff too, but sometimes I would rather a regular execution regardless of current event activity. I have always thought it would be nice if you could configure the Event Structure to fire off an event every x milliseconds without much programming. Configuring a timer (or multiple timers) would sure be nice.

I think it's probably because most people only use the event case for the UI (and generally wire -1 to it). And only a few are brave enough to base a whole inter-process messaging system purely on events.

Hey - if it works, it works

..lol

Sure you can find a use case for it. But I bet there is far more instances of head-scratching and cries of WTF. On the shoot yourself in the foot scale of 1-10. It's a bit of an 11. It's also one of those "issues" that you come across from time to time where the whole app just doesn't work, but when you try to debug. Everything works fine in isolation (or if you slow it down).

I guess the good news from this is (for me) - if its taken this long for this issue to be identified (LabVIEW 6.1 to present) then it must not have cropped up much (if not at all) before (granted, we could be using the event structure differently now).

You don't expect me to read threads do you?

Apologies. He's all yours

lol

Great thread, I had no idea and I have to say I don't like to behavior.

all events are known at design time: the event structure should be capable of recognizing the missing event frame. This is analogous to wiring up an enumeration to a case structure, where a value is not handled.

I disagree and I wouldn't want this enforced because of one of my current use cases.

I like to create modules where I can query the list of event refnums (as a cluster).

I then wire this cluster to the Register For Events node. From that point on it is up to me (the developer) to select which events I want to react to at design time for that Event Structure.

The reason I do this is I find this way very simple for what I want to do.

I also like to use the Timeout for how I thought it was intended

...it means that someone out in the world may have used this same idea for an actual realworld VI, which would make it hard to mutate away...

Given the above and that there are use cases on both sides, maybe it would be worthwhile to have two Timeout cases:

• Timeout - the current one where the behavior is to reset on any event received
• Timeout (Handled Events) - a new one where the behavior is to reset only on receiving any currently handled event

So, rather than a bug, maybe a gap in functionality has been identified?

...can be used only with NI 9401 ..

That is not entirely correct - it is any hardware timed DIO Module.

Also the cDAQ-9178 has two BNC connectors in which you should be able to access counters etc...

Kudos!

Hi Steve

Firstly, this is just my opinion. Secondly, if it works - it works (so good job ) - but I always like to ask myself can it be done better?

So on that note, comparing your two posts, it feels that you have just used LVOOP for the sake of it.

As a result you have coupled your UI to the logic of your code.

I discussed this on the darkside here with respect to the CLD so I won't regurgitate it again, only to say that you mention that...

There are no subvis which are not part of a class.

...yet you have used logic (nodes) on the top level BD which are not encapsulated.

Additionally, you have used typedefs that are not part of a Class, but which form an interface to your Class (i.e. public clusters) (private clusters is another topic for discussion when persisting data to disk not relevant to this one).

This is not always a bad thing, I do this for:

• UI Classes where the role of the Class is to essentially take data and format it for display (but note there is always that distinction) - I do this as opposed to breaking out an X-Control when I don't need to.
• Very Top Level Class which is just wrapping up all the Classes e.g. so method calls do not sit on the BD of a process\loop etc... - this is what I think you have done however, underneath it is still coupled.

Therefore, I think there is the opportunity to encapsulate more. However, given the size of the application it may be overkill, but would definitely be a good exercise.

Maybe this second version of the CLD practice exam (sprinkler controller) will be more exciting for people to review.

I don't think LVOOP makes it more exciting, perhaps using LabVIEW 8.6 instead of 2010 was a better idea this time to cover more reviewers? Although I prefer LVOOP when programming day-to-day, I ended up using a more traditional approach for the CLD given the nature of the question\solution, time available etc...

Cheers

-JG

As a side note to this thread, NI have a LabVIEW FPGA Compile Farm Toolkit which can speed up FPGA build time. The reason I mention that is there is a Cloud service (still in Beta I am guessing?) so you can offload the work and save on hardware.

Furthermore, given reports of 2+hr build times (I can hear ShaunR giggling), what makes the above more interesting is whether in the future this service could ever be offered (and would make sense to be offered) for a standard LabVIEW build?

...and continue working.

Oh yer, and this is how Mikael likes to build LabVIEW apps in parallel

Hello,

I recently add the following ideas to improve XControl in LabVIEW Idea Exchange.

1. Polymorphic XControl
2. undo step management in XControl
3. Add "Get focus" facade VI Event to XControl

Your thoughts (and kudos if you think it deserves it) about these are welcome.

Also, I encourage XControl fan to post on the idea exchange (fell free to add your idea to this thread) to see this awesome technology improved by NI

Regards

I support anyone lobbying to improve the X-Control

Hi,

I have some silly doubt regarding event structure. When ever I taken event structure it display some parameters inside the event structure. what does all mean Type, time, newval, oldval and ctlref. Can any one explaine me the meaning of those parameters. More empty event structure contains only type and time parameters inside it.

Hi Sjukheter

The Event Structure has an Event Data Node on the left hand side which outputs data for a configured event (when that event occurs) and is very similar to the Unbundle By Name node. As the data returned is specific to an event it will change from event to event however, there are some standard or common data that is returned each time i.e. what you can see with an 'empty event structure' - to answer part of your question:

Source - U32 value of the source of the event (LabVIEW UI, User Event etc...)

Type - Enum of the type of event (Key Up, Key Down etc...)

Time - U32 timestamp of when event occurred

For Filter events you will also see a Filter Node on the right hand side and this is similar to a Bundle By Name Node. These can be more complicated especially if you have multiple events structures configured for the same Filter event. Put simply, you can override data just by wiring it into the node, or you can leave it and no change to the data will occur. You can even ignore the event so no notification occurs.

I recommend you check out the LabVIEW help to find out more or do a quick search, here are a few links to get you started:

Event Structure Components

Notify and Filter Events

Using Events in LabVIEW

Also just by playing around with them and trying different stuff, you will pick up on it quick.

Cheers

-JG

Aside from the interesting situation it presents in the airport security lines.

It would make a search that much easier