ShaunR

LabVIEW is a Dataflow language rather than Functional Programming. State is implicit rather than explicit and execution is inherently parallel - it is quite a different beast to Functional Programming.That's not to say you don't need a state-machine at some level to control execution. In the LabVIEW world it is usually a sequence engine which is a lot simpler since LabVIEW execution can be represented as a directed graph and that is basically your block diagram.

Because state-machines are hard and have to be debugged with witchcraft. So just avoiding the problem means you don't need tools for that problem.

Are you sure it's not a sequencing issue? ...... ..... because you need.

I think it applies to all projects that have asynchronous processes which is why I'm interested. I don't know how all that works internally. From the initial cursory reading (which may change as I re-read another 20 times ) ) he is generally talking about a journaling system for messages (I think) and using this pseudo time mechanism to resolve contention by what seems to be a slot-scheduling method. Indeed. He has given me the prism and terminology to [succinctly] describe why I am so unhappy with all the frameworks and architectures I see being produced in LabVIEW. However, I'm hoping that this paper, or one of its later incarnations, results in an elegant solution to remote messaging that I have been unhappy about for quite some time.

Nice work. Don't over-reach for a first release. Named pipes for progress bars are a stateful digression from just showing a dialogue. Maybe take stock and put a stake in the ground of where you are - package and clean. Then look at that for version 2. Productionise. Then you can incrementally add features under version control. Just a thought

I am constantly amazed that some ideas were prescient in hindsight but rejected in their time for more mainstream alternatives. The sands of time covering their bones for an archeologist to piece together later. Luckily, the internet is an excavator I was watching a video called "Is it really "Complex"? Or did we just make it "Complicated" because I've felt for a number of years that the whole idea about using frameworks is really a dead horse flogging exercise because we can't innovate out of a rut. Anyway. During the video there is a throwaway comment that semaphores had a superior alternative called Pseudo Time. Wait. What? Non deadlocking semaphores? Well. Perhaps, perhaps not. The only reference I could find was a paper written in 1978 called Naming and Synchronization in a Decentralized Computer System by David P. Reed. In there he talks about an alternative (NAMOS) to mutual exclusion A.K.A. critical sections around shared resources, rather than semaphores specifically, but the real gold is his definition of the reliable and self recovering synchronisation of unreliable shared resources. In a nutshell, he's talking about synchronising across cloud servers and blockchain forks and any other distributed computational system you care to design - in 1978! This is a bit more than non-deadlocking semaphores, I think. So why am I posting. Well. a) Has anyone ever heard of this or any superseding research (links would be great) and b) Has anyone got any LabVIEW examples?

I think quite often new guys/gals don't really know the difference between LabVIEW source code and an image; especially if it is their first foray into programming at all. LabVIEW is just programming with pictures, right? Posting a screenshot is posting code, isn't it? I see all the time old timers posting screenshots. OK, they call them snippets, but they are screenshots and they say it is code, right? edited to add emoticons for Rolf

Are you sure? From you image, it looks to me that the first text selection node can operate before, during or after the "add symbol" sub VI as LabVIEW decides.

If you like wmic you'll love the wmi-delphi-code-creator

Oooh. An ion gauge? Is that part of a plasma rifle or a quantum defibrillator? Please post the code

Block diagrams don't scale (no zoom etc). I would check your fonts. Fonts do make a difference to the BD and cause things like unbundle by name to resize to accommodate. Perhaps a font that was used on the original machine is not available and the surface is picking a slightly different one that it thinks is close enough.

Thats not weird; thats a lemon. Send it back and get a new one. I had a couple of strange corruptions recently. Couldn't open VIs in LV2009 64 bit. Could load the project but when I tried to open this one particular VI; LV would just disappear. Opened it up in LV2009 32 bit and it was fine. Saved it back down (in 32 bit) then reopened in 64 bit and problem solved. Thanked every god I could think of and moved on

You have already answered your question. You know that it doesn't fit the task but perhaps not why. Look at what will be needed for system wide state control, sequencing and subsystem interaction. If they are required and must be deterministic; there are better, less painful solutions.

Have you turned off auto-scaling?

All my distributions have a licence, changelog and a readme (and/or HTML help). For remote systems they usually also have a method in the TCPIP interface where you can query the version (which is just TCPIP forwarding of a BD constant or, more commonly nowadays, read and send the changelog) so the client end knows without special connections or tools.

You've nothing to apologise for. Linux fan-boys are 10x worse than Mac fan-bloys 100x worse than Windows fan-boys , of which I am one (well, I was until I looked at Windows 10). I think we would all jump to the fileversioninfo library if it worked on Linux and Mac too (which isn't impossible, by the way). The point I'm making is that it is only a a semi-standard way on windows and when you factor in other OSs it isn't standard at all Most x-platform libs, for example, have a function to retrieve version info so the BD constant is arguably the standard. Lets get this in perspective, though. No one is saying never version control or even never link your source version to your executable version. Only that writing complex build tools that are purely for documentation purposes and work on only one of a number of OSs isn't a high priority to x-platform developers. Nice to have but meh.

I give up It's kind of like the Linux fan-boys that answer "install Linux" to every Windows programmers' questions about compiling.

I think you miss the point. The filversioninfo is windows only so it won't work with things like CRIOs running NI Linux Real-Time or VxWorks. How do you version control your FPGA code, for instance? I'm not even sure if it would work with NI ETS but it might-I'm sure someone will clarify that. Your customers' preferences are only one aspect to x-platform.

A BD constant is cross platform; FileVersionInfo.vi isn't.

Aren't all the supported (for that version) xnode methods in "resource\Framework\Providers\xi\xnode.llb"?

I haven't seen a BSOD since I left XP behind a few years ago. They still a thing? Maybe a long shot but if you have installed something recently (windows update?) and the OS has taken a snapshot, then there maybe something in the shadowcopy

It's probably FindWindow or FindWindowEx you are after.

The Delphi snippet you linked to had You can't do that natively in LabVIEW-just saying.

That method requires passing a callback pointer to EnumWindow. You can't do that in native LabVIEW unless you use .NET callbacks or your own DLL.

Just thinking on the fly here. Aren't all the capabilities to create and modify an Xnode available in the project window? Could we get around many of these issues by scripting that rather than creating an Xnode from scratch with a bespoke UI?