Jump to content

Recommended Posts

Our IT department is rolling out a SCC package called Version Dog to our site. Looking a the website, it looks to be geared for PLCs but down in the documentation it mentions LabVIEW. Has anyone heard of this before? Used it? Have opinions on it? Not impressed by the amount of openly available non-fluff information on the website.

We do have a SVN server running, however the network changes from when the current owners took over have FUBAR our ability to connect to SVN from our desk. This appears to be a much needed effort to version control the PLC programs (long overdue) and an attempt to close out IT work tickets that are many years old.

Thanks in advance for any replies.

Link to comment
15 hours ago, Michael Aivaliotis said:

Never heard of it. Seems like a proprietary system. So you guys have a lot of PLC code?

Yea, the lack of information and the lack of recognition are getting my attention.

Our systems have a plethora of drives, pneumatics, hydraulics... lots of motion control and contiguous fault monitoring. Lots of assembly stations where a small PLC works fine (or a larger one running a bunch of stations). The plants we put systems in have plenty of maintenance people who can deal with PLCs and they are comfortable with them. The test stations we put in are often the most advanced piece of hardware they have in the plant.

Link to comment
17 hours ago, Michael Aivaliotis said:

So is what percentage of the overall code is LabVIEW and how many active LabVIEW developers do you have?

That depends on the project. Some projects are full assembly lines where the conveyor, assembly and gauging stations are controlled by PLCs and the more advanced testing is done by PLC motion control and PC performing supervisory test control, data collection and analysis, etc. Small single test stations may only have a PC running the entire show (including motion control). There might be 100% LabVIEW or 100% PLC depending on the project (particularly since we may include other companys' software instead of our LabVIEW-based solution at customer requirement).

Our original LabVIEW application was written back in LabVIEW 2 when having the PLC do the bulk of things and the PC providing direction and acquiring/analyzing was pushing what could be done (this was also back in the days where you had to make your own custom cards as there just wasn't an off-the-shelf anything). We were still using a decedent of that software when I came on board (including a lot of things you had to do in LabVIEW 2 just to get things to work). That software is long mothballed and we're on version 4.2 of the current software, which is a set of distributed applications (security, data acquisition, error display, calibration, sequencing...) that communicate through TCP and shared variables. Our thought is to migrate the test itself out of the Windows PC into a real-time operating system and use the Windows PC for HMI and mid-term storage. We were able to get as far as we have with this because of posts people made on LavaG that we learned from and were able to get a lot of help from people here. (NI tech support is great, but I had to spend a lot of time explaining the concept of a plugin to them from LabVIEW 8.0 to LabVIEW 2012).

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Similar Content

    • By rharmon@sandia.gov
      So I spent much of the afternoon looking over postings here on Source Control Software and LabVIEW. I must say I came away discouraged.
      I've been programming LabVIEW for over 20 years in a single one technician lab and never really needed any stinking source control. Well now that's not the case. But thought I'd just read some posts, determine what everyone else likes and be done!!!!! That didn't work out for me ether... Seems nobody really likes source control after all. Or at least there are issues with just about every option.
      So here is my situation. I'm still the single labVIEW developer on a project. But the project requires a more structured source control environment. So I'm looking for source control that works flawlessly within LabVIEW and  is easy to use, I'm Using latest versions of LabVIEW.  
      Since most of the posts I read today are from years back, I'm hoping things have really improved in the last couple years and you guys are happy as a lark with your source control environment.
      If you could take a minute and tell me:
      1. What type of source control software you are using?
      2. You love it, or hate it?
      3. Are you forced to use this source control because it's the method used in your company, but you would rather use something else
      4. Pro's and Con's of the source control you are using?
      5. Just how often does your source control software screw up and cause you major pain?
      Thank you in advance.
      Bob Harmon
    • By MrShawn
      Hi all,
      I am fairly new to Labview development.  I want to implement revision control software (SVN in particular) to my workplace.  Before I can do this, I need to prove the concept and usefulness of the SVN application for us.  I have used SVN in some degree in the past, and noticed tortoiseSVN integration with Labview via the TSVN Toolkit.  I have a few questions regarding SVN and how I should organize my project files, in particular when using SVN.
      File organization has been a particular gray area for me in Labview, unlike linking my libraries and specifying their locations I don't seem to quite have that control in Labview.  This issue is somewhat more exacerbated (or at least so I think) when I began using SVN.  Let me explain: Using the TSVN toolkit it sees that my entire class (which was developed in a separate directory - then linked in) is not sourced and revisioned.  This is also the case for several other libraries which I have borrowed or developed myself.  I have two primary questions regarding this.
      The first - How does SVN add/commit these project files when they are not present within the project directory itself?  In fact I have created a separate repo for the class which I use to maintain that code.
      The second - Is my file organizational design fundamentally flawed? Especially in the context of SVN?  What are some good organizational tips/ schemes (when using SVN) which would help me for future projects in avoiding issues such as this? 
      A  less pressing question:
      How well does the "merge" functioning work with the Labview VIs?  Remember I am do not have the most experience with SVN - it is my understanding that merge basically would merge changes I have made back with changes by other devs to the file along the main trunk(?).  
      Thanks in advance.
    • By JackDunaway
      While creating a new a new repo in GitHub, I noticed there is not a template .gitignore for LabVIEW -- let's make one!
      After contacting GitHub support asking the proper channel for submitting a .gitignore to their set of templates, i received the following response: "We have an open source repository, https://github.com/github/gitignore that we use to accept contributions for the gitignore templates. The way we accept new contributions is through pull requests" From the readme.md on that repo, "Since this repo includes a large and diverse number of programming languages, frameworks, editors, and ecosystems, it's very helpful if you can provide a link to information supporting your pull request" -- we will use this thread and public discussion as documentation and justification for LabVIEW.gitignore.
      So, I went ahead and forked the repo and created a new LabVIEW.gitignore, found here: https://github.com/wirebirdlabs/gitignore/blob/master/LabVIEW.gitignore
      Please, feel free to contribute to this thread, and once we've come to a consensus, hopefully GitHub will accept the Pull Request.
      Here's the contents of the file right now:
      # http://zone.ni.com/reference/en-XX/help/371361H-01/lvhowto/lv_file_extensions/*.aliases*.lvlps How can this be improved?
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.