hooovahh

I'm not sure how much time you want to invest in any of these, but I looked into making my own just with the hardware we had on hand.  The stack lights we bought were cheap 24V ones, with individual wires for each light, and buzzer.  This meant you needed to use a relay of some kind to switch each light to the positive 24V to have it turn on.  Using an embedded device and some relays it can be pretty easy to setup things like blinking commands setting frequency, and watchdog functionality.  This allows you to make your own communication standard, and can be done through TCP, UDP, Websocket, Web Services, or maybe VISA.  The reason this was important to us is the devices controlling the lights might be a Linux RT target or Windows, and calling a DLL wouldn't cut it.

The experiment didn't get too far.  I started with an Arduino Mega, and used a cheap ethernet shield and touch screen to set IP address information, along with manual relay control, and status.  It worked okay, but was over kill for most things.  It didn't have watch dog, or blink functionality and the screen I got was a terrible with very little control.  I ended up needing to hack it a bit to allow for the screen to turn off rather than be on all the time, and it used a bunch of digital lines since it was the wrong interface.  If I were to do it again I'd probably use a Raspberry Pi since LINX supports deploying LabVIEW code.

Sorry I don't have experience with any pre-made solutions, but if it is ethernet based you can probably use wireshark to capture the communication, then replicate it in VIs.

Yeah I've gone down issues like that in an attempt to make a better looking multicolumn listbox.  In my case I wanted to have custom control options in my cells.  Maybe have a Boolean cell that toggles from one color to another when clicked which is easy enough.  But I also wanted drop downs for discrete cell values, numeric controls with increment decrement, color selection with a color box, and Tab and Return key navigation.

It turned out okay in limited usages.  But when you do things like resize a column, put it in a resizable pane, or subpanel, then lots more work was needed to ensure things looked normal.  I suspect you can get away with a cool transparent boolean, that reads the column locations and moves it there.  Just be sure and take into account the resizing nature, and hide the control when resizing or moving, then show it back once the resizing is done.

Yeah I have some drafted documents about my work and integrator issues.  Still waiting a bit for the statues of limitations. 

But the gist of it is that I worked at an integrator who sent me to a customer to do work.  I was working with them full time for a few months and they offered me a job.  There was a non-compete clause stating they couldn't hire me unless they paid my one year salary to my current employer.  Turns out I wasn't getting paid all that much and they were willing to pay the fee.  Instead I was given a raise to stay (and thereby increased the fee).  After the year was up they came back and offered me more pay since they now didn't need to pay the breach of contract fee. 

I'd been given offers from other customers plenty of times, but this was the first place I was sent to that I could see working at.  It was sorta poaching, but totally my decision to make.  And one I didn't take without considering what I would be leaving behind.  It also wasn't a spur of the moment thing, since I had a while to think about it.

9 hours ago, mcduff said:

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.

O RLY?  I'm not a Mac or Linux desktop user, but that might give me a reason to experiment in Linux and LabVIEW if the license and software is included with our SSP.

I'm interested in 64 bit RT and SFTP.  Python and Matlab integration is cool but not likely something I see using.  And there had better be a new icon number.  If there is that will be my number one new features of LabVIEW 2021.

Here is a tool that I used at one point to quickly view and update VI and control documentation..

https://forums.ni.com/t5/Developer-Center-Resources/VI-Properties-Editor/ta-p/3492371

https://bitbucket.org/merecsengineering/vi-properties-editor/downloads/

Glad you found a solution.  Keep in mind I think that method only works if you have the front panel loaded into memory.  I saw a clipboard API years ago but can't seem to find it now, which would probably work in that edge case better.

15 hours ago, MichaelBalzer said:

Sorry for the rant at the start, but this has got to be one of NI's most poorly supported products (except for maybe the Functional Safety Editor -

Oh wow never heard of this thing, and now that I'm looking at it, it sure seems like trying to solve a problem that has already been solved with state machine templates or State Diagram Toolkit, with an RT or FPGA.

