09-01-2022 08:57 AM - edited 09-01-2022 08:57 AM
Hi Dan,
Many engineering teams use LabVIEW and TestStand to build production testers for the manufacturing floor, or LabVIEW (or FlexLogger for non-code datalogging) and DIAdem to conduct large validation tests with automated data analysis and reporting. Test Workflow also includes access to SystemLink Cloud to store data and G Web to build a front panel for the web browser of your device of choice - this complements many different types of applications.
If you need two pieces of software in the bundle, you're likely to find Test Workflow is a better price as compared to purchasing the individual products.
09-01-2022 03:58 PM
@pauldavey wrote:
Can I clarify that "Support for MacOS on Apple M1 devices" should actually be "Support for MacOS on Apple Silicon devices"?
That definitely seems to be the same and of course excludes iPad, iOS and iWatch as they do not run MacOS. Even Apple seems to use Apple M1/M2 and Apple Silicon interchangeably.
09-02-2022 07:42 AM
@Matthew-B wrote:
If you need two pieces of software in the bundle, you're likely to find Test Workflow is a better price as compared to purchasing the individual products.
Thanks, that makes sense. I can see customers using 2 or 3 pieces of the big bundle. I assumed NI was claiming there are customers that use 75%+ of the bundle, which I couldn't understand.
09-22-2022 06:59 AM
@Jay14159265 wrote:
...the thing that I am not happy about is making LabVIEW [Software as a Service]...
I agree whole-heartedly with Jay. Cash ebbs and flows for a company/organization, and it kills me that my development environment will someday (and for no good reason) stop me from doing my job if the cash flow dries up but the project still needs to be supported. (Yes, I know about Debug Deployment Licenses, but I'm not excited about the watermark or having to buy yet another license either.)
The license expiration date is a ticking timebomb looming over my work causing unnecessary stress. Why should we continue to bankroll future LabVIEW development for NI when we only want one version to move forward with for the foreseeable (read: budgeted) future?
Sadly, I also think it may be the beginning of the end of my many years using exclusively LabVIEW to do my job...
09-22-2022 08:16 AM
There are no watermarks on the Debug and Deployment licenses.
These licenses have always been designed for supporting deployed systems. That is why they were created in the first place. If you were deploying them using DEVELOPMENT licenses that was never the correct thing to do. Additionally we designed these licenses to be less expensive than the development licenses since they are used to maintain existing systems.
09-23-2022 02:11 AM
@EricR: can Debug and Deployment license be used to fix codes developed by past version of Development license and rebuild the app EXE, after fixes?
09-23-2022 02:41 AM - edited 09-23-2022 02:47 AM
@cy... wrote:
@EricR: can Debug and Deployment license be used to fix codes developed by past version of Development license and rebuild the app EXE, after fixes?
My personal opinion on this, and please remember I'm neither a lawyer nor NI employee, would be that it is not really dependent on the exact version but much more on the type of work you do. If it is about bug fixing, debugging (the debug part of that license) or running the existing code in the development environment for whatever reasons (the deployment part) then the mere fact that you use a different version of the debug and deployment installation than what the code was originally developed in would be acceptable.
If you however are going to more or less fully rearchitect it, and quite often that is also when/because you change the version, then the debug and deployment license would be not the right thing if you want to stay legal.
But please note that this may fall flat on its face even if the debug and deployment license is legally valid to use for your case. The debug and deployment installation is a full/professional development system but it does not include other toolkits, and you can't install most older toolkits into newer LabVIEW installations. The interdependencies are quite often too complicated that this could work, unless it is a VI only toolkit without any other binary dependencies. So you may have to update those Toolkit licenses anyhow and there isn't always a debug and deployment license for them and their license may or may not be subscription based.
09-23-2022 08:30 AM
Cy,
The debug and deployment licenses are normally for a specific version of the products you are using. This is by design since you built the application in a specific version of the tool and in many (most) circumstances, you want to minimize the changes that can occur during maintenance of a deployed application. As an example, if you built your application using LabVIEW 2020 and deployed it, the version of LabVIEW for the Deploy/Debug would be LabVIEW 2020. This ensures you keep all of the existing functionality/dependencies the same. In this scenario, the answer to your question is "yes". You should use the debug/deployment license to fix bugs, resave VIs, rebuild executables, and all other tasks necessary to keep your application working.
There was another post in here about what that debug-deployment license enables that I want to talk to. In general, the debug/deployment license allows you to use many additional labview packages that you originally had a license for when you created your application. It may not include everything. The intention is that it should allow you to debug and deploy the application with any fixes you need. If you have a specific scenario where the debug license doesn't cover the specific module/toolkit you were using at development time, please contact me. Over time, I've worked on this license to make it as permissive as possible so that the debug scenarios are easy to resolve.
If you have somehow ended up in a scenario where the version of your debug/deployment license does not match the version of LabVIEW you originally used to create the application, please contact NI to resolve it. You shouldn't use a newer version of debug/deployment to modify an older version of VIs. Doing this invalidates any testing you originally did on your application.
Having said that, the debug licenses were always sold with a service contract assigned to them. That way you could upgrade the version of your debug license as you upgraded your development license and keep them both in sync. If you want to upgrade the version of your deployed application, the correct actions are to upgrade your development environment, rebuild and retest your application using the new version, and then upgrade your deployment license to match the new deployed version. This is a common scenario if you want to take advantage of bug fixes, security updates, memory optimizations, and newer features available in newer versions of the products. In my experience, this isn't a common scenario for deployed applications except when the project is going through a refresh cycle and part of that scope of work is to bring all components up to "current" versions, normally for bug fixes, security patches, and feature enhancements to the project itself. Under other circumstances, the desired "debugging" behavior is to minimize changes to the project, as much as possible. If your scenario differs from this, please contact me so I can capture the workflow you have and work with you on a solution that works better for your specific scenario.
09-23-2022 09:45 AM
Eric:
I just want to take the time out to thank you for agreeing to be the messenger for NI on these delicate matters. Although we try not to shoot you, sometimes you get caught in the crossfire and become collateral damage.
So thanks!
09-23-2022 11:18 AM
@EricR thank you for the explanation, much appreciated. seemed like there is no longer a reason to purchase the source codes anymore, since user cannot debug past codes without other past modules subscribed. are partners obligated to fix/patch deployed user applications should NI issues a bug/fix/update?