hooovahh

Also around this era was the Web UI Builder which has other elements now seen in NXG.

I too had one. The day of the meeting I installed NXG and went though all the old issues I had with it years ago and tried evaluating what things have changed and what ones haven't. I made a bunch of notes on things and mentioned them in the meeting. I then have started formalizing these lists and have been giving feedback to NI, most of the time linking back to where the complaints were first mentioned.

Hi all, friendly LAVA moderator here. I'd just like to gently remind everyone we are all human, and are at times emotional, and at times frustrated with colleges we interact with. Lets all take a deep breath and try to continue to give criticism in a form that will be most helpful. I know I've at times flown off the handle online, especially on the subject of NXG. I personally don't think I've shared code between projects for anything real project anytime recently. But I can remember times that I did it and didn't have any real problem. Likely because I was mindful of what effected what. X do you have some recent examples of code you shared between projects? What made you make that decision, and why were the other options seen as less desirable? Also it sounds like this isn't explicitly forbidden in NXG.

Well if you do get something working, please post any code you feel comfortable sharing. Obviously others might be interested in the protocol the UPS uses.

I do use Inno setup, and I am familiar with some of these options. But I've never really tested the cancel functionality and what it might do or how to clean up. Sorry.

I do remember discovering the Window Monitor and Ned windows semi-independently. Someone posted a way to show the Heap Peak window, with CTRL+Shift+D+H and I thought that was likely for Debug, and Heap. So why not try D+<every letter combination>. At the time I think only H, N, and W did anything. Most of the time I care to find a window's HWND I use a private function which lets me do what I want. I have never had a need for knowing the HWND of any of the other windows so that Window Monitor wasn't all that useful for me. The Ned windows unlocked more useful information, but just for curiosity sake really. Also I find it really interesting that Heap Peak has been in LabVIEW for such a long time and with seemly no or little updates to it.

I do believe the baud is correct at 2400. In another thread I showed OP some code I wrote here which interfaces with a Tripp Lite UPS, which worked on the ones I was using.

As I mentioned in that thread tunnels out of a loop, and case select terminals are the major issues I see with it. I'd estimate I probably have wanted to create a constant, control, or indicators from those conditions probably 5% of the time. The other 95% I want to change the tunnel options or make that datatype the selector input. I was told in the beta I was wrong, and that users want to create one of those things more than any other thing, in all situations. I mentioned this in that thread and Darren at least acknowledged that in some cases the developer likely doesn't want to create anything but being consistent is important. If being consistent is important then I'd say that is a vote to get rid of Auto-tool. Hover here to have this tool...no not like that click here first. Or just tab and get what I want. I'm still primarily in 2018 but consistently have issues in 2020.

You'd have to ask NI, but I suspect they don't want to have to support users calling the functions directly, and instead they only want to support the users calling the VIs that they create, exposing the functions. It gives them tighter control, and likely means less unit testing if they know a function will only ever be called a certain way. For instance the Write PNG File has no compression. The function internally does have a compression input, and setting it does create a more compressed PNG image. But it is possible that compression isn't tested or supported on all platforms. So they can either support compression on some targets and not others, either making duplicate VIs, or erroring out on those targets. Or they just take that ability away. Well that or someone just didn't realize that input would be requested and left it off the connector pane.

Yes I'm sure. I just opened the block diagram of the Add File to Zip, and Unzip functions in 2020 and I believe they are unchanged from 2018 at least calling functions from within LabVIEW. NI is calling system exec to touch the zip file, setting the file attribute that I believe is the file creation date, of the file that was uncompressed. Obviously the date will be right now since the file was just extracted. After it is done being uncompressed NI wants to touch the file, so it has the creation date that is stored for that file within the zip. This can be seen in the unpassword protected VI Set Unzip File Date Time. The VIM I linked to earlier shows how these call library nodes create the zip.

It is a series of call library nodes. I think if it were .NET NI would have a hard time getting it to run on other targets like Linux, Pharlap, VXWorks, and issues with ARM/x86. In the two examples I linked to I show how these are called to do compression with an array of bytes by calling them. Still a pure G implementation would be nice, just looking over the source and documentation is quite daunting based on my lack of understanding compression techniques, but those links do help.

That's good. I just know that for other things it can be more selective on the compression type. I wanted to make a way to create a PNG file outside of NI's native way due to some limitations. I read up on the documentation and it honestly wasn't all that complicated. The only issue is that part of the file is compressed with zlib. Using OpenG it made good normal PNGs file that could be viewed in any image viewer. But using LabVIEW's native API for compression created an image that only some image viewers would display, chrome was not one of them. I also made a BLF file API. This is a logging file format for raw automotive CAN data. It also has chunks of data that are compressed. Using NI's native method created a file that Vector tools couldn't open and I also needed OpenG.

I'm fairly certain the purpose is to query the UPS status. The API allows for reading the input voltage and frequency, the output voltage and frequency, the battery voltage, state of charge as a percentage, battery temperature, and if it is on battery power or not. These UPSs have a USB port but when plugged into a Windows computer it is not recognized as a battery device like you'd typically see on a laptop. Otherwise the normal Windows API can query the battery status.

The native LV functions don't implement the inflate/deflate from zlib but instead a different standard (pkzip?). Also if you do want to compress a stream of bytes using the native zip feature you don't need to create the initial temporary file. You can compress data using an array of bytes saving it to a zip. I made a VIM and posted it here which supports an array of bytes, in memory TDMS, DVRs, and a couple other data types.

If you can't get a dedicated IP address, one thing you can do is have your software query the outside world and find out what its public IP address is, and then update some location that you can get access to. This is essentially dynamic DNS. I have a domain I registered and have a website that I host. I have the computer that serves the web page update its own DNS every couple of hours because my IP address may change. Another option might be to do something like write a text file to Dropbox. Then when you want to connect to it read the dropbox file and that will tell you the public IP. Then the ports as JKSH mentioned will reference each device.

