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?

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.
 

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.

Hi everybody,
 
I am wondering whether or not it is possible to call the functions of a dynamic library over a LAN connection, without needing to control a VI on the server using the LV remote server (my server is Win7 embedded on an SSD, so not much resources to waste running the RTE). Does the "Shared library file is not on the local machine" checkbox allow that when using the Import Shared Library wizard? Is there any easier solution than implementing a protocol over a TCP connection to access my DLL's functions?
 
Thanks in advance,
 
Sylvain F.

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:
Documentation on a "Remote Cascade Lab" developed by KTH Royal Institute of Technology in Sweden that uses an earlier version of LabSocket: http://www.energy.kth.se/proj/projects/Remote_labs/RL/RL_website/RCL/RCL.html Screenshots of support for MultiColumn ListBoxes: http://labsocket.com/MCLB.html Presentation to Orange County (CA) LabVIEW User Group Meeting titled "LabSocket System - Plotting Capability and Sample Applications": https://decibel.ni.com/content/docs/DOC-30313

 
Any questions or feedback about the system are welcome.
 
-John Bergmans