Jump to content

All Activity

This stream auto-updates     

  1. Past hour
  2. 9376770 9376770 joined the community
  3. Today
  4. kosist90
    Thanks a lot! We're going to try it, but it seems that this is what we need, thank you!
  5. KyleFan KyleFan joined the community
  6. Rogelio Acevedo Rogelio Acevedo joined the community
  7. Yesterday
  8. Neil Pate
    Just did a quick test. Started LV2020, did not start or open a project just created a new VI. Did some simple stuff and then created a Sub VI from some of the diagram contents. Just doing this took nearly 30s 😞
  9. LogMAN started following VCS / Development Toolchains in 2020 and LV2020 Slow To Create SubVI
  10. LogMAN
    Sounds like the compiler is busy figuring things out. Just tested it on the QMH template and it is as fast as always (1-2 seconds). That said, the template is not very complex. Do you get better results with a simple project like that?
  11. Neil Pate
    I have been using LV2020 for a bit recently and have noticed that it is extremely slow to create a SubVI from a selection. This is the kind of thing I do quite often and I am used to it happening mostly instantaneously. In LV2020 this operation now causes the LabVIEW process to ramp up CPU usage and my laptop fans start to spin noisily and about 30s later I get my SubVI. Anyone else seen this?
  12. Shreejita Shreejita joined the community
  13. 肖杰 肖杰 joined the community
  14. Morteza Vafadar Morteza Vafadar changed their profile photo
  15. Last week
  16. Abdalrahman Abouzied Abdalrahman Abouzied joined the community
  17. 钟芝浩 钟芝浩 joined the community
  18. Chris Gardner Chris Gardner joined the community
  19. LogMAN
    Whichever system you choose will require a lot of time and effort to implement by the whole team. Don't think that you can simply choose a tool that "feels right" and expect everyone to accept your opinion. I made that mistake and had to rethink my strategy after a disaster of a start (only one of us adopted the new system - me ). You also don't want to be responsible for everything, so it's best to have the majority on your side before you enforce a new system. Your main focus should be on your workflow and your requirements to decide which tools are right for you. For example, do you have small projects or big? how many developers work on a single project? are your projects deep (multiple projects in separate repositories), wide (multiple projects managed in a single repository), or flat (single repository)? do you always have access to your servers when developing? do you have a project leader, or is each project managed by a single head-developer? who are your stakeholders and which kind of reports, documents, and access rights to they need? how are bugs reported to your team? do you need to give access to your source code and bug trackers to third-parties (external)? what kind of development cycle is used for your projects? do you need to integrate additional platforms or tools (i.e. CRM)? While it is kind of easy to state those questions, the answers are not that simple to give. I still struggle to answer some of those (among other) questions and simply made gut-decisions where necessary. Also, don't forget to include your team in this! Simple questions like "Where do you struggle the most?" do wonders if you care to listen. Here is our tooling for reference: We use Git for source control, Jira for bug tracking, planning, and reporting, and Confluence for the wiki. Our developers are free to use any client they want (i.e. Sourcetree), as long as they adhere to the commit guidelines. We still don't have a working CI/CD solution, so each developer builds their own project (or in case of larger projects, the head-developer). Unfortunately LV is exceptionally slow in this area, especially for large projects. We are actually at the edge of what we consider acceptable. In the past we used ZIP files, later SVN. I don't think I need to explain why we went away from ZIP files. SVN, however, we discarded because it wasn't the right fit. Occasionally we have to change programs on-site, without server access, and want to be able to commit changes. SVN simply is too much effort for such a workflow. You need to remember to checkout and lock files before you travel and hope that nobody breaks the lock. Lessons learned from using SVN: Don't trust your colleagues 😱
  20. drjdpowell
    @kosist90 Here is a beta version, that you can test if you like: drjdpowell_lib_sqlite_labview-1.12.0.89.vip It's not implemented exactly the same way as your example, but it should work in the same places. See the example "SQLite Parameters in Execute".
  21. Neil Pate
    @pawhan11 yes this was done because the "data" said that more people create a constant, so it should be at the top of the menu. Truly wish NI would stop f*cking around with stuff like this and fix NXG. There are tokens to turn it off but I have not bothered and instead just learning to get used to it.
  22. crossrulz
    This change happened in 2019. My suggestion is to start getting used to using Ctrl+U to clean up the wires (make sure the wires are selected first). I am pretty sure there is a LabVIEW.ini token to turn this off, I'm just having problems finding it.
  23. pawhan11
    Hello, I ve moved from LV2018 to LV2020 and it seems that position of Clean Up Wire changed from: To: Can this be changed somehow? I end up creating constants now and have to click multiple times
  24. Grv Chy
    Hello crossrulz, The actual target is to see each data in .csv Format but i am not able to find real time update in .csv , when LabVIEW send a data in each Minute, it should be also updated in csv while it is opened. I Need to monitor each data send from LabVIEW while csv is receiving it. I am not able Keep open csv file and monitor while it is receiving data from LV.
  25. pawhan11
    I want to leave svn behind as soon as possible because current repo structure that was tailored many years ago in my organisation. We have one svn server with one svn project and inside that project people created folders for multiple projects... i once found there labview iso image. After 2 years working with that i still have no idea where to find something. 🙂 I guess I could migrate to another svn and do it right this time. I want git because local repo is big benefit for offline work that is more common these days. Another reason would be to keep up with technology progress. All sw companies that i know use git. For project management we have Jira and it will probably stay that way. Ability to define custom workflows solves many problems for other teams, like projects for equipment calibration, maintenance, production support work really well. We do not have make custom tailored software to manage this. I tried to do this in gitlab and failed.
  26. Grv Chy
    Great man it is working… Now i just Need to find out how can i write random number continously in each row and column in each 500 ms.
  27. JB_1592
    Yes. To that end, the thing that mostly drew my attention to Azure DevOps last night was the support for TFVC. They advertise Git repos so heavily that I actually didn't realize they (still?) supported that VCS until I took a closer look. You are right, I probably should have limited my question to TFVC and not mentioned Pipelines as it certainly isn't the priority. Maybe tomorrow I'll find a little time to install Team Explorer and play around with it... but when I went looking for the download link I found a MS rep's blog post that basically said MS wasn't going to release a standalone Team Explorer with recent versions of Visual Studio until enough customers asked for it. That makes me wonder how much they even intend to support TFVC going forward and if it might get dropped at some point soon. Mostly you already mentioned them... "none of the common VCSes were designed to work with something like LabVIEW; they were all designed to work with text-based code" Yes, which is why I'd prefer to use a lock/edit/commit workflow vs. a branch and merge one. "They want an extremely high level of control and security over the code base" Define "extremely high level". A lot of Git workflows encourage rewriting or condensing history in ways I'm not entirely a fan of. Can we simply not create a lot of branches (if any), never fork, and hope for no collisions without locks? Yes... and it will probably work fine. That's why I'm not completely ruling it out and looking at the rest of the platform. (Sidenote: I'm actually a little surprised that, unless I'm missing something, Github seems to be the only platform that allows forking to be disabled at the organization level.) This is a loaded question... Define "interaction". They, and especially the managers that would have to approve, tend to be a little... insular. (Trying to be nice here.🤣) This research is mostly backup plan and personal learning... I hope.I do think using what we already have setup and that IS already knows how to support is the best strategy and I've already brought up wanting access to what they use. ... I just won't be surprised when it gets shot down. Yes, absolutely. SCC solution is the first priority, but trying to form some vision for what we might grow into can't hurt in making an informed choice. I was also generally like being aware of what's out there and what larger teams are doing. (Besides... I'm off this week so I've got time to research and play around with some free tier accounts. 😅) Here's my thoughts on the parts of CI that might be nice for us... Automating versioning Automating testing Automating zipping the build and other artifacts and moving the packed files to a NAS location. Ensure the build occurs in a clean environment. That way I know I won't have to go hunting down random dependencies that were in someone's vi.lib folder years later. Ensure the source of the build was checked in and record the commit info. 💭 Granted... I suppose I can do most of that in some form using the Application Builder API and some custom build scripts, and I suppose I could distribute those in project templates... Hmmm, maybe we wouldn't gain much... 💭
  28. JB_1592
    Before I go into that, may I ask why you are migrating away from SVN? I'm looking for perspective on other VCS options. As to your question, I think it mostly boils down a lot of little UX frustrations. So far I've had more trouble finding my way around the Bitbucket UI than any other. That said, after spending a little more time with it today... my view is softening a little. I also find the way Atlassian separates everything in different tools to be a little confusing. For example, to get project management, repository storage, and user management, I would need to subscribe to Jira, Bitbucket, and Atlassian Access. Before I added it all up, I also found this was giving the illusion of a higher cost when moving beyond the free tier of any of this services. Maybe that's just me, and it does turn out not to be true. All the separate parts are low cost enough that they combine to still be a decent value compared to the competition. Looking at the more common three Git platforms. Repo management Gitlab allows creating groups and subgroups. Each repo is part of its own project, which can be placed in groups. So I believe the way this would work is I would create a top level group for my organization, then use subgroups to further divide projects into categories. Github allows creating an organization, which can then have teams and subteams. Repos belong to the organization and all share the same namespace. Repos can be assigned to multiple teams. This feels like it would be more useful if I was more interested in controlling access vs. organizing repositories. The UI for navigating this just doesn't seem all that useful. Bitbucket allow creation of a workspace, which can have projects. Similarly to Github, repos belong to the workspace and have a single namespace. Honestly, this feels pretty useless as the projects literally just group repos together and serve no other purpose. As far as I can tell, these "projects" don't provide any actual project management or access controls. (Am I rushing to judgement again?) Jira allows adding multiple repositories to a project, which feels slightly more useful as it at least provides issue tracking, boards, etc. Project Management Gitlab has an issue tracker on each project. Issues propagate and aggregate at the group level. I sort of like this. The downside, which might be something that can be overcome (or ignored) with proper configuration, is that tags used for status automation are board specific. (Although I think I may have just figured out how to fix that.) Github has issue tracking on every repo, and allows creation of projects on repos, teams, and organizations. An issue can be placed assigned to multiple projects. Seems more flexible, but also like it might be more complicated to aggregate status. Bitbucket on its own just has a pretty simple issue tracker on each repo that doesn't seem to have much to it. On the other hand, it also feels like a token effort because they prefer you to go to Jira, which is definitely feature rich. That said, this is also part of the UX issues I mentioned. The method to get Jira issues to show up on the page in Bitbucket is apparently to create a commit that references one of the issues. I did that several times and it didn't work. The issues got hyperlinked on the commits page, but the Jira issues page still said there were no linked projects. I eventually realized this was because (I think) I didn't have Git configured on my computer with the same email as my Atlassian account. On the commits graph it says "This user cannot be matched to an Atlassian account," but apparently that doesn't stop me from being able to commit changes and reference issues... it just won't trigger a link to the project on the issues page. I edited the readme.md file from the web interface and created a commit that was linked to my Atlassian identity and it worked. The integration the other way is simpler; you just click Add Item, Repository, and paste in the address. Unfortunately, that doesn't form the link in Bitbucket. That said, I'm coming to realize the more I play with this that I'd probably be looking to do project management tasks from the Jira project page, not on Bitbucket. Documentation Yeah... they pretty much all offer per repo Wikis. User Management / Security Gitlab SAML enforcement is available at the Silver tier of the cloud application. Self-hosting is available even at the free tier of service. Github SAML enforcement is availabe at the Enterprise tier of the cloud application. I think you can also use Enterprise Server to self host for the same cost? They don't really seem to advertise this very well. Bitbucket Requires subscribing to Atlassian Access. All of their applications can also be self-hosted. (And apparently for next to nothing with a small number of users.) CI Gitlab - I know of others using Gitlab runners with LabVIEW, so that should work. Github - They offer self-hosted runners... Haven't seen anyone specifically using them with LabVIEW, but probably doable? Bitbucket - They actually get some points here for being the easiest to setup a pipeline to build a simple .Net Core console app. (Basic Hello World! thing.) That said, I don't think they offer self-hosted runners or other options that would work for LabVIEW. If we did get to the point of wanting this, I think we'd need to use Jenkins... or maybe Bamboo would work because of course there is another Atlassian product that does this. 🤣
  29. Michael Aivaliotis started following 2 x NI cRIO-9039 for sale
  30. Michael Aivaliotis
    I have 2 x cRIO-9039 controllers for sale (hardly used by me). If anyone wants a great deal on these, let me know. I can sell one or both.
  31. Gribo
    Type object is in the System namespace. Click .NET connectivity -> Invoke node -> Select class -> System -> Type -> Missing
  32. JKSH
    I suggest spending most of your energy on choosing a VCS for your team, as this is the part that takes the most effort for your team to adopt. I'd say that the other aspects (project management/issue tracking, documentation) have a lower barrier to entry. Can you elaborate on which parts of the centralized model are most important to you? I'm guessing it's because a distributed VCS (DVCS) can do just about everything that a centralized VCS can, but the converse is not true (hence my previous question). As a result, the online community (which is far more visible than corporations) are moving to a DVCS. The 2 reasons I can think of for a company to stick to a centralized VCS instead of switching to a DVCS are: Inertia. If the developers are already familiar with an existing tool, there is a cost to switch. They want an extremely high level of control and security over the code base. A centralized VCS makes it a bit harder for a rogue employee to make off which the whole commit history (but it doesn't stop them from taking the current snapshot). If the separate applications interface with each other well, how important is it to still have a single application/platform? Does your team have any existing interactions with the software engineering group? Can you get any support from them? Do you anticipate your team working with them in the future? If so, then the best choice for your team might be whatever the software engineering group is already using. That provides a lower barrier for collaboration between both groups. If you expect to be completely isolated from the software engineering group, then I'm guessing there is not much difference between the possible solutions you have listed. All of them will come with an initial learning curve; the important thing is to pick one, get everyone on board, and get familiarized together. I believe all modern hosting platforms support this. Be aware that none of the common VCSes were designed to work with something like LabVIEW; they were all designed to work with text-based code. So, regardless of which VCS you choose, LabVIEW devs must learn to take a bit more care to avoid triggering conflicts (and learn to handle the conflicts once they occur). How "big" are your team's projects? How often do you produce a new release? Are there parts of your release process where you go, "Man, this part is tedious and error-prone... It would be great to automate this"? CI is most useful when you have a lot of people working on the same code base and/or you have teammates who churn out commits at lightning speed. It can still be beneficial for small teams, but the impact is less pronounced (and the cost-to-benefit ratio is higher) CD is most useful when you want to release often, and/or your release process is tedious. DevOps is most useful for a large organization who wants better collaboration between their developers and their operators, and who want to make deployment more efficient. As you described yourself as a "small team with a badly overdue need for SCC", I suspect these are lower priority for you right now. Again, getting SCC in place first will probably be the most helpful; the automations can always be added after you've tamed the chaos.
  33. JKSH
    Spoken like a true LabVIEW dev 😁 That's a really good idea
  34. Mohammed Azharuddin Mohammed Azharuddin changed their profile photo
  35. Aristos Queue
    I have a theory for what a good UI for GIT would look like, and it is a bit different from the existing ones. I think there should be a picture of the current state of the world. You draw a picture of the state you want. Then the tool generates the command line commands that get you from A to B. This serves two purposes: rather than taking an action and then seeing if that did what you want, it puts the UI in charge of figuring out how to get you textually what you're specifying graphically. Second, it shows the user what the commands are that it is executing so that you figure out "oh, that's how that is done" so that when the UI inevitably hits its limits (for whatever reason, GIT seems to exceed the complexity of all UIs used to render it), then the user is already are familiar with the commandline interface. I don't think I'll ever be motivated to write this UI, but I figured I'd toss out that bit of brainstorming in case anyone decides to chase that albatross.
  36. JB_1592
    Maybe, but honestly I think it's just the Linux culture. There really isn't one singular, official GUI for the OS itself, why would we expect one for the VCS created by the same guy to manage the kernel source? Besides, if we took that as a valid reason not to create a GUI for something then how do we end up using a graphical programming language?! 🤣
  37. tlerunner
    Try setting the VISA input and output buffers to something like 1024.
  38. LogMAN
    Nice, that message did not exist in the version of Sourcetree I used a few years ago. Glad to know they keep improving. Still, some genius decided to make "Yes" the default answer...
  39. Bryan
    Our logging routines are home grown. Of course, we're not logging EVERYTHING, mostly just overall test results and not each bit of data collected from a UUT. Our older testers log production pass/fail data to CSV files (older testers) or the company's MS SQL database. I've wanted to use SQLite for local logging, but the push back that I got was that it adds a dependency - having to create or install a viewer to access the logged data. Most of the other Engineers that would be accessing that data want something that's ASCII based and easy to read and import into other formats that wouldn't require anything other than common applications to access. (E.g. Excel, Notepad, etc.). They like the KISS method.
  40. Darren started following Git can't be this terrible, what am I doing wrong?
  41. Darren
    I've noticed that too. I think it's because, for whatever reason, different UIs resonate with different people more than others. Of the several I've tried, Fork is the one I prefer. I can say that in the couple of months I've used Fork the UI has made my (admittedly simple) workflows straightforward, to the point that I've never encountered the detached HEAD issue, or any other major issues for that matter. And the authors of Fork provide incredibly responsive tech support as well.
  42. drjdpowell
    It's the difficulty in consuming text files with hundreds of thousands of log entries that makes me like a db.
  1. Load more activity
×
×
  • Create New...

Important Information

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

  I accept