hooovahh

So there are plenty of improvements I can suggest for readability, but overall I think the code isn't bad. A few comments would help, and I'd prefer less feedback nodes, and instead code that calls it in a loop, but to be fair that might have just been what you did to demo it. I think all that is needed to to try to not use the dynamic data type. It can do unexpected things, and can hide some of what is going on, inside those functions that you need to open the configure dialog for. This can make the code less readable. So I'd get rid of the To Dynamic data, and instead use the Array Subset function on the 2D array of doubles. This should allow you to get just the two columns you want, and write that to the TDMS file. You may have to mess with the decimation, and possibly transpose the 2D array. I can never remember how the functions work, and so I'm often writing test code to see if the columns end up the way I want. This will mean of course that you also use the Array Subset on the 1D array of string which is the channel names. As for the time entry, it looks like it works, but might I suggest a different string format? Here is a post that shows how to use the Format Into String, with the timestamp input, which returns an ISO standard string format. More standard, and if a log is moved from one timezone to the next, it can still be clear when the log was made.

Yeah targeting the upper management likely would result in more sales. But may also result in less engineers willing to use NI and their products, having been force fed the wrong, or less appropriate tool for the job. I worked with a group that had Veristand 2009 forced down from upper management. NI came in with a dazzling presentation and convinced them to change over their dyno control systems to it and the PXI platform. They did without consulting the engineers, and as a result there was a daily battle where I would repeat "Rewrite Veristand" when some trivial task for LabVIEW, couldn't be done in it. Veristand 2009 ended up being somewhat of a flop, and from what I remember nothing ported to 2010 since NI made some major rewrites of it. We eventually got an apology from NI which basically equated to, sorry we gave you the impression this product was more usable than it actually was. Luckily my current boss knows NI and their offerings, but trusts my opinion over theirs. They need to convince me something is a good fit, before they will convince him. They have some new test platforms that directly align with our business (battery test in automotive), and so far I'm unimpressed except when it comes to hardware.

@Aristos Queue, I was part of the private preview event and afterwards there were several comments basically saying "I watched all of this and have no idea what NI is announcing". And multiple requests that NI make it clear what they are trying to announce. I thought maybe the public event would be more clear. Nope, dozens of comments were flying in asking what, if anything was changing as the event went on. After the event ended my favorite comment was "That was a great introduction, but when does the actual event start?". Threads on Reddit, LAVA, and NI all have had various amounts of "What does this mean?" other than a new logo and color scheme. After reading and listening to NI's feedback, only your post made it clear to me what NI was trying to say. So while NI marketing may think they are making it loud and clear, the community has also been pretty loud themselves with their statements that they aren't sure what NI was trying to say.

I had my share of insane objects, but I'd just clear the compile cache, and revert with SCC. I don't ever remember seeing insane objects in the installed LabVIEW functions, but if that happened it would be a bit more of a pain to resolve.

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.