Does this forum welcome newer programers/engineers?

[LVmigrant]

Does this forum welcome newer programmers/engineers?

 

Hello,

I am a new(er) engineer working in automation and robotics. I am not a “beginner” as I have produced multiple LabVIEW programs that are currently in use and have been functioning well. Unfortunately, I am entirely self-taught with no senior engineer to advise me. My employer won’t spring for any official training as he likes my work so I’m left trying to learn from others on various forums. I’m looking to get into some advanced topics like scripting as well as refine my approach to coding. I’m also interested in providing basic advice to beginners as I can.

 

Some users on reddit told me this was a good place. Am I welcome to post here?

[Francois Normandin]

By all means!

And may I suggest you look at the events page on LabVIEW Wiki. You can check out many presentations on a wide variety of topics, including scripting and design patterns.

https://labviewwiki.org/wiki/Events

 

[JKSH]

Hi @LVmigrant, and welcome!

I think nothing beats the effectiveness of a well-designed and well-delivered training course -- you'd learn the most from them in the shortest amount of time and you can be taught to avoid bad habits that might be found online. Still, forums are definitely a helpful way to learn. I studied electrical engineering and basically developed most of my software-related skills via forums, StackOverflow, and lots of home practice. After that, I got my full-time job as a LabVIEW-based programmer in a systems integration company.

[LVmigrant]

Hi @JKSH, thanks for the reply.

I agree but my employer isn't willing to pay for training. I'm hesitant to shell out my own money for it as I'm not sure how invested I am / we are in LabVIEW (do we yell at people for writing labview here like they do on the NI forums?). I was hired by a group that already used it and NI products so I learned and programed in it. Boss wanted LabVIEW, boss got LabVIEW. But now the boss is asking me what I think we should do. There are a lot of factors I have to consider in making that decision. That being said, it's also fun learning more about a language and it's always useful to have languages to pick from based on the task (at least that's my limited experience).

 

I should probably mention that they used LabVIEW, they didn't know LabVIEW or really anything about programming.

[Gribo]

Welcome aboard, this is the right attitude.

[ShaunR]

1 hour ago, LVmigrant said:

do we yell at people for writing labview here like they do on the NI forums?

No. Welcome.

Well. I might yell at you if you write it that way in a CLFN and wonder why it doesn't work 

Edited July 16, 2021 by ShaunR

[Rolf Kalbermatter]

2 hours ago, LVmigrant said:

Hi @JKSH, thanks for the reply.

I agree but my employer isn't willing to pay for training. I'm hesitant to shell out my own money for it as I'm not sure how invested I am / we are in LabVIEW (do we yell at people for writing labview here like they do on the NI forums?). I was hired by a group that already used it and NI products so I learned and programed in it. Boss wanted LabVIEW, boss got LabVIEW. But now the boss is asking me what I think we should do. There are a lot of factors I have to consider in making that decision. That being said, it's also fun learning more about a language and it's always useful to have languages to pick from based on the task (at least that's my limited experience).

I should probably mention that they used LabVIEW, they didn't know LabVIEW or really anything about programming.

Unless you plan to go independent with your own company as LabVIEW consultant or something, you definitely shouldn't need to invest your own money to attend some training. An employer who finds a few days of training to expensive and unnecessary, might be not the right employer for you.

People here are generally quite friendly and will gladly want to help you. There are a few conditions of course. Nobody likes free loaders or home work hustlers, so if one of them finds his way here, he might get the first time a friendly reminder that he needs to show a bit more effort himself in order to get help. In the rare case that they insist to have a right to be helped no matter what, the tone can get less friendly, although yelling I haven't noticed, it usually rather turns into completely ignoring them.

To be honest I haven't really noticed yelling in the NI fora either. It's not your average youtube channel and there is some moderation too, who will often step in when things really are in danger of getting out of hand, which very rarely happened in the past.

But sometimes the answer can get a bit brisk and I'm sure I have been guilty of not always using my velvet gloves with certain people on there who refuse to follow advice since they know it better. 

[Bryan]

Welcome @LVmigrant!

If your company isn't willing to pay for LabVIEW training, but uses LabVIEW - it sounds like a great recipe for major headaches in the future.  

Speaking as someone who has inherited some really bad LV code over the years, a company's up front investment in training for their employees will save them a lot in the future as far as maintenance, refactoring, and many other things.  The bad code I inherited was from programmers who didn't take any training nor took the time to learn from other more seasoned programmers. 

This is a great community with some of the most knowledgeable LabVIEW programmers I've ever met.  Even though I've been using LabVIEW on and off since 1999 - I don't hold a candle to the knowledge contained within some of the the members of this forum. 

That being said - many of the users in here have contributed to the LabVIEW Wiki, which has a LOT of useful information.

Edited July 19, 2021 by Bryan

[LVmigrant]

Hey @Bryan.

I agree. It's already a headache, even just looking working on my own old code (I go through and clean things up as I learn more). I don't dare open up the older programs (anymore) for fear of what I'll see. I'll gladly let those sleeping dogs lie. At the same time, I'm concerned about developing bad habits.

Yeah, the LabVIEW Wiki has been a lot of help. The NI event videos have been a boon (at least the ones I understand have been).

