Random Ramblings on LabVIEW Design

swatts · ‎06-28-2013

Like code smells, sometimes you can get a feeling about an organisation, these clues we've called Process Smells. They are a clue to identifying risks when estimating for a project. As I've stated before we usually try and quote a fixed price for a job, this price tends to have a contingency based on the perceived risk attached to the organization, now what risks and opportunities can we attribute to organization types.

To please the Disney loving masses I've started by describing the

PERFECT CUSTOMER

So I wake up to breakfast in bed, provided by my wonderful family, skip to work through a flowery meadow and start to work for the perfect customer.

The Perfect Customer

Knows how to articulate the problem they are having (extra points for having specifications or requirements document).
Has unlimited budget.
And unlimited time.
And lets you do whatever you want
Oh and then is happy when you deliver the project

Oh then I wake up to the full horror of my day...................

I've tried to break down the attributes of organizations in a software design way, I'm sure there are different categories and as with all my articles most of it comes from my head rather than research. So please chip in with your own categories.

Technical Competence

It's sadly common now to go into a company and for there to be little or no technical skill left there. This essentially means that you're on your own kiddies.

No Technical Lead: can have the following affects on your project.

You'll have to learn the product, lead the requirements, test the application, explain and justify failures and rejects.
It can be hard to impress an audience that doesn't comprehend the difficulties involved.
If they appreciate you and you impress, they can be very good customers indeed.
Sign off can be chaotic, they may not want you to leave!

SMELL: Essentially this comes down to time, you will have to include a large contingency and assess whether you have the technical competency to complete the project.

DEODERANT: You can become indispensible, and that can be a good thing.

Weak Technical Lead: by this I mean someone who has the technical knowledge by little power in the organization.

When you come into a company full of competence and ideas it can be perceived as a threat, you may have inadvertently stepped on the toes of the person you need the most. This can be very costly especially if they are the main sign-off.

SMELL: Our job is hard enough without having to fight every step of the way, consider walking away from this situation as they will be a bucket full of insecurities, fear and frustration and it's a tough win.

Strong Technical Lead: by this I mean someone who has the technical knowledge and some clout. Make friends with this person and your project will go much easier.

SMELL: A hostile strong technical lead can be a challenge, but worth a bit of effort. Add contingency to spend some time to impress.

DEODERANT: If they come round to your way of thinking you have yourself a powerful ally.

Environment

Hostile: Some people just don't like LabVIEW and/or contractors, or old punk rockers who should know better. Funnily enough there is an opportunity here, my most skeptical, cynical, difficult customers have ended up some of my best and most loyal friends.

SMELL: Failure is not an option soldier!

DEODERANT: Win and you win big, the energy they put into their hostility will be directed at promoted you!

Friendly: Note to potential employers, be nice and we'll be cheaper.

DEODERANT: Woot we like friendly, and lucky for us most of our customers are just that!

Management Style

Democratic: Can make decision making slow, but usually a better working environment.

Dictatorship: If you are dealing with a very strong dictatorship you may find you'll end up working for a Weak Technical Lead and all that involves.

Decision Making mechanisms

Meeting Heavy: Some management book somewhere has taught companies that decisions are good, you shouldn't have a meeting without making lots of actions. These meetings should be booked regularly and involve anyone remotely interested in the project.

SMELL: Beware of long term projects done on a fixed price, this environment means the project will be constantly changing.

Technical Lead: This is the easiest way to deal with a project, an extra protection is to deal with a Project Manager and a Technical Lead. The Project Manager can then reign in some of the enthusiasms of the Technical Lead.

DEODERANT: Having this clear line of decision making makes projects run so much easier.

Sector

The different sectors have different characteristics. Here's my observations for what they are worth.

Medical: Likely to be a Meeting Heavy environment.

Aerospace: Having worked in Aerospace for most of my life I would suggest that Aerospace companies can be completely bogged down by paperwork, which in theory should be feared, in practice everyone finds ways of working around it. Find the company expert on getting round the system and you're in business.

Military: As above but a bit slower.

Academic/Research: Academia is used to getting it's code written for free by under-grads, generally quotes are met with shock. If you get the job, cost in for constant change, it's research dammit, they are bound to play around with requirements.

Company Size

Small company: <20 people

