Jump to content
Sign in to follow this  
Mechatroner

New Release of LabSocket (The Easy Way to Extend LabVIEW to the Web)

Recommended Posts

LabSocket enables LabVIEW applications to be easily accessed using a web browser, without the need for browser plug-ins or run-time engine on the client.

 

The latest release of LabSocket includes support for Waveform Graphs and Charts, XY Graphs and MultiColumn ListBoxes.  An option to integrate LabSocket with the Moodle CMS is available as well.  A detailed User Guide and downloadable demo of this release are at: http://labsocket.com/userguide_demo.html.  Below is a screenshot of a test VI (left) and its representation in a browser (right).

 

LabSocket-RT, a special version of LabSocket for the LabVIEW Real-Time environment (eg. cRIO), is also available: http://labsocket.com/RT.html.  A live demo of LabSocket-RT operating on a cRIO-9025 can be accessed at http://labsocket.com/Demo2.php, until approximately Oct 4.

 

Other links of possible interest:

 

Any questions or feedback about the system are welcome.

 

-John Bergmans

post-20414-0-46037300-1380818084_thumb.p

  • Like 2

Share this post


Link to post
Share on other sites

...well this is quite interesting.   I haven't tried it yet but I have some concerns.  I notice that not all UI elements are the same size between the VI and the web page.  So is it often that you will have UI objects on top of each other?  What about subpanels does it work with them?  How about splitters and panes?  Which brings me to the question about window resizing, and how it handles that.  Don't get me wrong very neat, and I like having options, I just see several updates to NI products having similar functionality.

Share this post


Link to post
Share on other sites

Hi hooovahh.

 

Thanks for taking a look at LabSocket.

 

It's true that there are some minor cosmetic differences in the appearance of elements in the Front Panel and their representation in the browser.  My sense is that the current replication fidelity is sufficient for most applications.  (I could well be wrong on this point and would be interested to hear about use cases requiring exact replication.)

 

If there is overlap of elements in the browser, you can try shifting the front panel elements in LabVIEW and regenerating the browser representation until the overlap is eliminated.

 

LabSocket does not currently support subpanels, splitters or panes.  Also, resizing the front panel does not affect the browser page size.

 

If there is a need for more exact replication in the browser or support for currently unsupported elements,  I'd be pleased to tweak the system to meet anyone's specific requirements.

 

-John

jbergmans /at/ bergmans dot com

Share this post


Link to post
Share on other sites

A quick update - I gave a presentation about the LabSocket system to the Bay Area LabVIEW User Group (BALUG) last week.  The slides are available at: https://decibel.ni.com/content/docs/DOC-33131.  My impression was that the presentation was well-received by the group.

 

To the BALUG members here that attended my presentation - thanks for coming out to the talk.  I found the group was welcoming and quite enthusiastic.  NI also did a good job of supplying food and beverages and providing a great space for the meeting.  I look forward to coming back to Santa Clara to attend future meetings.

 

-John

Share this post


Link to post
Share on other sites

Hi John - I was at the BALUG presentation and was awed by what you've accomplished with this code. Also, the presentation itself was well-organized. Thank you for sharing.

  • Like 1

Share this post


Link to post
Share on other sites

I'll be presenting a one-day workshop about the LabSocket system at the NI Offices in Santa Clara (Silicon Valley), CA on Feb 10.  An overview of the agenda is shown below.  The workshop will include several labs to provide attendees with hands-on experience with the system.

 

For more information or to register, please visit: http://www.eventbrite.com/e/labsocket-workshop-tickets-10111462657.

 

Workshop Agenda Overview

1. Theory of Operation

2. LabSocket Basic

3. LabSocket-MultiClient: One Target VI Instance per Browser Client

4. LabSocket-RT: LabSocket for LabVIEW Real-Time Environments

5. LabSocket Server Virtual Machine

6. Integration with Moodle Course Management System

7. User Authentication

Share this post


Link to post
Share on other sites

