A Scottish moose

On 5/4/2022 at 3:21 AM, Rolf Kalbermatter said:

LabVIEW never has been a money maker for NI directly. They were able to develop LabVIEW because of what they earned with their hardware sales. And LabVIEW was used to drive those hardware sales. A very successful model that drove others like HP Vee and such out of the market in the not very long term. Maybe HP/Agilent also was simply already to big for that market segment that they could possibly target with a product like this. The entire T&M component market isn't that huge. For HP it was what they had been starting with, but the big money was earned (and sometimes biggly lost) already in other areas. T&M was good for a steady revenue, but nothing that would stand out on the yearly shareholders report. It was unsexy for non-technicals and rather boring. That was one of the big reasons to separate HP into multiple companies. An attempt to create smaller entities that target a specific market segment and could be fine tuned in the sales and marketing efforts to the needs of that market.

About 10 years ago NI reached the size where they started to feel the limitations of the T&M component market themselves. There simply was not a big enough market left that they could capture, to continue their standard double digits yearly sales grow for much longer. Some analysts were hired to look into this and their recommendations were pretty clear. Don't try to be the wholesale everything for all little parts manufacturer in T&M, but concentrate on specific areas where big corporations with huge production lines invest their test and measurement money. Their choice fell on semiconductor testing and more recently the EV market. It has a huge potential and rather than selling ten-thousends of DAQ boxes to hundreds of integrators, they now sell and deliver hundreds of fully assembled turnkey testers to those corporate users and earn with each of them more than they could ever earn with several 1000 DAQ boxes.

What used to be NI's core business is nowadays a side line, at best a means to deliver some parts for those testers. But more and more a burden that costs a lot of money in comparison to the revenue it could even under ideal conditions generate.

If you can understand this you also can guess where NI is heading. They won't die and their shares will likely not falter. But what they will be has little to do with what they used to be. If LabVIEW still has a place in this I do not know. Personally I think it would be better if it was under the parapluie of a completely separate entity than the new NI but I also have my doubts that that would have long term surviving chances. Earning enough money with a development environments itself is a feat that almost nobody has successfully managed for a longer period. But the sometimes heard request to Open Source LabVIEW has also not a lot of chances. It would likely cause a few people to take a peek at it and then quickly loose interest, since its code base is simply to complex. And there is also the problem that the current LabVIEW source code never could be open sourced as is. There are so many patent encumbered parts in it and 3rd party license dependencies, that nobody would be legally allowed to distribute even a single build of it without first hiring an entire law firm to settle those issues. While NI owns the rights for them or acquired a license to use them, many of these licenses do not give NI the right to simply let others use them as they wish. So open sourcing LabVIEW would be a fairly big investment in time and effort before it could be done. And who is willing to foot that bill?

This is a good summation of the problem.  Thanks for sharing!

Ehh why not... <gets chair and looks intensely at camera>

I think that NI will sell in the next 2-3 years.  I agree with X on the churn rate.  There's zero chance NI comes out on top in the long term with this plan.  NXG is dead; LabVIEW as a competitive language is no more from a professional standpoint.  It's firmly an enthusiast language now.  That means like other enthusiast languages it's user base will continue to shrink from here on out.  Now you've got two options to deal with this problem; embrace it or hasten it's demise.  NI is obviously going with the later. 2-3 (maybe 5?) years of increased revenue while people work their way off the LabVIEW bandwagon (which they were going to do anyways when NXG was nuked) and then they are moving on. 

It's possible NI just understands the 'make hay while the sun is shining' concept and are going to get every value out of the product in the next half decade because, either way, LabVIEW is dead weight on the company in 5-10 years.  The other possibility is that subscription revenue has a higher impact on company value (on paper) than on-off sales.  I think subs are a 2-3x multiplier on estimated value.  If NI is looking to sell, moving everything to subs and holding for a couple years until they hit the peak of the revenue curve in 2025 and then shopping for a buyer makes the company look 50-100% more valuable than it was in 2021.  