SMELL: Your costs may be a very large part of their budget, make sure they can pay before you start. Consider getting money up-front, small milestones etc etc

DEODERANT: Less bureaucracy, faster decisions all ease the development process.

Large company: Got their own accounts department the big show-offs.

SMELL: Factor in extra costs for bureaucracy, late payment, changes of management. Sometimes they won't understand the costs and risks that smaller companies/individuals undertake.

DEODERANT: They may have more work for you to do, they can pay you.

Who holds the power

Increasingly some departments in a company forget they are there to help and service the important business of doing business and find themselves dictating to everyone else. For example considerable time has been wasted by strange edicts from the IT department. Yes I'm looking at you IT department who wouldn't let cRIO into the company without McAfee Antivirus loaded on it! And you IT Department who furnished us with a 10 year old server to do a job because they had put a ban on buying new computers!!

Other Smells....

SMELL: Picking apart your quote and asking you to justify each item in great detail ..... an indicator of trouble to come.

SMELL: Interrupting a meeting to make my colleague re-park his car to the company standard!!!....I suspect testing on that project will be hard work.

In our experience the best relationships with customers is when it is a partnership and we all look after each other.

Lots of Love

Steve

Thanks to Justin Goeres for the title. Fabiola, CRelf and CRoebuck for their input. And all my customers I love you really

swatts · ‎06-10-2013

In the blog before last it was suggested that it would be beneficial to run through a typical job. Bit of a dry subject if you ask me!!!, to liven it up I've done some more cartoons

Here's a few statistics about us, not for ego reasons (although we're awesome), but just to give a feel for the kind of business we run.

We have about 50 customers on our books.

They are mostly in Aerospace, Automotive, Military, Manufacturing, Academia and Transport.

We like repeat business and most of our work is fixed-price, we do both hardware and software.

Splitting our work into small, medium and large flavours (2-4 man weeks, 5-16 man weeks, 17+ man weeks) it's about 20:40:40 at a guess.

90% of our jobs have no specification at the start, generally it's a discussion, referenced to existing systems. The level of paper-work we do rather depends on our understanding of the job or our relationship with the customer.

We usually provide a target specification and quote (essentially telling the customer what we will deliver and how much it will cost), fairly often we do an initial milestone where we do feasibility, design reviews and provide a final cost.

95% of our projects don't need anything dynamic or concurrent. Is that because we only get simple work or that we choose to work simply?

We tackle the risky parts of the project as early as possible.

So I thought rather than live in a world of Unicorns and Rainbows I would run through a project that went averagely, rather than badly or perfectly. Most importantly we made money and it transpires that the customer thought it might never work (which was nice of them!).

Brief Description of System

It's a filter test system consisting of 2 controllable fans, 2 servo valves, loads of transducers for logging, control and calibration, some relays. It will be used for experiments as well as stepped testing. The control algorithm is a contrived calculation of 1 or more of the transducers.

A couple of meetings and an exchange of paper-work and we we're up and running (although a little cost constrained). We would provide the instrumentation, the software, the tools to set up the system and documentation.

Our general approach is as follows (with variants depending on the risks)

Requirements Specification
Target Specification/Proposal/Quote
Prototype screen/Design Review
Engineering Screen – Allowing customer to test the hardware wiring, control system etc.
Alpha Test – Off-site approval
Beta Test – On-site (usually cycle through a few Beta versions in fairly rapid succession)
Final Release
Support.

We have a general application template in our armoury that is useful for 80%+ of our projects and this consists of the following functionality.

Wizard based front panel, consisting of initialise, event structure, state machine and Queued Message Screen update.

This has several built in components as described below, you can guess how they are built from my previous blogs.

Config

This component handles all configurable items, via an enumerated type called parameter. To add a new parameter just add an item to the enumerated type

No Command – Error	This the default condition and will get quite indignant if called.
Initialise Config to SQLite	This command sets the configuration instance to use the SQLite database. Other databases and file type ini methods are available.
Save Config	Saves and up-issues the configuration database
Get Key	Gets a key as selected by parameter
Set Key	Sets a key as selected by parameter
Update Key	Updates a key in the database without up-issuing
Get Latest Config Data	Caches configuration data
Get Config Data for Version	Gets configuration data for a specific version

