thols

I'm just getting a blank page for the graphs. Anything else that needs to be installed or other requirements?

There were some minor changes in the TSS in that VI between LabVIEW-versions. I just replaced the old TSS in that VI with the new and now it worked. So no broken wires when changing anything in that VI.

For me it has improved but is not quite fixed. I still get broken wires on the calling VI when changing anything in some vims. In fact, I have a VI which I copied from the Debug Log.lvlib:Debug Write.vim in vi.lib and made some changes to. My version breaks when I change anything in it, but the VI.lib-one does not. I have force-recompiled and am now trying to make my VI work like the one in vi.lib, but mine still breaks. I just might recreate it and see where/if it breaks then. I don't know if I am unlucky or if that might happen for others too. When the wires do break, it seems like they auto-heal better than before, when I had to rewire at every broken place, but now its enough to just do something that triggers a compile (I think).

Wiebe has some answers here.

I would suggest using tdms to save the data. Then you don't have to reinvent the wheel, and you can save data for each point and just forget about how it works. The "Save" function you have can instead be an Export-function that exports the tdms-data to a text file. Just some quick thoughts to get you in the right direction. I'm sure you will get more thorough responses soon, but have a look at tdms in the meantime.

Remember when Adobe started with SaaS? Everyone hated it. But since there was no real competitor to Photoshop, many accepted the subscription model in the end. The big difference to LabVIEW is that there ARE real alternatives, FREE alternatives. If NI had successfully taken LabVIEW into a modern era, they would have earned trust. Now, they instead throw this at us after NXG is scrapped and no hope is given to us that any real progress into the future will be made with LabVIEW, and they expect us to pay. (By no hope, I refer to the corporate one-liners about NXG and LabVIEW that scares me and that silence has reigned since). Maybe it is an intended strategy: to start implementing real progress in LabVIEW when we have to subscribe to get it. I really hope not. I hope they listen to the concerns in this thread, since that mirrors the concerns of most of the LabVIEW user base.

Number of VIs means nothing. Design and following SOLID principles is everything. Then you will never have too many or too few VIs or have a hard time finding "the code".

Its just ridiculous and I feel sorry for you. Is it only the manager that demands this button or are there others in the review. A requirement needs a reason to exist. If the manager anyone wants something, ask him them to make a user story of it. A Suggestion: "As a manager, I demand a stop button to close the application, because ... I'm the manager!" or "As a user of the application, I need a button named STOP to close the application, because the X is so hard to find". When you have to describe a reason for it, it will either show how ridiculous it is or a real reason for it will emerge. Anyway, you will get it documented and you can blame others for the bad design :).

But we could have stayed with sexadecimal: HAL 9000 and Sexadecimal: Old School Math

And also, its not silent. Creating a file or writing to a file with too long path name will give you error 6.

Nice! Now make it infinite pac-man style scrolling like in that video

crossposted: https://forums.ni.com/t5/LabVIEW/Print-a-PDF-File/m-p/4158140#M1200089

NXG was terminated, with a few corporate BS sentences, and NI then said they would add all the great stuff to LabVIEW in 2021(+), but nothing of that is in LV2021. I can guess that it is due to a time of turmoil until the resources can be aligned to focus on LabVIEW. But, if NI does not very clearly present the roadmap at the NI Connect event, I will be more concerned. However, I do not agree that no real developments have been made to LV in 10 years. Heck, 10 years ago we didn't even have conditional tunnels. I think the biggest new thing is interfaces, which is a crucial part of the language that has been missing. But then we also have things like channel wires, malleable VIs, and much more. But many other things about LabVIEW feel old, and that's where NXG was supposed to come in... About NI services I don't know since it has been years since I bought hardware or had anything else to do with them. I cannot see any competitor to the productivity that is possible with LabVIEW compared to any other language. And the visual representation of parallel programming. So I hope NI makes the right decisions for LabVIEW.

Some answers here:

I used to use EyeStudio some years back. It worked quite well for finding buttons, clicking, entering text, evaluating visual results. https://eyeautomate.com/eyestudio/. At the time, it was free, but now its not, and quite expensive. So I have no idea if it is worth it now or how the product has evolved. Perhaps its great now or perhaps its an old unmaintained product they are trying to sell. But I wish I had this type of product now.

How could I miss that... I'm sorry for that.