All that's conjecture and theory. I'm more than happy to be proven incorrect, but I believe I am saying the quite part out loud here and I think that's a good thing. (I hope)

Best 

Tim

My approach has been Class based inheritance.  Have a parent class that accepts the messages in a VI and then overwrite that VI with your children classes. Using inheritance allows you to make a decision on who gets to handle the command first. The youngest class in the hierarchy gets a chance to handle the class first before you pass it up (or not).  I find that it makes it easy to handle the "What do I do if both controllers handle the same command differently?"

As an example.

MsgHndlrParent.lvclass:core.vi

ControllerChild1.lvclass:core.vi

ControllerChild2.lvclass:core.vi

Child 2 would attempt to handle the command in it's overwrite of core.vi, if it can't send it to Child 1:Core.vi, and if child 1 can't handle it pass it to MsgHndlr for error handling.  Hope that helps!

Tim

On 4/19/2022 at 8:48 AM, Aristos Queue said:

I_was_smarter_when_I_was_your_age

Can be read two different ways. 😉

Perceived_IQ = (150-age)

5 hours ago, Aristos Queue said:

I have been a community admin for another Stack Exchange site, and the difference in tone between the various sites astounds me. I didn't understand how much rides on the tone the admins take. Stack Overflow, the main Exchange, is really bad to the point that I have shadow accounts to ask questions there because once you ask what is seen by some as a dumb question, they follow you to your next question with "you're still an idiot" type comments. It's massively helpful when it is helpful and deeply insulting when it is not. But it doesn't have to be that way -- it's the choice of the admins for that particular Exchange site. 

There's a difference between one or two obnoxious persons shining a flashlight in your eyes versus a group of people with laser pointers and magnesium flares. In my experience, Stack Overflow is the latter form of hell.

I have always found that the core LabVIEW community to be kind and welcoming and more than willing to support and bring up new developers.  This is one of my favorite things about LabVIEW; that people actually have a passion for the language and the culture that it creates.  You write Python because everyone else writes Python.  You write LabVIEW because it's a unique experience and sharing that experience is part of the package.  The Architect's Summit every year was one of my favorite weeks of the year for this reason (aside from the free food  ).  The people on this forum are some of those most responsible for keeping that community expressly *not* like other programming communities out there.  It's a big selling point for the language and why I think it was so successful (IMO) in the mid '10s. 

On 4/13/2022 at 6:40 AM, Bryan said:

Just a thought, but I think that many younger/new developers aren't necessarily searching for online forums anymore. 

My guess is that newer generations of programmers may view online forums as "social media for old timers'".  If they have questions, they may look on platforms such as Reddit, et. al.  If they want to contribute, they may create videos on YouTube or other platforms where the rewards for contributing could be financial, notoriety or "influencer"-like status with a larger potential audience....

As a mid-career guy I think I can speak for some of the younger developers in the world.  If you are working on a programming problem  I think Googling "How do I do <this> in <programming language>" is basically the de facto solution to that problem.  Weither you get the answer from YT, Reddit, Twtr, IG, FB, etc is irrelevant as it the first answer on Google always wins.  This has been true for me for the last 10 years a least for whatever that's worth. 

If I could be so bold... I actually think one of LabVIEW's challenges is that it doesn't take well to posting on text forums and requires PNG'd meta files at the least to pass information around.  A 'dump VI to text' option similar to what was used in old video game saves (or Factorio blueprints if you are familiar with that game)  would vastly improve the share-ability of the language.  I might be showing my novelty here if this already exists. it would do a ton of good for the language.

22 hours ago, ShaunR said:

Try here.

I have frequently wondered on the 'Make it possible, but really inconvenient' approach to software legacy support that has become the norm amongst many large software corporations in the last few years.  I'm sure there is a  reason for taking this approach from the seller side but as an enthusiast/developer/consumer all I see is bad customer service...   

21 hours ago, X___ said:

Right... Feels like the 100 flowers campaign to me. They will learn their lesson quickly.