The supporting cast for this component consists of database components as described in previous blogs, and an intermediate component that does the SQL.

Error

This component handles error reporting in a fairly rudimentary manner.

No Command – Error	This the default condition and will get quite indignant if called.
Set to Dev Mode	In development mode it loudly complains.
Set to Released Mode	When released it stores errors to a log file.
Set Error	Either throws up the dialog, or files the error depending on mode.
Log Error	Forces a file store.
Throw Error	Throws up the error dialog
Log and Throw Error	Does both
Set Error Timed	Throws up the error dialog, for a preset time.

UI Control

This component passes commands to the UI update loop, there are several versions of this component, but they all perform similar functionality.

Under Range	This the default condition and will get quite indignant if called.
Exit	Close the queue and exit
Get FP Setting	If anything is on the Q, pass it out.
Get Q Ref	Pass out the Q Ref, just the once to allow it to hold the UI Loop.
Set Status	This is a command to send text to the status text box on the main screen.
Set Tab	This selects the tab to be displayed on the main screen (how we get our wizard going)
etc etc	Screen update command as required, all screen updates should ideally go through this component.

As mentioned earlier tend to push risks to the front of our projects and for this one the identifiable risk was that the control system wouldn't work. We didn't want to be held liable for a system we had little expertise in, with this in mind we required that the customer pay for the hardware, prototype screen and engineering screen.

The prototype screen is essentially a button functional screen that allows the customer to navigate around the system. By using this template we can get a prototype screen together in a matter of hours (we usually allow a day for this size of project).

The cost constraints of the project made us go for 4 process controllers using RS485 to talk to them. We insisted on Ethernet cDAQ for the measurement system at least!

The biggest risk here was talking to the process controllers and therefore that should be tackled first. It was a standard modbus communications and we had a component for that to reuse. This component was then called by the process controller component.

Process Controller Component

Communicates to any process controller on a single port.

No Command – Error

This the default condition and will get quite indignant if called.

Initialise

Set Setpoint 1

Get Setpoint 1

Get Process Variable

Set Proportional

Get Proportional

Get Setpoint 2

Set Setpoint 2

Reset

Get version

Get Bus Format

Set for RS232

Set for RS485

Get Derivative

Set Derivative

Get Integral

Set Integral

Get Output Config

Set Output Config

Get Input Config

Set Input Config

Get Alarm Status

Get Reading Format

Set Reading Format

Get Input Scale

Set Input Scale

Get Cycle Time

Set Cycle Time

Close All

At this stage in the project I was expecting to use auto-tune to get the PID parameters and also to set the controller up completely different for each test/filter. Hence the over-load of functions for this component.

For convenience this component was then wrapped in a batch controller component that did stuff to all 4 controllers.

Components to talk to the measurement system were also written. These were essentially DAQmx tasks wrapped up in components that describe the system. i.e. Control An Ins, Measure An Ins etc etc.

With these written and tested, a manual screen (engineering screen) was produced that gave access to the available hardware functionality and the system was delivered to the customer. This allowed us to get paid for the first milestone and to test some control set-ups.

The initial plan (I was sceptical) was to do closed loop control the fans and the servo valve, it transpired that servo valve could not be controlled in a timely fashion by the process controller for all the variations of test. Also the Fans and Servo valves squabbled causing instability. The process controller set up software was extremely poor and they were a bit more stupid than expected.

After too much time playing with the system we came up with a method that worked and controlled very nicely.

We then added components to handle calibration data, Valve setting lookup, set-up wizard display, Apply Closed Loop Calculation, Orifice Plate dB. A component was also added to Queue up Hardware commands to free up the control algorithm from slow communication operations.

The Beta system was then delivered and an intensive session of testing was undertaken.

What went well....

The system was delivered, working, when the customer needed it, we got paid, customer pleased.

What went badly...

The process controllers cost a great deal more time to get working and set-up satisfactorily than expected.

The agreement that the customer do all the testing and setting up of the system didn't transpire how we expected. In the end we pretty much did it all. This cost us about a week. On the upside we are now the system experts.

From a design perspective I think I over-used value signalling (a quick bodge to convert the manual screen to an auto-test screen). It all worked wonderfully but I found it made the software harder to read.

That felt a bit like homework, so don't expect me to write many articles like this!!

Hope it's of use to those that requested it.