Leaderboard

I normally don't post on LAVA, but lately I have been experimenting with the WebSocket protocol, ecmascript, and the SVG DOM for creating animated browser displays with data streamed from LabVIEW. The technique is surprisingly simple. All you have to do is create a script to change the attributes of the SVG elements using the Document Object Model. The WebSocket protocol has a built in message event handler that allows you to create your own script function which executes when messages are received. The browser connects to the socket server and sends a handshake when you create the WebSocket object in script. All you need do is put a TCP/IP listerner in your diagram and return this handshake as described in the wikipedia article on WebSockets. Once the connection is made, you can stream bidirectional data between your LabVIEW application and any bleeding edge browser (Firefox 4, Chrome 9, Safari, IE9?). You can use the DOM to set the transform attributes of SVG elements using the streamed info (rotate, scale, set heigh, width, line points, etc.). Now that we can all design our own GUI objects using Inkscape (free), I suggest a concerted effor to develop a standard SVG format, streaming protocol (based on WebSockets) and open-source script library. The very best thing about this is that it is all FREE, and runs on any platform that has an HTML5/SVG/WebSockets supporting browser (I'm keeping my fingers crossed for the next firmware revision of the Nintendo DSi), and requires NO PLUGINS. So all you folks with iOS and Android who feel left out by the WebUI Builder, or those of us who are infurated by it's $1500/yr price tag (after spending $ on LabVIEW RT/FPGA), Cheer Up! Here are some screenshots of my efforts. The files are opened in the OS, but will also work when served by the old-fashioned "non-webservices" LV web server (you gotta add an SVG mime type to the mime-types file). You can also use RGraph Library and the HTML <canvas> tag if you want to implement a non-SVG browser solution. The library is free for non-commercial use. I suggest a community effort the create the standard SVG formats for UI elements, and a free, open-source ecmascript library for handling the messaging and DOM animation tasks. If there is interest, I will upload my script as a starting point, but I must warn that there is much improvement needed. sm

I doubt it. (I hope not, seeing as how I didn't create one for my exam.) I view XControls as an encapsulated unit of UI functionality, much in the same way a class is an encapsulated unit of programmic functionality. I have found them most useful when I want to reuse some bit of customized UI behavior in multiple places, which doesn't happen often. Usually I just customize the control's behavior on the VI's block diagram rather than creating an xctl. I have too many crashes and issues with xctls to want to use them more than necessary. My personal opinion is that there are better ways to spend your time than by creating an xctl. Our local sales rep arranged a con call with an exam grader when several people in the area were preparing for exams. He indicated the sample exam is an actual solution turned in by an applicant--it's not an "ideal" solution. My perception of the grader's comments were that he thought the solution focused a little too much on implementation and not enough on architecture. Nevertheless, he did indicate the applicant scored somewhere in the 90-95 range. However, I absolutely agree with JG. Anyone claiming to be an architect--regardless of certification--ought to be familiar with xcontrols.

I prefer creating a property node for any of the controls in the FP. It doesn't matter which property it is and you don't have to do anything with it. The advantage to doing this is that you can add a comment next to the property node so that this does not break accidentally. I have also asked relevant people at NI specifically about this and they said this shouldn't break in future versions due to future optimizations, etc.

Well, maybe you should just read connected channels not every channel! Or use some case structure, if Temperature>1000°C then temperature=inf

I suggest that every time you create a new Method in your class, check if it can be placed in the generic base class or if it belongs to the Real test class. I normally create these methods in a Test Case class: The Main VI could be called stand alone or be a sub VI in a top level application. If the Main VI is runs stand alone I normally make sure the TestCase Base constructor creates all instruments needed for the test case. You can use Symbio's UML modeller to create your LabVIEW classes direct from the UML class diagram. Cheers, Mike