Leaderboard

Name: Dispatcher Submitter: ShaunR Submitted: 07 Sep 2010 File Updated: 03 Jan 2011 Category: Remote Control, Monitoring and the Internet LabVIEW Version: 2009 License Type: Other (included with download) This is a Publisher/Subscriber implementation of network communications. The package is comprised of two main parts. 1. A Dispatcher that handles connection requests. 2. An API for interacting with the Dispatcher. Overview. Most people are probably familiar with RSS feeds. An RSS feed is an example of a publisher/subscriber implementation, where information is "published" onto the internet and people may "subscribe" to updates using their browser or some other client. A single published service may have millions on subscribers and publish its data every few hours as data changes or periodically, maybe once or twice a day. This package contains a similar implementation where a client "subscribes" to a "publisher", however, it is geared towards high bandwidth data streaming across a local network. So, unlike its internet counterpart, it is not attempting to service millions of clients who require an update once or twice a day. But service a few (maybe 1-10) clients every few seconds or even milliseconds. Detail: The main focus of this package is the Dispatcher which facilitates the publisher/subscriber environment. The implementation can support many network topologies that suit the developers requirements. For example: A single dispatcher may be located on a remote machine and all publishers and subscribers are remote and communicate through it (centralised). Alternatively, there may be many dispatchers on different machines, each with their own cluster of local services and the subscriber connects to the machine that contains the publisher of interest (decentralised). Or even a mixture of both. The implementation is not rigid and allows for the developer to choose the topology simply by installing once or more dispatchers and initiating a connection. An API is provided to enable interaction with the Dispatcher to query its services, request a connection and send/receive data. Additional Features: Supports data-stream encryption (blowfish). Installation: Unzip to a directory of your choice. Required Packages: Labview 9.0 or greater. Transport.lvlib (Included) Queue.vi (Included) Position Form.vi (Included) Stop.vi (Included) Elapsed Time.vi (Included) Known Issues. None. Versioning: Current version 1.0. See changelog.txt. Contact: PM ShaunR on lavag.org (http://www.lavag.org) Click here to download this file

I looked through that thread and I wonder if there's a better implementation of the notifier behavior like using subscribers or something drjdpowell: Here's how this affects messages. I defeated the reentrancy by wrapping your "wait for notification" in a nonreentrant subVI. If "data 1" executes first, all messages are delivered nicely. If data 2 fires first (as shown in the image below), you get a timeout (or a deadlock if the timeout is -1) You can make it so both messages are delivered by using the "Wait on notification with history" primitive in your "wait on notification" VI instead of the normal "wait on notification" primitive.

Darren, that is quite a few long nights away. To whet your appetite, have many Slylandros!

Not trying to change the subject, but I avoid LLBs at all costs. Every time I find one the first thing I do is extract the VIs from it. I feel that way because it seems like a zip or an archive, where to use it with the normal tools, I need to extract it anyway. I also know there were odd bugs a while ago where the LLB would get corrupted and ruin all the VIs in it. I know that is petty especially since it probably has been fixed long ago, but it still lingers as a thing to avoid in my mind.

Yeah it should be possible. But rather than trying to read the file into LabVIEW, can you just use the hex file in a commandline program to load your device? AVRDUDE has command line support so you can provide the file and interface and it uploads it. You can make this a batch file if you wanted which is probably easier than LabVIEW.

Hi Guys, I'm due to sit the CLD this coming week and I was wondering if I could get your insight into it. Here's my current frame of mind: I just jumped into the sprinkler practice exam. Sat down and drew out the various state transitions, highlighted all the important info in the brief such as timing precision, the states that controls should be in during various running states, etc. I thought for a little bit about how best to handle it and reached for what I've been comfortable with developing at my work (for kind of a large scale distributed instrument), a Queued Message Handler. Questions: By convention, what's the best way to handle sequencing in a queued message handler where you have to be able to arbitrarily exit a sequence to transition to a different state? My thoughts were enqueue at front of a queue and flush remaining elements for priority messages like state changes (into "Setup" state for example). I don't like the idea of a QMH enqueueing to itself, even though it seems like the easiest way to solve the problem. Am I being irrational, or should I break out the actual "Running" state into a Job Queue? If so, how then do you handle the case where the job sequence needs to repeat? Should I be trying to shoehorn data such as the sequence array into a FGV? Or is it appropriate to maintain that data in the QMH data wire? When using a User Event loop for the main message producer in a UI, which loop should be responsible for maintaining control data? Given that sometimes the consumer (message handler) will want to access data that hasn't been explicitly messaged to it in that particular message. Should I just access the control value by property node (everything I've read says no)? Or should every single control change generate an event which sends a "Data Update" message to the message handler which stores that data in it's main data wire. In other words, should the message handler maintain control data information. Should Controls themselves in a QMH type UI always be in the User Event case they trigger? Should they sit on the Block Diagram by themselves? Should they sit in Message Cases where they're needed (once again back to this question of who controls the data in a QMH UI). I then tried using the LV2012 state machine project example, but it felt weird to me. There's a state which locks while it handles user events... How does that make any sense when you need to check the value of a control on every iteration? Then you have some states reading local variables of controls, while the user event state maintains the control itself... It just feels icky. Finally, I caved and had a look at the example solution. I found it to be really direct. I'm not sure that it's "easily scaleable" as I currently understand the concept. For example, the logic at the end of each loop which decides which state to go into; What if there's another button that the user might want to press (another state), are you supposed to just add chains of selectors ad nauseum? I think I'm getting caught in that trap of overweighting the importance of extensibility ("I must handle everything!!!") My final questions are: Should I switch my focus to tooling specific state machines to handle these specific problems, rather than to my mind, the more extensible approach of building QMHs? If I do use enumerated state machines rather than QMHs, should I bother with User Event structures, or just monitor controls directly? Really looking forward to hearing from you guys. Thanks in advance. Alex

Well, I sat it. Treadmill. With 25 mins to go I would have said I was a happy pass, then I decided to go for the last 10% of functionality. Unfortunately I had made some assumptions about timing in my accumulators and as a result the changes I made brought the app from about 90% functional to probably less than 20%. I was happy with style and documentation, but I'm pretty depressed as I think I'm gonna fall down on functionality , and all I needed to do in retrospect was change one input. Anway, just had to vent. Also, the LV2012 project templates are badly written. All the red check mark failures in VI analyzer came directly from their dequeue/enqueue/obtain wrappers. I really hope they don't just blindly subtract marks for red checks.

Here's round 2, with the ATM this time. Thanks for all you guy's advice so far! Once again, only the work I could get done in 4 hours. I really need to resolve this question of whether you can use LV's internal templates or not? I assumed I couldn't for this one and built the QMH from the ground up. Would have got this done a lot faster if I could have avoided that. This one, the commenting is a lot worse. Aside from that, anyone got any structural advice? I used the Queue timeout to decide when to kick the user off, rather than build a FGV timer, would I lose marks for this? ATM Prac Exam.zip

Thanks for the advice guys. I took it in and sat down and did the Carwash practise exam today. Just smashed it out in a simple "control polling" state machine. I've attached it below in case anyone wants to have a glance at it. I've also posted it in that thread you linked Todd, so hopefully will get some feedback before this Thursday (the big day!). Car Wash Prac Exam.zip

Hey Alex, You're asking a lot of very specific questions that, to me, boil down to stylistic choices. I think the question underlying the specifics is: how much should you try to program the "right in the REAL WORLD" way versus "right for the TEST" way? My response would be: code in the way that lets you complete all the requirements cleanly, within the time limit. The number one problem experienced LabVIEW programmers have with the CLD is the time limit. I know a ton of super experienced folks who failed the exam because they did not adjust their individual styles to match the time limit requirements of the test. If you can complete the examples with a clean application using your typical programming style, and make it as extensible as you would like to in the real world: great! Do that for the exam. If you tackle the practice exams with your usual mindset and coding style, and end up running short on time... then you might need to start sacrificing the "real world" extensibility and priorities in favor of coding to what the test is asking for. As you note, the example solutions are incredibly straightforward and simple. They're definitely something that an experienced coder should be able to crank out in 4 hours. They would probably also present problems in terms of long-term maintainability in the event someone wanted to make modifications or additions in the future. But they're presented as example solutions for a very important reasons: they are actual exam submissions that PASSED. Do all the practice exams, ESPECIALLY the more recent examples of the Car Wash, Boiler, and ATM. The Traffic Light and Sprinkler examples are older and aren't reflective of the current 4-hour exams. Try coding them using different design patterns. TIME YOURSELF. Make sure at the 4-hour mark you've cleared the broken run arrow and left notes for any unfinished code. Sorry I didn't directly answer your specific queries, but I hope this was at least a little helpful anyway.