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

One of my UIs has a problem where it can chug down if you throw too much data at it. The underlying problem is formatting I'm applying to a native LabVIEW multicolumn listbox (MCLB). I'm not aware of any way to get events out of the MCLB when an item is scrolled into view, etc, so the application just blindly applies formatting to the entire list. Not a problem when I wrote the application because the data set was at most bounded to perhaps 1000 rows. Being in R&D, we're never happy though and my colleagues who use the application started throwing data sets at it that can have something like 100 000 rows. Yeah, the UI bogs down for minutes at that point, even with UI updates being deferred etc. Simply performing hundreds of thousands of operations on the MCLB even with no UI updates takes patience. Now ideally I'd like to have better support for the native MCLB, but for now I need to work with what I got so I figured I'd kludge together a pseudo virtual MCLB in native G-code. Here's a proof of principle: virtual mlcb lv10.vi If you run the VI and generate some stupidly large data sets, say 100000x8, you'll see that the render time hopefully stays constant as you scroll through the data, and with a little luck is reasonably fast. Now if I could make a virtual tree view...

Hi, First off, i don't know if this post is in its correct category, or if the question has been answered before. I have been asking my dear friend google quite a bit but this time he/she unfortunately failed me. I was playing around with the labview provider interface (in lack of a better name) today, trying to create my own custom right click menus, to launch various labview plugins/scripts. What i did was taking an existing provider/plugin such as the SCC tool located in <LabVIEW dir>/resource/framework/provider/SCC , copy it, remove everything i didn't need from the toolkit (leaving only the interface vis) and point towards my own custom menu code/vi (using the "provider/API" vis to manipulate the menus) i kept the .ini file (Copy) intact. This all worked fine and i was ready to take the next step: creating everything from scratch "by my self", but here is where i got into trouble. What used to work just fine when stealing the SCC interface vis now didn't work at all. After some debugging i think i have narrowed it down to the signature used in the ini file that one have to add in the custom provider folder. This is the ini file i used/stole from the SCC folder: [Provider] SupportedInterface=SCC_Interface ProviderInterfaceVI=SCC_Provider_Interface.vi ItemInterfaceVI=SCC_Item_Interface.vi GlobalItemInterfaceVI=SCC_Global_Interface.vi IsPrimary=0 LicenseName=LabVIEW_Pro LicenseVersion=10.0.0 LicenseRestrictions=DisableDemoIfActivated InterfaceVersion=1.0 Signature=5X259R73LC93CCTK3LWBRTLJBS52CR9T My question to the bright people of Lava is the following: How the (##insert inappropriate words here##) do one generate the "Signature" key/checksum/XXX ??? I was hoping that it would be a MD5 or something similar but the MD5 generator in LabVIEW (file to MD5 thingy) only generates ASCII HEX values and this string (in the Signature field above) contains characters above "F". Also i don't know/understand for what portion of the file the signature is generated. Is the "Signature" field/line excluded when the calculation is done and then appended to the file? If anyone could shed some light on this it would be highly appreciated! (i'll bring kudos on next NI week!!) (P.S i have had a look at Jim's/JKI's "Right click framework" and considered it, but it didn't quite work so well under OS X and Linux as i had hoped + i was really hoping to get some answers for my own understanding on how LabVIEW calls the "providers" to see if my own interpretation so far is correct.) Regards, X

You could use the following code to set all cells of mclb to the same format. This not a "clear formatting" method, but it works and it's efficient. Regards, Olivier FormatAllCells.vi

No way, say it's ain't so. In other news, the sky is still blue. Well on Earth anyways, most of the time... I'm still pumped about this topic. Granted I got to spend zero time on implementing something like this this year (still very disappointed about that), but 2012 will be different. Yeah, that's it, different. What can I say, there's still a bit of foolish youthful optimism in me.