Random Ramblings on LabVIEW Design

Community Browser
Labels
cancel
Showing results for 
Search instead for 
Did you mean: 
42 Views
0 Comments

NI Employee of the month Peter Horn emailed me an interesting question the other day. It was pertaining to the LabVIEW Center of Excellence and associated processes.

 

To quote "I was wondering if you’ve ever measured the impact of implementing these processes – either with your own development work or customers you’ve been working with? Everything I’ve found online so far makes sense, but figuring out how to apply it to a specific account isn’t making sense to me just yet."

Now that is an interesting question.......

Read more...

116 Views
2 Comments

I modified the Modbus toolkit (some version I got off NI.com a while back) and in my normal fashion wanted to control my dependencies. All I wanted to do was to move the modbus directory from vi.lib and embed it into my project hierarchy. I also need to be able to then move my entire project hierarchy about on the drive too.

Here's how it went......

Read more...

600 Views
29 Comments

I visit a lot of companies and they all proclaim a pretty standard set of values.

Employees are important, empowerment, valued are all terms chucked around like insults at a political rally. Weirdly I see very little evidence that the majority of managers actually believe it.

Read along as I sow the seeds of revolution comrades.

Read more...

359 Views
4 Comments

SSDC stands for Structured Software Design Consultants, it shouldn't therefore be a surprise that we have a pretty structured approach to the software process. We like checklists, so here's a closer look at our code review checklist.

Read more...

307 Views
0 Comments

I took the opportunity to vent my spleen in my last article, I suppose I had better explain myself.

I'll attempt here to codify my proof that LabVIEW is not easy and programming cannot be optional in the vast majority of cases.

Read more...

383 Views
5 Comments

A feisty little bloggette about how easy my job is, really really easy, optional even......

Read more...

913 Views
6 Comments

I've been playing this game for 30+ years now and this has tempered my expectations. In fact it's made me a bit pessimistic. This is actually a good thing. Read why......

Read more...

865 Views
2 Comments

I touched on this in my immediacy presentation, but think it needs pulling out and concentrating on. It's an easy concept, but when I've shown and described this to people they seem to get value from it.

Read on.

Read more...

1160 Views
18 Comments

Pesky humans ruin everything, this article describes how their input will knacker your programs and spoil your day. Also how to deal with them!

Read more...

1083 Views
12 Comments

This article has nothing to do with LabVIEW, but read on and it might make your life more interesting..... 

Read more...

608 Views
5 Comments

This here article is a summary of the points we were trying to get across in our NIWeek 2017 presentation that you can see in the text. Enjoy!

Read more...

1704 Views
8 Comments

I've seen a few presentations that describe coupling and cohesion incorrectly and thought it might be an idea to revisit some material I have used in training before. I think all the talk about asynchronous processes (actors) also allows us to discuss the metaphor as well.

In our book we used an factory analogy and it worked OK, I think this might be a better analogy going forward.

Read more...

739 Views
5 Comments

I sometimes feel part of the "establishment" and then I rebel against it. With regard to programming what do I view as the "establishment" and why do I think rebelling is a good thing?

Read more...

859 Views
4 Comments

As I recover from jetlag (over-partyitus) I think I should do a review of my trip (including the fun bits and skirting over the business bits)

Read more...

776 Views
6 Comments

My output blog-wise has been poor this year, mainly because I've been making presentations. One of the side effects of the eCLA summit and NIWeek getting pushed closer together is I've lost 3 months in presentation design time.

Read more...

580 Views
0 Comments

This article is the second part of my presentation given in Vienna March 2017. It concentrates on Risks, Outcomes and Mitigating Factors.

 

Read more...

893 Views
0 Comments

Most project failures are not failures of programming skill or technique. The blame lays pretty squarely on a failure of judgement when applied to risks. This is the blog form of my presentation for the eCLA Summit 2017 in Vienna. i.e. it's  (words and pictures) - (messing around with microphone and accidental sweariness)

Read more...

944 Views
3 Comments

You may have missed this as it barely got a mention on NI.com. Which is strange!

Read more...

751 Views
1 Comment
962 Views
9 Comments

As it seems like narcissism is the current way of behaving I thought it might be interesting to keep a diary for a couple of weeks. If you're ever thinking of starting a business like ours, it may be of interest, or if you are already running your own business I would be very interested in your counter-diary. I'm nosy like that.

