ShaunR

It may have been an over generalisation. I was referring particularly to Javascript and python so am not sure if things like object passing and closures are acceptable in all functional languages.

Is you IT department remote desktop-ing into the machine? (clutching at straws here)

When we wire VIs together they are normally simple data types (numeric, strings arrays etc). The wire represents a single data type. When we pass a cluster between VIs we are now passing (potentially) a number of data types (the wire is "fatter"). A cluster or clusters is "fatter" still. At this point, it is anthropomorphic silliness and has no effect on the code. This isn't quite what I mean by "fat" wires since there is something missing from the definition.but it illustrates where the idea comes from.. When we get to LVOOP we are passing objects. In LabVIEW terms, these are clusters too but in addition to that there is also dynamic dispatch.These wires not only transfer data (the private cluster) but also a behavioural component. In LabVIEW this is hidden under the guise of dynamic dispatch but in other OOP languages they would be the methods and in Javascript (a functional language) we can easily see the nested functions (and oh, my god...the brackets ). Moreover. A class can contain other classes so its behaviour can be dependent on a number of previous class behaviours and inputs. So to predict a VIs output from its input becomes extremely difficult and assessment in isolation almost impossible. This is what I mean by "fat" wires. The wires are opaque behaviour modifiers crammed with data and dependent on upstream (or is it downstream?) behavioural results .In other languages they are imaginary but In LabVIEW we actually get to see them and even decide their colours and patterns (cool, huh? ). This is why when you wanted the banana, you also needed the gorilla......etc..Fat wires mean dependency.

Then why do it?

Functional programming still has fat wires-the greatest barrier to reuse. I don't think all the "cool kids" are going over to them because some perceived elegance of the paradigm. Lets also be honest. It's really Javascript & Python we are talking about (because I bet they aren't leaping for joy over Erlang or Lisp ) and mainly because of browsers and servers. The trend is for service oriented design and JavaScript is used by the clients and Python by [Linux] servers. LVPOOP maybe just a fancy way of hiding a clustersaurus but it brings a lot of dependency baggage with it to fulfill it's OOP role . Where it excels is as an instance scoped variable so it's great for small, self contained state machines where state is local to the instance (like comms authentication) but you are back to all the usual nightmares outside of that.

OOP is a philosophical thought experiment that gets more and more complicated as they try to implement it in real situations and cover up the failings with axioms. Side with me

Some chassis (big ones) have a buffered trigger that need additional routing.

Well. A recent one that springs to mind is the uncontrollable JIT compiling of Windows 10. You can argue that you could specify that hardware driver suppliers only give you precompiled assemblies but it's just more crap to do with .NET that I avoid by not using it.

Not sure where I read it (damn my FIFO memory) I learnt a long time ago .NET blocks "run queues" and DLLs don't (notice I don't talk about threads, here). I may have dreamt it but I'm sure Rolf will come along and clear it all up for us (difference in thread mechanics, task switching, overheads etc). I'm not the only one that is anti- .NET/ActiveX and it is usually from experience rather than band-wagoning. I'm not sure where you got that idea from since I said in the previous post:: If you look back through my posting history I also say that DLLs are a last resort when you can't do it in LabVIEW. I see it in terms of project risk, rather than difficulty and out of 10, .NET is 9 and DLLs are about 3. As for hunting through .h files to find the type. That's just lack of documentation and a bit weak. I don't like searching the Internet to find if that green wire (they are all green) is a type, an object, needs a constructor or has a default and doesn't care. Is that different? It's really familiarity with the API that's important rather than calling mechanics.

Yes. I think the confusion is that subroutines aren't really a priority, rather another type of VI. I suppose I know that intuitively so didn't see the relevance when you talked about in-lining and priorities. Source Chapter 9.9 We should try and get that document int our wiki/blog/articles or whatever-it's is the definitive guid to LabVIEW under the hood.

I'm not quit sure what you are getting at here. You start off with sub-routines and are worried about inline priorities at the end (which I'm pretty sure is ignored and not sure how you tested it wasn't). An answer to the obvious question though is: Yes it is intended and has always been so. It is a restriction on use in the same way that class methods can only be "Shared" reentrant and not preallocated.

Your thread, your call. None of that requires ,NET. If you think about it that would be a real problem for Linux or VxWorks as .NET is a Windows only technology (I don't count Mono). The follow on from that is that most, if not all of the LabVIEW primitives don't use .NET (JSON and XML are NI parsers implemented in the run-time, I believe) and where .NET is used it is a windows only toolkit (Office, for example) so is not very attractive to me. This may be a sweeping generalisation and they may have leveraged some .NET under the hood for some things like web services but I probably don't use them or found alternatives many years ago before .NET was a twinkle in the milkman's eye. I avoid XML almost as much as ,NET. JSON - I have my own but drjdpowels one would be my second choice over the NI native one (which isn't .NET anyway). For databases. I have my own cross platform SQLite one based on the [non .NET] SQLite binaries. MySQL type databases are just strings over TCPIP so that's no hardship but there is an excellent alternative to the NI toolkit which is open source and was free when you had to pay for NIs offering (which my google-fu is failing miserably at finding again). Where .NET usually comes in with databases is with the ODBC abstraction which is nice but unnecessary. As a sort of addendum. For OS shipped features, there is very little in .NET that you cannot do with calls to the OS Win32 binaries and you are not saddled with the huge overheads and caveats.

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.