hooovahh

14 minutes ago, X___ said:

The number of 176 day reamaining, it is the time you have until your  active license expire, I can assure you that version 2021 SP1 will continue to work after the license expires.

I can talk a little about VLAs since I have them, but I can't say how they will be effected by this change because we haven't had to renew yet.

In the VLA you have a system where you have a bucket of licenses that can be assigned to users, or computers.  I think NI wants this system to be automated, and maybe for larger companies it is.  But in every case I've seen a VLA done licenses are assigned or revoked manually.  At my last company we had something like 4 professional licenses, and 2 base licenses.  Every once in a while someone would create a goal for themselves to learn LabVIEW, and we would go into the VLA, and assign a base license to them and let them take online training.  We'd often make a disconnected license, which was a license type that works without needing network connections to the server running the VLA.  This is because IT, and VPNs, and internet stuff caused problems.  It was just easier to make a disconnected license, then email them a file, with instructions on how to add it to the NI License Manager running on their machine.  For these people learning LabVIEW we'd often make the license PC based meaning any user on that PC can use LabVIEW.  But developers that worked on multiple computers could have the license be user based.  This meant they could log into any PC on the network with their user name, and active LabVIEW with the same license.  This user name also doesn't care about if the user is a local Windows one, or a domain controlled one.

When you create a disconnected license you can give it an expiration date.  This by default is the date that the next renewal takes place on.  However you can create a disconnected license, for a user or PC, that is permanent.  This license can be used on a PC without the internet, and can activate that version of LabVIEW or older.  Again this can be based on a single PC, or a user name.  When a new version of LabVIEW comes out, the VLA gets updated, and a new disconnected license can be created.

I've been making permanent disconnected licenses for myself and I think that means LabVIEW 2021 SP1 will be accessible even after this change.  After that I'm unsure if a disconnected permanent license can even be created.

11 hours ago, Aristos Queue said:

LV's user base continues to grow. Not as fast as it has at some years in the past, but it still grows at a reasonable clip. 

Sorry I have to play devil's advocate.  But is it growing slower than other programming languages?

Ugh that sounds terrible.  All of this on top of the typical stress of preparing for the exam.  You likely already know this, but NI has a program for recertifying by participating in NI events.  These accumulate points, and if you have enough points you don't have to take another test to recertify.  I've done this once, and hope to do this for as long as NI allows me to.  It used to be much easier to get enough points.  I'd participate in a beta two years in a row for 30 points, and attend NI week for 15 and, then attend a user event for 5 giving the 50 I needed.  Also presenting at NI Week is 30, which is over half way there.  Unfortunately I haven't had much time to participate in betas, and NI Week and the CLA Summit hasn't happened in a while.  Luckily there are still user groups where presenting gets you 10.  I got a couple years before mine expires but I'll need to make sure I do enough.  Passing the CLA wasn't easy.

On 2/11/2022 at 10:52 PM, JKSH said:

The next headache is the rigid UI. It is near impossible to get the UI to even resize with the browser window; the result feels rather unprofessional next to non-NI web UIs.

Agreed.  I did use WebVIs when they were part of NXG.  And I did get a UI that had a decent amount dynamic UI stuff.  But it was primarily done with many duplicate controls, inside transparent tabs, so I could show and had data, while making it look like things were moving around.  Of course at the time this wasn't straight forward, not sure if it has gotten better.  It got so bad that the IDE just chugged to a crawl.  I contacted support at NI and showed them the several hundred controls I needed to make it look normal.  NI's original reaction was "Why would you need so many controls?" and then after explaining the UI/UX I was trying to make their reaction was "Yeah I guess that is the only way to get what you want".  Luckily once built into HTML it ran just fine.  

On 2/12/2022 at 3:13 AM, Antoine Chalons said:

I think it’s a pattern at NI, only scratching the surface.

lots of products or support for standards are superficial. 

I've found a couple times when these limitations are arbitrary, or just based on incomplete testing.  A few times a VI will return an error when on a platform that it wasn't intended for.  If you look at the block diagram it is a conditional structure just set to generate an error.  In a couple cases when I removed the structure the code ran just fine.

15 hours ago, Neil Pate said:

Thanks hooovahh. Now I am even more depressed. As a LV dev that list makes for pretty sad reading in 2022. 

