Global System For Automated Applications Using Plug In

Global System for Automated Applications using Plug-Ins

Jarobit Pina Saez

Global System for Automated Applications using Plug-Ins | Jarobit Pina Saez | 20/11/20132 | 37

Jarobit Pina Saez

User: JPina

Forum and Community

User: JPina

Write to me to:

[email protected]


WHO ARE DRAEGER?

2010 – Category winner for Process Innovation

2011 – Category winner for Logistics and Operational efficiency

2012 – Overall Winner 2012 – Category winner for Financial

management2012 – Logistics and Operational

Efficiency

2. Demonstration.

3. Database and system data.

4. Global System.

5. Test Application Template.

6. Thanks and Resources.

7. Questions.

1.1 Starting Point.1.2 Detected Issues.1.3 Goal.1.4 Desired Solution.


INDEX

1. Introduction.


1. Introduction: 1.1 Starting Point.

Where is the source code?

Who

designed

this test?

How long will take to update the system?

How do I

run this

test again?

Can I modify this Param?

Can I change

this HW?

What is the SW Rev.?


1. Introduction: 1.2 Detected Issues.

• Different Data Storage Systems:

• Non existent data retrieval tool.• Custom Stored Procedures.• Lots of paper based data and chart plotting.

• Not fully automated solutions and different test environments.

• Steep learning curves for the operators.

• No tracking system in the production line (No poka-yoke).


1. Introduction: 1.3 Goal.

• One database and management tool:

• One Test Environment:

• Unified data retrieval & analysis tool.

• Ability to track units in the production lines (Poka-Yoke).


1. Introduction: 1.4 Proposed Solution.

Server based code

One storage system

User Friendly

OneAPI

Universal Tracking

InitialisationOK?

InitialisationNot OK?


1. Introduction: 1.4 Goal.

Test ExecutionFinished?

Could we treat our test/automation applications as “Plug –Ins”?

• Software component that adds a specific feature to an existing software application. When an application supports plug-ins, it enables customization.

Framework:


INDEX

1. Introduction.

2. Demonstration

3.Database and system data.

4.Framework.

5.Test Application Template.

6.Thanks and Resources.

7.Questions.


2. Demonstration:


INDEX

1. Introduction.

2. Demonstration.


4.Global System.



7.Questions.

3.1 Database.3.2 Test Application Data.


• Characteristics:

• A.C.I.D.

• Atomicity.

• Consistency.

• Isolation.

• Durability.

• Data normalisation.

• Maintainable against future requirements

3. Database and system data:3.1 Database

Test Report

Operator

Rights

Operator/Rights Test Bench

TB Family Hardware

TB Status

Fixture

Fixture/Product

ProductOperations

Device

+ Sr. Number

Test Results

The system is based on a well designed and structured database

Operator data

Hardware data

Product Data and Tracking

Test Cases Data


3. Test Application Data:3.2 Test Application Data.

Test parameters:• Test application constants, settings details, instruments O.P…

Test Limits:• Test cases maximum and minimum possible value.

Hardware data:• Devices’ address, serial numbers, etc.

Device under test data:• Part number, serial number, name, etc.

LVOOP


INDEX

1. Introduction.

2. Demonstration.


4. Global System.



7.Questions.

4.1 System Overview.4.2 System Problematic.4.3 How to call unknown applications.4.4 Messaging between contexts.

Buttons (Events)

Custom Menu (Events)

SYSTEMQDMH

Dynamic Window: (Subpanel)

QDSMParallel process

Additional Info

Tracking Window:• Messages from the system• Messages from the dynamically

loaded application.

• User interaction.• Results display.

• DUT details.• Elapsed Test Time• Statistics.• YIELD.

EDSM Parallel process

QDSMParallel process

• Test Applications (Plug-Ins). UNKNOWN


4. Global System: 4.1. System Overview.

ERROR!!!!ERROR!!!!Where are

the missing dependences?

Dynamically calledVI in PPL

OK!!!OK!!!Dependences included

With the PPL (Compiled code)

• It is not possible to call unknown source code• The Packed Project Libraries provide with the solution


4. Global System: 4.2 System Challenge.

Dynamically calledUnknown source code

System Executable

!! !!


Framework

Generic ApplicationLVLIBP

Test ApplicationLVLIBP

Generic Application

Attributes

Methods (Dynamic)•Init Instruments•Run•Close Instr.

Context 2

Context 1

Generic Application

Attributes


Test Application

Context 3

Attributes

Instance Child of

Factory pattern

Context 3Context 2


Entry point to customised functions

Test Application

• Plug-in Architecture using Packed Project Libraries by Michel Lacasse

Problem!!• How do I build my executable without calling all the test applications

Solution!!

4. Global System: 4.3 How to call unknown applications.


4. Global System: 4.4 Messaging Between Contexts.

• Can I use common messaging tools?• Queues are context dependant.

• Needed to drive sequences in the applications• Classes are context dependant.

