Running Venus Client as an always on background service?

@EricSindelar_Hamilton @AlvaroCuevas_Hamilton

Tagging both of you to see if either of you can point me in the right direction.

I’ve been working on a WinUI Desktop Application to serve as a monitoring dashboard for any number of hamiltons, instruments, etc. but am now wanting to expand it’s capabilities to serve as the primary interface a single system to be operated by multiple different operators for long runs.

My question is specifically around, which of the Hamilton Services (if any) can be updated to run under the SYSTEM account so that the processes continue to run even when a user is not logged in?

My plan is to handle the attribution and interaction with the system through the desktop application and an integration with our IAM provider since.

The goal here is that User A is able to start a run. Log off the PC (or out of the desktop app) then User B is able to login and handle any errors. Traceability will be handled through the desktop app.

I’d like to avoid logging into the desktop as a designated shared service account and instead just have the process running.

Ideally, users would be able to just login into the workstation, but the connection to the device is established through a system service and doesn’t matter who logs into the desktop or sign’s out, but I don’t really see that as a possibility unless I use the V3 API.

Hi Brandon,
unfortunately this is currently not possible, and requires several changes in the current architecture. It´s in our roadmap to be implemented in a future release (TBD).

Alvaro

1 Like

If it helps, I used Transparent Screen Lock PRO in the past to achieve that.

The funny thing is we looked into transparent screen lock PRO, but our infrastructure team couldn’t implement it for reasons not visible to me.

I’m basically working on my own implementation with a shared windows account that is the controlling operator for the device and users interface with the desktop application that sends commands.

Unfortunately traceability basically falls onto the separate interface created log file to be used with the .trc, but that’s mainly because I can’t update our HSL methods easily to monitor a message Queue to just input the user details into the trace file itself.

When you used TSL did you have function protection enabled or did you have other means of controlled method usage?