Sorry.  I suspect part of the issue is that once NI announced WebVIs and porting the runtime engine to JAVA script, companies probably thought there isn't much sense in trying to have a 3rd party tool compete with NI's.  And either froze development, abandoned the project, or rolled it into other tools.  Still I do use MediaMongrel's WebSocket API, and I've used the Front Panel Publisher on a program or two but nothing active right now.  I've wanted to update it to add support for more data types, and clean up the examples, but without a program that uses it, and with very little Java experience, I don't think anything will happen to it.

I like to reference this thread occasionally when people ask about web and LabVIEW solutions.  Since it has been a few years lets see if I can give another summary of the options.  I haven't used all these but just wanted a list of NI and non-NI ones that were available.  These are not all equal, and the intention is that here is a landing page where people can find tools and do their own research on what meets their needs, while providing a little history.

Solutions From NI:

G Web Development - Came from WebVIs in NXG's Web Module. Paid toolkit.

Web Service - Great for simple request response, but the UI needs to be made somewhere else. Included with LabVIEW Full/Professional

Web Publishing Tool - Simple to use, works on RT, but uses Silverlight and no modern browser supports it, just IE. Included with LabVIEW 

Data Dashboard - Tool for displaying Network Published Shared Variables on tablet devices. No longer supported.

Web UI Builder - Pre NXG no longer supported with download links missing. Linked to the 2009 Keynote. 

3rd Party Solutions:

Front Panel Publisher - Open source originally used Web Service but now uses Web Sockets.

MQTT WebSockets Connection - Open source. UI needs to be built by another tool.

WebSockets API by MediaMongrels - Free toolkit, MIT License. UI needs to be built by another tool.

LabSockets - Paid toolkit with trial.

Wezarp - Paid toolkit with trial.

Encryption Compendium for LabVIEW - Websocket API included among other tools.  Paid toolkit. UI needs to be built by another tool.

WebPager - Not sure never used it. The original site seems down.

VIRemote - Appears to be a paid toolkit but has a free demo.

WebPanels - Hosting site seems down, LAVA thread linked.

Remote Witness - I think it was a paid tool but the site doesn't have much.

Sorry I haven't had experience with HyperV and Linux RT VM.  I've stuck with Virtual Box and with the instructions posted on the idea exchange and didn't have any issues.

1 hour ago, flarn2006 said:

When I do, is it okay if I just link to this thread here?

You can, but it would probably be best to just paste in your issues and any example code that demonstrate the issue in the report.  That way the issue can be tracked more easily by NI.

Thanks for the info. LabVIEW Linux doesn't get much love.  Combined with the large variation in Linux environments can mean issues like these.  Can you post this on the dark side?  Is there a Linux desktop sub forum?  If not sending these to NI as a service request would also help.

59 minutes ago, jacobson said:

The two times we had people in our AE team do this we never got them back 🙃

Sounds like there is a common denominator here.

For the second question I said other.  What I wanted to say is there is very little if any, unused code in the project.  If I make a VI to do some purpose, and then that VI is superseded, or the functionality is replaced, I delete the VI from the project and SCC.  Obviously it is still in the revision history so it can be restored.  There are a few cases when a VI isn't used, but still valuable, and in those cases I'll either move it to a sandbox folder for the project, or copy it to the reuse library candidates, where it might be polished and added to a reuse library.

With classes I might end up with several small VIs that don't do much, but accessor like VIs are usually scripted through the class as needed and don't take much effort to make.  And for me almost all of my classes belong to reuse libraries, where you'll access them from the palette anyway.  So it might have unused VIs, but it isn't like you are aware of them in the project, or where they might be on disk.

I messaged the site admin.

On 1/15/2022 at 8:43 PM, Jordan Kuehn said:

Awesome, I will give it a try. The cluster writing would be great as well!

Yes I do have some issues with flattening a cluster to a string for logging.  I already have a set of code in this package for reading and writing cluster data to a TDMS file.  It just doesn't support the various TDMS Classes I made, it works on the TDMS reference alone.  But the code in this package has a ton of overhead.  It flattens the string to a string, with human readable decimals, and tab delimiters.  I posted an update on the dark side here which works much better but by writing the array of bytes as a string, with padding used on the bytes that need escape characters.  It also supports different methods of compression.  (some of this is in the VIPM.IO package too) 

