LabVIEW Live Recap: Effectively Leveraging SystemLink APIs and Tools

LabVIEW Live Recap: Effectively Leveraging SystemLink APIs and Tools

Our June 17 LabVIEW Live was another great success. The event started with a sneak peek by Mark Black, Principal Product Owner at NI, of some new features coming in SystemLink and was followed with a presentation by Omar Mussa, Avionics Lead Test Engineer at Virgin Orbit, and James Duvall, Senior Project Engineer at G Systems, on real-world examples of leveraging SystemLink APIs and tools.

If you were unable to join us for the June 17 LabVIEW Live, you can watch it on our YouTube channel and you can register for our August 19 LabVIEW Live.

There was a lot of great discussion in the chat. We followed up with Mark Black after the event who had some additional insight to provide on questions participants asked.

Interview with Mark Black, Principal Product Owner at NI


1) When will the new features, Workspaces and Roles, in SystemLink be released?

MB: We expect the 2020R2 with workspace support to be made available this summer. This capability will be sold through a new license – SystemLink Server Advanced. 


2) How does SystemLink work through company firewalls?

MB: SystemLink uses standard HTTP(S) ports as well as Salt and RabbitMQ in its normal operation. See this documentation for details. It is not uncommon to expect a user to VPN into a corporate network to access this application. If you choose to expose SystemLink to the wider internet, you can still achieve a high degree of security and user management with technologies such as HTTPS and LDAP. While bringing Workspace support to market we invested a lot in deepening and hardening our security capabilities. Workspaces are not just skin deep. They are backed by security best practices. 


3) What does scalability look like? Is the user able to run 20+ million tests per year? How is data retention handled for say 10-20 years?

MB: This is a huge focus area of ours. We do have challenges now, but a project is underway to ensure we can meet and exceed these numbers. We hope we can bring these improvements to the market before the end of the year. 


4) Is your DB repo cloud-based or localhost? Impacts on alarm responses?

MB: You can connect to remote databases including on-premises, cloud-hosted, and DBaaS such as MongoDB Atlas. I would expect this to have a marginal effect on latency on service to DB communication and have little to no effect on alarms specifically. Using separate pieces of hardware for the app server (SystemLink) and the database (MongoDB in this instance) is a best practice and nearly all web applications we interact with on a day-to-day basis implement this pattern (known as a three-tiered architecture). For simplicity of install and setup, SystemLink defaults to both the web services and databases to be on the same box. 


5) Can you host multiple DB repos within the API? 

MB: Most databases (including MongoDB that we use) have mechanisms for replica sets, data backup and restore. We intend on using these established mechanisms rather than build our own. This lowers our cost of development as well as allows IT system administrators to use tools and patterns they are already familiar with. We intend on improving our documentation and tooling around these activities this year.


6) How does TestStand interconnectivity work?

MB: We have a REST API and database schema for test results and steps. Our TestStand plugin calls these REST APIs during its normal operation. If TestStand becomes disconnected from the SystemLink server these results are automatically stored and forwarded when connection is reestablished. 


7) When using system alarms,​ can SMS users ‘stop’ notifications if the system alarms get out of control?

MB: You can disable alarm rules, but I would recommend instead finding the root cause for the alarms and resolving those. This leads to more robust systems and the better user behavior of respecting and triaging alarms. 


8) For stats found on the ‘main’ summary dashboard (total tests, pass, fail, etc. in the past 30 days), how is that data gathered? Does it scrub the DB each time for those types of stats?

MB: Dashboard tiles can be bound to JupyterNotebooks which execute Python. We make great use of this functionality for our built-in shipping dashboards in Test Monitor, Systems Manager, and Asset Manager. More information can be found here. This capability allows us to use our REST APIs to return data from our databases and then compute higher-level metrics. The results of these notebooks analysis is cached to improve the responsiveness and performance.


9) Will free-form dashboards disappear or be improved in the future? 

MB: Free-form dashboards are not receiving any new investment beyond fixes needed to ensure compatibility with SystemLink infrastructure. We believe that WebVIs better fill the niche free-form dashboard occupy. This has allowed us to go in a different direction with our tile-based dashboards and occupy a niche not well served by other NI web visualization tools and technologies. 


10) Hosting WebVIs requires a lot of steps to build and deploy, will this be improved in the future?

We intend on bringing the SystemLink Cloud workflow for drag/drop WebVI hosting to SystemLink server. While this didn’t make it into the product for our R2 release we hope to release it in the future. Register for the August 19 LabVIEW Live where Darin Gillis, Agile Product Owner at NI, will be talking about WebVIs. 


11) What is the difference between using SystemLink (local) and a web service?

MB: SystemLink is essentially a collection of web services, databases, front end web applications, and clients (such as LV APIs or TestStand). Clients publish data to web services which turn around and store data in a database. Front end web applications call the same web services to retrieve data. This is the case whether you are on a web browser on the machine hosting SystemLink or a remote machine. 

Latest Posts


Automated Test System for SunPower

G Systems, known for their expertise in test system development, was granted the task to help SunPower develop a solar power automated test system to test new printed circuit boards (PCBs). Through this project, G Systems aided in the increase of production line accuracy, reliability, and efficiency, all while decreasing costs to SunPower.