Mads

Nice discussion, thanks for the link. The quoted statement seems to contradict my observations yes. I have not checked if the misbehavior was absent in any of my earlier LabVIEW installations yet...I am working in Windows LabVIEW 2020 SP1 at the moment.

The original producers acquire a reference to the consumer queue, and call enqueue in a pre-allocated reentrant VI...But when multiple copies of these are waiting in parallell to enqueue, the time at which they started to wait does not decide when they get to do the enqueue. So what I did as a test was to test how this worked if the reentrant VI was non-reentrant (which does not work in the actual system as VIs enqueuing to a different consumer should not wait for the same VI, but just to test now) - and that made everything run according to the time of call. I guess this comes down to the internals of the enqueue function; when you have multiple enqueuers waiting, I thought the queuing system would keep track of when the various callers had first requested access - and then, when the queue has room for another element, assigned access to the originally first request. Instead it looks as if there is something like a polling system in the background (running when it is hung in a wait to enqueue state) that makes it random which of the waiting enqueuers will win the race...

If the enqueue and wait for a reply function of all producers sharing the same consumer is put in a non-reentrant VI, the execution *is* scheduled according to the order in which the producers call it. So that is one solution. Assuming that the execution of enqueue calls (or rather their access to the bounded queue) would be stacked in the same way; ordered by the time of call, seems a bit less obvious now that I think about it, but the level of queue jumping is still surprising. If for example there are 5 producers, 4 will at all times be waiting to enqueue (while the fifth in this case has finished enqueuing and is waiting for the consumer to return a result). In my test case, where each exchange between a producer and the consumer will take 1 second, a fully ordered execution should consistently complete a round in 5 seconds (which it does if I use the non-reentrant VI solution). - Instead, due to all the seemingly random enqueue-queue (!) jumping, the period of processing for any given producer can spike as high as 15 seconds😱! That means it has been bypassed by the others several full rounds before it got first in line.

Does anyone here know how LabVIEW decides in which order multiple instances waiting to enqueue to the same size-limited queue get to enqueue?😵 If e.g. a consumer has a queue of length 1 (in this case it is previewing, processing, then dequeing to ensure no producer is fooled into thinking that the consumer has started on their delivery just because it was allowed to enqueue 1 element...) and multiple producers try to enqueue to this consumer, I have (intuitively / naively) assumed that if Producer A started to wait to enqueue at t=x, and other producers try to enqueue at t>x, producer A would always be the first to be allowed to enqueue.. This does not seem to be the case (?). Instead producers that begin to wait to enqueue while others are already waiting sometimes get to enqueue prior to those. This causes the waiting time for some producers to increase unpredictably, because a variable amount of producers cut in line. This phenomenon occurs in a rather complex piece of code I have, so I wrote a simulator to see if I could recreate the issue - but so far my simulator seems to adhere to my previous assumption; Each producer gets to wait the same amount of time because they keep their place in the enqueuing order. This might just be a weakness in the simulation though...or I have so far misinterpreted what is really going on. If my assumption about priority was wrong all along it would solve the case faster though....(then it becomes a quetion of how to solve it in a manner where producers actually have such a priority 🤨)

I think this is about as wrong as it can get. If an indicator is wired only (no local variables or property nodes breaking the data flow) it shall abide the rules of data flow. The fact that the UI is not synchronously updated (it can be set to be, but it is not here) can explain that what you see in an indicator is not necessarily its true value (the execution, if running fast, will be ahead of the UI update)- but it will never be a *future* value(!). As for breakpoints they do not exist just in the UI - they are supposed to act at the code level, and their execution should be controlled by data flow. So in the case of a break point the break will (should) occur as soon as it has its incoming data available at the execution level, not the UI. The UI will update the state at its pace, but UI is just displaying the state after it has occured, not deciding when it is entered. One thing that makes this more complex in LabVIEW and in this example is that we are dealing with parallel execution within the same diagram. A breakpoint should really (we expect it to) as soon as it has its input value cause a diagram-wide break, but it does not. Instead it waits for the parallell code to finish, then breaks. As for the indicator showing the value prior to the break that part is explained by the bit LogMAN refers to; that breakpoints allow the value to pass before they hit the break...

In the few cases where performance is that critical you will probably have to get by without traditional debugging anyhow. Do you expect you comfy car seat to occasionally disappear, and accept that as a consequence of wanting a quick car...? Sure, in the rare cases you need it for drag racing 😄 I do not consider key features like data flow and breakpoints something that should be allowed to occasionally break/act randomly. Either you have them and they work as they should, or you remove/disable them and explain/visualize why they are sacrificed (to get performance) until you are able to offer both performance and proper behavior. Disabling debugging and/or turning down/off optimizations could still be an option in the few cases where that is the only way to get the necessary performance.