I've unfortunately had to cancel the one-day LabSocket Workshop on Feb 10.  If anyone is interested in attending such a Workshop or having a private version of the Workshop at your organization, please contact me.  Here's a brochure about the event: http://labsocket.com/LabSocket_Workshop.pdf

 

Also, here's a brochure with some information about the LabSocket System, including the new MultiClient version, the proposed MultiTarget version and the new LDAP user-authentication capability: http://labsocket.com/LabSocket_Brochure.pdf

 

-John

Edited by Mechatroner

Share this post


Link to post
Share on other sites

I'm pleased to announce that the LabSocket system is now listed in the LabVIEW Tools Network: http://sine.ni.com/nips/cds/view/p/lang/en/nid/212532

 

To go along with LVTN listing, the LabSocket website (http://labsocket.com) has received an update and includes a much-improved "Technical Details" section and the latest downloadable evaluation version of LabSocket-Basic.

 

Please let me know if you have any questions or comments.

 

-John

 

LabSocket%20Product%20Image.png

Edited by Mechatroner

Share this post


Link to post
Share on other sites

LabSocket Application Example

Engineering students at the British University in Egypt recently used LabVIEW and LabSocket for a Smart Home Hazards Monitoring project.  In this application, the high-level LabVIEW home monitoring software was accessed remotely from a number of devices, including an iPad.

 

A YouTube video, a Prezi presentation and the student's well-written final report are all available on the LinkedIn LabSocket User Group page: http://lnkd.in/bnHxWzi.

 

This work is a great example of how LabSocket enables LabVIEW applications to be easily accessed over the web.

 

-John

Share this post


Link to post
Share on other sites

Hey John we met on the expo floor and we were talking a bit about taking an image front panel controls being able to use it else where.  You mentioned that the solution you found was to save the image data to a PNG file, then you could load it somewhere else.  I don't remember the full context but I remember what I suggested as a better solution.  

 

This VI can take a PNG file as an array of bytes (or rather a string) and convert it to the LabVIEW Image cluster.

 

<LabVIEW Folder>\vi.lib\wsapi\VIs\PNG Data to LV Image.vi

 

More importantly you can take a LabVIEW Image cluster and turn it into an array of bytes as a string using this VI.

 

<LabVIEW Folder>\vi.lib\wsapi\VIs\LV Image to PNG Data.vi

 

A demonstration I've often linked to is the GDI resize function posted here.  It can take Image Data in as a cluster, convert it to a PNG, scale it using .Net, then save it as a stream, then convert it back to Image Data.  That VI also works in a similar way with a image file instead of Image Data.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

  • Similar Content

    • By IpsoFacto
      I've got some weird stuff going on with a cRIO project I'm working on wanted to get some opinions on it. The basic architecture is a set of classes that do some process. That process registers with a server. The internal data of the process is held in a DVR and the server get's access to that DVR. Clients use TCP to ask the server to do something, the server makes a call against the classes DVR and returns a response to the client.
      To simplify the issues I'm seeing I created a class that internally just increments an integer every 500ms. The client asks the server what's the current count, the server asks the Counter class and returns the answer to the client. This works perfectly fine when running the VI in the IDE. When built it connects, will get the JSON message back, but always gets a default value from the DVR call (zero, in this case). As soon as I open a remote debug panel to the cRIO, everything is working. The count is correct, the client calls work, just like normal. As soon as I right-click, close debug, it goes back to zero. Open debug works, close debug, back to zero. I know the DVR isn't getting dropped because the count continues to increment while not in debug, the process is still running happily with no issues.
      Here's a few screenshots of the code;
      Count Class process (get the count, increment, write it back to the DVR) - Counter Class process
      You can see the DVR vi's are actually vim's using a cast. I can't imagine that's the issue.
      Server Side call - Server Side calls
      All this does is get the count from the DVR (same as above) and wraps it in JSON and passes it back to the client as a JSON string.
      I also implemented an Echo class that ignores the process and DVR's, it just takes whatever string you sent form the client to the server and passes it back with a prepended "@echo". This works when running as an executable with the debug turned off so I know the client, server, and the server/class calls are all working as expected.
      Any thoughts here would be welcome, thanks.
      edit: I added the any possible errors coming from the variant cast to the JSON reply. When the debug is open there are no errors, when the debugger is closed it throws error 91, but the in-place element structure reading the DVR does not throw any errors. How can a variant not exist until a debugger is opened and than it magically exists?
      edit: the internal data dictionary is a wrapper around a variant attribute, I wired out the "found?" terminal all the way out to the JSON reply and if the debugger is open the attribute is found, but not if the debugger is closed. Anyone have issues with Variant Attributes in Real-Time?
    • By pysenberg
      Hi all,
      So I'm working on making a certain vi a remote panel. However this vi is quite complex with a lot of property nodes events which makes remote panel connection can be a bit unreliable cross-site because of the amount of data being transferred.
      What i'm trying to do to solve this is use a secondary vi that grabs an image of the first vi's front panel at a given frequency so that any changes are seen with out having to send too much data back and forth between the server and client. Basically all we should see is the change in pixels. When a user clicks on the image on this secondary vi i would like to simulate a click on the first vi at the same co-ordinates which should give me full control. I would use the secondary vi as the remote panel instead. I'm guessing this is how remote desktop would work?
      I have looked into simulating mouse click events using the User32.dll and it works great > http://digital.ni.com/public.nsf/allkb/9BB3211F3469623649257360000E272C
      However my problem is that this vi may not be the top vi or may be transparent at times. So my question is, is there a way of simulating a mouse click on a specific vi even if its not on top or hidden?
      This idea may be too crazy to work and in that case any suggestions are welcome.
      Thanks in advance.
       
    • By PhilipK
      I'm having some issues with a LabVIEW driver I'm writing for a Mensor CPC 6000 pressure controller.
      Issue
      I open the TCP Connection using the LV "TCP Open Connection" VI, and can then successfully read various values from the Mensor, such as "id", "gasDensity", etc., using the "TCP Write" and "TCP Read" VIs wired with the connectionID refnum.  I save the connectionID in a shift register and want to use this connectionID to write and read values the next time the VI is executed, however as soon as I perform a "statusUpdate", "TCP Write" returns Error Code 1. Tests already performed
      I've confirmed that I'm not accidentally closing the reference in LabVIEW. I've confirmed that the connectionID is saved correctly in the shift register (by casting it to type U32 and comparing outputs and inputs after each execution) If I open a new connection and immediately perform my "statusUpdate" the expected values are returned possible cause?
      is LabVIEW or Windows automatically performing some clean-up in the background leading to an invalid reference, or is something with my hardware setup funky?
       
      Setup:
      Hardware setup: PC running Windows 8 and LV2016, directly connected to Mensor CPC 6000 using a crosswired ethernet cable. 
      Mensor IP Config: Address, 172.18.149.201, Subnet Mask: 255.0.0.0, Port: 6000
      PC IP Config: IP Address, 172.18.149.1, Subnet Mask: 255.0.0.0, Default Gateway 172.18.149.1
      The driver is a simple affair (see attached VI snippet for the VI which reads strings from the Mensor)


      Any help would be appreciated!

    • By pysenberg
      Hi,
      I am currently developing a scope that displays live data from a test rig. The scope is accessible via remote panels. Tests normally run for many hours at a time, when monitoring the scope after several hours of running I notice that the data on the chart displayed via the remote panel is not in sync with what can be seen on the actual 'server' vi. The delay also seems to be getting bigger as time goes on. I also display the current data points in an indicator; however these seem to be in sync and 'current'.
      The scope is part of a built application and I am using labVIEW 2012 f3 to develop it.
      I know that there is an issue with synchronizing front panel appearances when using remote panels in built applications but I think I have got around that by re-applying panel changes when a new client connects. Also on every execution of the VI, I defer panel updates make all my updates to controls including the chart in question, force draw the chart and then re-enable panel updates.
      I would really appreciate if anyone that has experienced this sort of issue could share a possible solution/work around.
       
      Thanks in advance.
    • By Gribo
      A simple bi-directional interface between Labview and Google maps, using Websocket. 
      See readme.txt for instructions.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.