JB_1592

I have done a minor project with it. Thoughts so far... I think what you hope to achieve and what you need from it is a big consideration. Unlike a typical sequence file, OpenTAP TestPlan objects do not have Setup and Cleanup routines. That makes mandatory cleanup steps that must occur even if test is aborted less intuitive. There are a few ways to achieve the basic idea, but they require a shift in thinking and a decision on how best to achieve the goal. For what I've done so far I've gone with the idea of using steps with names like "With Power On" and ensuring power is turned off in a catch block that should run even if an exception is thrown, but I do worry a bit that if I have multiple instruments/interlocks/whatever that deep nesting of these steps could make editing TestPlans cumbersome. Outside of that, if your goal of going open source is something available for free then you may be in for some disappointment or have a lot of work left for yourself. The engine is free, unless you really want to pay Keysight for support. The WPF based Editor a community edition, but it is not free for commercial use. You can use the open source text based one (TUI) if it meets your needs, but it isn't quite as user friendly or fully functional. (Although it works basically anywhere there's a terminal, unlike the Windows only WPF based Editor.) There is a new "EditorX" available, but I haven't tried it. If I understand correctly, the "community edition" license for this application no longer contains the prohibition on commercial use, but does require that you agree to a bunch of telemetry. This one is built using one web-based UI tech or another and is supposed to be cross platform. There are some basic things outside of the engine not included, such as printing a nicely formatted report. Keysight does have a HTML5 ResultListener plugin, which I believe needs to be licensed per workstation. That may not be an issue if you don't need to print paper copies of results. There are free plugins for writing results to CSV files and SQLite or PostgreSQL databases. If you want or need to pay for any of these things then it catches up to (or exceeds) the basic deployment cost of TestStand pretty fast. Of course, you could roll your own for any of those things, but that can add up to some effort. Then there is the greater .NET vs LabVIEW portion to consider. LabVIEW is built for test and measurement and has a far greater ecosystem in terms of instrument drivers and such*. .NET certainly has more general purpose libraries and larger community, but if you need data visualization you'll need to decide on a third party library to do something as basic as data plotting. I think some of that may be taken for those used to building UIs in LabVIEW. The devops ecosystem is much stronger for .NET if that matters to you. Overall, a lot of give and take and I'm not 100% sure whether or not this will be the long term path for larger projects. *OpenTAP does include base classes for instruments, as well as a generic SCPI instrument implementation that can be derived from, which somewhat facilitates creation of instrument plugins, but I don't think you'll find a lot of vendor provided ones. I think even a lot of the Keysight provided ones require license keys... Come to think of it, that seems like a major weakness and barrier to adoption if they really want to drive adoption of this framework,, so... not really sure how I feel about that business model.

I find most pages on NI.com to be pretty underwhelming these days. Mostly marketing buzzwords and very little substance.🤮

Yikes... I've never gone to one of these conferences. Is the privilege of sitting in a terrible focus group for an hour what people buy tickets for?! 😲 Anyone else find it hilarious that "you're talking about a different file format, it's really hard for us to do" was his explanation of what would stand in the way of... A different file format. 🤣 (And is it just me, or are most of his responses to questions/concerns just complete nonsense? Either completely misunderstanding the question, or not relevant at all. Does he really believe that anyone commenting that the way NXG implemented a feature wasn't ideal is concerned about whether they will literally just copy over the source code?)

Well... we will be due for renewal in November. Guess I'll know by then. AFAIK, the only automatic system they offer is to use concurrent licenses, which are automatically checked in and out by authorized users/machines as the applications are used. (As opposed to nonconcurrent, which can only be assigned to one person or machine at a time.) I looked into those a little while (maybe 2 years) ago since we have a number of people that only very occasionally use LabVIEW or other NI products. Unfortunately, NI charges 3x the price for a concurrent license. 😲 My primary purpose in looking into it was to simplify management of them, but I don't spend that much time reassigning them. 😬

Is that definitely how they are handling this? Extending the SSP wipes out your perpetual license? This section of the announcement had me under a very different impression. It makes it sound like the subscription license and the perpetual are two separate entities, and would continue to be so after the, "transition." What will happen to my current VLA perpetual licenses after I transition to subscription? You will continue to own your perpetual licenses, locked at the version of your services contract expiration. NI can provide you a non-expiring license file or break out the volume license into single seat installations.

Can you describe the expected behavior a little better? You are only reading from the CAN adapter under the Manual Send state, it isn't deterministic whether the VISA send or CAN read occurs first, and you are only reading one message each time so if you have a bunch in the buffer then you are never getting to them. I've used PCAN-USB devices quite a bit and one other thing worth noting: Aside from the CLFN nodes being set to run in the UI thread, the PCAN-Light library that driver uses is no longer supported and I've had issues with that DLL under Windows 10. Make sure you find the latest version of the DLL, which helps, but an even better idea is to switch over to the PCAN-Basic API. The usage is mostly similar. EDIT: Also, in regards to putting another CAN device on the bus, you shouldn't need to if what you are doing is correct... You are never calling PCAN_WRITE, so if you actually intend to send anything over the bus then there's problem number one. If you really are only trying to read, then you can see what messages are being received by opening PCAN-View. You may already have it if you installed the OEM driver package, but if not then you can download it here: https://www.peak-system.com/PCAN-View.242.0.html?&L=1 Note that you'll want to open PCAN-View only after your application initializes the CAN adapter or your application may error on initialization. (PCAN-View can operate in listen only mode while another application has a the adapter open, but other apps generally won't be able to initialize a new session while it is running. I think newer drivers might behave better there, but I haven't played around with that for a while.)