• They contain the test data.• Events are “not” context dependant.

• Needed to send messages from the application to the system

!• So how can I communicate with my test application

• LVLIBPs create their own contextFramework



Context 1 Context 3

You wish!!Message

Test Application

Class

Generic Application

Class

Generic Application

Class

Inst

ance

Child of


INDEX

1. Introduction.

2. Demonstration.


4. Global System.



6.Questions.

5.1 Reasons and Objective.5.2 Concept.

• Avoid time loss programming the “Framework-Test Application” API for each test application.


5. Test Application Template: 5.1 Reasons and Objective.

Reasons:• Provide the other developers with a complete level of abstraction

from the framework

• Allow other programmers with lower LabVIEW knowledge to deploy their test applications

• Provide the other developers with a “Stand Alone” environment.


5. Test Application Template: 5.1 Reasons and Objective.

Run Application

TEMPLATE

InitInstruments

CloseInstruments

Framework

Process queue

Process Events

Objective: ProvidedTo do by developers


5. Test Application Template: 5.2 Concept.

InitialiseInstruments

Idle

CloseInstruments

Test Application

CheckAbort

Keeps the instrumentsReferences alive

Takes the resourcesto drive the instruments

TEMPLATE

Frees the resourcesto drive the instruments

Abort buttonPressed?


INDEX

1. Introduction.

2. Demonstration.


4. Global System.



7.Questions.


7. Thanks.

Francisco Sáez who introduced me to the engineering.

Fabiola de la Cueva for her unconditional support.

Michael Lacasse for coming out with the Plug In architecture and his help.

Grant Heimbach who helped me to understand how the application builder works.

For their support and confidence in me.


7. Further Information.

• Resources:• Advanced Architectures Courses.

• QDMH.

• APIs for Messaging

• Michael Lacasse’s “Plug-in Architecture using Packed Project Libraries.”

• Plug-In Architecture using Packed Project Libraries.• Grant Heimbach’s “Under the hood of the application

builder.”• Under the hood of the application builder.

• LAVAg.org

• National Instruments Forum.

https://decibel.ni.com/content/docs/DOC-19176

https://decibel.ni.com/content/docs/DOC-29877


INDEX

1. Introduction.

2. Demonstration.


4. Global System.



7. Questions.


8. Questions.

QUESTIONS

Do you want to know more??

•Come to the CSLUG Meeting

•4th of December in Newbury

Thank you for your attention


THANK YOU


Possible Questions: Dynamic Window Thread.

It is basically a repetitive sequence:

STATE MACHINEInitialiseSM

Request Test

BenchData

Request Operator

Data

Request DUTData

InitialiseTest

Report

DownloadApplication

InitialiseInstruments

RunApplication

Show Results

UploadApplication

Data

CloseInstruments

Exit

Test Bench Data Operator IDOperator Rights and Name DUT ID & Sr NumberProduct Info

Product Info

Generic ApplicationClass

Server

Test ApplicationClass

Parameters& Limits

Test BenchData

Generic ApplicationClass


Possible QuestionsMessaging Between Contexts.

Framework



Generic Application

Attributes•QUEUE Ref•Event Ref

Methods (Static)•Init QUEUE•Enqueue•Dequeue•Close QUEUE

•Generate Event

Context 2

Context 1

Generic Application

Attributes

Methods (Static)•Init QUEUE•Enqueue•Dequeue•Close QUEUE

•Generate Event

Test Application

Context 3

Attributes

Methods (Static)•QDSM

Instance Child of

Factory pattern

Context 3Context 2

• Create User Event• Register User Event

• Attend to User Event• Close User Event

Methods (Static)• Init QUEUE• Enqueue• Dequeue• Close QUEUE

Door to our application

Test Application

• Event Ref• QUEUE Ref

• Generate Event


Possible Questions: Messaging Between Contexts.

• Classes:

• Classes are context dependant.• Same class is different in 2 different applications.

• Parameters, limits, product information, test bench information.

• Data collected in the framework.

• Data is application dependant.• Data is used and modified by the test applications.

Framework



Generic Application

Attributes

Methods

Context 2Context 1

Generic Application

Attributes

Methods Methods

Test Application

Context 3

Attributes

Instance Instance

Different ClassesClass To Cluster(Method)

Variant To ClusterCluster To Variant

Cluster To Class(Method)

Inclu

des

• Plug-in Architecture using Packed Project Libraries by Michel Lacasse


4. Global System: 4.3 How to call unknown applications.

Problem!!• How do I build my executable without calling all the test applications ?

Solution!!

Test Application

Class

Generic Application

Class

Framework

Generic AppLVLIBP

Test AppLVLIBP

Generic Application

Class

Generic AppLVLIBP

Generic AppLVLIBP

Test Application

Class

Inst

ance

s

Includes

Factory Pattern

Parent/Child

Global System For Automated Applications Using Plug In

Technology

Transcript of Global System For Automated Applications Using Plug In