If you will be using a singleton, please have a look at this: https://forums.ni.com/t5/Bay-Area-LabVIEW-User-Group/LabVIEW-Design-Patterns-Mini-Series-Singleton-by-Dmitry/td-p/3527270 The NI implementation is not very good. In the zip-file in the link above, you will find some others and a ppt for a presentation that goes through some others and points out the best one.

Thanks Darren, I didn't know that. Maybe because that is also not in the help.

Very interesting. Error rings are so large I am tempted to put them in a sub-VI just for that reason. And if they also always should have a case structure around them... I agree that it should be documented, and I had a look in the help to see what it said and found that LV2020 displays: However, LV2019 works. Is it only me? (its only on the error ring, everything else in the help seems to work)

Are you sure you really want to share the class instance? Often, really what you want to do is send messages between the loops with info of change.

I know there was a discussion on the NI forum about execution highlighting with a similar issue. A VI "later" on the error wire was shown to be executed before a VI "earlier" on the wire. In reality, that probably didn't happen, but I guess the reason can be the same (probably something like what drjdpowell is saying). But, I know that it was answered in detail from someone from NI. Unfortunately I cannot for my life find the thread. I think it was some tcp/ip VIs or perhaps a save to text file involved.

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!

This has been filed as CAR 455443 see this thread: http://forums.ni.com/t5/LabVIEW/Chart-Redraw-Issue-with-Multiple-Plots/m-p/2755616/highlight/true#M812948

Hi, I hope this is the right place to post this. Please take a look at the attached VI to see an issue I'm having. If you have any ideas, please share. I managed to find a partial workaround to this issue, but the behaviour looks odd and bug-like, and sweep mode still looks very bad. Background: I wanted to use charts to create the most efficient way of displaying data, since I need to display several plots with high update frequencies but of varying sampling frequencies. Before plotting the data, it is already decimated so I will only plot as many points as I have pixels available. Scenario: Plot 2 waveforms periodically to a chart (array of wfms for each period). Use scope or sweep mode. Strip mode seems to work a little bit better. Issues: * If one plot in a wfm-array is empty for an update, the other plot will not redraw properly. It will redraw when the second plot has data but the first plot will be incorrectly drawn, parts of the data/points will be missing. * Sweep mode will leave lots of red lines and erase some of the data it is passing. Attempted workarounds: * ForceRedraw: Does nothing. Am I using it wrong? * Defer FP: Does nothing. * Remove empty wfms at end of wfm array (for one update/iteration): - draws first plot correctly - does not draw line on second plot - If window is resized, data is cleared, only the last section of the plot is visible. Seems like earlier data in plot is "forgotten". - Autoscaling will not work. It will autoscales on the last section of data. * Increase history lenght: Does nothing. * Put an indicator in front of the graph: Screws up redraw until window is resized. Graph update gets very slow. I used this trick once on a flickering text indicator and placed an invisible object in front of it, which helped in that situation. * Resize the window: Works! Not a very convenient workaround. Even sweep mode looks ok. * Use XY-graph: My goal was to make the most efficient way of displaying data with relatively high update rates. I Used an XY, but when I had a few of those graphs, the cpu load was very high, and I verified that it was the actual writing to the graph indicator that took all cpu. I tried updating less frequently and I already have the data decimated before sending it to the graph, but the cpu was still too high. Replacing with chart work like a miracle with almost no cpu-load * If a wfm is empty for an iteration, plot the last plotted point again but with a very small positive time-offset (I think it didn't work well plotting with the same time again): graph redraws ok in scope mode but not in sweep mode. But If I plot that last point again and again, the other plot will eventually cause the x-scale to autoset, and I will need to keep track of the scale and not re-plot that lone point if it falls out of the x-scale. It starts to get tricky here and I have not solved all issues that can arise here yet, but this is the workaround I'm using now. And For charts, I haven't found a way to disable that automatic scale update (is there a way?). I have made and test VI for testing these issues (attached), where different workarounds can be tested by activating different buttons. Just run it in the default setting to run it without workarounds activated and it should show the refresh issue quite clearly. I have tested this on 2 PCs and on LabVIEW 2013, 2012, 2010 and 8.6. Any ideas? Chart Redraw issue - LV2013.vi Chart Redraw issue LV 2010.vi

Thanks for your help. I will try the fix.