Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 04/29/2020 in all areas

  1. The directions have changed rather radically on many points in response to user feedback. The new component system is completely redesigned twice from customer feedback, and that's another thing I definitely wish LV20xx could backport. They dropped work on interfaces to prioritize scripting because of overwhelming feedback that the scripting tools were higher priority for getting work done in NXG. (Interfaces help some large apps... scripting helped almost every developer either directly or in the tools written for others.) I am not on the NXG team, and yet I can point to decision after decision made directly from customer feedback.
    2 points
  2. Funny you should mention that. LAVA has created a new subforum dedicated to the LabVIEW Community edition, and this thread (among a couple others) have been moved into it. Feel free to post questions comments, and information regarding the community edition there.
    2 points
  3. I thought I'd reply to this thread for posterity. LabVIEW Community Edition is now fully released starting today. Just to summarize: LabVIEW 2020 and NXG 5.0 are part of the release. Includes everything that comes with LabVIEW and NXG Professional Edition, Including App Builder (exe builds). No watermarks or feature restrictions LabVIEW NXG Community Edition includes the LabVIEW NXG Web Module Extending SystemLink Cloud evaluation to 6 months during 2020 LINX toolkit included with install. Supports: Arduino via serial port. Digilent uChip board RasPi and Beaglebone Black as LabVIEW targets via Ethernet Port. You can build/deploy a LVRT application on the above targets (RasPi and Beaglebone Black) and run headless. Exact same process as traditional NI embedded targets etc like cRIO. You can use the LINX toolkit separately if you need it for commercial usage. Just install it on a non-community system. The license for LINX allows this now. License allows usage for anything and everything except: NO Commercial use. If you want to do commercial work, buy a full license for your business or use your company's license. NO College University courses/labs (post-secondary). Academic Site Licenses apply in these cases. Note: Students and teachers in K-12 classrooms can also use LabVIEW Community and LabVIEW NXG Community. License is activated through your ni.com account and lasts for 1-year (renewable each year). Clear definitions are detailed in this link. *Arduino is only serial support (not a target)
    2 points
  4. I went to ask. πŸ™‚ Answer: Yes. ARM V7 Pi or greater. The ARM standard is very hard to keep straight. Various vendors add their own suffix and number to indicate something they extended. I believe the correct statement is that we require that it have ARM architecture of ARMv7 or greater, as shown on the Wikipedia page. There will likely be some corner case that makes it harder to describe. As an example of confusion, the ARM8 is actually an ARMv4, the ARM11 is a V6, the Cortex M3 is a V7, etc.
    1 point
  5. You are unable to activate the community edition with a pro license. It is always activated with a 365-day community license.
    1 point
  6. Well, apart from the bug in LV8 (I think) where moving files around using the file tab would cause them to go into the wrong place on disk I am pretty happy with it! I must be an oddball. Regarding your previous comment about changing the icons in the project in NXG if you had your way... this is a bit scary. If you (yes, we really do put you on a pedestal!) cannot get traction within NI what hope is there for mere mortals like us. Thank you for your comments though (πŸ™), even though I sound a bit negative I genuinely appreciate the time you take to engage. I know a product the size of NXG is the result of the direction and labour for a large number of managers and developers, but I not so secretly wish more NI decision makers would comment here. I know there are other forums I could post this on which might get more involvement from NI, but I feel the general audience here on lavag represents a more accurate spread of developer skills.
    1 point
  7. Because the refactoring is so much better. I would make this change in a heartbeat in LV 20xx if I could do it without breaking compatibility. I would differentiate the icons in the project tree, which NXG chooses not to do. Take a look at LV 2020*... interfaces and classes use the same file extension, and it is way better for refactoring hierarchies. BUT we use distinct icons in the project tree and various other places. You can read the details of this decision in the document I published yesterday about interfaces. I even go into detail about where we deliberately do NOT differentiate for end users. * LV2020 Community Edition became available yesterday. Commercial edition will be later in May... we prioritized the CE release for all the quarantined engineers at home.
    1 point
  8. Official answer from folks at NI: The answer is unfortunately no. We compile our VIs for ARM V7 architecture. Pi Zero is less capable, doesn’t support all instructions.
    1 point
  9. (Thank Michael). I do see this as a slight issue. For now the new LINX is only in the Community Edition, so this one subforum will support both sets of topics. In the future LINX will be its own updated package on the Tools Network, and won't necessarily be part of the Community Edition. That being said I don't think we will be making another subforum just for LINX stuff. I expect the majority of Community Edition topics will be related to LINX, and splitting LINX into Community and Non Community subforums would only split the conversation up. For now the Community Edition subforum has pretty icons showing the Pi, Arduino, and Beagleboard. This will hopefully drive people wanting to make topics on this hardware, into that subforum. Co-mingle away.
    1 point
  10. And this is another thing that makes the jump to NXG less palatable; it is like starting over.
    1 point
  11. Very good thread, keep up the discussion. I just wanted to chime in on one thing with my opinion. I think I understand what you are trying to say with this. But it seems with every version of LabVIEW, NI focused on at least having a couple important bullet points with every release. They likely have to split resources between current and NXG flavors, but just for my own categorization I made a list of features that seem important to me with each release. Looking over the release notes of each version of LabVIEW it is clear that each year lots of work goes into each release. Its just that some years are more packed with features I care about than other. 2020 - Interfaces, 2019 - Maps and Sets, 2018 - CLI and Python support, 2017 - VIMs, 2016 - Channel Wires, 2015 - Right click Framework, 2014 - 64bit support in Linux and Mac, 2013 - Linux RT OS for RT targets, 2012 - Concatenating and conditional tunnels, 2011 - Silver Controls and Asynchronous Call by Reference, 2010 - VI Analyzer and PPLs, 2009 - New Icon editor and Snippet, 8.6 - QuickDrop Fundamentally dataflow concepts don't change, which is a good thing. A LabVIEW developer who started on LabVIEW 8.0 could probably do programming in 2020 just fine. They will discover all kinds of things they never had but it won't be like starting over to them.
    1 point
  12. @Aristos Queue, the problem is the GUI is everything. It does not really matter what is going on under the hood (although all us CG devs really appreciate the regular strides forward). I have yet to speak to another dev who has tried out NXG and is really excited about the majority of changes that have been made. It *really* feels as though very few actual current LabVIEW devs were consulted in the process. I am sure you will say that NI have done studies and had focus groups etc etc (which I totally believe), but to me personally the new changes suck. I have used the Digital Pattern Editor which has the same GUI framework as NXG and the MDI nature of the GUI sucks so much. All the time I need to be able to look at several different things, and MDI makes this an exercise in frustration.
    1 point
  13. That's a good question. I know it's not officially supported in the LINX documentation. I think it has to do with the type of ARM processor used on the zero vs the Pi 4 (for example). I just received a Pi zero, in my hands and will be trying that out soon. So I'll let you know if I find out anything. I remember seeing some info by someone in the community working on this and will post any info i find. Edit: LINX toolkit does not support Pi Zero. If you need a small form factor Pi then look for a device with the same or similar CPU.
    1 point
  14. This IS fixed in LV 2020, but it got left out of the Upgrade Notes*. I have posted details here: https://forums.ni.com/t5/LabVIEW/LV-2020-Upgrade-Note-Altered-rules-for-named-Bundle-and-Unbundle/td-p/4035624 The fix is very healthy for most apps, but we did find one internal-to-NI app that was dependent on the dumb-luck-that-it-sometimes-works behavior. We had to fix that one up by using the Coerce To Value primitive to set a name of the element in the caller. But going forward, such antics should not be necessary... the adaptation rules of named bundle/unbundle are now well-defined. * My mistake -- apparently my tech writers cannot read my mind; I actually have to hit Submit on bug reports, not just leave them in Draft. *chagrin*
    1 point
  15. Version 1.0.0

    622 downloads

    For a personal project, I needed to communicate between my computer and a SPI device slave device. So, I use a FTDI chip FT232h. I have adapted the library MPSSE I2C already available on this website to make it works for SPI. Warning ! VI are not 100% tested (especially Read functions), I provided it as it is.
    1 point
×
×
  • Create New...

Important Information

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