ShaunR

I've always wanted the Val (Sgnl) property node to fire when new data arrives at the control as well as when the user clicks on it so that I could use events instead of a VI.

There is also != with a shift register/feedback node. That is the common method for detecting change in a sub VI - poor-mans On_Change event.

That is pretty weak. For non enums (rings etc) the default can be anything that's not in the list and use the default frame of a case structure. It is at least visible to the maintainer by inspection of the diagram. For enums, adding an extra entry is non-sensical? (You could have used "OFF", "N/A" or any number of words to make more sense) The proposed alternative is a "setting" on terminals that changes the behaviour so that you have to know has been set.? Does this mean that "style" would then be to have a statement on the digram that the setting is in play since there is no code indication?

Doesn't LabPython run from within the LabVIEW process?

You can call the "PostLVUserEvent" in the functions exported by the LabVIEW executable. The C prototype is in <LabVIEW Version>\cintools\extcode.h so you can see what parms you need. TH_REENTRANT EXTERNC MgErr _FUNCC PostLVUserEvent(LVUserEventRef ref, void *data);

This sounds like a code smell. I don't think I have ever done that. Is this something to do with classes requiring the same connector for overrides?

I'm not sure I'm understanding this fully. Programmable inputs? How would they be programmed-isn't that what our code is for? Going off half-cocked, as per usual, I could perhaps see a benefit of dynamically loading (plugins, DLLs etc) whereby you could define a list of files/names (so a programmable path input control) and somehow it would figure out which one to use. For example a path input on the CLFN that would load a 32 or 64 bit DLL depending on the LabVIEW version - so a kind of conditional path. But like I said, I'm not sure I know what you are getting at so perhaps give a concrete example in another language or a piece of LV code that would benefit from this feature.

Multi-tasking <> multithreading. You seem to be conflating many different aspects of application execution.

The HDF5 library uses recursive locks and keeps a separate error stack for each thread.

Strings are tricksy since there are a few ways that it can be done and sometimes dependent on how the DLL was created. Here is an example. Call Generator2.vi

It's not a choice and it is always needed. You need to invert your view of who is locking who.

Well. The libraries state categorically that you need callbacks when using multithreading and give the code that is required for you to implement (I've just outlined why it is the case and why you can't in LabVIEW). I can only tell you what I know from successfully implementing quite a few different ones; I'm not here convince you.

No it doesn't. I don't know this library but from your description it sounds like it is "thread safe" or single threaded. The developers will have (or should have) made a statement about it somewhere. Well. Serialization means writing binary as strings to me (like the flatten functions,XML etc). So I'm already floundering with your question. Synchronisation maybe? But thread safety isn't about one problem. It is an umbrella term for multiple undefined behaviours when using multiple threads, including race conditions, pointer overflows, memory dereferencing, counter overruns, and lots of nasty stuff that will crash LabVIEW-probably randomly and when already deployed to the customer site. LabVIEW uses thread pools and there is no guarantee that a node will use the same thread from the pool for every call of a particular node. Unfortunately (or fortunately, depending on your perspective). Most of the time LabVIEW tries to use the same thread if it is available, for performance reasons, so for the most part everything seems to work great - right up until it doesn't. So I hope you can see that it really doesn't matter what you do in the LabVIEW code with DVRs, semaphores and other native synchronisation methods. The only guaranteed solutions are to use a thread safe library, use the "Run In UI Thread" or, if the developers have supplied a callback mechanism, use an intermediary library to mediate.

That wont work, especially for recursive mutexes. Neither will that. You cannot mitigate thread safety in LabVIEW. It has to be done in the library itself or an intermediary that can install the lock callbacks and handle them. Serialization != thread safety and you cannot guarantee that a CLFN will always use the same thread on each call unless it is the UI thread (because there is only one).

Only if you compile it to be so, then perform back-flips in your code.

Nice write up. I was going to write some examples but for the life of me I couldn't think of one real world problem that it solves . I keep looking at those functions and coming back to this every couple of years in case I've missed something but every time get stumped by by the per node instance nature and being unable to pass a parameter into it Most modern APIs use opaque objects/structures and it is these we need to clear up rather than the function call instance. I guess it is meant for managing thread safety but we are concerned with a purely IDE event so we can unload a resource as the final operation. It is a design-time problem alone. The classic requirement is to prevent error 5 when aborting a SQLite query and requiring a restart of LabVIEW to close the handle. I can do this by installing a "monitor" into the IDE but it's an awful solution. I can't think of any way to utilise these features for that use case without an intermediary - you can't even [object] reference count .

I have found this not to be the case especially if the alternative is a statically linked "middle layer" where you have to rely on the developer to release a new one whenever the other libraries are updated. I've found conditional statements a superior solution when the main libraries are already supplied by the developers or operating system. We need a definitive guide to using the "Instance Data Pointer" which can alleviate, if not remove, this.

Yes. Working again now. Thanks.

Yeah. I looked a bit more and it's looking like the image wants to create a USB device as part of the install and, IIRC, VMWare has problems with USB boots.

When I visit lavag.org and I'm not logged in, I'm greeted by the page below (Chrome, Firefox, IE11 and Opera.) Once logged in the pages display normally.

Yes. It is a "recovery disk" so requires a pre-existing install. It fails "provisioning" if you try to install from scratch in VMware.

The only time you usually see an error 56 on a send is when the TCPIP buffer is full. Error 66 is a normal server disconnect. There are a couple of reasons that you may get error 56 on a send but the usual one is sending too quickly, say, 2MB/s on a 10mb TCPIP port. Other less frequent are when the connection goes deaf and mute but the connection is still established (usually happens with transparent proxies) and NIC problems (especially with multiple cards.)

I don't blame them for this. Linux is a house of cards and probably the best way to have some confidence that something might work from version to version or distro to distro is if you statically include your entire execution environment (like Steam). Even then it's a 50/50 chance that some nutter hasn't broken an ABI that you overlooked.

Interesting..... If it is from Pharlap to Linux. then it is not an "upgrade". Hmmm. Dual boot a PXI rack? That must be worth a few hours playing around with

it doesn't matter.