As drjdpowell mentions the bug could be caused by optimizations, but it should still be considered a bug that optimizations are allowed to interfere with the data flow in debugging mode. I suggest you post it on the ni.com forum as well and see what NI says.

Looks like a bug to me. It is not restricted to your example though. Breakpoints should execute according to the data flow, but often do not.

Here is one that involves a nice mix of small challenges: My first assignment after being hired as an engineer back in 1998 was to write a multiplexer and demultiplexer. In that case we had 8 instruments outputting readings as an ASCII string every second (fixed length message containing a numeric value: "AA 2500BB\r\n"), and all those strings had to be read from 8 separate serial ports, tagged with a channel (c1, c2, c3 etc..) and then sent on through a single serial link (because we physically only had two wires available) to another PC where the signals would be split into the original 8 live values...Unless you are already familiar with serial IO you might want to simulate the physical parts at first to finish the downstream logic, then you can add the physical / serial communication bits at the end (in case you end up spending too much time on that to finish everything).

I definitely prefer the pre-SP colors and icons. The SP1 LabVIEW "20" Icon marking is completely unreadable...and the fonts, font sizes and layout of the welcome screen is all over the place. I do not understand how these things pass quality control🤮 Post-sigh: And as always upgrading to SP1 the license is no longer supported by our Volume License Server (even though our SSP agreement runs for another year...) - so a manual request for an updated license is once again required...Rinse and repeat later for the 2021 release...😒

Who said anything about debugging a built application, it's about seeing what you get without having to build it - because WYSIWYG. Many applications have multiple windows that run in parallel, and I want to see them like that during development. And I want multiple diagrams and front panels open while tracking the data flow and/or inserting debug values. I even want to be able to have panels open just to see them while I am working on something related, because it helps me maintain the full mental model of the thing I am working on. I do not want to be bothered minimizing windows all the time just to clear the space either, there is enough of that in current LabVIEW. With NXG having more than one front panel or diagram per display was barely possible, no matter how small the actual front panel or diagram was.

For the first versions of NXG it was not possible. Then it started to allow you to have multiple instances of the VI open and hence to see both the diagram and the front panel at the same time, but each window had so much development-stuff surrounding it that it was not practical to have much more than one or two open. Hiding any of it to free up space and/or to see something closer to what you would see in the built application was not an option.

Having the ability to work with multiple front panels viewed as they will look in the built application, and looking at multiple diagrams at the same time, has very little to do with break-points and reentrancy. It's about WYSIWYG, testing, and having a good understanding of multiple interacting parts of your system. Having a thin line between what you see in edit mode and what you get when running is invaluable, not just to the understanding for beginners (which is a great plus), but for anyone wanting to avoid surprises because they lost the connection between the code and the result... As for break-points in reentrant VIs that is something to avoid and handle in a different way...that's a minor issue.

I see a lot of people wanting this, but why? We code graphically after all. The way to make sense of the underlying code to a G-programmer is to present it as G-code, not text... Ideally we had a SCC-system made specifically for graphical code, but I do not expect that to become a reality (unless someone made it on top of an existing one perhaps). Personally I live relatively comfortably with the solutions we can set up already, but would prefer to see it better integrated into LabVIEW and/or have out of the box solutions on how to get started with various major SCC alternatives. If the VIs were humanly readable it might make it easier to create more powerful alternatives to VI Scripting though, and to generate code at run-time in built applications...That is something else.

This mistreatment of WYSIWYG was the worst of NXG. Having multiple front panels and block diagrams open at the same time, and being able to jump from run to edit mode quickly to do debugging and GUI-testing is one of the core strengths of LabVIEW. The lack of understanding of this was also reflected in other changes, like the removal of the Run Continuously-button. The front panels need to present themselves as close to what they will be during run-time as possible (greatly lowers the threshold for new users in understanding things, but also helps experienced developers maintain a healthy relationship to their GUI - and testing(!) during the whole development) , with a minimum of development-related real-estate wasted around them. It can be nice to have lots of stuff available around a window under active development, but only on that window and only when you want it.

According to VI Package Manager the library is compatible with LabVIEW 2013 and onwards...SQLite can support multiple users, but it locks the whole database when writing, so if you have lots of concurrent writes it is not the database you want (usually the time the database is locked is a few milliseconds - so for most uses this does not matter).

The library operates directly on the database file, no ODBC.