Well maps could make this caching stuff a little easier.  Using the Variant Attribute meant having to use a string as the unique identifier years ago, where today a map can be a cluster of random data.  But beyond that I can't think of a way to make this whole process any easier.  If the native function is slow, you can try to use this caching method, and possible save and load its results to disk too, in a temp file or something.  I still don't know the cause of this functions slowed down behavior, and can only suggest ways to work around it

On 7/5/2021 at 2:44 AM, JimPanse said:

There is no RT Linux Labview for Desktop PCs. 

I searched and couldn't believe I couldn't find an idea on the idea exchange for this so I made one here.  There is a related idea of having a VM of the Linux RT environment, and some comments in the post outline how to do this.  Using the method described you can have Linux RT on a desktop, but there is no support from NI, and in my experience network driver support is limited.  It is also a licensing issue as others have pointed out, since NI's drivers aren't licensed for this unofficial hardware even if the kernel and Linux core is less restrictive.

Oh I understand now, that is a pain for sure.  I'd try just by plugging in the device and restarting the controller first, and see if any new device is seen in MAX.  If not I don't think you'll be able to get away with a RS-232 to USB, and USB to RS-232.  I'm guessing you are going this route because there isn't any other communication methods for your device?  Obviously LXI or ethernet would be easier, and even RS-232 instead of the USB which will act like a RS-232 device, would be better.  But if you really are stuck with USB out of the device, and it isn't recognized by Phar Lap, then I don't have any other suggestions.

What is the controller you are using that is running Phar Lap?  I've never tried any of the RS-232 USB devices with it but the cDAQ running RT Linux works great.  There is a limit to I think 12 serial devices that is a bios limitation.  I've also used some controllers that have a RJ-45 connector that has serial pinned out in it.  Also I did find this thread that might be useful.

This thread on interview questions might be helpful.  I suggested asking about describing reentrancy in your own words, but I think that might not work.  Matt in that thread suggested asking what your favorite, and least favorite features of LabVIEW are which might give incite into their experience level.

Still finding good engineers who don't need much hand holding often takes years.  And I don't mean like 6 years of experience, where you repeated the first year 6 times.  Those types of people are either very expensive, or are very under appreciated.

So for the most part I believe these could be replaced with VIMs.  I think the only feature that is used that a VIM wouldn't support is that the icons change color based on the data type being used, but I'm not sure anyone would really miss it.  This also supports writing a scalar or array of data but a well constructed VIM can do that too.

Also I believe there was a bug in early versions of LabVIEW that supported VIMs, which wouldn't allow for an inlined VI that had the New DVR primitive, but I just tested in 2020 and it worked fine.

So one thing I have done in the past is generate an installer using Application Builder, but not include any VIs or EXEs.  Then you can call this NI installer silently from something else like InnoSetup. 

37 minutes ago, Gepponline said:

Yes, I've posted my question to both forums 'cause I expect different users use different forums so better possibility to have suggestions.
 

That's fine, it just helpful for others to know that a duplicate conversation is taking place elsewhere, so that we know not to suggest things already tried, or to suggest things that have been tried or won't work for some reason.  Oh and in the past I have used this toolkit but have had issues with Windows picking the right printer in the past.

In cases like these I assume (possibly incorrectly) that NI's compiler can handle these lower level operations better than me.  They have more intimate knowledge about what is happening, and can make performance improvements to handle the delay and notification of data to dequeue better than me.  Then again I know more about what my application needs than NI, and maybe I could write more specific software for a queue, and NI needs a more general purpose solution.  I don't really have any more information on how NI implemented or handles queues and polling.  I'm just glad that over the years it seems to be pretty robust, and works well on the various platforms supported.

In a setup like this I might not even have a timeout or rather have a -1 timeout.  This allows the dequeue function to just sit idle waiting for a request to take an action.  That action might be to quit or something else.  Another common thing you might see in examples is to use the error out of the dequeue and have it stop the loop.  If the queue reference is destroyed while waiting, it will return an error and that can be a way to tell the loop to shutdown.  A better method is to use a quit message of some kind but it is seen in several NI examples.

1 hour ago, X___ said:

So NI knows that their password protection is a joke, but they are still using it. No comment.

