ThomasGutzler

So it looks like I won't be able to continue my LabVIEW development in the near future (or at least have a major break) *sadface* Is anyone interested in continuing development of the project? It is now at the point where all dependencies to web services have been removed and replaced with web sockets. That means the page for the front panel can be viewed via file:// protocol and doesn't require a http:// any more. Web socket connection is established to a configurable port. It can handle multiple clients (how ever stupid that may be to give control over a single system to multiple users; makes sense if they're all indicators). It supports a bunch of common controls that can be represented as HTML5 and it supports representing any control as an image. I've implemented a basic config editor that can be used to select if a control should be represented as HTML or image. Current version is attached. FPPublisher.zip

Yes, we found they usually lag behind current for a bit. Just adds to the pile of inconveniences leading to uninstall :/

So am I I haven't tried that yet but it shouldn't be a problem as long as your browser supports HTML5 and websockets

Wow, where do those come from? My LabVIEW calls your Books vol and the rest is just dimX Or did you just make that up And what comes after Planets? Solar systems? Quandrants? Universes? How much further can we go?

What's missing? Don't get too involved with this project. I'm currently rewriting it to get rid of the NI WebService and replace it with websockets. Should have an update out soon.

Don't you have to build with debug enabled to be able to connect the DETT?

And when you want it to accept dropping of multiple files you enter the next level in the world of pain

In theory my solution should be able to do that. It was certainly designed with that feature in mind - I just haven't tried it yet As long as the front panel is running somewhere and visible it can be interacted with. In fact, my plan was to have a navigation menu inserted into every html page to allow the user to navigate between all available front panels without having to type in a new URL or make an awkward link on the actual front panels. Unfortunately, all that only exists in my head...

It shouldn't matter if you're calling your dll from the development environment or a built executable. As long as one or more dependencies of the DLL are missing, it won't work. You can try dependencywalker to find out what you're missing.

That's right, you shouldn't have to play with the Webserver configuration at all. I guess my "How to run it" description wasn't great. I've edited the post and added some screenshots to make it clear.

When you're loading a project that does calls to external libraries, LabVIEW tries to read those libraries on load. If they haven't been installed properly or are distributed incompletely you will get an error if those libraries were built on a C++ version that you don't have the runtime installed for. I haven't seen this exact error so I'm not sure if that's what's causing it but there's a chance

Let us know how hard it is to get the data into the right format for the dll to read it in happily. I've done in C#, so all the data structures were defined and ready to go. I'm not sure if Matlab made it that easy for LabVIEW.

I'm aware of "the competition" and they all charge a lot. I've looked at LabSocket WebPager (after handing over $2k for the software they charge an additional $100 per hour for tech support. WTF?) WebPanel (similar but dead?) Wezarp (uses VNC) NI's own Web UI Builder (dead, mainly thanks to Silverlight requirement I heard). Is that what you meant, hooovahh? VIremote sounds like it's using different technology, since it seems to be limited to apple devices. I hadn't seem that one before. What I wanted to do is to provide an open-source, low-cost or free tool that allows the developer to achieve similar functionality as the above via a web browser. Get them started in a pain-free way and if they're keen provide the ability to modify to their own needs. I'm not a huge web designer myself. Enough to get this demo to work (for me at least) but for the final version I would probably need some input. There is a weird "bug". When you open the "Show Public URL" dialog the web service seems to freeze until you close that dialog again.

Alternatively, you could get the Matlab compiler toolkit and build yourself a dll from the matlab code. I've done that but haven't interfaced with LabVIEW - but how hard can it be..

This is a weekend project (ok, several weekends now) I've been meaning to share for a while. It's a proof of concept which I'd like to get some feedback on before I invest more time. The idea is to provide a toolkit that uses LabVIEW webservices to serve an interactive HTML5 representation of any application's front panel(s) as an easy way to monitor and control the application (over the internet) without the need for heavy applications or runtime engines. Just a browser. And because not everyone is a also web-developer, the work required to create that website should be done entirely by the toolkit. In my solution it's as easy as dropping a single vi on the block diagram, that registers the VI with the FrontPanelManager which takes care of all the data exchange between the website and the front panel. Here's a screenshot of an example front panel showing all supported elements and its HTML version on chrome: Obviously, there are some cosmetic differences that can be fixed later. Controls on both LabVIEW front panel and HTML site act as controls and are synchronised across the two. By default, the website queries the front panel every 250ms for new data. The refresh rate can be changed with the cog button in the bottom right corner. To run it open the project start the WebService Get the URL of Main.html and point your browser to it start "To Publish/Main.vi" and watch the data appear in the browser As I said this is a proof on concept and it's a long away from being a toolkit. I'm working on functions that appear in the Tools menu to automatically add and configure the webservice and dependencies and many other things. [2014]FPPublisher.zip

