LabVIEW, Websockets, and SVG

[lordsathish]

ShaunR, Will you be posting your fixed code

[David Wisti]

Wow that is a nice mirror! I've updated the Websocket code and wrapped everything into a class. Also updated the chat client and added in a chat server that echos back what you send. Still struggling with the close handshake and I'm not sure if its 100% yet.

WebSocket Chat.zip

[Jon Kokott]

chorme "16.0.912.63 m" is immediately closing the connection, anyone got it to work?

[Jon Kokott]

I'm assuming that this information is correct for chrome:

http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-17#page-7

section 1.3

This says that the protocal uses a SHA-1 hash, whereas the example is using a MD5. I'll start with that is suppose.

[Jon Kokott]

So the connection is actually being established now (it was using the incorrect hash), but I get an error code 62 on the first write to the connection...

[ShaunR]

ShaunR, Will you be posting your fixed code

Not sure what you mean by "fixed code". But I won't be releasing it until the api is completed and tested (it's a bit of a mess at the mo'). I'm currently up to supporting Hybi 17, 10,8, 6 and 00 (looking at Hixie and auto negotiation now) and have a prototype library for exporting events and commands (i.e. for remote monitoring), but still need to figure out the reciprocal methods. And, (this'll surprise a few people) some of it is LVOOP. . Oh. And finally, you get events for errors, status, messages etc

[mje]

And, (this'll surprise a few people) some of it is LVOOP.

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.

[ShaunR]

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.

Yup. It's not as clean as I usually like (can't use polymorphic VI's with dynamic terminals) but I needed to maintain state on a per-connection basis. So this is one of the rare instances where it is the better choice. It won't happen again, I promise (Sky's always grey over here )

Edited December 20, 2011 by ShaunR

[David Wisti]

I'm currently up to supporting Hybi 17, 10,8, 6 and 00 (looking at Hixie and auto negotiation now)

I'm curious, why are you supporting older versions of the protocol? What is auto negotiation in Websockets?

[ShaunR]

I'm curious, why are you supporting older versions of the protocol? What is auto negotiation in Websockets?

Because (for example, currently) Chrome uses Hibi 10, Firefox uses Hybi 9, I.E 10 (will use) Hybi 10, IE.9 (with HTML5 Labs plugin) supports Hybi 6 and Safari (different flavours) supports Hixie 75,76 or Hybi 00.

The specs are still fluid and browsers are having difficulty keeping up. If it's to be robust, then really I have to support all of them and besides, some of my favourite stock tickers are still on the old versions

Auto-negotiation:

In the latest specs, there is a negotiation phase whereby the client requests a connection and the server replies back with the supported protocols. That's part of it (for the server). The other part is the brute force client connection whereby you iteratively try each protocol until one works. This is one of the reasons why I needed to move to a class since with multiple connections all (potentially) talking different protocols, the reads and writes need to switch on each call and maintain their state (i.e closed, connecting etc). Rather than writing a connection manager, it made sense to bundle that info with the class data. Besides. this is TCPIP over HTTP so performance is secondary

Edited December 20, 2011 by ShaunR

[smarlow]

Hello, Everybody, I am back!

I have finished an 'alpha' version of the SVG demo program that complies with the new websocket protocol (RFC6455). Below is a rough list of release notes, along with a 'to do' list that I will be working on in the coming weeks.

Changes:

1. Changed the handshake and websocket read/write VI's to conform to the RFC6455 version of the websocket protocol currently supported by Chrome 16.

2. Replaced the string indicator on the main front panel with a dialog that pops up when a message is received from the client (from clicking the buttons and switch on the SVG document.

3. Tested the demo with Chrome version 16.0.912.75 m. Seems to work OK so far. If you find bugs, let me know. I did not test the script and program with any other browser. I use Chrome exclusively, with the intention of using this system with Android tablets and Chrome OS. I do not currently own a tablet, so if anyone tests it, please

4. Cleaned up the folder system for the project and got rid of the RGraph library demo, as well as a bunch of other files that were not used and cluttering up the folders. I will no longer be working with the RGraph library, and will instead focus on the webpanel library.

As with the previous version, open the WebPanel project and the SVGDemo VI. Run the VI, then open the \www\WebPanelTest.svg file on the same computer. It should connect to the listener and begin updating.

Disclaimer:

Please test and use the library however you wish. No warranty is implied, and I am not responsible for anything that happens as a result of using this code. Downloading the file acknowledges this disclaimer.

WPLavaG.zip

LabVIEW 2009 or later is required. Please contact me for earlier versions (will need 8.5 min due to the use of classes).

My to do list (not necessarily in the order presented here)

1. Change my web host to a suitable provider and migrate the files to a subversion directory.

2. Rework the websocket Labview Class and add dynamic dispatching to accomodate future revisions of the websocket protocol

3. Change the SVG namespace of the webpanel objects to shorten the name.

4. Clean up and document the ecmascript file and look at new methods of controlling the objects.

5. Document the SVG elements and create new objects.

6. Fully document everything in a PDF file, with commentary on methodology

7. Create new website with documentation and file download area.

8. Offer the package to OpenG.org

9. Change the protocol to binary

10. Migrate the ecmascript engine to open source.

Please post your comments/questions on this version here, or message me privately if you wish. Thanks, everyone, and happy SVG'ing.

I should also note the LabVIEW side of the demo does not cleanly close the websocket on shutdown, as I have not yet added any control frames to the new protocol. Also,in case you missed it, while the new protocol supports binary, I opted for text so I wouldn't have to make any changes to the javascript. Obviously, binary is a better choice, but that is down the road because it will require the data parsing portion of the script to be overhauled. I also want to spend some time thinking about what the binary protocol should look like. Any thoughts on this subject are welcome. I hope to have the new website up and running sometime before the end of Feb.

[ShaunR]

I noticed that you had this in your JS

top.wpSend = wpSend; //for sending webpanel msg from HTML if SVG is embedded. Firefox 4 only (no Chrome)

I'm guessing this comment is because you get a x-server script error when using chrome to access a "file://" URI (i.e a local file rather than an "http://" URI). You can override this limitation by launching chrome with the command-line switch "-allow-file-access-from-files". You should then be able to connect after opening an html file on the local file system without an error.

[jgcode]

...because you get a x-server script error when using chrome to access a "file://" URI (i.e a local file rather than an "http://" URI). You can override this limitation by launching chrome with the command-line switch "-allow-file-access-from-files". You should then be able to connect after opening an html file on the local file system without an error.

Using a web-server in the past has fixed my XSS issues (among other things).

I am interested to try out the switch you have posted i.e. does it allow cookies to work in chrome?

[ShaunR]

Using a web-server in the past has fixed my XSS issues (among other things).

I am interested to try out the switch you have posted i.e. does it allow cookies to work in chrome?

No-eyed-deer. This is purely a mismatch in the URI which chrome resricts by default (firefox, Safari and explorer don't exhibit this behaviour). I have only had this problem with websockets since I have never had the need to send cookies from labview. So I guess if your cookie issue works in the other browsers but not in chrome, then maybe it will solve it- you tell me

[smarlow]

I noticed that you had this in your JS

I'm guessing this comment is because you get a x-server script error when using chrome to access a "file://" URI (i.e a local file rather than an "http://" URI). You can override this limitation by launching chrome with the command-line switch "-allow-file-access-from-files". You should then be able to connect after opening an html file on the local file system without an error.

Thanks for the tip. I had put that function in for use with HTML form buttons when the user was embedding the script in an HTML file. I could never get the function to work with Chrome, but it worked with Firefox. I'll try it again with your suggestion. Like I said, I really need to clean up the script, as I have a bunch of notes to myself in there, and some code that was used merely for debugging. I plan to revise it and release it again on the new website. Thanks for your help.

[smarlow]

Hello remote controllers and websockets fans.

I thought I'd give a little teaser update and let you know what's going on with webpanel. Hopefully, those of you who downloaded the update I posted a couple of weeks ago got the newer version working alright. I've had a chance to rework a little bit of the javascript, and am also working on upgrading the LV project to 2011. My first concern was to tighten the javascript engine a bit, and by reversing the nesting order of some loops in the message handler, I was able to eliminate the need to duplicate code for every new webpanel object type. I added a new wp:type called "image" that allows the user to stream base64 encoded PNG images to an HTML document. I works well, but of course you have the associated performance hit on the Labview side that comes with continuously generating FP images using the get image method node. If anyone has a faster way of generating images (win api?) let me know. Anyway, I added it so users could do a quick and dirty panel without having to learn about using inkscape. I hope to change the format to binary soon, along with all of the websockets messages. I am currently outlining a subprotocol of websockets based on binary messages that are flattened Labview data, to eliminate the need to convert. I also changed the namespace from webpanel: to wp: to shorten it.

I have created some new SVG elements "inspired" by the new silver palette in LabVIEW. Gradient frames are added, along with drop shadows. The gradients aren't perfect yet, but I am working on my graphics skills. Here is a preview of work so far:

I also made some changes to the SVGdemo.vi program that acts as the websocket server:

As far as the project website goes, I have set up web hosting and I am just waiting to get the domain transferred over. There will be a subversion repository, but I need some help getting everything set up (open source license advice, etc.). If anyone is interested in helping me with the script, and with adding elements, etc., please let me know. Sorry I can't release the new code or new elements yet, but I need to get all these other issues resolved first. I'll post a link here when everything

is ready.

Finally, as a quick route to better control, I plan to create more HTML shell examples, with the SVG embedded in the shell. The script embedding will be handled at the HTML level, although users may opt to embed the script directly in the SVG, as is done in the current examples (I will continue including at least one example of script emdedding inside SVG). The reason I will focus on examples that use HTML at the top level is that I want to make use of the nifty HTML5 form input elements (range slider, buttons, etc.). I want to leverage the power of these input controls, as I expect more in the future in HTML6, etc.

Well, that's about it for now.

[smarlow]

Moderator:

Any chance you could change the title of this thread to "LabVIEW, Websockets, and SVG" or something similar. I'll understand if you don't want to, but I just thought I'd ask.

[crelf]

Any chance you could change the title of this thread to "LabVIEW, Websockets, and SVG" or something similar.

Admins and moderators don't read every post - in future, if you want something like that done, you need to report it to a moderator (using the button).

[smarlow]

Admins and moderators don't read every post - in future, if you want something like that done, you need to report it to a moderator (using the button).

I started off with the report link, but there is a pretty stern warning on the form page about using it for anything other than reporting violations. I suppose I should have gone with it. Anyway, thanks for the help.

[smarlow]

The open source version of WebPanel has launched.

New lavag topic announcing launch here.

[dns13]

to get this working with a sbRIO startup application i had to change the CR/LF constant in the handshake vi with concatenated CR and LF, it worked fine with front panel opened, but as soon I compile and run as startup I get a corrupted frame where LFs are not replaced with CR/LF.

Edited February 15, 2012 by dns13

[smarlow]

@

to get this working with a sbRIO startup application i had to change the CR/LF constant in the handshake vi with concatenated CR and LF, it worked fine with front panel opened, but as soon I compile and run as startup I get a corrupted frame where LFs are not replaced with CR/LF.

I don't know if you are referring to webpanel, but the first version posted here had a problem with MD5 characters containing LF characters. ShaunR posted a fix for this. I no longer support that original code because it is no longer compatible with most browsers. The new version can be downloaded at evexiallc.com. I have changed the trunk for webpanel to eliminate the search and replace vi with formatting changes to the format into string function. Here is a snippet of that change.

I tested it on a PC and it seems to work. If others can confirm it works with the cRIO and sbRIO (I do not yet own one), I will include this change in the next release.

[ShaunR]

The CR/LF constant in labview is platform dependent. It also depends on which browser you are viewing in (some are happy with only one EOL char, others require both). You should use a constant string with "\r\n" which will work on all platforms and browsers.

[smarlow]

The CR/LF constant in labview is platform dependent. It also depends on which browser you are viewing in (some are happy with only one EOL char, others require both). You should use a constant string with "\r\n" which will work on all platforms and browsers.

The string format constant in the snippet has the lines terminated with \r\n, with an extra \r\n at the end, which Chrome seems to want. This new version will be included in the next release.

[mje]

The CR/LF constant in labview is platform dependent. It also depends on which browser you are viewing in (some are happy with only one EOL char, others require both). You should use a constant string with "\r\n" which will work on all platforms and browsers.

Haven't downloaded any of the recent code, but if I recall the HTTP 1.1 Specification explicitly requires CRLF sequences in the response status and headers, including the header terminator (empty line). See section 6 and other sections referenced therein. Granted many browsers don't care, but if you're designing something from the ground up, I'd say it would be best to stick with the specification and not have to rely on quirks that might be implemented in whatever your favorite browser is.

As Shaun implied, the line terminator constant in LabVIEW is platform dependent, I'd stick with strings containing "\r\n".