jgcode

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

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. 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!

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!

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. 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. Everything has pros and cons that influence our design decisions (Queues vs Events etc...) - its nasty surprises I don't like

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?

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.

No probs 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 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 QFT ...lol... sorry couldn't resist

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.

Are you able to go into detail here? Thanks.

I think ShaunR is just shy too admit thats how he likes to program too 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.

Hey - if it works, it works ..lol

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).

lol

Great thread, I had no idea and I have to say I don't like to behavior. 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 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?

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... ...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. 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? Oh yer, and this is how Mikael likes to build LabVIEW apps in parallel

I support anyone lobbying to improve the X-Control

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