Weird *$&@ in LabVIEW

[Darren]

Just now, smithd said:

My problem is that it regularly fails to send the logs up, even when I'd like it to.

Maybe zip up all the logs every once in a while and send them to an AE? They're located here:[LabVIEW Data]\LVInternalReports\LabVIEW

 

[Darren]

6 minutes ago, hooovahh said:

So on the topic of weird LabVIEW stuff I had a few today.  I noticed a couple my quick drop functions not dropping what they should be.  Now this might just be a result of my custom quick drop shortcuts, but I don't have any shortcuts for the Copy or Delete functions.  I recorded my oddness here.  Anyone seen anything like this?

Nope, I've never seen that before. You specify the name of a primitive, the thing that gets put on your cursor looks like a Place VI Contents VI of some kind, but then it drops a constant? Go home LabVIEW, you're drunk.

[hooovahh]

Well I started wiping my INI settings and found that removing the QuickDropKeyboardShortcutMappings line fixed it, but removing just the QuickDropPanelShortcuts and QuickDropDiagramShortcuts didn't fix it.  Still LabVIEW doing weird stuff, but just to me I guess.

[ShaunR]

22 minutes ago, smithd said:

My problem is that it regularly fails to send the logs up, even when I'd like it to. (Definitely IT being annoying IT, still doesn't work though)

None of the NI products can navigate proxies properly-even transparent ones. I have to connect directly if I want to use any of their download/upload features (updates, the toolkit down loaders, NIER, et al.), 

[Neil Pate]

I regularly use the "Explore" option from a build spec, it normally works as expected.

Just yesterday LV2015 SP1 would take me to a different build spec folder when I did this. Very strange indeed. 

[Aristos Queue]

 

On 8/16/2016 at 10:29 AM, ShaunR said:

None of the NI products can navigate proxies properly-even transparent ones. I have to connect directly if I want to use any of their download/upload features (updates, the toolkit down loaders, NIER, et al.), 

ShaunR: I don't know enough networking to know what a proxy is, much less the difference between an opaque and a transparent one. That makes it hard for me to file bug reports when I read comments like this. Can you write up more details about what the issue actually is? I might be able to get someone to look into the issue if I could describe it properly.

[hooovahh]

On 8/16/2016 at 11:11 AM, Darren said:

Nope, I've never seen that before. You specify the name of a primitive, the thing that gets put on your cursor looks like a Place VI Contents VI of some kind, but then it drops a constant? Go home LabVIEW, you're drunk.

So I decided to make a new thread on the dark side because this weirdness keeps getting weirder.  It now does it on multiple versions of LabVIEW, and does it on the Place Palette Object On Cursor method.

[Rolf Kalbermatter]

On 23-7-2016 at 10:58 AM, ShaunR said:

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.

DLL calls will block the thread they are executing in for the duration of the DLL function call. So yes if you do many different DLL calls in parallel that all take nasty long to execute, then you can of course use up all the preallocated threads in a LabVIEW execution system even if all the Call Library Nodes are configured to run in the calling thread. However if your DLL consists of many long running and synchronous calls you have already trouble before you get to that point, since your DLL is basically totally unusable from non-LabVIEW programming environments, which generally are not multi-threading out of the box without explicit measures taken by the application programmer.

So I would guess that if you call such DLL functions you either didn't understand the proper programming model of that DLL, or took the super duper easy approach of only calling into the upper most, super easy dummy mode API that only exists to demo the capability of the DLL, not to use it for real!

.Net has in addition to that some extra complications since LabVIEW has to provide a specific .Net context to run any .Net method call safely. So there it is quite easily possible to run into thread starvation situations if you tend to just call into the fullly synchonous Beginner API level of those .Net assemblies.

But please note that this is not a limitation of LabVIEW, in fact if you call lengthy synchronous APIs in most other environments you run into serious problems at the second such call in parallel already if you don't explicitedly delegate those calls to other threads in your application (which of course have to be created explicitedly in the first place).

The problem of LabVIEW is that it allows you to call easily more than one of these functions in parallel and it doesn't break down immediately, but only after you exhausted the preallocated threads in a specific execution system. By using lower level asynchonous APIs instead you can completely prevent these issues and do the arbitration on the LabVIEW cooperative multithreading level, at the cost of a somewhat more complex programming, but with proper library design that can be fully abstracted away into a LabVIEW VI library or class so that the end user only sees the API that you want them to use. 

Edited September 14, 2016 by rolfk

[ShaunR]

56 minutes ago, rolfk said:

I learnt a long time ago .NET blocks "run queues" and DLLs don't (notice I don't talk about threads, here).

Can you expand on the LabVIEW "run queues" and task scheduler WRT .NET and DLLs?

[Rolf Kalbermatter]

21 hours ago, ShaunR said:

Can you expand on the LabVIEW "run queues" and task scheduler WRT .NET and DLLs?

Not sure about the .Net details really. But .Net is somehow executed in a special subsystem of LabVIEW and communication with the rest of LabVIEW is indeed in some form of queues I would assume. No such voodoo is necessary for normal DLL calls though. They just execute in whatever thread and on whatever stack space that thread has assigned at the moment LabVIEW invokes the function. Invocation is a simple "call" assembly code instruction after setting up the parameters on the stack according to the Call Library Node configuration. It's as direct and immediate as you can ever imagine. And of course for the duration of the function call the thread LabVIEW has used to invoke the function is completely consumed and unavailable for LabVIEW in any way. The only thing LabVIEW could do is aborting the thread altogether but that has a high chance to lead to unrecoverable complications, that only a process kill can clean up.

Edited September 15, 2016 by rolfk

[smithd]

22 hours ago, rolfk said:

or took the super duper easy approach of only calling into the upper most, super easy dummy mode API that only exists to demo the capability of the DLL, not to use it for real!

So...all of sysconfig

22 hours ago, rolfk said:

The problem of LabVIEW is that it allows you to call easily more than one of these functions in parallel and it doesn't break down immediately, but only after you exhausted the preallocated threads in a specific execution system. By using lower level asynchonous APIs instead you can completely prevent these issues and do the arbitration on the LabVIEW cooperative multithreading level, at the cost of a somewhat more complex programming, but with proper library design that can be fully abstracted away into a LabVIEW VI library or class so that the end user only sees the API that you want them to use. 

But the finite number of execution threads doesn't seem like it really makes sense. I'm assuming this simplified some code a while back and probably saved a lot on performance, but something in the runtime system that instead says "crap every thread has been blocked for N ms, better make a new one" doesn't seem that crazy. Or to put it another way...yes sure you could use the async API instead of the sync one, but isn't that what we pay labview for?  

 

Edited September 15, 2016 by smithd

[Rolf Kalbermatter]

1 hour ago, smithd said:

So...all of sysconfig

But the finite number of execution threads doesn't seem like it really makes sense. I'm assuming this simplified some code a while back and probably saved a lot on performance, but something in the runtime system that instead says "crap every thread has been blocked for N ms, better make a new one" doesn't seem that crazy. Or to put it another way...yes sure you could use the async API instead of the sync one, but isn't that what we pay labview for?  

Can you elaborate more about what you mean with sysconfig? For me that is a configuration file under /etc/sysconfig on most *nix systems not a DLL or shared library I would know off. From the name of it, if it is a DLL, it would probably be a highly UI centric interface meant to be used from a configuration utility, which could explain the synchronous nature of the API, since users are generally not able to handle umptien configuration tasks in parallel.  But then I wonder what in such an API could be necessary to be called continously in normal operation and not just during reconfiguration of some hard- or software components.

As to LabVIEW allocating threads dynamically, that is a pretty tricky thing. I'm pretty sure it could be done, but not without a complete overhaul of the current thread handling. And something like this is an area where even small changes can have far reaching and sometimes very surprising effects, so I can understand that it's not on the top of the priorities to work on, when you take the advantages and the risks into account.

Besides, a simple programming error in your LabVIEW code could easily create a thread collector and although Windows is pretty good at managing threads, they do consume quite a bit of memory and the management does take some CPU horse power too, and once you exhaust the Windows kernel resources you get a hard crash, not a DOS for your own application only. So personally I would prefer my application to run into thread starvation at some point rather than the whole Windows system crashing hard when doing something that uses up to many threads.

As to if it is the task of LabVIEW to make our life easier, I would generally of course agree. However calling DLLs is a pretty advanced topic already anyhow, so I would really think that someone working on that level should be possible to be bothered about using asynchonous APIs if there is a chance that the synchonous ones might block threads for long periods.

[ShaunR]

32 minutes ago, rolfk said:

As to if it is the task of LabVIEW to make our life easier, I would generally of course agree. However calling DLLs is a pretty advanced topic already anyhow, so I would really think that someone working on that level should be possible to be bothered about using asynchonous APIs if there is a chance that the synchonous ones might block threads for long periods.