I hope this is true.  LabVIEW is the only language I enjoy programming in.  I had thought community edition was the solution to this problem but I've basically seen LV interest continually wane in the 10 years I've been using it.

Corp gave the rubber stamp so I'm planning on being there.

18 minutes ago, X___ said:

Just to make it clear to those who did not watch the video (or attend the meeting): these were LIVE inputs from the audience, which were fed directly into the presenter's screen.

But, yes, I don't think the "distribution and licensing" comment was addressed by NI's new licensing policy. But again, he just laughed all these comments off and went on to the next question.

Harsh but true. 

To his credit it takes a brave presenter to take live comments, especially when they are posted directly behind you. 

Hey everyone! 

I've looked through google and the lavag forums for this problem and haven't found much so I thought I'd ask and see if anyone had some ideas.

Problem:  I have an executable that is launching applets from several different PPLs.  I am defining what PPL should be loaded by passing an INI file as command line arguments and also providing any other important start up information in that file.  I've been trying to also force the icon on the application to set so that, depending on what the user is doing, the icon matches the process that I'm presenting them.

Originally I thought this to be rather trivial as LabVIEW provides an invoke node to set the icon but after attempting it (and then checking the documentation) I realized that it is not available at run-time, (also it doesn't support .ico files according to the docs)

http://zone.ni.com/reference/en-XX/help/371361R-01/lvprop/vi_set_vi_icon/

My hope is that I can force the application icon on the start bar and the title bar to match the .ico file that I'm providing to LabVIEW from the ini file.  Any thoughts on this?  I assumed it would be rather simple, just a function call to the right property/invoke/activex node but I've not come up with much at this point

Thanks for your help,

Tim

Hello everyone,

TL;DR - Any thoughts on if it's a good or bad idea to spin off an actor from a QMH framework?  I've got some library code that would be valuable but the project itself doesn't justify AF.

I'm brainstorming ideas for a tester that I'll be building over the next few months. The project that I'm currently winding down is an Actor Framework test system that has come out really nice. Part of the project was an actor built to handle all of the DAQ and digital control.  The main actor spins it off an tells it when and what tasks to launch.  It send back data and confirms commands, uses Dynamic events to keep up with the generated signals, and uses actor tasks to ship the data back to the controller.  Works amazing. Nothing revolutionary for sure but very handy.

This next project doesn't really need actor framework, it's much smaller and has a lot smaller list of requirements.  That being said I'm curious about integrating my DAQ actor (Dactor, because who can resist an amalgamation?!) into the project. Any thoughts on if it's a good or bad idea to spin off an actor from a QMH framework?  Is this even possible based on how the AF tree is designed to work?

Thanks for reading!

Tim

Anyone know of a way you can do a ctr+drag on the block diagram (adding or removing space) that only impacts the current structure?  I find myself wondering if this functionality exists often enough I thought I'd ask.

Basically if you have a for loop inside a case structure is there a way to do a drag inside the for loop and grow that structure without impacting the case structure size or position?

Thanks,

Tim

Yes.  They are... however this was out of the classic palette.  Perhaps you've taught me something new.  I was under the impression that only system dependent controls are in the systems palette but I bet you are correct. The system button in the classic palette is OS dependent.

Good catch

Don't listen to my previous posts then because my conclusion was incorrect.

Also thank you for your observation.  

Tim

Update: I was able to replicate the original look with a 'Flat Square Button' and some color matching in about 5 or so minutes. Just be aware that if you move to sp1 of 2016 some of those graphics will change on you. Replicating them isn't a big effort however.

Cheers,

Tim

Hello Everyone,

I noticed an interesting change today that I thought was worth mentioning.  I've been using the classic system button for some of my UI's.  It's flat and looks clean.  Less busy.  I noticed today that the graphics for this button are different from one of my PC's to another.  My laptop, which is running 2016.0, looks like the original.  My desktop which is running 2016.0f2 looks like the 'different' one.  Both 2016 but one has no depth graphic and one does.  I've dug through the menus folder and it looks like the classic and modern controls are not housed there, which makes sense really since they are probably proprietary.  I'd prefer the original look as it matches with the flat Windows 10 style that's in vogue right now.  Just something I noticed and thought was worth mentioning.

Cheers,

Tim

Thank you sir

Hello Everyone,

A couple CLA summits ago (and I think even at an NI week or two) one of the NI R&D guys demo'd a software library that used variant attributes to create a lookup table.  It was a class based interface that could be swapped into an actual database later if needed. I'm in the process of developing an application that would really be able to use this concept. I remember sitting in on this discussion but I don't have any notes on the name of the project or where to find it.   I did some digging on NI.com and LVPM but came up with nothing so far.  Does anyone on here remember that discussion and perhaps know what I'm talking about?  

TL/DR - A couple years ago an NI R&D engineer demo'd a lookup table that was class based and ran on the variant attribute engine in the background.  Trying to remember what it was called, looking for tips.

Thanks,

Tim

Hey everyone!

I'm working on a test system right now that requires the operators to sign the test reports.  In the previous generation this was done by the print/sign/scan method.  During one of the meetings it was mentioned that getting around this requirement would be nice.  I recommended we look into a digital signature pad and see what would be required to integrate one.  I've been thinking about ordering one and just giving it a go but I thought first I'd ask and see who has done this with LabVIEW before.  I know someone has, I just haven't found the documentation online yet.  

Here's how I expect it would go:

1. The software prompts the user to sign at the end of the test.  

2. The signature pad saves the image location to the hard drive or provides it to the client through an API (any experience on how this usually works is appreciated) 

3. My software would aquire the image and save it to a named range in Excel using the report gen toolkit.  Currently my report writing tool of choice.  

4... Profit!

Does this theory match with reality?  What are your experiences?  Do you have any models you prefer to work with?  

I dug for a few minutes on this and didn't come up with much so perhaps a discussion on the subject is valuable.

Thanks for the help!

Tim

What about stripping the VI of it's borders during runtime?  This is what I've done and it's worked well.  If the VI is just a box during runtime you'll end up with that nice splash screen look... The attached shows how I set up my splash screens and that as worked for me in 2015 and 2016

Using 2016.

 Checked the strict Type Def idea, nope, using regular type def. Good idea though!

 I've tried to reproduce it a bit today but haven't had much luck.  Yay for non-repeatable failures!

2 hours ago, crossrulz said:

If you are just adding to the end of the enum, I don't think the enum constants are supposed to reset.  I have ran into issues when changing names and/or adding in the middle, but the Update Typedef tool is used to fix those.  Now I have to go play around with this...

Exactly!  This was my thought too, and the exact reason I add at the end of an enum if at all possible.  Going to work on it some more today and see if I can figure out why.

Hey everyone,

I'm working on a midsize (Actor framework) project that has a main command message that gets used by all of my nested actors.  This command messages payload is a typedef enum that defines what job gets done.  As I've been developing the project I've been adding values to the enum and handling the resulting job in the 'send command.vi' message....  This works well because all of my nested actor messages that don't have a payload just send a constant enum to the controller to request a job... so I'm adding a new function to the said enum and after editing the typedef LabVIEW resets ALL constant instances of this typedef to default across my entire project. Every instance in memory of this enum gets set back to the zero value.  I have everything backed up in SVN so this isn't a big deal from a time standpoint for me but I don't think this is intended behavior.  Has anyone else seen this?  

TL/DR - I have a typedef enumeration and after adding a value to the end of the enum it resets ALL constant instances of this enum to value 0... ideas?

Thanks,

Tim

18 hours ago, Neil Pate said:

Yup we were trying to be positive.

I have not experienced too many crashes involving classes lately although I do purge the mutation history every few weeks 

(No problems with a medium size project including approx 85 classes).

How does purging the mutation history work?  Any white papers you could link to on this?

Thanks,

I forget sometimes how easy it is to test a function or behavior in labVIEW.  Ctrl+N and throw a few VIs on the block diagram and see what it does.  So very powerful for sure!