Michael Aivaliotis

On 5/6/2020 at 2:43 AM, ShaunR said:

Your argument is inconsistent. If it's not a priority then making a change to remove it is allocating resource to "the least important". Leaving it in would be the least impactful. However. If you are going to change it then you might as well make it a "Preference" since that is clearly what it is. You don't seem to have a preference or, at least, are indifferent. So why advocate taking away a feature that other people obviously feel strongly about?

Inconsistent to a post i made 10 years ago? Besides, that was related to CG. I'm not advocating for removing an engrained CG feature. I thought we were discussing NXG. My assumption is this feature hasn't even beed implemented in NXG. There is a lot more work required in NXG to make it even barely usable. Lack of continuous run is not a problem in NXG. Lack of everything, is a problem.

4 hours ago, ShaunR said:

Just make it an ini/preference setting. The main tenor of that thread seems to be "I'm not very precise so please remove it" which, from that low point, then devolves into "my work-flow is better than your work-flow".

I can live without it. On the level of priorities for NXG, this has to be the least important. Just drop the vi on the diagram and wrap a while loop.

8 hours ago, Neil Pate said:

I am a bit late to the Map party. I love them though, thanks NI. 🤩

For those that have not tried them, take a quick look. I have only used the Map a few times (so cannot comment on Sets) but the API is nice and simple. Goodbye Variant Attributes 🙂

I can't live without them.

4 hours ago, Neil Pate said:

That is possible. Obviously for the sake of change a colon is now used to separate the elements, because hey they were changing everything else, right?

Oh, so it selectively only works for clusters then. Well at least NXG is consistently inconsistent.

1 hour ago, Neil Pate said:

Same with this unbundling drama in classes. No LabVIEW developer would look at the technique in NXG and come to the conclusion that is a good experience

So I guess NXG doesn't support dot notation unbundling.

So I took a look at the code that pulls the device info and ya, my assumption was correct. Actually, not sure why they are even reporting on the model type. It should just return the generic type. Like Raspberry Pi. No need to report the exact model, since you will always be wrong and really, it doesn't matter.

10 hours ago, Neil Pate said:

The depressing thing is I don't even want to know how much money has been sunk into development.

Considering development was started years before even the CABs were a thing. i'd say too much money. For a product that is not used by the majority of veteran developers, this is a problem. This is similar to the Star Wars franchise that was taken over by Disney. They decided to move forward with new characters and stories and burn the past.

I'm hopeful that this will still evolve and improve over time. ...while I'm still alive.

11 hours ago, Aristos Queue said:

Wouldn’t be “Go To...” it would be in the project item’s Find menu with Find>>Callers. Like all of those, Find>>Parent Interfaces would jump directly if there was only one and pull up a results list if multiple.

That works.

11 hours ago, Aristos Queue said:

The project tree is an all-files view. Not every file is a member of a class. There are VIs in libraries, loose VIs, non-LabVIEW files (like readme.txt). We talked about a class view in project back at start of LVOOP project and repeatedly since then, and we repeatedly decided the project window was the wrong place for that. That is the reason the LabVIEW Class Hierarchy window exists.

Ya, I get it. But a new view wouldn't hurt for those passionate OOP users. Similar to the Files tab, you could have a Class tab.

As a side-note. In 2020, NI changed the "change inheritance" dialog to "change parent class". Most likely due to interface nomenclature. But this triggered a thought in my head. Why can't we get this class relationship view inside the project tree? It seems useful.

3 minutes ago, Mike Le said:

How would this work if a class has multiple interfaces? Maybe instead of a right-click menu option, some kind of visualizer that only shows the class's interfaces?

Maybe a fly-out menu.

Checkout @ElijahKerry's home automation project I also featured on my VI Shots livestream. It's a great demonstration of how to interface to NXG webVIs to get a nice interface into your hardware:

It would be great to have a project menu item, goto parent interface:

1 hour ago, Jordan Kuehn said:

I too was looking at those hats. I haven't gotten too deep into it, but it does seem like they haven't built LV drivers for them yet and would require calling some custom commands from the Raspberry Pi. At least according to the existing LINX webpage:

https://www.labviewmakerhub.com/doku.php?id=libraries:linx:faq#6

However, I have used MCCDAQ products before (TC-32) and they do seem to have some good LV support in house. I wouldn't be surprised if they add support to the product. If I'm wrong about needing custom commands/drivers that would be great!

Well considering NI owns MCCDAQ... It could be a good thing or a bad thing.

On 4/29/2020 at 6:14 AM, Jordan Kuehn said:

I'm very curious to see if this can fit a niche where a cRIO is overkill and $$, and I really need something like a USB-61xx in an embedded target.

I'm investigating this hardware which might fit your requirement: https://www.mccdaq.com/DAQ-HAT.aspx

11 hours ago, Jordan Kuehn said:

Awesome. Thanks!

I'll be putting out videos on testing all the hardware out there and compatibility with LVCE, over time. As I do, I'll be populating this page: https://labviewwiki.org/wiki/Linx_Toolkit_Hardware_Compatibility_List

If others confirm compatibility, then please update that page.

15 hours ago, Neil Pate said:

Thank you. Sounds like I should just wait a few weeks for the official release of 2020 and 5.0

Ya, you're kinda in a gray area, between release dates. However, you can still download it and play with it. That's what VMs are for right?

The LabVIEW community edition, community is tiny right now and it's up to all of us to build it up and help others. We are the pioneers so to speak. Don't forget we have the LabVIEW Wiki to use as a place to create compatibility tables and information. Creating a LabVIEW compatibility table should be the first thing on there, actually.

15 hours ago, Jordan Kuehn said:

I'm looking at the Pi Compute 3+ for example as well as Pi 3 and 4.

I've tried the Pi4 it works no problem. No idea about the Pi Compute. However it has the same CPU and guts of a Pi3, which also works, so don't see any issue.

That's a good question. I know it's not officially supported in the LINX documentation. I think it has to do with the type of ARM processor used on the zero vs the Pi 4 (for example). I just received a Pi zero, in my hands and will be trying that out soon. So I'll let you know if I find out anything. I remember seeing some info by someone in the community working on this and will post any info i find.

Edit: LINX toolkit does not support Pi Zero. If you need a small form factor Pi then look for a device with the same or similar CPU.

If you want to try LabVIEW, you can download a free full version of LabVIEW for non-commercial use. It contains the LINX toolkit so you can use Arduino, RaspBerry Pi and Beagleboard:

Download LabVIEW for Free

Ok, now your idea has 2 votes... 😀

Ya, I decided to delete them all manually, and also the Update Service installers, which are probably temporary packaged files for the update service.

I work with VMs and monitoring VM drive space is one issue I look at every now and then.

The "C:\ProgramData\National Instruments" folder on one of my VMs is using 40GB. Does anyone know the proper way to clean up the NI crap?

Using SpaceSniffer, it show the bulk of it is used by the Update Service and NI Package Manager. I'm sure it's just leftover installers that may be needed.