-
Posts
161 -
Joined
-
Last visited
-
Days Won
3
Content Type
Profiles
Forums
Downloads
Gallery
Everything posted by SteveChandler
-
Self-addressed stamped envelopes
SteveChandler replied to drjdpowell's topic in Application Design & Architecture
I use it. What I like most about it is it's simplicity. The community page lists 38 members. I'm sure I am not the only other guy who uses it -
I would like to take this opportunity to pimp one of my ideas on the Exchange - Bundled Project Library. Only 12 votes for something that will make all of this easier? It contains all the benefits of a packed project library, llb and lvlib. The only reason I don't use llbs is that I can not always use llbs. The way I program these days I get name collisions more often than not. I have put several ideas on the exchange and out of all of them this is the one I would most like to see implemented.
-
Cool it works I ran into the same error 6 problem. I am on vacation and when I get back to work I will test it on a very large application that is full of globals.
-
No go. It was a little closer than I expected and I think I might be able to pass next time. There were several modules and I started designing them in order. I spent too much time on each and just ran out of time. I aced style and for documentation, architecture and requirements I had about the same percentage of available points as the percentage of modules that I completed. Next time I will take a more iterative approach. I think I spent too much time writing code. I didn't actually try to do full implementation but I did things like create the required case structures, loops, etc. This brings up a question. Is it possible to pass without writing any code, meaning only subvis, connector panes and typedefs? I tried to create about as much code as what is in the sample solution. Is it possible to pass with none at all? I really wish there were more sample exams with solutions. It would really be nice if NI could release samples of failing solutions and explanations of what should have been done differently. I will probably give it a few months before my next attempt.
-
The comment was supposed to be funny. Look at the date But now I hear we have until October 21st before the world ends
-
Disconnecting from *.lvlib
SteveChandler replied to neo_zion's topic in Application Builder, Installers and code distribution
Well the customer is always right. Or at least they always need you to make them feel that way. I have found that putting an idea into the customers head in such a way that they think it was their idea is the best way to handle these types of customers. The best way to do that is with the right questions. -
Is LabVIEW a "pure" dataflow language?
SteveChandler replied to SteveChandler's topic in LAVA Lounge
Oh yea? Well I just got home from the hardware store where I was buying some caulking to plug a hole under my sliding glass door that ants were crawling through -
No, nothing like that. In fact I was surprised at how similar the sample exam was to the actual exam. I know that with enough time I would have completed everything. Those four hours really do fly. If I did pass it was probably close. If I did not pass then, well, it's not like it's the end of the world My goal is to pass the CLA before 2012 so I still have lot's of time.
-
I just got done with my first attempt at CLA certification. I may be close to 70% but I was already expecting to have to do this again so no worries if I need another try. It's much more difficult than it looks! When I first looked at it I thought I would nail it but after three hours I wasn't so sure. To be continued...
-
Please vote for the Bundled Project Library. It is like a Packed Project Library but is not compiled. It would be an lvlibb - a single file containing everything in the library.
-
It says not found.
-
For the CLD you can use whatever reasonable architecture you are comfortable with as long as it is a state machine type of architecture. No stacked sequence structures with a dozen unlabeled sequence locals! I don't have access to LabVIEW at the moment but as I recall you have two loops and each has it's own event structure and you communicate between the two with user events. I think that should be fine but the architecture that is probably more preferable, or at least more common, is the producer/consumer. You have one loop with an event structure that sends messages to the second using a queue. That second loop sends messages back to the first loop using user events. If you want to get some attention here on Lava just use a class for something simple like timing and make the claim that your solution is object oriented Have you tried asking for feedback on the NI forums?
-
Christopher, I admit I am just making a guess as to why NI would want you to pass each exam in order. It seems reasonable or at least it did when I wrote it. Another seemingly reasonable guess is based on what you just said. NI wants to make sure a CLD knows the CLAD stuff and that a CLA knows what it is to be a CLD. Since nobody would take a ten hour CLA test encompassing all three areas they broke it up. Hey NI can you tell us why?
-
Yep CLAD is a prerequisite for CLD which is a prerequisite for CLA. You might want to forward this link to your boss. Maybe you can make a deal that you pay for the CLD if he pays for the CLAD. It wouldn't hurt to send an email to NI explaining the situation and asking for a discount coupon. All they can do is say no right? I don't think NI really makes a whole lot of money on the certification. For the CLAD Pearson VUE probably keeps most of it and there is some administrative cost at NI associated with it. The CLD and CLA are four hours of test time plus review by two NI engineers. At $299 I don't think there is much profit if any. And for re-certification Pearson VUE again probably pockets a big chunk of the money. [Edit] I think maybe the reason they want you to take the CLAD first is evidence that they don't make any money on the process. If you had someone coming in for the CLD test who doesn't know what a state machine or a typedef is and only uses stacked sequence structures, local variables and sequence locals, doesn't know about the icon editor or that they can easily make their own context help for vis, doesn't even use subvis, it will be a waste of everyones time. If you pass the CLAD they know you at least have a shot at passing. If certification were a profit center with gobs of margin they probably wouldn't have that requirement.
-
I couldn't find it either. But I did find confirmation in this post on the Dark Side by Wes P who is a Certification Engineer for NI.
-
When did you take the recert? There is a one year grace period where your status is changed to "suspended" or "inactive" or something like that. You can still take the CLAR during this time and do not have to start at the beginning.
-
If that is true it is in the engineering process and technical writing. If you had the time write a book on the topics you write about here on Lava it could easily be the best selling LabVIEW book. You write some pretty long posts and I typically loose interest in long posts. But your writing style is very gripping, never dull, and always educational. I read every word - sometimes twice! I have an ulterior motive in wanting you to write a book. I am a book junkie and already have all the good LabVIEW books. I need another one! LVOOP is in it's infancy but what better time? There is always the second edition when LVOOP matures! Of course it would mean you would have less time for us here on Lava so maybe it is better you don't.
-
The main startup vi should be at the top level of the hierarchy. I personally hate auto-populating folders but that should definately not have any impact on your score. Some of your subvis do not have documentation properties. Make sure every one does including the main vi. That was the only point I lost on documentation. Some of your controls do not have tip-strips. A few backwards wires You should put labels on the shift register wires. One way to ensure you got all the documentation properties is to use view/hierarchy and mouse over the subvis. You can right click from the hierarchy view to open the vi properties. A better way to make sure is to immediately fill it the documentation when you create the vi. Same for tip-strips on controls.
-
Is LabVIEW a "pure" dataflow language?
SteveChandler replied to SteveChandler's topic in LAVA Lounge
Ah that is the crux of it. What I was getting at earlier is that something somewhere is polling for a message in a queue even though, as AQ says, the thread with the dequeue is fast asleep. And if code is triggered by a state change that is event driven. But something is continuously checking for the state change. I also got my start in extremely low level assembly language and most of my experience with event driven programming is Twisted. That has to impact on my way of viewing the world. -
Is LabVIEW a "pure" dataflow language?
SteveChandler replied to SteveChandler's topic in LAVA Lounge
I think you are right - it is all about definitions. My definition is that if Windows is checking something every time an ISR is fired it is still polling regardless of the fact that the check was fired by a hardware interrupt. I think what you are saying is that since the code that does the check is automatically fired directly or indirectly by the ISR it is not polling. I can kind of understand that definition. -
Is LabVIEW a "pure" dataflow language?
SteveChandler replied to SteveChandler's topic in LAVA Lounge
Hey, no worries, this has turned into a much more interesting thread than I had hoped for! About the only input I would have is on polling vs. not polling. I think you hit the nail on the head. At a low enough level every event driven programming environment is in fact polling. I just read the link to AQs post that jdunham provided where he said there is no CPU activity from a sleeping queue prim. He would know and I would agree. But he goes on to say that the thread with the queue prim goes to sleep until another obviously running thread wakes it up. The distinction between event driven vs. polling is really just a matter of perspective. It is event driven if the polling is provided for you. The LabVIEW runtime never really sleeps and it is doing the polling on behalf of the sleeping thread with the queue prim. Even if it does sleep it is awakened by the OS which is doing the polling. CPUs have come a long way but they still need to continuously execute instructions which conditionally execute other instructions I wish I could write pages of interesting thoughts but I will go back to lurk mode for a while. -
Welcome!
-
Is LabVIEW a "pure" dataflow language?
SteveChandler replied to SteveChandler's topic in LAVA Lounge
Michael, I was probably a little unclear. This is not a suggestion or even a programming issue that I am having. It is just one of those random thoughts swirling around in my head Yair, I have no reasoning other than what I have already said. LabVIEW is indeed a pure dataflow language up to the boundry of a node. This is perfectly reasonable and I would not want it to change. It could be an interesting execution option. More likely it would be an option available only for inlined subvis. Mark, I agree that it is pure dataflw up to the node. But it would be more pure to let the outputs become available naturally as if the subvi were in the top level diagram. And yes it would be very difficult to understand and debug code. The node boundary is a very logical place to control dataflow. We do need a way to control the flow of execution which is a very good use for the error wire. Controlling execution order is what strikes me as less pure dataflow. I was reading a post on the idea exchange that got me thinking about this. Somewhere in an alternate universe NI implemented the subvi such that outputs become available when they are ready rather than waiting for them all to be ready. I am sure glad that I do not program in that universe! -
Is LabVIEW a "pure" dataflow language?
SteveChandler replied to SteveChandler's topic in LAVA Lounge
Yes two parallel tasks belong in separate vis. The thing I was getting at is that subvis draw an implicit sequence structure around the code which is why you can run an error wire straight through it to control execution order. If outputs became available as soon as they were ready then all hell would break loose with existing code! The little subvi with error in and error out and Wait mS that comes in so handy would not work anymore since error out would be immediately available. I also would not want this to change. Maybe there could be a setting in properties under execution. I don't even think I have ever had a need for something like this. But I think that a pure dataflow language would make vi outputs available as they become available. I just did an experiment. I inlined the dual adder subvi and changed the wait to 2500mS then ran the calling vi. Both sum1 and sum2 became available at the same time. So inlining doesn't really inline the code. It does but it effectively places a single frame sequence structure around it. This is a good thing - try to imagine the confusion if it didn't! And no I still don't have a point or any kind of programming issue that I am trying to resolve. This is just some stuff that I have been thinking about lately. -
The outputs from subvis are not available until all of outputs are available even without data dependencies. LabVIEW would be more of a pure dataflow language if vi outputs became available as soon as they are ready. This is not something for the idea exchange. Changing this behavior would break nearly all code since the error cluster is probably used more as a sequence structure wire than it is for error handling. I don't know if I have a point. Maybe it will spark an interesting philosophical debate about using the error cluster as a sequence structure wire. It is necessary in a lot of situations. But that causes LabVIEW code to execute in a programmer controlled sequence making it less "dataflowey". A picture is worth a thousand words. And yes if there are two independent functions they don't belong in the same vi - this is just for illustration.