That's a fair point but generally API developers don't (and I think shouldn't) offer multiple ways to do the same thing and where they do exist, it is usually due to legacy support.

Saying that, though. For network sockets there are blocking and non-blocking calls that get wrapped by developers On the surface, these blocking calls seem far easier to use when viewed as linear steps since there is no need for synchronization in your program. However. I have always been forced to go for asynchronous since they cannot be aborted by the IDE. In all cases with communications. Asynchronous is always the final solution and blocking calls always fail to deliver.

I'm pretty sure what we have today wasn't always the case. I have recollections of aborting DLLs that had frozen (and there were  lot )  I also have recollections of sharing  a global from multiple built  executables . I also remember ridiculing the C programmers with their pitiful 16bit when LabVIEW was 32 so it was probably quite a while ago  . 

If I could still crowbar a DLL with the abort button. I expect I would go for blocking calls every time and let LabVIEW clean up the mess 

[Rolf Kalbermatter]

25 minutes ago, ShaunR said:

I'm pretty sure what we have today wasn't always the case. I have recollections of aborting DLLs that had frozen (and there were  lot )  I also have recollections of sharing  a global from multiple built  executables . I also remember ridiculing the C programmers with their pitiful 16bit when LabVIEW was 32 so it was probably quite a while ago  . 

Well Windows 3.1 was not fully protected mode anyhow. Your LabVIEW process could kill your File Manager (the predecessor to your good old File Explorer for those young sports knowing Windows 3.1 only from hairy tales of others) quite easily. And multitasking was fully cooperative, if an application forgot to call the GetMessage() API (or at least the PeekMessage() call) in its message loop (the root loop in LabVIEW and the thread_0 or UI thread too) then all Windows applications were hanging for good and only some kernel driver stuff would still be working in the background. To be fair though MacOS Classic was about the same .

That about sharing globals between LabVIEW executables does sound a bit strange to me though. What you could do is referencing VI files (and gloabals) in an executable as if they were VIs in an LLB (which they actually were back in those days). But that wouldn't really share the dataspace, only create a copy of the VI and its dataspace in the other application.

There is no safe way to abort a thread that has been locked by an external DLL and resume operation from just after calling that DLL. That DLL could have been suspended in a kernel call at that point (and quite often that is exactly where the DLL is actually waiting) and yanking the floor out under its feet at that point could leave the kernel driver in a very unstable state that could simply crash Windows.

Edited September 15, 2016 by rolfk

[smithd]

18 hours ago, rolfk said:

Can you elaborate more about what you mean with sysconfig? For me that is a configuration file under /etc/sysconfig on most *nix systems not a DLL or shared library I would know off. From the name of it, if it is a DLL, it would probably be a highly UI centric interface meant to be used from a configuration utility, which could explain the synchronous nature of the API, since users are generally not able to handle umptien configuration tasks in parallel.  But then I wonder what in such an API could be necessary to be called continously in normal operation and not just during reconfiguration of some hard- or software components.

Oh...no. I mean NI System Configuration API, for managing software etc. on RT targets and in theory doing other stuff with hardware but people who really use it for this totally get 100 pts extra credit. Very creative name obviously, and the shortened form is nisyscfg: http://zone.ni.com/reference/en-XX/help/373107E-01/nisyscfg/software_subpalette/

Basically everything is synchronous and everything totally ignores its timeout. To quote the help:

connect timeout in ms specifies the time in milliseconds that the VI waits before the operation times out. The default is 4000 ms (4 s). In some cases, this operation may take longer to complete.

*by 'some cases' they mean 'pretty much all cases' and by 'longer' they mean 'go fetch a snack'.

 

Edited September 16, 2016 by smithd

[Neil Pate]

5 hours ago, smithd said:

Oh...no. I mean NI System Configuration API, for managing software etc. on RT targets and in theory doing other stuff with hardware but people who really use it for this totally get 100 pts extra credit. Very creative name obviously, and the shortened form is nisyscfg: http://zone.ni.com/reference/en-XX/help/373107E-01/nisyscfg/software_subpalette/

Basically everything is synchronous and everything totally ignores its timeout. To quote the help:

connect timeout in ms specifies the time in milliseconds that the VI waits before the operation times out. The default is 4000 ms (4 s). In some cases, this operation may take longer to complete.

*by 'some cases' they mean 'pretty much all cases' and by 'longer' they mean 'go fetch a snack'.

 

You mean the same System Configuration API where changing the time could cause a hard-crash of the cRIO. Yes lovely stuff that.

[smithd]

lol didn't know that one