ShaunR

Silverlight was definitely the stake through the heart of Web UI bulder just as (I think) C# will be the same for LabVIEW. I've been actively moving over to Linux for a while now and .Net has been banned from my projects for donkeys' years. So doubling down with a Windows only .NET IDE is a bit perplexing. Especially since at this point, I consider Windows pretty much a legacy platform for T&M, IoT, DAQ and pretty much everything else LabVIEW is great for. When Windows 7 is finally grandfathered; Windows will no longer be on my radar at all.

Node Red FTW

What are these long-term plans? I did manage to get it working on another PC and whilst there were some nice IDE features (tabbed panes with split) I couldn't use it for proper work. it doesn't address any of the long standing features we have asked for, it is quite slow in responsiveness. Graphs are very basic (no antialiasing? No cursors?) and, I believe, it is Windows only (was that C# I saw in its guts?). If they had added the MDI style of UI to LabVIEW 2017 I would have been over the moon! As regards your comment about relevancy. Is it similar to Test and Measurement where, in the last year, Python has overtaken LabVIEW as the language of choice? (at least in the UK, that is)

Lots of examples on the net.

Maybe. But is there now a proper Source Code Control? Can we make our own native controls? Or are we looking at just another BridgeVIEW-like environment?

Well. I was pleased to see that they finally created a NI package manager-I wasn't impressed when they opted for a 3rd party company to provide one (and, of course, said so). That's about as far as I got, though. .LabVIEW 2017 installed fine!

This is why I prefer the "TARGET_TYPE" which doesn't have this limitation.

I highly recommend you use the native property nodes which are guaranteed to work on all supported platforms. The "Execute" is a last resort and I don't see anything in your code which cannot be obtained with property nodes.

AQ gets quite irate when people talk about LabVIEWs "garbage collector". I will defer to his expertise and definition Just to get in before someone pipes up about THAT function......."Request Deallocation" is not a garbage collector in any sense. "

Viewing is easy. Just Save a FP image to a file and reference it in a webservers HTML page (NI Webserver, Apache NGINX,whatever.) Control is much harder which is why many of us use Websockets. The NI webserver is based around calling individual functions (Vis) in a command/response manner from the browser which is why they have Remote Panels as Smithd has mentioned. There are indirect methods like VNC or surrogate "SendKeys" software but direct control of a LabVIEW application requires you to embed a server in your application which can respond to browser clicks

LabVIEW doesn't have a garbage collector. I've seen these sorts of behaviours with race conditions when creating and freeing resources.

I posted an example a little while back of using a SQLite DB for this sort of thing which was based around testing rather than pure DAQ so it is a superset of what you require (at the moment ). Code is here.

Build Array

This can be done in a VIM because the comparison primitives' adapt to type so all that is needed is for the controls and indicators on the VI to do the same. Do you have another example? That's because variants are run-time evaluated even though we have to stipulate how to deference them with the Variant To Data primitive. Wouldn't a "To Variant" that could be configured much the same way control refs have the option to "Include Data" to make them "Strict" be more intuitive and easier? After all. Variants do contain the type already, it just doesn't get propagated at design time. The bonus would be we wouldn't need the "Variant To Data" 99% of the time at all.

Not sure what you are trying to achieve here. The "List" is an example of a class that can be used with different type data (that's what variants are for) and VIMs give you a simple method to "adapt to type".

Indeed. My conversation was in replying to Shoneill. The OP doesn't have a problem with the producer being faster than the consumer.

The use of TCP/IP is because it is acknowledged and ordered. Don't forget this is for when the producer is faster than the consumer - an unfortunate edge case. No. The client is effectively DOSing the server (causing the disconnects). TCPIP already has a mechanism to acknowledge data and even retries if packets are lost. This is just using the designed features to rate limit. The receiver side can have as much buffer as it likes. There is no need to "match" each endpoint. We just want to rate limit the send/write so as not to overwhelm the receiver (I'm not going to use client/server terminology here because that is just confusing) As I said earlier. They don't have to be matched. If you are really worried about it you can modify the buffer size on-the-fly. You are getting bogged down on being able to set a buffer to exactly the message size. It doesn't have to be that exact, only enough that the receiver doesn't get overwhelmed with backlog and occasional room to breathe. It's simple, fast, reliable and far more bandwidth efficient than handling at Layer7.

Interesting. Why didn't you use Websockets, RTSP or WebRTP? Well. B & C are the same thing essentially from a display point of view. I have achieved similar things to A in the past with saving to memory mapped files at high data rates which can be exploited by other VIs or even other programs. But your problem seems to be rendering, not acquisition or exploitation. What I'm not understanding at present is if an image needs operator intervention then presumably they can only operate on one image at a time and 30 line profiles or histograms aren't that intensive (why did NI drop array of charts?). (each vI is updating at 125ms and displaying 20,000 points - CPU utilisation ~ 6%). So how big are these image files?

You don't need a file to display an inline image in HTML and there is the LV Image to PNG Data VI. The limitation is how fast JavaScript can render images.

I used HTML5 canvas for just displaying an image. But used Raphael to overlay ROI, annulus, annotations and cursors. I could have exported an image to SVG (which Raphael supports) but LabVIEW can't do that. The hard work was by the back-end so this was purely for display purposes to the user. If you are planning on post-processing outside of LabVIEW then JavasScript is definitely not the way to go.

It sounds like the cRIO doesn't have the device profile. I'm guessing here, but on Windows we use MAX to create a profile for an unknown device or tell MAX what the device is using *.cfg files for that device. IIRC there is a NI DAQ Configuration Utility for Linux targets where *.cfg files can be imported. Maybe have a hunt around the forums for more information about the utility, because raw USB is a nightmare.

As a first stop. Have you tried using the "External Window" tools. I'm not sure of the details, but I seem to remember some people switching to it for similar reasons. Outside of LabVIEW, I have used Raphael (JavaScript) but had to write my own ROI and annulus which isn't that hard really. Another that springs to mind is ImageJ. This is Java (....shiver....) but has excellent manipulation tools and certainly should be on your list of "things to look at"

Sure you would. The servants don't need a modern kitchen to cook their gruel

They aren't really architectures. It's like saying a kitchen, bedroom or bathroom is a house. It is the composition of all the different room types that makes a house (analogous to software architecture) and the different rooms (Producer/Consumer, Pub/Sub, Actor, State Machines et.al) fulfil specific requirements within it. The problem is that people choose one room type and try to fit everything in it, ending up with a studio apartment where the mess, caused by trying to make everything fit, just spreads around tripping up the residents, making it hard to move around and almost impossible to redecorate.