This has not been a typical week as we've done a bit of travel, that said it's not really that atypical either.

Read more...

2368 Views
17 Comments

My personal observations (as a white male egalitarian)

Read more...

957 Views
1 Comment

For the world I feel that 2016 was a right ugly beast of a year, for SSDC 2016 has been pretty good fun and teetering on the edge of being profitable. Here's our story of 2016.

Read more...

1041 Views
8 Comments

Often SSDC is asked to conduct design reviews and one area that this can be improved is by reviewing against a customers use-case. With this in mind I'm trying to come up with a questionnaire that will help us to understand the project requirements better.

Hopefully this will be a useful document to help weed out the nuances and maybe group-think will make it even more useful!

Read more...

1430 Views
6 Comments

Only those on the path to programming enlightment should read further. In the last couple of years I've changed my view of the world of programming. Reinforced by my conversations here. I promise there will no spiritual stuff here and very little mindfulness.

 

 

Read more...

1074 Views
2 Comments

They've only gone and given us our own NIDays track. The catchily titled "LabVIEW Power Programming with the LabVIEW Community". Find us in the Shelley Room. 

 

 

Read more...

830 Views
0 Comments

Hello Risk-takers

This article concentrates on a very simple rule we apply to all our projects, it's

Identify Risk and Tackle it First

The best way to emphasize this is to describe some common scenarios.

Scenario #1 Hardware

We quite often get projects where the hardware is purchased prior to even a schematic being drawn. You then are presented with hardware you are unfamiliar, for a use-case you barely understand. So what we do first is manually get the thing running. In fact one of our standard milestones is a manual hardware screen, with this you can test the wiring, start exercising the UUT (unit under test), confront your customer with the real world.

Scenario #2 Badly Defined Requirements

Very rarely* one of our clients doesn't fully define their requirements accurately, sometimes they don't fully understand how the system goes together, how the hardware works, even how their UUTs work. So it's not incomprehensible that they can't define their systems requirements. Once again we therefore have to confront them with the real world as quickly and cheaply as possible. To mitigate these risks we use prototype screens.

Scenario #3 Payment

For SSDC we deal with approximately 5 new clients a year, some are nice, some not so much. To mitigate financial risk in the UK you can do some rudimentary checks. Websites like companycheck, DueDil are very useful for some background checks. Talk to your suppliers. Generally we make sure our hardware liabilities are paid first, so pro-forma invoices are the way to go. Define your terms (30 Days Net) and stick to them!

The standard project management approach is to do a Risk Assessment and a matching Method Statement (RAMS), while we only do these on an informal basis (some companies require them to work in certain environments) it's not actually a bad idea to think about risks.

And you should never ever sit on them and hope they go away!

Lots of Love

Steve

* By very rarely I actually mean all the bloody time.

836 Views
0 Comments

To save you some time in your busy schedules this article can be summed up in 8 words a comma and an exclamation mark.

Before you write any code, do some research!

See.. told you.

I'll now expand it just to fill the page with words.

For the lazy engineer there's nothing worse than discovering a toolkit after you've expended blood, sweat and tears to make your own. You may not end up using it, but it will save you time. I recall a conversation with an engineer who had spend 9 weeks creating a PIC relay controller that took a serial command and closed a relay...."um you know you can buy these for $60 don't you.....".

Take my tree control example found here the google search was "tree control database", this then leads on the second part of research for a software engineer.

Learn another language

There's a lot of info and ideas outside of the world of LabVIEW so look outside the community.

As a LabVIEW programmer you will benefit from being multi-disciplinary. So you can spend all your brain-power learning 100% LabVIEW and pride yourself in the knowledge of esoteric tools and techniques from the dark cobwebby corners of the LabVIEW IDE or learn enough to be proficient, then learn how to design databases and learn enough Linux to host stuff.

The second option will allow you to tackle enterprise level solutions out in the real world.

kun amo

Steve

PS mia ŝvebŝipo plenas de angiloj

925 Views
4 Comments

Hello and welcome to my latest L³ Ramble

If you use source code control (SCC) then Kudos to you, this then will lead neatly onto version numbering

 

I've seen a fair few ways that you can version your source-code and this is what we've settled on. Guess what! it's not very complicated.

 