Having (exhaustively?) tested combinations, I have found this strategy the least of evils. I like that, but it really just redefines the function of my scripting VI to: put the vi that contains the paths for different bitnesses on the BD and wire it up to every CLN (after enabling "specify path on BD"). I think this is such a simple task that it must be able to get it right enough to be trusted almost blindly. With my original design, you'd get immediate broken arrows for trying to call libraries of the wrong bitness or incorrect path. When providing the path via input, those checks don't happen until runtime. This scripting vi was supposed to save time and keep me sane when I have a library with tens or hundreds of CLNs. I'm quite willing to let a script do the first run and then spend a smallish amount of time to fix up the bugs afterwards - as long as I don't have to repeat the same 4 steps a hundred times.

Before I reinvent the wheel, has anyone done this? I'd like a VI that goes through a block diagram of another VI and places conditional disable structures around any call library node, sets the condition to bitness==32 and Default, duplicates the case, sets the condition of the new case to bitness==64 and changes the path of the called library from path/filename.ext to path/filename_64.ext or similar or something that gets passed in as a parameter. Optionally, there could be a check if a CD structure already exists, if a path is wired to the CLN, what bitness we're currently on (and change above behaviour), etc. etc. but let's start simple

Good on you for playing three games without a mistake It was fun writing the recursive algorithm. Prost!

I am sharing my implementation of the Tic Tac Toe game. Unlike many others available, this one has an intelligent AI, which is trying its best to beat you by running a minimax algorithm to figure out the best move for every turn. Alternatively, you can put it on the dump (random) setting. I built it on a JKI statemachine and saved as version 2014. TicTacToe.zip

This has got to be a bug. As we know, probes inside parallel loops don't work. That's usually indicated by a slightly greyed-out version of the probe ID in the block diagram (1). However, if I insert a disable structure inside the for loop, I can suddenly have a working probe again (in the Enabled case)! In this picture, probe 3 is a memory I32 probe (old values are shown in the array) and I can actually step through the disabled diagram and get useful readings from the probe. And no, this VI hasn't been flarned Works in LabVIEW 2014 32 and 64bit.

This post offers a solution (amongst others), which I should have tried before posting this. tldr: Set the "Legend: Plot Minimum" property to the number of plots in the graph. The property name and its documentation seem to suggest a solution to the opposite problem: The number of entries in the plot legend will never go below this value. That's what threw me off, because I was looking for something that would make sure the number of entries in the plot legend will never go above this value. As it turns out, this property node also has the effect of removing "unused" plot names when the number is set to the amount of plots in the graph. And in 2014 it also works with scroll bars in the legend without having to turn them off and on again. Delete Plot Names From Legend.vi

Rephrasing slightly from what I said this in the other Windows 10 thread. I had the same problem with my Wireless Desktop 5000 mouse. If you have a Microsoft mouse which is supported by the Microsoft Mouse and Keyboard center, this article may help: http://www.microsoft.com/hardware/en-au/help/windows-8/troubleshooting/mouse/resolving-scrolling-problems

I've been running Windows 10 insider builds for a while with LabVIEW 2014 and haven't had any problems. I did start with a fresh install, not an upgrade from Windows 7. The only thing I had to fix was the scrolling for my Wireless Desktop 5000 mouse but the Wireless Desktop configuration application lets you select applications for which scrolling doesn't work and somehow makes it work. Neat. I don't pin things in the start menu but I find it's too tile-y. Will have to look into that "Start10" thing

Craig, unfortunately it's not that easy. That array is empty. Maybe I phrased my original post badly. Here's what I mean to say: These are the suggestions users usually get when asking a similar question. I've tried those and they don't give the result I'd like: - change the amount of plots shown by reducing the size of the array that connects to the terminal or Value property node - change the amount of items shown in the legend by setting Legend / Number of rows.

You'll need 3rd party libraries to read mp3 files. Once you've got the waveform, you can use LabVIEW native methods such as "Sound File Write Simple.vi" to write a .wav file. Try this really old post as a starting point or Google yourself