Random Ramblings on LabVIEW Design

I'm pretty sure I did a presentation on this some time ago, sadly I seem to have lost it so I can't just regurgitate it here!!

A few years back there was a marketing campaign based around how learning LabVIEW could lead you into different skill areas and work. Normally these fly right over my head, but this one made an impact.

So this article will be pretty self-indulgent, but the point is that the link between LabVIEW and the hardware it can drive can push your career into new and interesting areas.

Below is a slide from my presentation on immediacy, it maps the way SSDC has changed from a mainly Test based company to much more of a Distributed Machine control company.

All of our experience has stemmed from designing test and production equipment from the factory floor (to those of you that have never seen a factory, they are what industrial estates used to be full of back in the olden days).

A few years back we saw the test market becoming increasingly commoditised and so decided to look for work in other areas (a decision also based on the fact we were bored with designing test systems). RT came along and we embraced it for control work, both in Factory Control and Machine Control.

The first factory control job was for Mclaren where we designed the composite moulding plant for the body and chassis (worlds first!) for this beauty!

Another job in 2005 was focusing a blu-ray dvd mastering system to 40nm on a glass platter spinning at 5000rpm. Pretty damn challenging, but excellent fun.

Databases have always been central to our skill-set and we found ourselves doing Laboratory Management Systems, these are essentially large UI applications, connected to a database with lots of screens to manage reporting, scheduling etc etc.

If RT was good for us, cRIO was brilliant!!

The weird thing was that we weren't using it where we expected to. A large percentage of our work was actually using the FPGA to hack and convert old systems communications. The ability to do this fast (1 load/unload of the buffer) has been really useful. The best thing about this type of work is that our customers have never heard of NI or any of their technologies. It's fantastic to break an entirely new market.

So this week we will be fitting a system on this ship.

It's a proper engineering geekfest. The next picture is the ship balanced on its keel in the drydock!!

This job came from Adrian cold-calling the ferry company and telling them that we could hack the ships monitoring system. Kudos and employee of the year to him as there is a lot of ships bobbing about that need this work!

So who knows where we will be in 10 years time, all we know now is that the skills that currently pay the bills are....

LabVIEW

RT

FPGA

Linux

Databases (MySQL, SQLite)

Distributed System

Communications - Serial, CAN, UDP, TCP

So looking at the original slide, a large percentage of our work is now in the bottom half of the triangle and who knows what will be added to the bottom.

Lots of Love

Steve

Howdy Doody my precious programmers

I'm often asked "How do you keep your project so shiny, clean and smelling so minty fresh?"

Well first let's have a look at a clean project

This is our General Application template and you'll notice that the main VI (GenAppMain.vi) sits atop the hierarchy and that's because he is the king and everything should be relative to him. This is how LabVIEW like things organised, it will always look below itself in the hierarchy first as standard behaviour. You'll also notice that we use auto-populating folders showing the entire hierarchy, the way we structure our projects lends itself to having no virtual folders (IMO it's an abstraction too far) Dlls, config database file, startup VIs are also at this top level. All of this stops LabVIEW going searching when you move the project around. Keeping everything at this level also helps when you build an executable. It's much easier just to search in your own directory. Like Unit Testing? well look in the TestVIs directory (we are trying to use Teststand if we need to do Unit Testing, this is quite new to us as we far prefer lots of functional testing) Next we need to make sure there are no conflicts. Click on the exclamation mark and solve the problems. What we are aiming for is a portable project. Ideally I want to dump my project directory on a new computer and the it to work. At the very least I want to be able to move the project around on the computer you are developing on. All this preparatory work is to allow us to upload the project into our repository (SVN). If the project is portable we can then download the project onto any SSDC machine or even across customers machines. We take an uncompromising view on dependencies and in truth anything outside of SCC (Source Code Control) is something that can change how your software works in unpredictable ways. See here for a discussion on this. With this in mind we can see that the Dependencies section is pretty light and we aim to keep it that way.

Project Flossing

Over time scrappy bits of old project can get caught in the gaps, and these need cleaning. This is because they are indicative that a lack of control and understanding. One common area that needs regular flossing is in the Dependencies.

