ShaunR

Can you clarify what you mean by "crash". Generally it means LabVIEW disappears completely or a "General Protection Fault" of some kind ("Insane Object" or "Virtual Function" failures are nasty). If that happens you usually don't get to see any error cluster type errors at all and have to restart LabVIEW.

DLLs are not the same as .NET. The only time you will have problems is when you run in the UI thread (because you only have 1 in the root loop). They are also non-blocking (when "Run in Any Thread") so we're a couple of rings further out in hell when compared to .NET but arguably you are in hell somewhere if not using native LabVIEW . If you are using orange nodes you need to throw that code out and think of something new. FWIW. .NET and it's older autistic sibling ActivX, are banned from all my projects because this is just the tip of the iceberg and most are show-stoppers that can sink a project - and have done so it's not rhetoric . To co-opt a saying:. "If one uses ,NET to solve a problem, one now has two problems and no portability"

Not that I'm aware of. This is a trick I use it in the SQLite API for LabVIEW installer. When you read the licence it won't let you continue until you have scrolled all the way down. I get the scroll position of the end of the text first without updating the display and then check to see if it is reached.

"Resolved to customers satisfaction" it is then. FWIW. Escalation can be very quick or many days. It's only the time-zone differences that make the delay if (and this is a big if) the application engineer knows who to contact and can articulate your concern. This is why examples are so important. Once you have found a well connected application engineer that you can ask for by name to get past the front door bouncers - 24 hours max for a useful response.. As en ex European. - a telephone call with a follow up email (with example and bulleted list of questions) at 4pm and you will usually have the result sitting in your inbox in the morning . That named engineer is now your dive buddy (as much as they might resist ) in the murky waters of NI support procedure. Hold on to them as if your life depended on them because your sanity does

Most recompiling and the object cache queries you have outlined for when the "Separate Code" is set is probably because it only applies to new VIs. If you have vis that you have imported/updated from an older code base or those that were originally saved with it unchecked; the setting has no effect. You need to run a script (JGCode posted one here, if memory serves) that updates them to remove the code stored with the VI and recompile as seperate.

I'd expect at least a "clumping optimisations" hand-wave from paid support rather than a "dunno, ask someone else". The gesture controlled quad copter making it too dangerous to walk upstairs to ask R&D?

Sounds like you haven't set up the clocks correctly.

I'm still waiting for you to modify the named event macro to be an xnode that labels the event ref the same as the indicator label and makes the need for the re-labeler in your example, moot (Especially now that it looks like it won't be fixed in LV 2016)

They are on Sourceforge like LogMAN says. A file called "jkisoft.ogpd.zip" is downloaded from their repo and it contains the list of OpenG packages and redirects to sourceforge for each. I'd forgotten they were a bit more convoluted than most packages

I'm not sure if your issue is that you have to use VIP Manager at all or that you can't download the packages without the VIP Manager but you can manually download the packages from any of the repositories.

No and I believe they run in the root loop so I would suggest using sparingly and not too fancy.

Yeah. I just don't get that.I'll just not bother, with it, thanks.

Ah yes. Forget everything I said because I obviously opened the wrong VI to be able to see the diagram. Thanks for pulling me up on it.

You don't need the queue-it is just adding complication for no benefit. You are taking the event (which is automatically named by the control label) then grabbing the control name and sending it via a queue to a case structure that has the same names as the events. Your code will be lot simpler and easier to read if you just use the event structure with a frame for each control.

Like I said, the only thing preventing me is the *hardware* to test on. Software is not really a barrier for me or the platform "type" because I'm not particularly clever, but I am persistent I pretty much have a one click (well, 3 click) process for producing the binaries for all the platforms (except VxWorks) now so the overhead of creating them has been solved. No-one is asking for these platforms so it is really my own satisfaction in striving for completeness. Virtual machines would be better if, and only if, there isn't a cost associated and they accurately reflect the hardware target. Because the API is free, there isn't a lot of incentive go out and spend real money on expensive NI hardware on the offchance that someone *might* use it. The only realistic way new platforms will be added (if no VMs are available) is through sponsorship or someone donates a device. I did go out and buy a VxWorks (6.3) RIO - quite a while ago now - because that only left the PXI racks (Pharlap ETS) at the time but obviously more platforms have been released since then. My own self satisfaction isn't enough for me to spend more of my own money on hardware just for testing once or twice a year when the burden of maintaining the binaries is not trivial and no-one really wants them. Just to be clear, though. This is a mainly a support issue. The API probably does work on those platforms with the standard SQLite binaries but even then I cannot support those platforms without test targets.

There sort if is. Generally you would set up a watchdog so that if your software hangs or crashes, things get reset back to a known state.

Thanks for this post. Unexpectedly. It sent me down a rabbit hole where I'm now furious about MQTTs lack of authentication and have another little project started.

Python is cross platform so of course it will run on windows and Mac. But the reason why all your "kids" are Python fanatics is because they are Linux fanatics. If they were Windows fanatics they would be C# fanatics instead. The interesting debate would be how your company protects its intellectual property in the face of a predominately Linux open-source mindset (not to mention some of the awkward licences for businesses that python relies on). I look forward to pulling your code from Github

Ask your "kids" what's their favourite OS. I can guarantee it is Linux. Python is the go-too tool for RPC GUIs to Linux programs and services. You've just got a lot of Linux "kids" where you work

Isn't the issue that the OP is referring to, that when large data amounts are sent to the graph (regardless of how they were acquired or organised) that the indicator is slow at rendering them? Yes. Ring buffers are great for recording data at high rates but you are still left with the rendering problem, are you not? I think the OPs issue becomes a little clearer if you make your 500 plots 8192 data points in length instead of 128

Hey. What about us old baldies? There is little correlation between LabVIEW and Python (unlike PHP) The boom in "software as a service" is the main driver behind this uptake. Outside of this domain, Python is a poor choice and is nothing without its C/C++ bindings.

If you right-click on the icon for setting the volume and select "Select Type>>Array"; you can enter more than one value.

You speak for me too. Generally there are only two things that prevent me supporting all LabVIEW platforms for my products: Hardware to test on NI Third Party Licensing Toolkit. For the SQLite API for LabVIEW the second one is moot so it is only a test platform that prevents me supporting Linux RT, PXI and x86 cRIO.

A new feature called the "Session Extension" has just been rolled into the trunk of latest release of SQLite (3.13.0). From the authors: In a nutshell you can "diff" a database and produce a patchfile of the changes (and the reverse). Now. Most are probably thinking source code control at this point which isn't very interesting in terms of LabVIEW. However. There is another use case - synchronizing remote acquisition databases. Previously we could have a SQLite database to store acquired data in, say, a cRIO or PXI chassis. Periodically we would want to back up or synchronize another database either for back up, offline exploitation or the file was becoming too large to store.. This meant making a backup copy locally and then sending the entire database file to the recipient. That could take a long time, was fraught with problems of disconnection and there may have not been enough space to create a copy. With this new feature we should be able to overcome or at least alleviate these issues and effectively implement "restore points" and "staged updates" for remote databases as well as bandwidth reduction while synchronising and configuring. For example. We may store configuration information, amongst other things, in the database and only want to update that section. We may only want the last 24 hours of data sent back for exploitation. We may only want error or waveform meta information....and so on. I'm looking forward to playing with this feature over the next few weeks. so if you have suggestions for another use-case, then I would like to hear it.

The usual issue is finding out the processor you chose based on cost, isn't enough to run ethercat and your application at the same time (half way through your project ). If you are not using the FPGA then I highly recommend spending the extra effort and using that instead.