DnD vs Labview.

How Dnd can substitute Labview in LHC control system, what needs to be done.

Timofei B. Bolshakov,James F. Patrick

DnD vs Labview.

DnD and Labview has similair structure and appearance:

Interactive Builder

Runtime (integrated with Builder for Labview)

Component Libraries

Web Interface (Dnd)

Strength Dnd - Integration

into control system:

security,

safety,

logging,

control over source,

retrofitting old lib's

Web interface

Labview – support of National Instruments:

code quality,

support + documentation,

hardware drivers,

publicity,

experienced users,

rich components library

Weakness Dnd – small group

of developers:

documentation,

training,

code quality

component library should be extended

uncertainty

Labview – is too general, market is different:

model – not aimed for integration

price (and you still need specialists !)

slower development cycle

experienced users :-)

National Instruments

Why some of Labview strongest points are not important.

Experienced users may bring much harm – fast prototyping of not integrated projects brings tremendous risk

Device drivers does not matter, because all of the devices should be controlled by FESA

Commercial companies have their own life and view on the future of products, LHC should work and be upgradable for decades

What do we need to bring DnD closer to being accepted at LHC Better understand CERN requirements and

applications where DnD should be used.

Component libraries – more computational pipes, including JMathLib, Beanshell

Refactoring source code, writing additional documentation, tutorials, tests

Main – we need at least one enthusiast on CERN side

CERN Requirements.

Several CERN concerns were not addressed in Requirements document:

- Ability to release the DnD project as self-contained web startable application

- Save project in standard CVS, versioning

- Layered representation

- Remote debugging / monitoring of layers

Component libraries. At first glance this is a big problem, in reality

it is NOT.

Most used components does not include complicated transforms.

Complicated transforms are EASY to include: JMathLib (analog of MatCad), Beanshell (interpreted Java), other scripting languages.

Scripts should not dominate the scene !!!

We should use Open Tools!!!

Component libraries. What should be really included:

- Bitmap picture as background

- Limited amount of scripts (should be discussed and specified)

- Layering with JMS interface to layers (should be used the CERN one – JAPC monitoring)

- new Plotting components : JdataViewer (may be modified), 3D from JmathLib, ...

Component libraries.

What people really demand (our experience):

- Highly tuned “special engineering symbols” : look at cryo library

- Extended support of all aspects of control system.

- Better / Standard plotting package

CERN support.DnD should not substitute Labview in general, it should substitute Labview in

concrete CERN/LHC environment.

Only insiders can tell what components CERN need. And as detailed as

possible.

Software should be used ASAP. And users should apply pressure on

developers.

ConclusionsUnregulated and uncontrolled Labview projects will be a disaster (FNAL operators

experience).

Labview projects are HARD to document (FNAL instrumentation group experience).

Component Libraries are not the Show Stopper.

DnD will not be useful without the really strong support from CERN side.