TobyD

I'm curious what people think of the Automatic error handling options in LabVIEW. Is this something you leave enabled? Do you disable it? Why?

QUOTE (Eugen Graf @ Aug 27 2008, 09:28 AM) See http://forums.jkisoft.com/index.php?showtopic=501' rel='nofollow' target="_blank">this.

QUOTE (Tom Bress @ Aug 26 2008, 10:36 AM) No problem - Thanks for the feedback. I'll take another crack at it when I get a chance. I could argue that I fully met the design specification, but when I really think about the exercise it never really made sense to do it the way I did . On a tangent...I disagree that the type defined enum is always the best choice for a state machine. I know it is currently considered the only way to go, and I think with most large applications with many states it is useful, but for an application like this with only a few states - a simple string is faster/easier to implement, as clear as a type def enum, and the chances of error are minimal. Even in a larger application, the inclusion of a default state named something like "UndefinedState" will quickly catch any typos (although changing a state name can be cumbersome). Toby

QUOTE (Karissap @ Aug 25 2008, 04:00 PM) True, there are cases where faulty software has killed or seriously injured people - but I still don't think writing software and flying a plane have too much in common. We could make training and certification a requirement to write code for any commercial application as it is a requirement to fly a plane, but I don't think that would prevent potentially deadly bugs from creeping into the code. The killer spaghetti code will always find a way :ninja:

QUOTE (TobyD @ Aug 12 2008, 09:06 AM) Is it OK to quote myself? Thanks to Ben (neB) for a push in the right direction I was able to contact Zaki Chasmawala - Senior Engineer in Training & Certification at NI. He gave me some good information, including the slides from a CLA prep course that was presented pre-NIWeek. Here's what he had to say... QUOTE (Zaki @ Aug 25 2008, 08:46 PM) The project on the CLA exam is a CLD project for which the UI, data structures are not given and the functionality is not as clearly defined as in the CLD project. For the exam, you will have to complete a project planning document in a Notepad/WordPad document with short answers - three to five sentences or a bulleted list. At a high level, for the project architecture, you will have to develop the following: - main UI - modules (SubVIs with their own hierarchy), - the main architecture (example: producer/consumer with events), - architecture for the modules - major data structures - documentation (in the form of instructions) to developers to complete the functionality. And here are the slides: http://lavag.org/old_files/post-8758-1219768547.zip'>Download File:post-8758-1219768547.zip

QUOTE (JiMM @ Aug 25 2008, 03:38 PM) Sure. Here is what I did (saved as 8.0 and with a pretty icon added). I think the most important thing with documentation is to make sure every control or indicator on the front panel has a description and Tip Strip filled in and that every significant wire has a label. It is also critical that every subVI has a description. In this case, I didn't use any subVIs, but my main vi should have a description. As Tom mentioned, if this were for certification, it should also be done in a project and be well commented. One more piece of advice - fill in the descriptions and tip strips as you go. You probably won't have time at the end to go back and add them and documentation is the easiest 10 points on the exam. http://lavag.org/old_files/post-8758-1219767455.vi'>Download File:post-8758-1219767455.vi

QUOTE (Tom Bress @ Aug 25 2008, 10:32 AM) Actually I did do most of that except the pretty icon and the LabVIEW project. I beat the rest of it into myself when I was studying for the CLD (I got a 10/10 on documentation) so it has become a habit to document as I go. I have found that even if I think I'll never look at a piece of code again - chances are I will go back to it at some point and the comments and tip strips really help figure out what I was doing at the time.

QUOTE (Tom Bress @ Aug 25 2008, 09:36 AM) Thanks Tom! I went through the exercise and it worked the first time I hit the run button (and even got the extra credit :thumbup: ). I would love to see more examples, but now that you have taken the test you are probably a lot more limited in what you can post. Do you have anything else that you came up with before the exam? :ninja: Toby

QUOTE (Norm Kirchner @ Aug 25 2008, 09:41 AM) http://forums.lavag.org/The-Art-of-Creating-Dynamic-t3760.html' target="_blank">Here it is. LabVIEWSearch.com found it as the first entry when I put in "art of creating dynamic"

QUOTE (jorwex @ Aug 21 2008, 02:44 PM) Hello!

QUOTE (martin zhxie @ Aug 21 2008, 01:30 PM) Can you describe the flow of your program and the interaction between TestStand and LabVIEW? Maybe post a flowchart if you have one. I'm curious what you are trying to do. There may be a better way to do it.

QUOTE (crelf @ Aug 21 2008, 12:34 PM) Not for those who are already active in the community and could rack up enough recert units through normal activity.