I've been lurking on this and the NI Community to pick up things here and there.

[ASTDan]

I try to keep a library of useful LabVIEW resources on my website you may be interested in

https://www.autosofttech.net/resources/library-weblinks

Welcome!!

[ShaunR]

6 hours ago, LVmigrant said:

(I go through and clean things up as I learn more)

Then you are already more advanced than the average programmer.

6 hours ago, LVmigrant said:

I don't dare open up the older programs (anymore) for fear of what I'll see.

What you will see? Or how long it will take to make it right?

Sub VI, sub VI, sub VI.

Look for reuse. Take a very small section and make it a sub VI (only one click). Clean it up. Nibbling old code from spaghetti to sub VI's has huge benefits. Don't do it all at once. A little clean up goes a long way. Do a sub VI every week or month.

I can guarantee you've rewritten the same behaviors and data manipulations many times in the past; probably even within the same application. As you create the sub VI's you will start to notice some of them are very similar. Look to see if you can make them identical. This is a heuristic way of creating code reuse. Then you can start looking for old code that you have turned into a sub VI that look similar to your current project. Your old code is a test harness for your code snippets. It's been proven to work, right?

Once you have it working correctly in both old and new; fill out the documentation, icon etc if you haven't already and put comments in it. Then stick it in your special toolbox for reuse. You don't need to publish the modified old code but as you gain confidence in your toolkit, you will merge the reuse code into it. If you change the reuse code, run the old software to make sure it still works correctly. This is called  Black Box Testing.

Old code is very useful. It's proven code that works. Cleaning it up and sub VI'ing it will benefit your current and future projects too. You will eventually be able to spot reuse code candidates as you create new VI's - the patterns will jump out at you. You will look like you were a master from day one when other people look at your old code. Only you and your source control system will know the truth .

[Lipko]

6 hours ago, ShaunR said:

Then you are already more advanced than the average programmer.

What you will see? Or how long it will take to make it right?

Sub VI, sub VI, sub VI.

Look for reuse. Take a very small section and make it a sub VI (only one click). Clean it up. Nibbling old code from spaghetti to sub VI's has huge benefits. Don't do it all at once. A little clean up goes a long way. Do a sub VI every week or month.

I can guarantee you've rewritten the same behaviors and data manipulations many times in the past; probably even within the same application. As you create the sub VI's you will start to notice some of them are very similar. Look to see if you can make them identical. This is a heuristic way of creating code reuse. Then you can start looking for old code that you have turned into a sub VI that look similar to your current project. Your old code is a test harness for your code snippets. It's been proven to work, right?

Once you have it working correctly in both old and new; fill out the documentation, icon etc if you haven't already and put comments in it. Then stick it in your special toolbox for reuse. You don't need to publish the modified old code but as you gain confidence in your toolkit, you will merge the reuse code into it. If you change the reuse code, run the old software to make sure it still works correctly. This is called  Black Box Testing.

Old code is very useful. It's proven code that works. Cleaning it up and sub VI'ing it will benefit your current and future projects too. You will eventually be able to spot reuse code candidates as you create new VI's - the patterns will jump out at you. You will look like you were a master from day one when other people look at your old code. Only you and your source control system will know the truth .

In my opinion, subVi-ing is only a small thing. There are so many ways something can be solved, and in a long term project that was started as a newbie it can mean a huge mess if you start mixing these ways. SubVI-ing only makes it prettier but the underlying architecture is still going to be a huge mess.

These messy mid-sized projects are very hard to refractor, because it's simply very hard to test throughoutly if you didn't document testing all the way through the project, which you probably haven't if you made such a mess in the first place.

Most of my late cleaning-ups ended up in a buggy software. Sure, those few bugs could be fixed easily but these occured not during testing but during usage.

But I'm no pro, maybe I'm totally wrong. I know that my software testing knowledge is very weak.

[ShaunR]

1 hour ago, Lipko said:

In my opinion, subVi-ing is only a small thing. There are so many ways something can be solved, and in a long term project that was started as a newbie it can mean a huge mess if you start mixing these ways. SubVI-ing only makes it prettier but the underlying architecture is still going to be a huge mess.

Refactoring and re-architecting are slightly different things. The main difference is scope, intent and risk but how you achieve them may be similar.

Refactoring is to improve maintainability, readability and complexity. This has less risk to the overall behaviour of the software and sub VI'ing will do this effortlessly.

Re-architecting is to improve the logical operation of how you achieve external behaviours. It's to improve modularity, interoperability and cohesion  . This is a much riskier proposition. You cannot re-architect spaghetti code without first refactoring but while you are refactoring; changes in architecture may become more obvious. For example. You can't switch from a Queue'd State Machine to an Event Driven State Machine just by sub VI'ing sections of code.

So what I described was refactoring. I don't think we disagree that sub Vi'ing improves readability, however, I have also outlined how to improve maintainability and reduce complexity through code reuse - not only within the old code but leveraging the time spent to benefit current and future projects. This is a tried and tested way of making sure hideous but working code doesn't turn into beautiful, not fit for purpose, code and is an argument to justify the time spent refactoring when there is probably no longer a budget for it.