For every unique deliverable item we require a version number.

 

So......

MainVIVersion.png

For our main VI we have a version number and this is linked clearly (via the comments) to our versions in SCC. Clicking on the indicator will pop-up the details

Version info can be found in SCC comments and we also stick them in VI Documentation too. If they get too wordy we can link to another file or write a specific container.

VIProps.png

On the block diagram we just use a version constant vi.

VersionConstant.png

We use embedded exes and micro-services for some our programs and these will need versioning too.

EmbeddedExe.png

Here we see that the bugreporting dialog is an exe called by the main VI and this one is on Beta Version 1:14.

 

For exes it's very useful to be able to query the version from the command line. Here's the code.

GetVersionCmdLine.png

Using this we can send the command line bugreporting.exe --Version and it will respond on the std_out it's version number. It won't actually load itself as this is a dynamic calling VI not the actual bugreporting screen. We use this for auto-updating.

 

For Realtime systems we use similar tactics, but as well as something visible on the front panel, we also need to be able to query it remotely.

RTServer.png

Here we query the rack info for a connected server and our version constant is front and centre.

RTQueryVersion.png

In fact this applies to all embedded targets, for example we have PIC controllers that respond in a similar fashion.

 

Finally for FPGA targets we just embed a couple of controls on the front panel and these are then passed up to the host.

FPGA.png

These are updated each time they are released to the outside world and not for every commit to SCC.

 

Here's some practices we've observed and DON'T do ..... you may have a use case that these apply to.

 

I've seen CLA level work that individually version numbers each VI, I guess this is instead of a pukka version control system. Seems very counter-intuitive to me!

I don't use the individual revision history options as part of LabVIEW, to my mind it drowns you in information you don't need.

 

In short I want to know what version of software is being used/ reported against and then be able to trace this back to a SCC release.

 

So far this has worked very well for us.

Lots of Love

Steve

 

10-July-2017 Here's an addendum based on a project I've been called in to support.

 

New rule: The version of the source-code needs to be traceable from source code control to the version of the built exe. I came across a project last week where I had no clue as to what version of the source code was used to build the version of the exe.

 

This option was used on the application builder.

VersionAppBuilder.png

The build version was then taken from this and displayed in the title bar. This is fine for the customer, but for someone supporting the code is was essentially useless. I could replace the source-code with an entirely new set of code and all it would do is increment to the next build. 

940 Views
7 Comments

Hello World Wide Wire Wranglers,

You may well have heard be going on about KISS and it's really an acronym that I can buy into. For those of you who have never heard it, it stands for.

KISS.png

And this applies to everything we try and do, but what about Realtime systems I hear you ask (you know who you are, you scallywag)

RT

Well as RT has a subset of LabVIEWs capabilities we then apply

KISSer.png

Yes, but surely FPGA has different rules? actually it does.

FPGA

KISSest.png

One time this doesn't apply is when you're electing a president .......

Much Love

Steve

751 Views
0 Comments

Howdy Doody Developer Chums,

Keeping the output coming thick and fast, this article describes something I've been thinking about a fair bit in the last few months.

First of all let's describe the nuances here. I don't really like supporting software (it's boring) and supporting software with a customer breathing down your neck is significantly more difficult than writing it in the comfort of your office. Some of my worst programming experiences are when something doesn't work in front of the customer and you just don't know why.

A large part of repeat business is based on how well the software is supported. Support is judged on responsiveness, the important criteria is how quickly/cheaply you find a fault or add additional features and get the hell out of the way.

So the thing I've been saying recently is that we program slow so that we can debug fast. In fact our whole way of working is debug focused, and this suits us. Fair warning, it may not suit everyone.

We invest a lot of time on our code, look here for proof.......

Rapid Modification and Debugging, Immediacy Presentation, I'm not being critical but... (Re-use) Part 1, A Tidy Project is a Happy Project even LabVIEW Life Lessons #1 - Project Portability

All of these are ways that we spend a great deal of time on our code, that has nothing to do with solving the problem and everything to do with making life easier down the line. In fact it could be thought of as technical overhead.

All of this work is us building our technical assets and paying down our technical debt.

So that when it matters our projects are easy to maintain. In fact all of this effort is so that we're not struggling in front of a customer!

effortless.jpg

Which will lead into my next L³ article

Lots of Love

Steve