Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Posts posted by mcduff

  1. On 7/12/2021 at 4:53 AM, crossrulz said:

    Code is also orders of magnitude more complicated now than back then due to more computational power being available and therefore more features are possible.  More code just increases the probability of bugs.


    About 15 years ago, I was peripherally involved on testing code for a $50k FPGA in a satellite.  The amount of testing that code went through was absolutely insane, including days of just Reed-Solomon test cases.

    Don't disagree at all with the increase of computational power, but JPL has rules for code. I think having a set of rules helps to reduce possible errors.

  2. 29 minutes ago, X___ said:

    Let's clarify:

    if you develop in LV 2020 and use the released standalone with LV/Vision 2020 RTE, I am assuming there is indeed no problem (I haven't tried)

    If you develop in LV 2019 and use the released standalone with LV/Vision 2019 RTE, things work fine (I have tried, box checked or unchecked).

    It is only when you release in LV 2019 with checkbox checked AND use the released standalone with LV/Vision 2020 RTE that things go South (my experience of that is indirect: a user reported a problem that sounds related, but I can't verify that it was that specific problem, as it was subsequently solved by using LV 2019 RTE - I think. However there have been two other reports above that seem to confirm this pattern. It would be nice to have NI look into it in order to move from the anecdote level to the bug tracking one).

    You thought it out more than me. The test will be when I get 2021.

  3. 2 hours ago, X___ said:

    I am not sure I understand the reasoning. The DMC image display control is just a  cosmetic modification of the original control. It doesn't change anything to the underlying coding.

    It seems to become a consensus that checking that box sounded like a good idea, but turned out to be a very bad one in some cases. I have stopped checking it when releasing a standalone app, as I don't have the bandwidth for testing all corner cases.

    Again, as long as nobody reports the issue with NI, nothing is going to be done about it. I won't because of the above sentence, but someone making his or her living from products developed with these tools might want to send a wake up message to NI. You can't engineer ambitiously if you dread every single checkbox in the application builder.

    Just reporting that I used the DMC image control, had the box checked, and did NOT have a black image display. (LabVIEW 2020SP1, 64bit, Win10)

    No commentary on whether to check/uncheck box. Just suggesting a possible work around for folks who may want to check the box.

  4. Not commenting on whether to allow future versions ...

    However, if it is checked and you want to use an image control that won't change colors in the EXE version, the Image Control in the DMC controls package available on VIPM does not suffer from this problem.

  5. 3 hours ago, Neil Pate said:

    I actually have a scenario where your MoveBlock method might be faster. Using the primitives you cannot replace a portion of a row (which is actually what I want to do). This should be a lightning fast operation but I have to either do it item by item or index out the row first, replace a portion of it and then replace the 2D array.

    Probably slower than your method, but it is possible using primitives, and it is quite messy also. See below.



  6. On 6/18/2020 at 4:54 PM, Aristos Queue said:

    The core of our business has changed. Fewer users are developing their own test applications; instead, they're buying something off the shelf like  TestStand. Fewer users are developing their own data acquisition software; instead, they're buying something off the shelf like FlexLogger. This trend alters significantly the role of LabVIEW (CG and NXG) in the NI ecosystem -- it becomes far less important to support whole application development (though, of course, we still do and will) and far more important to support "just a bit of customization" when the pre-built tools fail. A lot of software has an endless array of switches and options, but LV provides the ability for a user to write a custom routine to specify the behavior they want in some corner niche of a product. Think like Signal Express, able to generate sine wave, square wave, triangle wave or "pick a VI that generates the wave that you need" wave. 

    What's funny about this is that although the app devs are growing rarer, they're also individually growing more profitable for NI as a whole because the companies still paying to develop custom software are the ones that are generally buying a lot of hardware to do something unique in the world (or not in the world, in the case of SpaceX, Blue Origin, Ad Astra, etc.). So I don't expect the big scale parts of LabVIEW to vanish, but I do expect them to be driven by specific requests from megascale customers rather than from the massed collective. The massed collective will be driving more of the IDE developments. At least, that's my suspicion at this time based on the presentations I've seen. 

    It appears that NI is a hardware company rather than a software company. LabVIEW is developed to drive sales of hardware. This is similar to Apple, OS X, iOS, etc, are all developed to drive sales of hardware.


  7. On 5/5/2020 at 8:09 AM, Aristos Queue said:

    Nope. Variant attributes and maps use the same — identical — underlying data structure. For reasons I don’t grasp, the C++ compiler adds a couple extra instructions in the maps case only when the keys are strings that aren’t in the variant attributes. Still, the conversion time to/from variant for the value tends to dominate for any real application. 

    Please correct my misunderstanding, the biggest difference between Maps and Variant attributes are

    Maps: Keys can be anything (all keys the same type), but all "attributes" need to be the same type.

    Variant: Keys need to be strings, but "attributes" can be different types.

    The structure seems similar, although slightly different.


  8. 4 hours ago, Aristos Queue said:

    Of your six items, NXG addresses three of them and has improved support for a fourth. The source code control stuff is still in flight -- not sure when the target is for delivery [again, not my department]. Sealed classes is so far down the priority list, it's not even in the backlog I bet. I couldn't get traction for that in LV20xx. 

    @Aristos Queue

    I haven't used NXG yet, but I heard that a future feature was the ability to drop other code snippets in the the block diagram. For example, I heard that it would be possible to drop some C code, Matlab "script" code, or python code directly in the block diagram.

    Is that still going to be a feature?



  9. There is important aspect to the Front Panel defer updates nodes, this is from the help

    When you set this property to TRUE, LabVIEW redraws any front panel objects with pending changes then defers all new requests for front panel updates. For example, controls and indicators do not redraw when you change their properties or values. If the operating system requests a redraw, such as if the window is no longer behind another window, LabVIEW redraws the front panel with the current properties instead of the original properties. If FALSE, LabVIEW immediately redraws the changed elements of the front panel.


    So when you use it, it actually causes the front panel to redraw twice.

  10. On 12/28/2016 at 7:12 PM, martijnj said:

     My understanding is that netCDF-4 is an HDF5 file with specific applied structure


    Would you happen to have a document that has HDF5 attributes needed to make an HDF5 netCDF-4 compliant. I have downloaded some example netCDF-4 files and the attributes among them are slightly different. In addition, finding information on this site is not straightforward.

    Thanks for your help.




  • Create New...

Important Information

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