Experimental Physics and
Industrial Control System

Michael Davidsaver <[email protected]> · Tue, 12 Aug 2014 22:00:32 -0400

On 08/12/2014 07:00 PM, Andrew Johnson wrote:
> Hi Tom,
> 
> Since nobody else has bitten yet...
> 
> Have you considered using http: to deliver your screens to the users?
> That appears to be the way that some sites are going,

Beware.  NSLS2 started out this way, but eventually switched away due to
performance problems (lack of caching mixed with the linking container
widget).

Happily, while it isn't obvious, simply referencing files by absolute
system path works.  We have a read-only copy of all .opi files
accessible on each system.

So read-only access doesn't need workspace setup (which no one seems
able to automate).  People editing .opi files make a VCS checkout, which
is added to the workspace.

> as it solves the
> shared workspace problem and might simplify the soft-link management.
> You might even be able to do some of your version selection on the
> server-side instead of using soft-links if you wanted to.

We have a wrapper script which uses symlinks to select a version of the
executable, and a customized preference file (which includes the path to
the main .opi).

The goal of this is to ensure that users interacting only with pre-made
screens (the 90% case) don't need any setup.  They just run the script.

We still haven't completely dealt with the shared workspace problem.  To
mitigate this, our wrapper script keeps track of which computer a
workspace is used from.  Attempts to start from a different machine give
a prompt and the option to terminate the running session (via ssh).

Michael

> That said I have no experience with doing this at all, so you'll have to
> find out how to go about that from the real CS-Studio guys.
> 
> - Andrew
> 
> On 08/11/2014 09:30 AM, [email protected] wrote:
>> Hi all,
>>
>> We're looking at how we should launch CS-Studio BOY screens on beamlines and machine, and have the following requirements:
>> 1) If an IOC has a database template instance from a motor version 6-5, the screens for that IOC should come from motor 6-5.
>> 2) One insertion device may have all its IOCs pointing at motor 6-5, but another may be at 6-4 or 6-2.
>> 3) A user may want to launch sets of screens for many insertion devices at the same time.
>>
>> The same is true for beamlines, front ends, and other technical areas: a user may start at a high level screen, and drill down to a different version of the motor screen depending which IOC that component is on.
>>
>> For EDM we simply launched a new EDM for each insertion device with its own search path, but doing the same with CS-Studio would be quite resource hungry. We have had more than 20 instances of EDM running at once, and I wouldn't like to do the same with java virtual machines.
>>
>> We have come up with a proposal that would work for us:
>> * Create a project for each insertion device (and beamline etc.) with soft links to the versions of each support module it uses
>> * Run a command that tells the current running CS-Studio to import that project to the user's workspace and run a screen within it
>> * We could then have one CS-Studio instance, and let each user have their own workspace, but manage the locations of the projects within it ourselves
>>
>> The eclipse navigator file structure would look like this:
>>
>> workspace/ # located in user's home directory
>>   CSS/
>>   ID1/     # Eclipse project pointing to /dls_sw/.../ID1/2-0
>>     motor/ # Soft link in /dls_sw/.../ID1/2-0 pointint to /dls_sw/.../motor/6-5
>>   ID2/     # Eclipse project pointing to /dls_sw/.../ID2/3-0
>>     motor/ # Soft link in /dls_sw/.../ID1/3-0 pointint to /dls_sw/.../motor/6-2
>>
>> Has anyone else done anything similar? How do other sites launch CS-Studio BOY screens?
>>
>> Thanks,
>> Tom Cobb
> 

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System