ShaunR

Well. If datasocket isn't quite doing what you need. Perhaps try network streams? They have a property node whereby you can retrieve the datatype of the endpoint. I've never used them, as I have Dispatcher, but from what I can tell they can operate in a number of configurations (one to one, one to many etc).

Change you SQL query control to "" codes display by right clicking on the control and selecting it.

Nope. Shows up with a big letter A for me denoting a string.

Hang on. I missed this in your first post. Are you sending control refs? Control refs are integers and have no meaning outside of the application instance (they are basically pointers, but not quite). Have you tried,using the Variant To Flattened String. That will give you the type info that you can send and examine the other side. No messaging system can help you with that. It is a serialization issue.

I think you misunderstood. I didn't proffer it as a solution. It was a retort to Yairs dig at me and classes (a kind of in-joke). You should instead take a look at the Dispatcher (that I highlighted in a previous post) which is very similar to your requirement, but native labview.

Ssshhhhh. Don't look closely at the MDI toolkit either

Transport.lvlib is just a protocol leveler (it just means that you can send data via UDP, TCP, Bluetooth etc transparently). Dispatcher, however, is a Pub/Sub implementation that uses Transport.lvlib and is probably closer to what you are looking for. Woohoo. Links are working again!

It's interesting that they use a length header which is the same as the transport.lvlib so they could be compatible (or at least made to be compatible-transport.lvlib has a compression and encryption byte). I don't think it really brings that much to the table over native labview implementations. From my cursory look. Pub/sub seems to be it's main "killer" property and there are native labview implementations which are safer and x-platform, This is probably the reason for NIs lack of enthusiasm. I'm not being dismissive, I think I just need to spend more time looking at it and maybe something will jump out as being an advantage. for my use cases - there has to be a really, really good reason to rely on 3rd party compiled binaries. I think the library could be improved by allowing binding to the labVIEW event system (a big bugbear of mine with VISA).If an intermediate binary is used, (as it is in this case) then adding events so that developers can hook into the event structure is trivial (even more so than in native labVIEW). I find event driven asynchronous comms, vastly superior to the normal methods ( )..I had a few issues with the library but I don't think they are insurmountable. I kept getting an error (too many sockets) and pressing abort in LV x64 causes it to hang (on the Multi example, without a stop button). But the person who wrote the wrapper seems eu fait with binding to labview, so I expect the latter will get worked out.

Indeed. Mobile dynamic display of graphical data is constrained and very browser dependent. Firefox especially seems to be very resource intensive since for something like the following demo which is using 2 channels @ 100 ms each; most mobile browsers can cope, but Firefox glitches often http://37.235.49.79/example_gauges.html However, the following demo chokes all mobile browsers as there are a lot of graphics to update and there are 4 channels @ 100ms each and one channel @ 1sec.. Additionally, the datapoint stack for the graphs is in the browser (the server is sending single datapoints) with each line having a history length of 100 datapoints once the graphs start scrolling. http://37.235.49.79/example_dash.html If you turn off the graphs then even Firefox can keep up, so the data rate and number of channels isn't the restriction. It's the graphical rendering that brings mobile devices to their knees. The demos aren't doing anything special though (like your matrix of data). The server is just spewing data out and the javascript redraws happen when each piece of data arrives. Desktops can cope with the redraw rate, but mobile devices can't.

I agree. The only purpose of an enum is to code improve readability. Granted LV takes it one step further by linking to case statements. But again. The benefit is readability.If you want a run-time extensible numeric type, use a ring.

I'm also a very visual person (hence my preference for LabVIEW). Combine what you are saying with Taguchi analysis and it takes a lot of the intuition out of it. https://controls.engin.umich.edu/wiki/index.php/Design_of_experiments_via_taguchi_methods:_orthogonal_arrays Damn. What is it with links?

Well. My 2p. It's the best since 2009, but there have been some real dogs (yes 2010, I'm looking at you).