This works much better but I found a bug in regards to how the extended ASCII table is used.  If you write a cluster to a TDMS file, then FTP that file over to a Linux RT target, it won't be able to read the bytes where the 8th bit is used.  I believe this to be a bug that NI hasn't confirmed.  In any case extra escaping characters can be used for these cases too.  Anyway this is all just to say that at the moment the reading and writing of cluster data needs some attention before being updated in this package.

15 minutes ago, Mads said:

The path to the rtexe launched by the RTE is not fixed...so perhaps you could just change the given path before killing the current application?

Oh that is better than renaming EXEs and copying them.  A native solution from NI would be even better but I'm guessing they don't get this kind of request often.  Still if the embedded target has some desktop like functionality it isn't crazy to be able to run arbitrary LabVIEW binaries.

So combining the script to stop and start the NI service, with a couple of file copies or moves, you could get something that works but is pretty clunky.  When the user tries to switch programs, it will need to copy over the other rtexe, replacing the current one, then have it call a script to stop and start the NI service.  That might bring up the new rtexe, but will have issues if you restart the controller as it will run the now new rtexe instead of the older one.  It might be possible to on start up, copy over the first rtexe back before the NI service starts.

All very clunky, and probably not what you want but possible.  Other developers would probably suggest trying to just make a single LabVIEW project that combines the code from both into a single application.

On 1/14/2022 at 1:30 PM, Michael Aivaliotis said:

I think you're more of a sidekick.

I'll take it!

Also a Texas Tea is like a long island tea but with tequila instead of gin. I like gin, and don't usually like tequila but man when I'm at NI week, those are amazing.  Thank you @Mark Balla. 

Okay here is a quick first update to the Write VIM that has special code if you are writing an analog waveform, or an array of analog waveforms.  It will write the waveform properties and then flush the file, then write the 1D array of doubles for a scalar, or a 2D array for a 1D array of waveforms.  On the next write it will see the property for the waveform exists, and not write it again, but the dT between the write must match.  If it doesn't it generates an error.

This is still using just the normal TDMS write.  So if you are having memory issues, this doesn't use the advanced stuff, and might not fix it.  Partially because don't have experience with advanced TDMS stuff, and also because I don't fully understand the original issue. Write Tremendous TDMS - Waveform.vimSet Waveform Properties.vi

Also I noticed that there is a disabled structure that has a partially implemented cluster write.  I should probably finish and test that.

1 hour ago, jcarmody said:

I had dreams of someday going to one and taking selfies with all of my LabVIEW heroes.  

Never meet your heroes.  Unless it's me and you're planning on buying me a Texas Tea at the piano bar.  In that case you should definitely meet your heroes.

So I'm still reading the thread, but I don't fully understand the issue, or the solution.  I get that you are saying there is some issue with the normal TDMS Write, and this issue is most commonly seen when writing waveform data.  And I get that waveform data really is just a 1D array of doubles, with a bunch of special properties.  So I can absolutely update the write function to instead of writing a waveform, write the properties and the doubles differently.  But I don't have much experience with the advanced primitives, and I'm not sure how they come into play.  Is it possible to attach a VI that demonstrates this uncontrollable memory leaking/growing problem?

14 minutes ago, Neil Pate said:

Total thread derailment... Hands up who remembers the great error cluster colour change. Was it 2005?

Around there, if I had to guess I'd say 8.0 or 8.20.

Okay I may have a solution, but I don't know if it will work in your use case or not.  If you wire a cluster to an Add, it will work if all elements in the cluster support the Add function individually.  So you could have a VIM that has a Type Specialized structure, and perform a type cast if all elements in the cluster support the Add.  Oddly enough in my test I used a Timestamp Constant, and that makes a pink wire, but supports the Add, and is a fixed size.  But I'm not sure I understand what you want done into the byte array.  If you are just trying to get a byte representation of a cluster, and you want to use a fixed string for those cluster elements, it probably would just be best to iterate over element in the cluster with while loop recursion.  What I think you what can still be done with a VIM, using the Type Cast in one type specialized case, and then if that fails, then to iterate over all elements.

Thanks I appreciate the feedback and I'll change it, but not push out a new version of the package for a change like this.  Also your comment does at least help me know that someone does use it on a cRIO and finds it useful.

Edit: Actually looking at the newest version of the package here, and the newest version of the package on VIPM.IO, the front panel looks like this.

And actually I think I always put defaults in parenthesis and not brackets, and I don't think I would bold a front panel label.  Are you sure someone didn't edit that?