There is something wrong with that control for sure. It isn't disabled, and the other thing I checked was if you customize the control I thought maybe there were elements over top of the scroll bar but that isn't it either. If you manually turn off and then on the scroll bars it works again but only until you call the property node that sets them on again. One fix I found was that after you enable the vertical scroll bar, disable it, and then enable it again. Another thing that worked was I replaced the whole graph with another style and it was fine so it is something with that control. I did all of this in 2020 since I don't have 2019 on this machine so I'm not sure if it behaves differently there.

I was a TI guy, but likely just because it was what I was exposed to in High School. There my mom bought me TI-82. It worked well up until partial derivatives and systems of equations in college. I wrote a program to do this manually but due to precision of the calculation only worked on simple problems and the values wouldn't be right for complicated ones. So I bought a TI-89 Titanium used for $100. Basically the most powerful calculator they'd allow. Had it all through my EE degree. Even used it to hack my PS3 years later. Then I lent it to a family member for their college and haven't seen it since. Not that I've really needed it since. Oh and look at that new today they are still over $100. I once asking to use a TI emulator on my laptop in class because I was too cheap to buy a new one.

Yup. Just make sure you have the null of the cable correct. Sometimes the manufacturer puts the null-ness in the device so a straight through cable should be used, some times they don't I can't remember what it is. Some example code I posted here should get you started.

So yeah I've struggled this same issue with TRIPP-Lite UPSs. Mine luckily had a DB-9 so after investigating a bunch of time into getting a proof of concept going on the USB side, I decided to just drop it and go with the simple COM port. NI's official method of talking to HID devices involves creating an INF driver for it, and then using that in Windows. The problem is Windows 10 is quite restrictive when it comes to unsigned drivers, and you need to do some extra work just to install the driver, so that the hardware can be shown in MAX, so that you can start to communicate with it using raw VISA. This isn't that big of a deal for one, but multiply this manual process by the 20+ machines I'd want to do this on and it is an issue. Here is the process NI suggests. At the time I did find some DLLs posted on the NI forums that wrapped communicating to HID devices so that this wasn't needed. It was incomplete, and my knowledge of DLL calls, and C is limited so I just never found success in this method. I don't remember the code or examples I used but here is a thread that came up when I was searching. If you do get anything working feel free to post it. EDIT: Oh I just saw a command line tool that might help. I'm not in the office to test with.

In the event structure, have an event for the Shortcut Menu Activation? event. This returns a Menu Reference that can then enable, disable, add, and remove menu items.

There's lots of examples of this posted on NI's forums. Here's one I've been using for a while: https://forums.ni.com/t5/LabVIEW/crc-8/m-p/580831#M272003 Note that if you are using this for the CRC calculation in an automotive CAN frame you may also want to add in the ability to skip the CRC byte location, as I've seen CAN-FD frames that have the CRC not at the last byte in the payload. In some cases the CRC stops being calculated once it hits the CRC, and in some cases I've seen the calculation skip this byte, and continue with the test. Also if you are doing this calcuation and you happen to be using XNet hardware, you can actually have the hardware perform the CRC calculation for you. Here is the idea exchange on adding this feature, and here is a blog post talking about the unofficial way to get the hardware to do this today.

Currently NI's package manager is less suited to distributing LabVIEW reuse in NXG, when compared to VIPM in LabVIEW 20xx. This is partially because in NIPM the package must be built for a specific version of NXG. So a package made for version 3.0 can't be installed in version 5.0, until the creator of the package updates it and rebuilds it for version 5.0. For reuse to be more adopted in NXG, this limitation needs to be removed.

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?

Unrelated - Nice mouse I have the same one. Well I did until I left it at the office just before a stay-at-home order.

Oh you're drugging up more of my old complaints. WebVIs were to me the most important bullet point to use NXG. Today almost all of my non FPGA code is written to work on Windows/RT/Pharlap/Linux/Mac. I try to do my best to not lock it down to an OS as some arbitrary limitation. So when WebVIs came around I figured I'd just think of it as another target, and the same VI for Windows can be used for WebVIs...nope. New file extension, and various limitations. The reason for this is that the controls on a WebVI aren't the same controls as Windows. The WebVI controls are HTML5 compatible controls that look and behave as closely as the Windows-only counterparts. Almost 2 years ago I was told that NI was moving toward having both platforms use the same control technology, thereby making them more compatible with each other...but well that apparently hasn't happened yet. My specific complain is that in current LabVIEW I can go to Tools >> Web Publishing Tool and create a HTML file that allows me to view and control a VI running in Windows or on RT without having to write any code. Yes it is very limiting on the browsers it supports, and it has issues. But in a couple minutes I can be controlling a VI running on any non-FPGA target from a computer on the network. NXG can do something similar, but there needs to be lots of code to handle communication. And updating one application means having to update the other. Another thing you touched on was the front panel UI. Ugh. Okay so I harp on the fact that we are missing System Controls every chance I get. NI usually pushes back and is like "Well why do you need system controls?" Most likely trying to gauge the importance of it. I say: Look at most LabVIEW front panels and you can know right away that they are written in LabVIEW. I don't want that. I want a program to just look like a normal native system looking program. And when the software is installed on a new system, my application will use those new system looking controls and now look native to that system. Look at how old and drab LabVIEW UIs look, that is why I want system controls. The majority of LabVIEW UIs look like they are old and stuck in the early 2000s. I had one person from NI say "But NXG is new and fresh and modern and doesn't look old". And I said "Well for now, but in a few years all NXG programs will have the same problem, they will all look the same and dated by the new UI standards." And here we are.