I don't think it is as different as you might think. With temp controllers you reduce power approaching setpoint since you only need to put enough energy in to compensate for heat loss (synonymous with your holding current and, generally, it is a current unless they are gas heaters). You need far less energy to maintain a temperature than you need to get there (overcome thermal inertia). Similarly with motors. You need more energy to drive to position (overcome mechanical inertia) than hold it for exactly the same reasons. That's the thing about PID tuning. It doesn't matter what the system is (3 fat ladies on a see-saw). It's an empirical method to map a systems final output solely in terms of its input to arrive at an approximate model of the system - regardless of what the units may be (deg/C, deg/rad, or lemons).

It is a black art because it depends on the load and the symmetry of (in the case of temperature controllers) the heat/cool cycles (try an oven with nitrogen injection cooling!). It is always a trade-off since some systems cannot tolerate any overshoot and therefore require different parameters to those that can even though they behave the same in relation to transients. You can formally calculate PID parameters but they are, at best, a "first best guess" in real world applications and unless you are dealing with an ideal load, will need to be tweaked with things like prop-band and dead-band. This is all you need to know about calculating PID. http://www.dcnz.com/resources/tutorials/pid.pdf The rest is knowledge of the system and experience with similar systems which give you the Control Engineers equivalent of "Code Smell". It is similar in many ways to debugging which is why it is difficult to explain by the experienced engineer.

Is that a limitation of the STOMP server? I would expect far better than that with websockets.

Great More binaries to support

It's been a problem all around the internet of late (not just LAVA). Even spam killers such as Akismet are not immune. It was such a problem that I wrote a plugin for the CMS I use and released it last week to the CMS community. I get zero spam on my site, so I'm waiting to see how effective it is for those really suffering..

Just to get the last word in The Raspberry I has 17 GPIO pins.

As you are not constrained by labVIEW. Raspberry PI is a cheap option (check out the forums for lots of goodies and examples). You can program it in either Java or Python and has USB/LAN/GPIO built in.

I don't think it was Paul who was confused. Look at your post above his

Flatten to JSON. You'll be able to use clusters on your side and they can use equivalent objects on the other side (within reason)

Not that I'm aware. Sort of. See next. The classic solution is to make access to the dynamic VIs loaded by a relative path. Then you can have a directory that you just add dynamic VIs/Classes to. This is slightly different to what you are describing as they are not bundled or built with the exe. Instead, they are usually supplied and managed as a separate installation. But they will not break the exe if not present (just that feature/function will not be available) and are flexible to add/remove functionality. The issues with this approach are that the "modules" have to have diagrams attached otherwise they cannot be loaded into different versions of LabVIEW. So stripping the diagrams creates version and maintenance problems but as the password protection of some LabVIEW versions was compromised (the best solution); it is unsavoury for commercial products. Distribution of the total solution is problematic from a NI only stand-point too. It can easily be achieved via a VIPM package, but NI don't own that. So Alice would distribute a VIPM package with a dependency on the modules that would get pulled in and installed to the right place alongside the exe. Using NI builder solutions are much less elegant requiring a source distribution for the modules and an exe build for the main VI that must be modified to get to install in the right locations on another machine or labview version (because of absolute paths) and requires work from Bob to realise. Yes.

Hear, hear. The palettes are hopelessly restrictive and haven't really changed since 2.x. I would like to see dockable palettes that I can attach to the screen edges (and to each other) and be able to create palettes that I can drag and drop primitives onto as a quick favourites for that project. I've had a play with the "Smart palette" and it's good. But not exactly what I would like. Still hate the probe window so much that I'd rather create temporary indicators on FPs rather than use it (especially for strings which you cannot format). And while I'm ranting Are they ever going to fix the greying out during execution highlighting that seems to forget and get confused as to where and what it should grey out.

Nope. It's far too slow.

Agreed. You are much better of testing for an invalid refnum instead. Then it will be created on the first call and if it ever becomes invalid - recreated.