ShaunR

You really need to migrate to a database so that you can maintain different configurations and calibration data by just viewing the database information in certain ways (usually a single SQL query). The benefits far outweigh not being able to use a text editor and you can easily manage multiple configurations and calibrations on-the-fly.

Ah. the ol' "digital" problem. Try something like this (maybe hunt for an isolated version) and use your super duper cRIO FPGA to do 100kHz . Of course. I'm ignoring your accuracy requirements etc but you should get the idea.

Someone is working on cold fusion If you insist on long distance, then you should be looking at 4-20mA current loops and I highly recommend not doing CJC yourself - it's a black art. However. I personally convert close into digital then transmit via ethernet, rs485, profibus, smoke signals, whatever) since you can string many off of one link. Your FPGA should be plenty for the high speed bit.

No-one has stated categorically, so... The first image is a raw, unadulterated image of the part under inspection with a rake overlaid. Whilst you can take measurements that way, it is very lighting and part specular dependant. To make more repeatable measurements you post process (threshold in this case) to remove noise and make features more defined. The result is a binary image. You then apply the rake to the post-processed image (second of your images). None of this is camera dependant so changing camera properties does not yield the second image unless it is a smart camera with post-processing (threshold) on board. So how would you create the first image? Two ways: 1. Acquire an image and use the Horizontal Clamp to to make your measurement (it will add the rake overlay). 2. Acquire an image. Make a copy (using the IMAQ Copy Image primitive) then apply a threshold to the copy (there are a couple, one of which I gave earlier) . Next, use the Horizontal Clamp on the copy then copy the Overlay (IMAQ Copy Overlay) onto the original image. This will give you the measurement repeatability of the second image with an output of the first. Note that operations on IMAQ images are destructive so if you want to keep an image after processing you must make a copy of it before the processing.

I cannot replicate your problem. (Untitled 1 Folder.zip)

Looks like the second one has a clustering threshold (AutoBTThreshold)

If you use a "Wait" (or Wait until next millisecond) with a value of zero, it will yield when other tasks want the processor but run full-pelt if not.

No. It will wait until you have closed the dialogue. If you want it to run independently you will need to dynamically load it.

I wouldn't use Python for this just like I wouldn't use PHP - right tool for the right job and with NI support, which is second to none.

HMI_PopUp_KB has one (HMI Pop Up Num KP.vi). You just need to place it in the Mouse Up event.

Plotly is a rest API (V1, V2). You don't need (nor should want) Python. Just use the HTTP VIs in LabVIEW.

The DVR is a container that enables you to access data via a refnum (so you can pass around the reference rather than make copies of the data). It is not a pointer but has some analogies. You will notice that there is a "data value" output of the delete primitive which returns the contained data when the container is destroyed and, if you inspect this data, you will find the incremented value. .

Well. The Celeron is probably a quad core and the Atom you describe is a dual core but you might also look at the Ethernet port since most budget boards use 10/100 rather than Gb ethernet.

As do browsers. But perhaps it helps to think of it another way. Once you have completely separated the UI from the working code with a cross platform, standardised communications scheme (like websockets, WebRTP, TCPIP or UDP) you are not just limited to browsers or even LabVIEW - you can create interfaces in any language rather than patching LabVIEW. However. If you intend to support cross platform for the UI then doing as you suggest means you will end up with [a minimum of] 3 different and distinct code bases along with all their test harnesses and build tools (probably in different languages). You are also a bit stuck if you want to see the pseudo interfaces of embedded applications that LabVIEW provides natively. It is a maintenance nightmare that browsers solve quite nicely and, if you are as incompetant with an ebrush as I am or almost at the deadline, you can outsource the UI to web developers while you do the interesting stuff. There's always a few web-devs hanging around IT departments and they can argue about layouts, corporate colour schemes and logos. Maybe we should move all this to another thread if we are not finished?

LabVIEW is cross platform (Windows, Mac and Linux).

No problem for me. The Websockets support HTTPS (wss://) when this is installed and it has proxy support (HTTP with NTLMv2 auth and Socks 5 with basic) I don't know what "Evergreen UI code" means but sandboxed has never been a problem. Besides. As I said earlier. I've been playing with Rainmeter which doesn't use a browser and is more like desktop gadgets. I've never used the NI web server for webservery things (there is no public security analysis). I've always used Apache or Nginx but never for streaming or real-time; its too slow. Nice to see the community taking security seriously at last

Ignoring the obvious Gif (and apng)........ Dynamically create controls. Tables with child controls in cells. Proportional control resizing. Tab controls that work properly. Window and graph animations. Skins. Drag and drop....shall I go on?.

There's no magic here. Browser + websockets + LabVIEW. It definitely doesn't make me a web developer, that's why I want to use Rainmeter because I suck at drawing.

Indeed. Also. That warning means So here maybe more characters.

Do all your UI in a web browser and just let LabVIEW be a back-end. I switched a couple of years ago and all LabVIEWs UI problems are moot now. I've even been experimenting with "Rainmeter" to break out of the browser frame and utilise the desktop-works great!

If they don't listen to their guru, Linus Torvalds, they deserve "snarky" comments as far as I'm concerned. Let's be clear, here. It is a community problem that Python is just the tip of the iceberg and perpetuates because of its ubiquitous use. I have many Linux friends that complain like hell that games are often not ported to Linux and when I tell them why, they get all defensive and demand cross-platform developers yield and point blank refuse to improve the platform (even though they have the skills to do so). When seeking support, after being told to read the manual, I am always told to patch/port it myself, send it to them and they "will think about it". So ...... what is good for the goose is good for the gander, right? (Not the guys/gals who maintain CMake. They are a drop of water in the dessert) As you will probably be aware, most of my toolkits are backwards compatible to 2009 and work on Windows, Mac and Linux (mainly due to LabVIEWs guarantee) but I removed support for Linux with those that use external libraries for exactly these reasons. I wouldn't blame you in the slightest for putting LabPython back into your private toolbox because it is more hassle than it is worth and they (the Linux community) aren't prepared to give an inch to improve the platform. Of course. They could ask you or your employer for a quote to upgrade to a certain Python version on a particular distribution version. Perhaps start a Kickstarter campaign?

LabVIEW ignores frame rates less than 1 second (greater is OK) and doesn't support extension blocks.

Right. But you just recompile from source because it is so powerful

Right. Are you saying no-one should be using it at all? Using Python 2.3 should be OK, yes? All this is basically saying "you can't" to the original question and "here are some alternatives". But the OP wants to generate a LabVIEW event with Python. I don't like changing the requirements to fit the code. However. Saying that. I could knock up the TCPIP in a few minutes in LabVIEW by just wrapping the generate event primitive ..... so I can see the appeal.

It's not as straightforward as that. The issues are fairly straight forward to resolve for any one version but since the Linux community don't see any problem with breaking ABIs at the drop of a hat and that backwards compatibility is a fairy tale; Rolf has already lost the battle for keeping it current, requiring significant effort with almost every release. If I was in his shoes, I would make it 64 bit compliant, make all the CLFNs orange nodes and tell the users they have to use a specific version of Python or patch it themselves (it's open source after all). Then freeze it for others to champion. Why should Rolf shoulder the problems caused by the intransigence of a completely different language that is nowhere near as disciplined as he or NI are? Unless Rolf has a business need in one of his projects, this is just a millstone caused by open source altruism. We can hope he finds the time and energy to update it but I suspect he would have done so already if that was the case. This is Rolfs very polite way of saying "here are all the problems I know about, fix it yourself if you are good enough".