Prototyping is critical to getting a working design. On a complex new design, no one gets it right the first time — at least no one who is being honest with you.
When prototyping, I have found two opposite extremes that are easy to fall into:
This time we will be looking into the Houston, we have a problem code in detail. This is the cRIO air jet control system that we demonstrated at the National Instruments User Group in February.
We will have a chance to really dig into the details of the program and discuss the ins and outs of FPGA and RT programming on the cRIO. You will also have a chance to program your own control algorithm for the inverted spring pendulum device. Can you stabilize it? Harder yet, can you make it hold at an arbitrary position? It may be harder than you think!
Come with your laptop, your questions, and your idea for a clever algorithm to control two air jets on a spring.
This meeting will be at Seneca5, Tuesday March 2nd at 6:30. We serve pizza, so you can come straight from work.
Check out the LabVIEW Advanced User Group page for more details.
This month, we presented at the quarterly National Instruments LabVIEW User Group. We had a great turnout! The 27 people that attended crowded the room at Manchester Grill. We had some good food (Thanks NI!) and we had a great time learning about LabVIEW programming on the cRIO FPGA and RT.
Below are pictures of the event and the LabVIEW code for the program that we demonstrated.
We host the regular meeting of the LabVIEW Advanced User Group at our office each month.
This month, we are presenting at the quarterly National Instruments LabVIEW User Group. Details are below.
It is an NI event and lunch will be served, so you do have to register (but its FREE!). Register here
We host the regular meeting of the LabVIEW Advanced User Group at our office each month.
Good vision systems are difficult to engineer. Our brain, as far as computations are concerned, is a very parallel system. It can account for contrast and brightness, recognize and categorize a seemingly endless number of shapes, and set our eyes to focus faster than any commercial camera, all simultaneously. It can also, through the depth perception of having two eyes or through the patterns of experience, give volume to the two dimensional image your eyes obtain.
Replicating these tasks on a computer is nothing short of impossible with today’s level of research and design.
What the computer does well though is sequential logic very quickly. Vision systems use this to their advantage by constraining the vision problem to one task at the time. In the end the computer can attack and solve particular vision problems better than our own vision systems can.
Today we will be detecting the value of an off-the-shelf PSI gauge using NI Vision Builder. Hopefully our solution gives some insight into the current level of vision systems.
Multithread programming in traditional languages can be a challenge. The programmer is responsible for managing many things, such as:
LabVIEW, on the other hand, lends itself easily to multithreaded programming. In fact, if you follow the dataflow rules, multithreading will happen automatically when LabVIEW finds the opportunity.
You can make pop-up windows quickly and easily by using tab controls.
By using tab controls, you can create the same visual effect and the same functionality as a pop-up window, but you don’t need to create a sub-VI. Since you never leave the VI, you don’t need to worry about passing information into and out of the dialog, simplifiying the code.
While this technique may not be appropriate for every situation, it is a nice trick to have when you need a quick pop-up window.
Give it a try. An example VI is attached.
Download VI: QuickPopUp.vi
The standard LabVIEW listbox control has very archaic icons. So I made some improvements. You can use this control as a direct replacement for the standard control, but it looks a lot better.
This takes advantage of the properties for the listbox to load your own custom graphics.
Download VI: ListBoxIcons2.0.vi
One rule to remember when designing a user interface is to do things in standard ways.
For example, if you want to close a program in Windows, you click the red X button in the upper right-hand corner of the window. Most LabVIEW™ have a tell-tale “Stop” or “Done” button. That always bugs me. Why shouldn’t a LabVIEW program end the same way any other Windows program ends?
Error handling. You know you have to do…well, you should do it…well, maybe you will get the code working and then come back later and add proper error handling.
Let’s be honest, you will never go back and do it. If you can’t take time to do it right the first time, how do you expect to find time to do it over again?
Error handling is not the most fun aspect of programming, but doing it right can separate a buggy program from good solid code.
