Jump to content

NXG, I am trying to love you but you are making it so difficult


Recommended Posts

Thanks for the info-labview quote, the decline of Silverlight and NI's inability to pivot is a shame.  Especially when posts by NI on the forums hinted that HTML5 features would replace Silverlight tools.  I interpreted that as being transparent to the users of their systems.  Like update to the newest version of MAX and all the tools that did use Silverlight have been replaced with their HTML5 equivalent tools.  We are 5 years after that post, and it is a shame that remote front panels still use a technology so unsupported.

Also you do know those last two links are April fools jokes right?

Link to comment
1 hour ago, hooovahh said:

Thanks for the info-labview quote, the decline of Silverlight and NI's inability to pivot is a shame.  Especially when posts by NI on the forums hinted that HTML5 features would replace Silverlight tools.  I interpreted that as being transparent to the users of their systems.  Like update to the newest version of MAX and all the tools that did use Silverlight have been replaced with their HTML5 equivalent tools.  We are 5 years after that post, and it is a shame that remote front panels still use a technology so unsupported.

Also you do know those last two links are April fools jokes right?

Yes but the last two links are what make this tragically ironic...

Link to comment
1 hour ago, hooovahh said:

Also you do know those last two links are April fools jokes right?

Luckily the context of the emails they were embedded in made it clear and pointed this out to the overly graphically oriented. But thanks for checking.

Link to comment

For those of you not using any of their remote systems (rt pxi, crio, or slsc): silverlight is still alive and well technically extant in the WIF.

you have to use internet explorer because no other browser supports the silverlight plugin, but thats still better in many cases than trying to find a remote system in MAX.

Link to comment
On 5/11/2020 at 8:34 AM, JeffP said:

I would love to set up some 1x1 interviews with those of you who are interested so I can better understand how you are using LabVIEW today. I will start a different thread about that.

I really really hope that everyone who has chimed in with significant feedback on this thread to reach out to get one in a 1x1 session with NI - lots of people have complained that NI doesn't solicit our feedback: this is an example of NI specifically requesting it, so let's not waste the opportunity.

Link to comment
1 hour ago, crelf said:

I really really hope that everyone who has chimed in with significant feedback on this thread to reach out to get one in a 1x1 session with NI - lots of people have complained that NI doesn't solicit our feedback: this is an example of NI specifically requesting it, so let's not waste the opportunity.

A pack of hungry wolves could not hold me back. I am just waiting for the thread Jeff said he was going to make.

  • Like 2
Link to comment

I want to give feedback, but its just so much. I did give feedback on 2.0 on a long list of issues on the beta forum but it was frustrating then to not know if there was any reason at all to give feedback. I don't recall even receiving anything that the feedback was received or anyone saying that they read the forum posts. I used 4.0 on a new small/tiny project but gave up since some simple things were not there yet (or who knows, maybe wont be) and I quickly had a new long list of issues but did not have time to document them, and I didn't know if there was any meaning at all in doing that.

It would make it much easier for you and us if the development was more transparent so we could see per issue what is intended to work now, what will be implemented and how and the design decisions per feature. Now, this kind of information occasionally comes from different people in different channels (forums, blogs, summits, ...), which makes it easy to not know the state of NXG when you start exploring NXG x.x and thus get frustrated. If we could have access to this information we would know what to not get frustrated about and why and what you are open for feedback on, then we could help by focusing on giving feedback where it actually is helpful to you and then you wouldn't need to respond to all this frustration in different forums/channels. Yes, we all want NXG to be great, so let us help!

  • Like 1
Link to comment
12 minutes ago, thols said:

I want to give feedback, but its just so much. I did give feedback on 2.0 on a long list of issues on the beta forum but it was frustrating then to not know if there was any reason at all to give feedback. I don't recall even receiving anything that the feedback was received or anyone saying that they read the forum posts. I used 4.0 on a new small/tiny project but gave up since some simple things were not there yet (or who knows, maybe wont be) and I quickly had a new long list of issues but did not have time to document them, and I didn't know if there was any meaning at all in doing that.

I feel your pain. I did a long private session about two years ago with some people inside NI where I showed them my current workflow and how I did not think it was going to work in NXG. Nothing at all changed as a result of that feedback.

Link to comment
  • 2 weeks later...
  • 2 weeks later...

So where is a good forum for discussing NXG?  Here on LAVA?  I'm not one who likes short 1 on 1 private talks nor am I in to "workflows".  But I could make lots of feedback on NXG if I have time to craft posts. 

Right now, for example, I'm trying to make sense of the NXG Project created by the conversion tool from my JSONtext library.  I'm completely stuck at not knowing what a "Link" is, and how I can get the JSONtext.gcomp to not be a Link.  As a "link", namespaces don't seem to work (I can create a namespace, but not add anything to it) and I suspect this is because a "link" is some kind of leser membership in my project.  Maybe.  Who knows.  I cannot find anything in the NXG help on what a "Link" is, or how to open up the JSONtext.gcomp as not a link.  

1178988486_2020-06-0214_44_46-JSONtext_-LabVIEWNXG5.0.0Community.png.bc3a789a2c19e70b990c0544dc06cc43.png

