Jump to content

Michael Aivaliotis

Administrators
  • Posts

    6,196
  • Joined

  • Last visited

  • Days Won

    103

Posts posted by Michael Aivaliotis

  1. Don't forget cRIO has RT so you can implement a lot of programming on the RT side for various scenarios. As a master of the LabVIEW language and NI hardware. I would prefer a platform that allows me to use the language I already know and love. I can provide a PC application that implements anything the customer desires. then I can configure a cRIO and implement ECAT, serial, Devicenet, DAQ, DIO or whatever they want using the same language and skills. If NI does not support the desired hardware i need to talk to, they have many other options like DLL calls and other ways of interfacing that I still have not found a specific limitation that I was not able to workaround to get the job done and still make the customer happy. Yes, there are other languages and opportunities. Anyone who has worked with ECAT has heard of Beckhoff. They pretty much came up with the standard and are pushing it across the industrial world. It's just another communications standard. NI and LabVIEW are at a whole other level above and beyond that.

    Can NI improve the tools they provide for ECAT, DeviceNET and others? Yes! There are some features of ECAT that the NI tools simply cannot access or configure. A lot of what NI implements is the basics of the industry standard. They rarely go above and beyond unless customers push for it. They have a checklist of industry compatibilities they try to maintain so the marketing looks good. So they still can do better.

    Recently they started adopting TSN which is very powerful and allows synchronized DAQ across cRIOs and cDAQ chassis. Technology is constantly evolving and I commend NI for always trying to keep LabVIEW on the forefront by providing hardware that keeps up with todays requirements.

    So as you can obviously tell from this post, I am not going to convert to TwinCat any time soon. However competition is always healthy and keeps companies like NI on their toes to make sure they are always providing value to their customers so they don't start wandering off to other solutions.

  2. On 3/2/2020 at 1:23 PM, Aristos Queue said:

    Figured someone over here might be interested... over the weekend, I built a new right-click menu item plugin for editing set controls and constants. The UI is bad, but it works; if anyone wants to work on the UI, you're welcome to do so. Building a map editor would follow the same pattern as the set editor.

    https://forums.ni.com/t5/LabVIEW-Shortcut-Menu-Plug-Ins/Edit-A-Set-Value-llb/ta-p/4020190

    What I would like to see is a way to minimize the map or set constant by double-clicking on it. Like you can do with cluster constants. Hand editing Maps is such a small use-case but useful for some I guess. You usually work with these things programmatically. Thanks for the tool.

  3. I'm noticing that when I probe LV class wires in LabVIEW 2019 SP1, it won't display any data on the probe. In fact it appears as if that part of the code never executed. I just can't figure out how to reproduce it. I'm wondering if anyone else has noticed this behavior. I can clearly see that I have multiple probes on one diagram and the probe attached to a class wired shows "Not Executed" in the probe watch window, even though "Retain Wire Values" is enabled. LabVIEW restart does not fix it.

     

  4. 7 hours ago, Rolf Kalbermatter said:

    I think it is a little far fetched to request full VIPM feature completeness from any new package management system.

    It was not developed in a bubble. There was already a close relationship between the VIPM team and NI. So they knew the requirements and the need. It's been over 5 years since the release of NIPM, so not much movement however...

    7 hours ago, Rolf Kalbermatter said:

    But NIPM was more an NI attempt to do something along the lines of MSI than VIPM despite their naming choice and marketing hype.

    That might have been the first step, but hardly the long-term plan. In reality, I think the main reason for lack of development on NIPM is that people got shuffled around and new management came in and the original development plans for NIPM got put on a shelf. I can tell you that NI had the goal of full VIPM replacement.

    There is much churn internally at NI on where to take NIPM next. They are back to wanting to add features to facilitate better reuse library installation for current LabVIEW (how to achieve this is not clear). For sure however, this is the clear case with NXG.

    I suggest you watch this video: 

     

    • Thanks 1
  5. On 12/4/2019 at 4:21 AM, ShaunR said:

    About time too :ph34r: I never understood why they went for the JKI one in the first place. I moaned like hell when they first said that the JKI one was to be NIs preferred solution. So I guess they are only about 7 years late.

    NI caused this problem themselves. NIPM should have provided all the features of VIPM from the start and then added GPM features. Lack of investment. Now they're playing catchup, but technology is moving on.

    • Like 1
  6. On 12/2/2019 at 11:22 PM, JamesMc86 said:

    Yeah that would be cool but it is a front for different package technologies i.e. npm, nuget

    Well, it seems to be more of a back, than a front. GitHub is becoming the package repo. GitHub is not making a front end manager.

    On 12/2/2019 at 11:22 PM, JamesMc86 said:

    It would involve persuading GitHub to run a LabVIEW package server - maybe not impossible - but probably not high up there list.

    Agree this would be hard or impossible to achieve.

    On 12/2/2019 at 11:22 PM, JamesMc86 said:

    Many package managers can just read GitHub repos as a package though - so rather than just entering a name you enter a path to GitHub - that seems more achievable if GPM takes off

    Ok, ya this is a more attainable goal and a possible path forward. But GPM is not widely adopted and has limitations.

    On 12/3/2019 at 1:59 AM, ShaunR said:

    Aren't all the addon installers (VIPM, GM and the one I was playing with) about to be made reduntant with the NI Installer now it supports addons?

    NIPM will win by default, because it is made and fully supported by NI. However, it has a long way to go to support all the features we (as developers) need. It's a dumb installer and has no smarts related to the LabVIEW environment. For example, you cannot target LabVIEW by version and cannot allow up compiling of code. NI is investing resources to make it better over time and we need to keep pushing them to add features we need. However, NI moves like a big company does, very slow. There are currently 3 package formats: VIPM, NIPM and GPM. It's a mess, and by reading this thread, it seems people are open to ditching packages all together.

  7. GPM extracts code into your project, BTW.

    VIPM, NIPM and GPM provide built products of reusable code, among other things. I believe what you are saying is that you consider existing, cloud-based source code control tools such as GIT as a viable option for reusable code distribution. This shouldn't be limited to packaged stuff.

    • Like 1
  8. On 11/5/2019 at 5:46 PM, JKSH said:

    Files that don't have revisions don't need to be commited into the repository itself.

    I agree. I don't store those type of file in the repo for a while now. My specific comment was about how to transition from one large files extension in Mercurial to Git.

    I use Bitbucket Downloads. However, I'm finding that different file sharing tools can be useful for different use-cases. There's really no one-size fits all.

  9. On 10/21/2019 at 5:41 PM, Aristos Queue said:

    Unsigned EXEs are a major threat vector, and the IOT threat just keeps increasing. The world can’t afford to keep running arbitrary code much longer, in my opinion.

    I sign all my built EXEs, for all my customers. It's trivial to do and doesn't cost much. This also allows me to know if the application that I'm asked to support was built by my company or the customer did the rebuild themselves.

  10. On 10/26/2019 at 8:44 AM, Francois Normandin said:

    I've started migrating the open source code I still have on bitbucket (Mercurial-based repos) to Github.

    What's the reason for moving to Github?

    I was using Kiln to host my code, which used Mercurial. I switched to Bitbucket with Git. I had to migrate many projects from Mercurial to Git. I did the migration using the HG-GIT extension: https://hg-git.github.io

    The main problem I encountered was using the "large files" Mercurial extension. The automatic import tools provided by GitHub and others don't like that extension and barf. Otherwise you can use the web migration tool provided by GitHub. My workaround to the large files problem was to accept the fact that I will lose the revision history on those files. Not a huge deal, since most large files I had were installers and binaries that didn't have revisions per say. So after the migration I did a diff on the project folder, identified the large files, which were missing from the new Git project and just copied them over and pushed them up to the Git repo. Don't forget that the core GIT functionality is the same regardless of service provider. So let's say you found a way to import your repo to GitHub, you can easily turn-around and move it to GitLab, bitbucket or whatever. You're not locked-in. But it might be an issue if you are using an extension that only one service provider supports.

    The future is GIT. I made the jump over a year ago and haven't looked back. The service provider you choose should give you the tools you need to do your job. The reason I picked Bitbucket was because I liked and used all the other products that Atlassian provides, JIRA, Confluence etc. The tools from Github are a bit weak for my business. I also like companies that continuously improve and invest in their products, among other things. Github seems to be the popular choice for open-source, since that's how it got started. Now that Microsoft owns them, perhaps they don't have to worry about generating revenue (don't know if it's good or bad). But I don't see features that compare to what Atlassian offers.

    • Like 1
  11. Published 10/29/2019 See here:

    https://finance.yahoo.com/news/national-instruments-announces-plan-ceo-200200768.html

    AUSTIN, Texas--(BUSINESS WIRE)--

    NI (NATI) today announced that Alex Davern will step down as Chief Executive Officer of NI, effective January 31, 2020. The NI Board of Directors has appointed current President and COO, Eric Starkloff, as NI President and CEO, effective February 1, 2020. Davern will take up a teaching position at the University of Texas McCombs School of Business starting in the Fall of 2020. Davern will remain on staff at NI as strategic advisor to the CEO through May and will continue to serve on the NI Board of Directors.

    Board Chairman Michael McGrath said, “The board appointed Alex as CEO in 2016 to lead the transition from our founder, Dr. James Truchard. Over the past three years, he led NI and shaped a new core strategic vision, expanded our strategy to provide more complete systems for our customers, aligned the company to focus on growth industries and delivered record results. The board’s intention, after a successful transition from the founder, was to appoint the next CEO to lead the company to achieve this new vision. After considering alternatives, we unanimously selected Eric as our next CEO to lead NI into a very promising future. Alex will leave NI stronger, with experienced leaders and a clear strategy. We are excited to have Eric as our new leader as he has proven to the board that he is the most qualified person to take NI to the next level.”

    Davern, CEO said, “I have thoroughly enjoyed being part of NI’s incredible success since joining in 1994, one year before the IPO, and I am confident the company is well positioned to deliver on its growth strategy. I am proud of the progress our employees made in significantly improving our operating results and we have developed a team of highly experienced leaders. I have worked with Eric for many years and have great confidence that as CEO, he will continue to take NI forward to realize the company’s long-term potential.”

    Starkloff, President and COO said, “It has been an honor to work alongside Alex for the past 22 years and I want to thank him for his mentorship and his significant contributions to NI. I am confident in our strategy and our team, and I believe we are in a position of strength to deliver on our goals. I look forward to taking on the responsibility of CEO, as we connect our deep engineering experience and software-connected systems with our incredible customers who are taking on the complex challenges shaping humanity.”

    This leadership transition will be discussed during the Q3 2019 earnings call today at 4:00 p.m. CDT.

  12. 1 hour ago, Aristos Queue said:

    I've got an 80-slide PPTX on actors as first-class citizens: no queue management, no classes for messages but retaining type safety, no weird error codes, easy handling of parallel loops without custom stop signals, direct execution testing, debug monitoring... but I just don't see it happening in LabVIEW.

    Does this mean the Actor Framework functionality will now be represented graphically in NXG, as apposed to a list of hundreds of class VIs in a tree in the project?

    • Like 1
  13. Just watched this presentation by Richard Feldman called: Why Isn't Functional Programming the Norm.

    As I was watching this, many ideas came to mind about how LabVIEW stacks up in various areas of the presentation. I wanted to hear what the community thinks about this. We can all agree that LabVIEW is NOT a popular language (as defined in the video) and it probably will not end up on any presentation as the one in this video (I desire for this to change though). However, I think the discussion in the community about FP vs OO is currently taking place. I know people that do not use OO in LabVIEW and many that swear by it. So I think this is a fitting discussion. However, the core question of the presentation as put by Richard is "Does OO features make a language popular?" His argument is NO.

    I don't think OO by itself will make LabVIEW popular, but where does LabVIEW end up on the reasons for popularity as presented? Or better yet, what can make LabVIEW more popular? Is that something that anyone should care about?

  14. I can see why you asked that question. It seemed to come out of left field. The intent is not to fork OpenG or create a separate development branch. The intent is to facilitate community involvement and incorporate some of the ideas floating around here on LAVA into new future builds of OpenG. JKI has taken some of the libraries, not most. I counted 5 on JKI and there are around 23 that I found and migrated. Granted, some of them could possibly be merged into new or cleaned up. However, this can be decided by the community.

    I think having a location that the OpenG community can call their own is important. Including documentation on how to contribute and providing an open, inclusive, transparent development and deploy process is part of it. Having them on GCentral was my idea. I didn't get official approval from GCentral. I've since moved (and renamed) the repos from where I had them to a dedicated OpenG organization. This way it would truly be separate. If you want me to add you as a maintainer, let me know. If there are any contributions to OpenG that JKI has made on the JKI branch, we should merge them into the new repos.

    New location:

  15. 5 minutes ago, Jim Kring said:

    I'm really happy to see this renewed interest in LabVIEW and OpenG, since I've been doing a lot of the maintenance work, myself, and would love more participation in both development/testing and documentation/examples.

    I'm glad to hear that you are welcoming to this. I think this initiative and the positive response shows that the community is willing to take on some of these tasks and responsibilities as long as there's an open and inclusive process in place.

    As a starter, it would be great to revive the openg.org domain which has been dead for many years and at least point it to the LAVA OpenG root forums,. That's where it was pointing to before as indicated by this post. In the future, it could point to a GitHub landing page.

  16. 46 minutes ago, Fab said:

    Semi related issue with OpenG URLs

    One of my customers has added to his application's About page that the app uses OpenG code. He was including the old url http://openg.org, what URL should he include now?

    Thanks,

    Fab

    It seems like OpenG needs a landing page. Perhaps if we use GitHub Pages for the GitHub repos, as proposed here. This could be the new URL to include in licensing.

    • Like 1
  17. 9 minutes ago, jacobson said:

    I noticed all of the repos have their own ToDo.txt. Many are empty but for those that are not, you might want to create an issue for each item.

    I don't know if you can create a wiki for an organization but I would also want to be able to find information on how to contribute and some specifics like what LabVIEW version is being used for development, expectations on testing, and build/release process.

    Good points. You can't create a wiki for an organization. I've setup an OpenG team, but even there, no wiki support. Limitations... However, each repo has its own wiki. Which is good for content related to that specific repo. It's possible now with separate repos, to have each one have it's own LV version and build/release process if needed. However, if not, then each wiki can simply have a link to some global page that covers the overarching policies. This could be on LAVA, but I think the LabVIEW Wiki could provide support here. There could be a single page there covering everything, which is also community editable.

    Creating issues can be done by anyone. So if you want to do that, go for it. If they are invalid, they can be closed later. We should also search here son LAVA and create issues for stuff reported by people in the past.

×
×
  • Create New...

Important Information

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