SystemLink Idea Exchange

The SystemLink results plug-in filtering is not at all what I expected and does lack some desired features.  In TestStand it would be nice to updated results filtering to be similar to the current test stand report results filtering much like the picture below.  Where the filter would allow the capability to weed out done steps that are not useful in some cases and would avoid transmitting every step to system link.  This filtering would also avoid in most cases the modification of the results plug-in call back that is deployed with the client. 

Idea

Host the full Python SDK package on PyPI to support pip install operation. There is  a PyPI package for Systemlink, but it currently only provides the Tags API. 

Motivation

There is a helpful set of tools that can leverage the Test Monitor API, Files API, etc. for interacting with Systemlink data, but as of now, the only way to access those files is by installing the Systemlink Client via NI Package Manager, and then referencing the python modules via absolute path.

It would be nice if we could pip install these packages into a virtual environment as we develop utilities that leverage them.

See also: https://forums.ni.com/t5/SystemLink/pip-install-systemlink-sdk/m-p/4200716

Currently on a dashboard you can pick any system using the system filter. If a dashboard is in a workspace it should only be able to select systems from within that same workspace using the system filter.

Would be nice to have the option to export the data to excel or CSV file while using the Trend plot.

Currently a great deal of functionality is available via the SystemLink API. This is a very valuable tool. However, it is quite difficult to utilize these features via LabVIEW and build out integrations within the NI ecosystem. Tight integration between hardware and software has been a staple of NI and it would greatly benefit us as LabVIEW developers if we could more readily access the full feature set available in SystemLink. Further, when putting together programmatic implementations it often leads to partial solutions that are fragile and limited in scope. 

Right now through SystemLink when you go to the server to approve a new system, you get a listing with the Minion IDs of all the systems waiting for approval.  The problem is that the minion ID is made up of the computer type, serial number and MAC address.  As a production line manager person, I don't know the hardware serial numbers of computers, or MAC addresses of systems.  Yes they are great unique identifiers, but it's kinda like having a conversation about people by only using their social security numbers (instead of calling them by Jane, John, Marry or Harry). 

What it comes down to is I've got a list of systems that I don't know what they are, and to be able to make a reasonable decision about the security of my process I need to do a large amount of research to decide whether it is an appropriate system.  I wish the list included the system HostName too.  With that I could decide quicker and easier if it was a valid system to approve.

Currently the only files available in the UI are at the root level. If you utilize the file ingestion rules to organize into folders they are no longer accessible via the web interface. Placing all files in a single directory is not scalable.

Allow to copy a package in one feed (say a dev feed) to another (say a release feed) so that you don't need to publish to two different feeds from a LV Project, but can still have devices only able to see one feed (release) and not the other feed (dev).

We noticed that when there is an ATML report included in Systemink, one needs to double-click the report log to check for the parameters additional results pulled from a TestStand as parameters with the log box checked. 

It seems like this information should be accessible without double click the test. It might be a good idea to use some additional blocks like the following:

Or to explicitly include the parameters and values. 

Currently the authentication options are all on-premise options. It would be nice to have Azure Active Directy as an authentication option to have cloud based authentication options available as well.

When you have several systems to manage it can take forever to scroll to the right system (partially because the scroll is laggy, and the sorting sometimes works, and collapsed groups don't stay collapsed). It would be helpful to be able to start typing a system name into a box at the top to filter the shown systems. This is present elsewhere, like on a custom dashboard when using the system filter at the top.

If you're importing packages into a SystemLink Repository from a remote feed, the current status / progress is entirely unhelpful... On computers with slow connections, importing something like LabVIEW or DIAdem can take up to 10 minutes... and then in some cases it's failing.... and all we get while we're waiting is the following spinning wheel.  It would be nice to get some additional feedback on the status of what's going on.. maybe a "downloading x of y" or a progress bar or really anything else.

I see that the LabVIEW Built in Package Builder has options for the Dependencies to require a certain version range.

It would be nice to have this same capability on the Client side with NI SystemLink.   What I mean by that is that say I have X # of testers that are in the same group under the Managed Systems, and I have a feed for that Group.   Currently all of the testers are running version 1.0.0.1 of the package.

If I deploy an update to the feed, version 1.0.0.2, and I say the minimum version for the feed is 1.0.0.2, all of the clients would have to update to the new version before running (or get notified there is a required update).

Currently the "Created By" is fixed asTagRuleEngine. It is helpful if one can modify the name to filter alarms. (Currently the property is read-only.)

Systemlink seems unaware of software changes deployed to a Managed System outside of the SystemLink Systems Manager.  If I install a software package using Systems Manager to an RT client, then install something else on the same client directly from LabView, Systems Manager will continue to show the original package as the Installed Software.  Ideally the SystemLink client on the RT target should recognize the difference and report to Systems Manager that an unknown package is installed.  Additionally, Systems Manager should have a Reinstall option on its installed software tab.  The current procedure is to uninstall the currently installed version, then install it from the Available software tab.

It'd be great if there were a way to have SystemLink Server or Enterprise applications help with file management by offering something like the following:

1. Check file age and if it is older than X days/weeks/months/years THEN

2. Move the data to another data store that the server can connect to

3. Update the result ID attachments info with the new location for the file(s)

Obviously, there may be other reasons to move the files, so additional properties could be added to trigger file moves. I think the big thing would be time for most people, especially those of us in the ADG space where records may need to be kept for many years. It doesn't make sense to keep expanding the server size to store these files, but a Cloud File share, data lake, or something similar may make sense to push to once the files have outlived most of the their utility other than recall. Providing some hooks for an automated job to be able to configured and run in the manner described above would eliminate the user's need to develop custom scripts to perform these actions unless the "out of the box" feature set didn't do what they wanted.

The big trick here is making sure the server/cluster knows where to find each file after it has been moved.

Appreciate your consideration in providing this feature at some point on the road map.

Currently, you can only read one message from session your queue at a time through the SystemLink message service (nimessage/v1/). It would be nice if it was possible to read multiple messages with a single HTTP call.

Currently if you close a project all the package build specs lose their feed credentials. Provide a way to retain these or authenticate via SSO or some other option.

Currently you can assign a Workspace to a State, but it does not restrict that state to a specific Workspace, e.g. a device in Workspace A can see all States as available to apply even if the States are in Workspaces B or C.