Programmatic Locking and Unlocking of SystemLink Clients

[GreyGrey]

With SystemLink 17.5, we introduced the ability to lock and unlock targets. Locking a target will prevent any job from being done on the target while it is locked. If a job is sent to the target, the job is queued up, and then initiated when the target is unlocked. 

You can lock/unlock targets from the SystemLink Systems Manager grid by selecting a target, clicking the 'More' drop down menu, and selecting 'Lock' or 'Unlock'. Additionally, you can lock targets programmatically from LabVIEW. You can use this programmatic lock in LabVIEW applications to prevent any task from being interrupted. I have attached the minion_lock.vi and the minion_unlock.vi which can be run from both Windows and Linux RT SystemLink clients to programmatically lock themselves.

*Note: The lock can take up to 15 seconds to take effect. 

[RaulPerez]

Hello, I would like to try to use the locking/unlocking functionality but the examples VIs are in a LabVIEW version that is higher than mine and I cannot open the files.

Could you create the same examples for LabVIEW 2015 SP1?

Alternatively, some screenshots would probably help a lot.

[GreyGrey]

I've attached 2015 versions of the VIs. Let me know if you have any issues opening them. 

[RaulPerez]

Thank you for sending it on the 2015 version.

I have a few questions about how it works:

• On the conditional disable structure I see there is one condition for each OS. Is that OS the one where the server is on or is it where the code is being executed?
  I will be running this code on cRIO9030 so I think the OS selected should be Linux but I just need to confirm.
• I see it creates the_blackout.lock will this lock prevent the development computer (where Labview is installed) to deploy new software? or does it only stop the Systemlink server from performing any tasks on the cRIO?

[GreyGrey]

---

@RaulPerez

• On the conditional disable structure I see there is one condition for each OS. Is that OS the one where the server is on or is it where the code is being executed?

---

The purpose of these VIs are to allow targets to lock themselves. The conditional disable in the VI has been included to allow Linux RT targets like cRIOs to run the case that corresponds to its operating system.

---

@RaulPerez wrote:

• I see it creates the_blackout.lock will this lock prevent the development computer (where Labview is installed) to deploy new software? or does it only stop the Systemlink server from performing any tasks on the cRIO?

---

This lock will prevent the SystemLink minion from accepting new jobs. The server can queue up a number of jobs while the target is locked, and when unlocked, it will start working through the queue. Locking a SystemLink minion will not prevent the SystemLink master (server) from queuing up new jobs for the locked minion, or for any of the other minions registered with that master. 
 

[D.S]

How it can be done through HTTP or Python APIs?

[JoshuaP]

If you are wanting to lock a target from an application running on the target, it is just a matter of creating a file call minion_blackout.lock under C:\ProgramData\National Instruments\salt\var\cache\salt\minion.  The presence of the file will lock the system and the removal of the file will unlock it.

If you want to lock/unlock it remotely you can do something like the following depending on whether you are using 19.0 or 19.5+:

19.0

POST http://<server>/nisysmgmt/v1/systems/managed/jobs

19.5

POST http://<server>/nisysmgmt/v1/jobs

{ 
   "fun":[ 
      "nisysmgmt.set_blackout"
   ],
   "metadata":{ 
      "queued":true,
      "refresh_minion_cache":{ 
         "grains":true
      }
   },
   "tgt":[ 
      "<minion ID>"
   ]
}

[ryan_sheppard]

Does this way of locking the clients still work with 19.6? I have an application that creates the file in the "C:\ProgramData\National Instruments\salt\var\cache\salt\minion", but the system did not lock, with the system sitting for 10 minutes. I was able to push an update, instead of properly queuing. 

[ryan_sheppard]

Couldn't edit post, going the HTTP route. APIs didn't include much information on the blackout function. Struggled to find how to unlock after locking the system. For others future ref, use unset_blackout. Found by looking at the details of an Unlock Job in the history tab on the web app.

[JoshuaP]

---

@ryan_sheppard wrote:

Does this way of locking the clients still work with 19.6? I have an application that creates the file in the "C:\ProgramData\National Instruments\salt\var\cache\salt\minion", but the system did not lock, with the system sitting for 10 minutes. I was able to push an update, instead of properly queuing. 

---

In 19.6 we changed the location of the lock file to enable test applications to change the lock without having to disable Windows UAC or run the application as an administrator.

The new location for the minion_blackout.lock file is C:\ProgramData\National Instruments\salt\conf\lock.  The presence of the file will immediately trigger a lock and the absence of the file will unlock it.

You can also manually lock and unlock a system from the new SystemLink tray application.