QUOTE (mross @ Aug 21 2008, 09:25 AM) I agree that in this example it makes little difference, but I think we have all seen examples where a large vi will be completely "sequence structured" so that a single vi can run at the proper time. Generally this method of wrapping a single vi in a sequence structure is less intrusive to the block diagram and still forces the programmer to be conscious of dataflow in the rest of the program.

QUOTE (eaolson @ Aug 21 2008, 08:08 AM) I agree with Tom on this one. It's would be best to wrap it as a subVI, but if you insist on using the sequence structure there is still no need to wrap everything. It is only necessary to place the "offending non-error-propagating native function" inside the sequence structure. http://lavag.org/old_files/monthly_08_2008/post-8758-1219335175.png' target="_blank">

QUOTE (dannyt @ Aug 21 2008, 02:01 AM) There are no tricks that I am aware of for pulling out this extra info. If you have it working with the parser I'd stick with that.

QUOTE (martin zhxie @ Aug 20 2008, 02:01 PM) Sorry about that I can't save back to 7.1, but here is a screenshot (it's pretty simple) and a version saved in 8.0. Maybe someone else can save it back to 7.1 if the screenshot isn't enough for you to recreate it. Download File:post-8758-1219267020.vi

QUOTE (electrika @ Aug 20 2008, 10:33 AM) Do you know about the context help window? Press Ctrl-h to bring it up, then hover over the subvi you would like to know more about. If the original programmer documented anything, you'll see more information about it in the context help window. 1. Based on the extremely limited information available, I would guess that this subvi sets the velocity of a given axis in um/s 2. Your guess is better than mine because you can see all of the code, but they appear to be global variables that are storing status information

I've always done it like Ben (take off the true constant and you'll get the network machine name)...

QUOTE (martin zhxie @ Aug 19 2008, 12:51 PM) This may be more simplified than what you are trying to do, but if you send a reference to the Sequence Context from TestStand into LabVIEW, you can directly access the TestStand Variables. I have attached a small vi to demo this. You will have to create a Locals.Numeric variable in TestStand and then call this vi from TestStand. Setup the inputs as shown in the picture below. When you run it, it should increment the Locals.Numeric variable by one (you'll have to watch the variable in the watch window to see this happen). Download File:post-8758-1219255987.vi

QUOTE (Karissap @ Aug 19 2008, 05:57 PM) I like the idea of extra training counting as a re-cert. This would require that NI continually come up with new and interesting classes to offer though. However, I think there are some innate differences between a software certification and a pilots license. When flying a plane I am sure you have to be up to date on all the FAA regulations, airport/tower procedures, etc. Peoples lives and safety depend on these rules. If I write ugly code, it is not usually going to physically harm anything (not that I would ever write ugly code ). That said, my brother and his wife are both registered nurses. Neither of them has worked as a nurse for the last 3 years, but they continue to pay a small fee each year to keep their RN licenses active in case they ever want to get back into nursing. There is no recertification required at all. They could come back after 15 years (and they both know people who have) and start right up, notwithstanding the advances in medical technology, etc. (There is not really a point to this paragraph, just thought it was interesting).

I don't agree that certification should expire. I think a better system is to have the certification linked to a LabVIEW version number. Perhaps with each major release (7.x, 8.x, 9.x, etc) NI could revise the test and come up with a new certification. This would encourage people to re-certify, but they could still claim CLD in LV 8.x 10 years from now (for what it would be worth). -Toby

QUOTE (jdunham @ Aug 19 2008, 12:19 PM) Careful - This could send us off on a whole different tangent

QUOTE (neB @ Aug 19 2008, 07:54 AM) Many companies have started running credit checks on potential employees to get an idea of how responsible they are. The thinking is that people with poor credit tend to miss more work and are less productive than those with good credit - those with financial problems may be more likely to steal from the company and/or accept bribes in return for company secrets. With all these stereotypes linked to poor credit, I think it is less intrusive to ask a question about finances in an interview. This at least gives the interviewee a chance to explain their circumstances.

QUOTE (electrika @ Aug 18 2008, 10:05 AM) We are going to need a lot more information. It is difficult to answer your question without knowing what you are controlling, what are you controlling it with (hardware used), what have you already tried, etc. Post your code so we can see what you are working with.

The problem lies in the flow of your data. In LabVIEW, a structure will never begin execution until all of its inputs have data. The loop that you want to run first is relying on data from the second loop (the stop boolean). The first loop will not start to run until it sees data on that input terminal, but that data does not arrive until the second loop stops and outputs its data. I would highly recommend spending some time here and getting a good book (I found "LabVIEW For Everyone" to be extremely helpful and easy to follow) to learn the basics of dataflow in LabVIEW and the best practices for creating easy to read, expandable code. It will make your life a lot easier if you can break the habit of using all those stacked sequences.