Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Mads last won the day on December 10 2020

Mads had the most liked content!

Community Reputation


About Mads

  • Rank
    Extremely Active
  • Birthday 12/01/1975

Profile Information

  • Gender
  • Location
    Bergen, Norway
  • Interests
    Trail running, skiing, fly fishing, science fiction, food and travel.

LabVIEW Information

  • Version
    LabVIEW 2020
  • Since

Contact Methods

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I'll leave the logic to others for now, but here are a couple of initial observations: 1) If these tables can get larger you might consider making the table cell formatting more efficient: Defer front panel updates (updating table GUI for each step is extremely slow) then format the table cells and headers in one go before you reenable front panel updates. If all rows of all columns are to have the same format anyway (empty ones can get the same as they are empty anyhow) you might as well set the active cell to -2,-2 and apply to all. If the headers are to be different you can then apply
  2. I have not seen that. It is not the NI Tools Network your thinking of, is it? We did put one product there as it relies on NI hardware, but otherwise it feels more right for libraries and coding tools than generic applications...
  3. I recently needed to figure out a good way to get a piece of shareware (developed i LabVIEW) distributed to the various popular download sites. It does not really matter which programming language or tool(s) were used in the development so I did not search for help on this here or at ni.com. One good source I found was this https://www.fatbit.com/fab/promote-software-app-online/ It did strike me as a bit curious though that we never really discuss such matters. Most applications developed in LabVIEW are probably not generic enough to be released through such channels, but sometimes they a
  4. I have seen this a couple of times in my applications and a fix then has always been to either remove all but English, or support all languages on the run-time languages page in the application builder (perhaps any change there is what is really doing the trick, I have not explored that as I have always just moved on when the error disappeared).
  5. Just to tie off this thread: The reason for the glitch was that the wiring allowed for a minuscule race-condition ๐Ÿ˜’. One minor adjustment was needed to ensure everything was *only* decided by the enqueue scheduling. So no worries about that anymore ๐Ÿ˜€
  6. 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.
  7. 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 th
  8. 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
  9. 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
  10. 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
  11. 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
  12. 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.
  13. 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.
  14. 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 o
  15. 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...๐Ÿ˜’
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.