mcduff

The issues that I have found are frustrating are the following:

1. Staff go on field test with their laptops in another timezone, and forget to change the timezone. Although the metadata is in UTC, when they look at the time in their file stamps(time created, etc,), they get all confused.
2. Timezone caching, bit me on a field test, luckily I noticed. Started the program, realized I had not changed the TZ, and then wondered why my timed start did not update correctly.

Not sure if this is related, but I have had an issue where if the LabVIEW program had been running and the timezone was changed, the time in LabVIEW would not be updated until the program was restarted. It appears LabVIEW caches the the timezone information and the beginning of the program and never receives an event that the timezone has ben updated. 

I wonder if it does the same for DST.

And yes, I use UTC times for saving metadata in the file, but the users of the program like a local time stamp on the file name such that it matches their notebook log.

It looks like the external dll call has an extra buffer allocation, don't know if it is real or not, just what NI is reporting, whereas, the native implementation does not. See below. That may account for the speed difference.

EDIT: Execution Trace toolkit shows the same.

FYI, cross-posted on the dark side

https://forums.ni.com/t5/LabVIEW/USB-6215-10-Hz-triggering-with-2-TTL-signals/td-p/4181960?profile.language=en

Maybe not a new feature, but somewhere in the talk they mentioned a 2021 LabVIEW license would give you access to Windows, Linux, and Mac versions, no separate purchases required.

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.

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.

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.

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.

MAT files are now just H5 files(HDF). Look at the library https://h5labview.sourceforge.io/  and find the example for writing a MAT file. You just need to add a special header in the beginning. I assume the dlls needed will work on Windows server, but am not sure.

Maybe this link on the dark side may help:

https://forums.ni.com/t5/Example-Code/Determine-Clicked-Array-Element-Index-in-LabVIEW/ta-p/3536340?profile.language=en

(Some limitations in the code, may have to change for newer style arrays)

mcduff

The following will replace a row or column subset or complete row or column of a 2D array using native functions and no loops or IPEs. If your subset array is 1D all you need to do is reshape it before a replace operation.

ReplaceRowColumnSubset.vi

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.

Maybe this thread can help, if you haven't seen it before

mcduff

The Matio library uses the old .mat file format; the new .mat format is based on HDF. Try one of HDF libraries to read your .mat, or re-save your file using the old version.

mcduff

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.

mcduff

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.

mcduff

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?

Cheers,

mcduff

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.

Try this link for Material Design https://materialdesignicons.com/

You can do an advanced export where you can change the color.

Wow. You picked the hardest thing to start with. Start with the following.

http://www.ni.com/getting-started/labview-basics/

http://www.ni.com/academic/students/learn/

http://www.learnni.com/

http://sine.ni.com/myni/self-paced-training/app/main.xhtml

http://www.ni.com/training/labview/

https://labviewwiki.org/wiki/Home/

NIPM

I saw a seminar by the person who created the program. It basically converts LabVIEW code to an Arduino script such that the Arduino can run without being attached to a computer/LabVIEW etc. I believe you can still communicate with a PC if desired.

mcduff

36 minutes ago, drjdpowell said:

i'm afraid I only ever had the documentation from the netCDF website, sorry.

Thanks!

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

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

@drjdpowell

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.

Regards,

mcduff