The OCD part of me is screaming over the naming. "Collectable" is an object that can be collected. Why is it also the collection? IMO, a interface called Collectable that provides access to an array of Collectable doesn't make much semantic sense. I notice that in your first version, Collection inherits from Collectable. That also seems odd, but I think maybe you did that so that your Collection class could be part of a Collection. If you separate Collection and Collectable into different concepts, then Collectable seems to have little value. LabVIEW has a common ancestor for all classes, so if you wanted to create a "generic" collection then it should just hold an array of LabVIEW Object. (Or possibly even variant...) Of course, that introduces some complexities with type parsing, so multiple <SomeType>Collection classes might be preferable. The way you have defined Collectable typedef and are using it in all your private data controls just doesn't really feel right. You've basically defined a class, come up with an odd proxy/composite sort of thing where the encapsulating class owns the data. I personally think it feels like you are putting too much into one interface, and then when you refactored you tried to consolidate even more into it. To accomplish what I think you are going for, I do believe you will have a common interface across these classes, but I'm not sure if Collection or Collectable is it and, in any case, you should probably be creating more than one! Remember that classes can inherit from multiple interfaces! Some ideas... Iterable, Test Step, and Collection all sound like separate interfaces to me. (Collection may not even be of much value...) A Test Sequence is a Test Step that contains other Test Steps... sounds like a class that inherits from Iterable, Test Step, and Collection. 🤔

I chuckled, but honestly NI seems to be doing a far worse job of this than Microsoft. Office, the formerly perpetual SaaS product I'm most familiar with, has a lower cost of ownership if you keep up with the latest version now. That doesn't seem to be the case looking at NI's subscription prices. I understand that if you are the type to buy a perpetual license and skip several versions between upgrades that any SaaS model isn't a welcome change, but in my opinion the biggest issue here is the apparent higher cost to stay up to date. I don't know about that. Maybe for someone that buys an entire new license at full cost every X number of years, but for those that kept their SSP up to date it seems like it will more than double the annual cost. The lower startup cost is nice, but irrelevant when we have had our licenses for years, and doesn't make up for the higher long term costs, IMO. I really hope they start talking about renewal discounts at some point, but... who knows? The only benefit I see to this is that it might make the decision to add/drop licenses from our VLA simpler. Now we tend to renew unused licenses every year just so we don't get slammed with the 5x higher cost if we need to rebuy them. You're referring to the Test Workflow bundles? They made it pretty confusing by combining them with the subscription announcement, but those are just new product bundles., not what the entire licensing model is going towards. LabVIEW is still available as a standalone subscription. (The new bundles look interesting, but I'm already on the Automated Test Software Suite and would have to really look at the impact of switching to one of those since I still need to support a lot of things that were/are done with CVI.) Seems to me like there's still a lot of unknowns. Wonder how this will impact the way we manage licenses through our VLM server, if there's any changes to how multi-seat licenses work, etc...

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... 💭

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. 🤣

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?! 🤣

So let's pretend for a moment that Git hasn't taken over the world. Assuming you had a choice, what is your toolchain of choice these days? This is more about total platform than specific VCS implementation. I work with a small team with a badly overdue need for SCC. I find myself in a position to change some things, but, unfortunately, I've spent most of my career here and I'm a bit lacking in experience myself, so I've been looking into available options for a few days. The more I research, the deeper down this rabbit hole I go. Maybe a bit of discussion will help solidify the tools and features I'm looking for, and this seemed a good place for it since "works well with LabVIEW" is a factor. Ramblings from here out... Current state: Madness and chaos.🤪 Desired state: VCS repository management including either on-premises or cloud storage. Project management/issue tracking. CI/CD might be worth exploring? Documentation. A wiki or similar that can document the applications would be great. Due to the industry we are in, user management is sort of important. Ideally I'd like to use SSO and enforce dedicated accounts. Thoughts on possible solutions... Gitlab Seems the most likely Git contender. Bonus points for the fact that it can be self-hosted, which mitigates some of the user management concerns. That said, see drjdpowell's recent thread for the type of discussion that makes me nervous about rolling Git out to an inexperienced team, especially under my not-exactly-expert guidance. Perforce + Jira + Jenkins I believe our software engineering group is using something along these lines. (Not sure what their CI pipeline is.) This loses a some of the appeal of a single application, but I do think I would prefer the idea of a centralized VCS for our situation. SVN + ??? Maybe my Google-fu is off, but I'm not turning up a ton of modern guidance on a full tool chain. Helix Teamhub or Assembla along with Jenkins maybe? (Except I just noticed Assembla says their Jenkins plugin only works with Git... Hmm.) Azure DevOps Can anyone share experience with TFVC or Pipelines? I haven't actually tried any of these tools yet and I'm not sure if it's worth pursuing, but the website is looking... surprisingly not bad. (Although even they seem to be pushing users toward Git.) Also tried Github and Bitbucket. Found myself leaning towards Gitlab over Github, and prefer not to talk about Bitbucket. 🤢

Which goes a long way towards explaining why it's necessary to use the CLI for so much. (And why there isn't actually a real official GUI to begin with.) I'm not saying you are wrong about the CLI being better for some tasks, but this message seems clear enough to me. That said, GitKraken does not seem to show any warnings at all when creating a detached head or navigating away from one. That's a bit disappointing.

Assuming you've tried both, what are some of the features you found useful over Sourcetree? At least at a glance they look pretty similar. GitKraken has the ability to add issues to the sidebar, which is nice. Unfortunately, it only seems to be available for Jira and their own Boards product, and I'm not really planning to use either... probably.