The new branding is not my cup of tea so hopefully that does not tell too much about the new management. Reducing (the need for) administrative positions could be a good thing. As for raising the quality and speed of the LabVIEW development I hope they use their savings to keep and build a highly skilled, tight nit, centralized team. The developers should all worship Graphical programming🧚‍♂️🧚‍♀️, even though many of themselves have to be proficient with many an awful text based tool. If they have seen the light from the many lessons about the uniqueness of graphical vs textual programming embedded in current LabVIEW, they might not stray to the dark path of NXG 😀 Steal the best (the graphics) of the textual worlds, keep the spirit and innovations of G. The first letter graphic in the next LabVIEW should be G.👼

Here's hoping the right lessons have been learned, and that things will jump and move in a better direction from now on.

That would make sense if the question was whether they would support that a third party created a tool based on this type of manipulation. I do not understand why they do not support it within the project explorer though. When they control both the file format and the editor, supporting this type of target copying would just be a matter of updating it to their new format. They already convert the project file to new versions so that part would be taken care of.

I am sure it is possible to mess up any type of SCC system that way 🙃 The main complaints I have with SVN really is the slowness - mainly related to locking (can be sped up *a lot* if you choose to not show the lock status in the repo browser though), and the occasional need for lock cleanups... (When someone has been checking in a whole project folder and it did not contain all of the necessary files for example...).

Slightly related topic: I wonder what the trend looks like for the share of questions in the NI discussion forums marked as resolved. Based on my own posts there, it seems to get harder to find a solution to the issues I run into. I am not sure if that is just because the things I do in LabVIEW are closer to the borders of regular use / getting quirkier though, or if it is a sign of declining quality in the products involved. I suspect it is a mix of both. It would be cool if such statistics were readily available. A trend of the posting rate per forum/tag for example could reveal shifts in the interests of the users (the mentioned shift towards configurable turnkey solutions vs general application development for example) and/or the quality of the product. The latter might partially be possible to separate from the former by looking at the mentioned share of resolved issues; adjusted for the number of years of experience the questionnaires had (which perhaps could be inferred by how long they have been registered at ni.com and/or the number of posts or solutions made by that user...).

Good to see that we are not alone 😄

Sure, that's basic (always dangerous to say though, in case I have overlooked something else silly after all, it happens 😉). The lvlib and its content is set to always be included, and the destination is set (on source file settings) to the executable. The same goes for the general dependencies-group. The dynamically called caller of some of the lvlib functions on the other hand is destined to a subdirectory outside the executable, and ends up there as it should. But then so does lots of the lvlib-stuff - seemingly disregarding that is destination is explicitly set to be the executable. Correcting other usual suspects (read: additional exclusions) do not produce a repeatable solution either. Perhaps someone else here have observed similar voodoo though, and figured it out?

I happen to have some JKI JSON calls, among other things, in a dynamically called plugin, and it seems that whatever I do in the application build specification to try to get all those support functions (members of lvlibs) included in the executable, the build insists on putting the support functions as separate files together with the plugin (the plugin is here a VI included in the same build, destined to be in a separate plugins folder). (Sometimes I wonder if there is a race condition in the builder; what does it do for example if there are two plugins include din the build that will call the same VI, and the destination is set to Same as caller ..🤔That's not the case just now though, right now the only caller is one dynamically called external VI..) In an ideal world I think I would create a destination for the lvlibs that plugins are to use in a single external support container-file like an llb...In the case of this JSON library though there are classes involved to, so an llb does not work (name collisions etc). Packed libraries are too cumbersome to use I think, for various reasons (having to support multiple targets for example). So as a second best solution I want everything (all lvlibs that plugins may need something for) packed into the executable (works as a single file container, and supports classes as long as it is not using the 8.x file format...), but then the application build seems to behave very unpredictably. At first I would expect that if I included the lvlib on the always included list, and then set the destination of the lvlib to the executable I would be fine, but no. - Suspecting that this only applies to the lvlib-container file itself and not the VIs it owns, I then also set the destination for all dependencies and packed and shared libraries to the executable...- Still the builder puts lvlib-VIs together with the plugin. I have tried this with and without excluding unused members of the library with/without modification...and with and without disconnecting type definitions. In the end I returned to the original build setup (as this was noticed after a conversion from 2018 to 2020), tried a build, got a Bad-VI error on a couple of VIs used by an xcontrol, set those to include the block diagram...and voila - magically this affected where the JSON lvlib ended up as well, even though they have no links in the code. This problem keeps popping up though, and once it is there it seems like getting the lvlib-files to the wanted destination always includes some voodoo...😧 Or does it?