The design choices of LabVIEW make it impossible to encrypt the entire file.  The block diagram has to be readable at some point which means access to it will be possible in a variety of ways.  I'm sure there's some kind of compromise between restricting VIs to a specific target and build of LabVIEW, and the current implementation.  I just wanted to highlight the fact that the solution to protect the block diagram isn't a simple one.

Yes there is no real native solution for this.  NXG did tease a dynamic control creation but I'm not sure it made it far into development.  Depending on your needs I would suggest different solutions.  I have accomplished similar functions with picture controls in the past for creating a dynamic ribbon interface.  Here a running VI can generate an image that looks like a set of group buttons, and tabs and allows for setting of various background colors.  Another less polished solution revolves around parent and child relationships of windows, and dynamically running VIs.  I called this the Multi Panel Interface and honestly it didn't make it pas the proof of concept phase.  But for simple stuff, and a finite set of controls, you're probably better off just having the controls, then showing or hiding them as needed.

1 hour ago, Bryan said:

I'd like to think (realistic or not) that if NI ever decided to completely get rid of LabVIEW, that they would show appreciation to all of we who have made it successful in the past by making it open source.  

I hope for that future too, however I get the feeling that with 35+ years of LabVIEW development, that parts of the system are in a state that open sourcing the project might take a larger effort then NI would want to put into it.  Then there is the liability issue if some kind of exploit was found because the source was released.  I'm lucky enough to work in an environment where my boss asks for work to get done, and is less interested in the means of getting it done.  If I were making test systems for external customers I'd be more nervous, but internally I can just continue to use a legacy platform.  Cobol anyone?

26 minutes ago, ShaunR said:

If 2021 has multilingual support I will change to that but I won't hold my breath.

You don't need to hold your breath for the answer.  There is a public beta, it can be downloaded right now for free, only requiring an NI.com account.  It probably won't surprise you to know the answer to your question.

1 hour ago, JimPanse said:

or the pi... there are only non-commercial projects like linx.

LINX now is supported on commercial applications starting in 2020 BTW.

Your opinion is valid, and you have reasons for it, but I think it might be a bit of forest from the trees situation here.  LabVIEW tends to have a one or two major bullet points of new features with each release, with many smaller improvements that are less noteworthy.  Some of these aren't very applicable to me and I don't see the benefit of the update, but I can still recognize that a bunch of effort was put into a making it into the release, and makes me think NI isn't sitting idle.  I know I made a list like this in the past when a similar topic has come up but I'm having a hard time finding it.

• 2012 - Loop Tunnel improvements with concatenating, conditional, indexing, and last value / Project Templates
• 2013 - Improved Web Services / WebDav / SMTP / Bookmark Manager
• 2014 - Actor Framework (I might be off by a version or two) / 64 bit Mac and Linux support
• 2015 - Custom Right Click Framework
• 2016 - Channel Wires
• 2017 - VIMs / Forward Compatible Runtime 
• 2018 - Command Line Interface / Python integration / Type Specialized Structure for Improved VIMs
• 2019 - Sets and Maps
• 2020 - Interfaces for classes / Free Community Edition with Application Builder

And here are a few of my favorite features that I can't remember what version they were added.  Error Ring, Improved VI calling under Application Control for starting asynchronous processes and static VI references, DVRs, Conditional Disables based on environment or Project variables, Linux Real-time operating system, allowing for 3rd party and open source tools to be installed and called with the System Exec, and then adding an embedded HMI, User Events, LINX toolkit for running LabVIEW VIs natively on a Raspberry Pi, or controlling an Arduino connected to the host, QuickDrop's plugin system allowing for all kinds of tools, filtering on search results, improved performance of tree and listbox controls, NIPM, and loads or more scripting functions with more added with each version.

I sure hope LabVIEW has a future because I've hitched my career to it.  But even if NI closed its doors tomorrow I feel like I'd still be using it for another 10 years or so, or until it didn't run on any supported version of Windows.  But I feel your concern, and if I were a junior engineer starting out, I would feel safer in another language.

Oh boy 2006, I think that predates the LAVA 1.0 migration issues, and then several other newer revamps.  I certainly don't have this, and have no way of getting something so old.  I can contact Michael if you'd like.