Leaderboard

So I don't have any spare time to improve this at the moment, but I do have this running on the embedded RT Linux with UI. Before running the VI I needed to transfer the contents of the www folder to /usr/local/natinst/labview, and I needed to specify the IP address host in the example VI using the IP to string function. I'll admit things aren't 100% but I do have the example VI running on the Linux RT target, and after mapping a network drive to it in Windows (using Webdav) I can open the webpage and see the VI running on my RT machine from chrome on my Windows machine. Not all of the controls look quite right, but interactions seem to work. Then I installed Firefox on my Linux RT target by downloading it from here, and updated soundlib2 as described here. The result is a similarly looking, semi-broken but interactive web page running on the embedded target. Again looking a little broken, with images not being sent over, but even if this can't be correctly fixed, there are other solutions for controls with a limited number of images like picture rings, and buttons. This is pretty exciting to me because it can mean that the same interface for interacting with a VI on the embedded UI, can be the same interface for controlling the same VI from any web browser that can access that target.

Hi. I’ve discovered what appears to me to be a quirk in the behavior of dataflow in LabVIEW. This discovery occurred while working on an application that contains a main while loop and housekeeping code that runs after the main while loop. I’m enforcing the order of execution in the VI by wiring the error cluster through the main while loop and over to the housekeeping code. Attached is a zip file containing a VI that reduces the application to its key components. The VI contains two while loops connected by an error cluster. The cluster passes through a subvi and sequence structure in the first loop, then passes through the second while loop and finally enters another subvi. A screenshot of the VI block diagram is also attached. When the VI execution property “Allow debugging” is selected, the VI operates as expected - the second loop will not start until the first loop stops. The quirk occurs when “Allow debugging” is de-selected. In this case, both loops begin running as soon as the VI starts! For some reason, the two subvis and the sequence structure are required to make this phenomenon occur. This phenomenon also occurs when the sequence structure is replaced with a conditional disable structure. This behavior occurs in at least the following two environments: 1) LabVIEW 2014 32-bit on Windows 8.1 running within Parallels Desktop 11 for Mac 2) LabVIEW 2015 SP1 32-bit on Windows 10 I suspect that the cause of this behavior is that the LabVIEW compiler is trying to optimize the VI performance by noticing that the second loop and second subvi are not dependent on any data generated in the first while loop. If this is the case, it’s great that the compiler is trying to improve VI performance; however, what’s not so great is i) this demo VI shows that the error cluster does not always enforce order of execution, and ii) a change in the "Allow debugging" setting can change the behavior of a VI without any indication to the developer. This apparent quirk raises two questions: - Are there other situations where the dataflow paradigm does not behave as expected? - Are there any tools available to find out about changes that LabVIEW implements behind the scenes that could cause this or other unexpected behaviors? A short video demonstrating this issue is available here: http://www.screencast.com/t/D3mCCqFyz Any thoughts on this issue would be much appreciated. -John Bergmans Data Flow Test.zip_remove_me

Also - since you're using python for the data processing you can use python's web server and avoid the legacy nightmare that is ActiveX.

Hello everybody, here is a solution that works for me. Problem: ODBC Connection, Declare variables and get Result of "Select" SQL Statement Hope it helps you