In general, I'm experiencing a lot of "blank stare" moments in trying to figure out this software.  Can it really be designed for new users and non-programmers?

 

 

 

 

 

Link to comment
1 hour ago, drjdpowell said:

I'm completely stuck at not knowing what a "Link" is, and how I can get the JSONtext.gcomp to not be a Link.  As a "link", namespaces don't seem to work (I can create a namespace, but not add anything to it) and I suspect this is because a "link" is some kind of leser membership in my project.  Maybe.  Who knows.  I cannot find anything in the NXG help on what a "Link" is, or how to open up the JSONtext.gcomp as not a link.  

I don't know if there is any documentation for this, but a link points to a resource external to your project. You can create your own links by adding files that are not located in your project folder.

It looks like your component is located on a shared network location?
Maybe the conversion tool uses UNC paths and the project expects mapped paths?

Maybe you can re-add those files to get it to work.

Edited by LogMAN
Not sure if that is a network location or just Mac
Link to comment
1 hour ago, drjdpowell said:

In general, I'm experiencing a lot of "blank stare" moments in trying to figure out this software.  Can it really be designed for new users and non-programmers?

Welcome to the jungle!

New users wouldn't have to convert legacy code, so this is probably not an issue.

Link to comment
7 hours ago, drjdpowell said:

So where is a good forum for discussing NXG?  Here on LAVA?  I'm not one who likes short 1 on 1 private talks nor am I in to "workflows".  But I could make lots of feedback on NXG if I have time to craft posts. 

Let me get back to you on this - we are internally discussing some options for improving this - as you noted the activity on the existing beta forum is pretty limited. We want a forum that everyone has access to where we can have collaborative discussions on NXG. The specifics are still being hashed out but I will update when I have more information. 

Regarding your question about Links - LogMAN's explanation is correct - files under Links are non-addon dependencies located outside your project folder on disk, for example if you use a subVI that is saved elsewhere. This should be uncommon for projects developed from scratch in NXG - it is more common in converted projects - especially if you convert multiple projects with shared dependencies at the same time. It is an aspect of the conversion process that we are looking to improve - at this time I would not recommend converting multiple projects with shared dependencies at the same time - it works but may lead to confusing results. 

Link to comment
14 hours ago, JeffP said:

Regarding your question about Links - LogMAN's explanation is correct - files under Links are non-addon dependencies located outside your project folder on disk, for example if you use a subVI that is saved elsewhere. This should be uncommon for projects developed from scratch in NXG - it is more common in converted projects - especially if you convert multiple projects with shared dependencies at the same time. It is an aspect of the conversion process that we are looking to improve - at this time I would not recommend converting multiple projects with shared dependencies at the same time - it works but may lead to confusing results. 

JSONtext was a single project, but for some reason the conversion tool created two projects: "JSONtext" and "LooseFiles_JSONtext for NXG", plus a "Shared" folder, which actually held the JSONtext.gcomp.

I fixd the issue by:

  1. closing NXG
  2. moving the floder with all the JSONtext files into the same "JSONtext" folder as teh JSONtext project
  3. reopening the JSONtext project
  4. "Excluding" (bad terminology?) the now-broken JSONtext.gcomp "link" (was annoyed there was no way to fix the link by pointing to the new location)
  5. "Add file.." to add JSONtext.gcomp from new location (was pleasently surprised that this then fixed all dependencies without LabVIEW CGs endless dialogs)

 

Link to comment

I may be incorrect in my assumptions here - but when you converted the single project how did you specify which files to convert in the conversion utility? The logic for creating multiple NXG projects works something like this:

  1. If you just selected a lvproj file its easy, we load the project, all files in it, and their dependencies. Then we determine which files will be converted and put them all in the same NXG project.
  2. Similarly, if you just select VIs, we load the VIs and their their dependencies, determine which files will be converted, and put them all in the same NXG project.
  3. Things get more complicated if you select some combination of VIs and a lvproj, or multiple lvproj files (or a folder with some combination). 
    1. We load everything and find all dependencies. 
    2. We create a NXG project for each lvproj file. If there are additional files which are not part of any of the lvproj files we create an additional LooseFiles project for those files.
    3. If files are shared between multiple projects, we create a Shared folder next to the projects which contains the shared files. This is because we can't preserve your file disk heirarchy - NXG requires the project and disk hierarchy match, so the only alternative would be to choose one of the projects to be the 'owner' and that didn't seem correct. Unfortunately that leads to these shared files showing up under the 'Links' section of each project.

In an ideal case these shared dependencies would be converted into a component in their own project and built into a gll that is shared between the projects, or some similar process. Directly sharing source VIs on disk between projects is not the recommended way of sharing code in NXG.

In your case - I have seen this happen in the past where a folder containing a project is converted and some files are not detected to be part of that project so they are put in another project. Autopopulating folders can also make this worse in some cases. 

In general this is a part of the conversion utility that I would like to simplify because it can be really confusing, it is just not a top priority at the moment.

Link to comment

I think you need to give the User a choice at step 2 of what to do with the loose files.  In my case they are just deprecated VIs that never got deleted (deleting files in Current Gen is very inconvenient).  Step 3 need a choice too, as adding the shared files to one of the projects will usually be the right choice.

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.

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

×
×
  • Create New...

Important Information

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