In this example we can see that although there are no conflicts, there is still some ugliness in the Dependencies section.

Cleaning these out is fairly straight-forward, you just need to find the unused VI in the project that is referring to these dependencies. But if you use dynamic VIs you should employ the following trick first.

Sticking any dynamic VIs in a non-called case of the main calling VI will not effect the running of the VI (LabVIEW will compile them out), but it will allow the IDE to tell you if they are broken. It will also allow LabVIEW searches to ascertain if the search VI is in the hierarchy.

Now you are ready to floss....

Right-click on the offending Dependency and select Find>>Callers, because the main calling vi is not broken and all dynamic VIs are on the main calling VIs block diagram we can be pretty sure that there is a broken, unused vi in the project. Find it and delete it (using the SCC delete function!)

Also notice the \user.lib folder, for us this is a sure sign of something untoward in our project structure. This is because we NEVER use user.lib. Also view instr.lib with suspicion, anything that is not part of the standard LabVIEW install should be moved out and put under the project (use lvlibs to protect the namespace).

Having a tidy project makes cross-linking and unpredictable loading a rare thing and it may even prevent gum disease.

Lots of Love

Steve

Hello G-Stringers,

I'm listening to King Gizzard and The Lizard Wizard as I write this and rather jolly they are too!

I'm stupidly busy at the minute so forgive my lack of output!

This particular article is about numbers. It's the numbers we charge and the what they mean. I'm hoping it will help people starting out in the trade and help when a customer is considering hiring a company.

SSDC are a LabVIEW consultancy and as such we charge people for our services. There are 2 ways you can charge for your services, hourly (time and materials) or fixed price.

For hourly the customer takes on the risk (although there is always a limit to what your customer will pay), for fixed price the risk is on the supplier. As such the price you use to calculate a fixed price job should always be higher.

How much higher is the important question?

I'll drag up a story from the past to give some context.

When we started out our rate for fixed price work was £35 ($50)/hour and we struggled! Every job was hand-to-mouth, we couldn't offer the customer service we wanted and it was generally hard. If you can't offer decent levels of customer service you won't get the repeat business that makes life so much easier. Things were bad so I did some maths!

For my company I needed to know how efficient we are. The easiest calculation is hourly rate * number of hours worked in a year = £67200/person/year. If I got an hourly paid job at my hourly rate I'd earn £67k ($100k). Trouble is we were doing fixed price work and this dropped us down to a net turnover of £40k($57k), take out 20% tax, business expenses, insurance, transport and it all begins to look a little sad!

It dropped to 40k because we were 60% efficient, this means we were spending time on unpaid work -> Sales, Marketing, quotes, accounts etc etc. So even if we were fully employed we were still barely earning enough to pay the mortgage.

And this 60% efficiency shouldn't be regarded as a bad thing!, you should spend time on all of those things, you just need to account for them.

The other assumptions here is that you'll always win on fixed price work, I would suggest that even if you were good at software estimation you'd still only win 50% of the time (and I'm still waiting to meet THAT person!).

Lastly on fixed price is what happens if it all goes wrong....you don't get paid!

So when calculating a rate to apply to a fixed price job you need to take the hourly rate you would be happy to earn if you had a contract for the year, factor in your efficiency. You can then apply this rate to the estimation of hours and add in a contingency (we'll come back to this).

So for us we should have been aiming for an hourly rate of £58.3 ($83.3) when calculating fixed priced work.

Disclaimer: these numbers are circa 2000 and we are considerably more expensive now!

Coming back round to contingency, we use this help us cope with uncertainty. So if for example there are some requirements that are poorly defined, you could bully your customer into divulging all the details or you could just add some contingency. This is where experience really helps.

So the final fixed price equation should be at least

((Desired Hourly Rate/Effiency)*Estimated Hours)+Contingency

Hopefully by using this equation you can avoid paying your mortgage with your credit card!

So it looks as if I'm coming to NIWeek 2016, I have submitted a presentation or two (more details to follow, but they will both be sensible!)

I do have a T-shirt design in mind and if there is any interest I'll get some made properly.

Here's a rough early concept.

Lots of Love

Steve