crossrulz

I used to use Tortoise SVN. It was extremely simple to use as it was right from Windows Explorer. Due to company requirements, I have moved over to GitHub (enterprise server) with SourceTree as the interface. Both work well for me. The only real problems when it comes to SCC and LabVIEW is when you have to merge. If you avoid merging, you will rarely have issues. Text languages also have issues when it comes to merging, it is just easier to manage text files than binary files. I have yet to run into any other issues due to the SCC screwing up.

At this point, I would probably go a slightly different route. You could get an Arduino or Raspberry and program them to do the I2C communications for you. In the RT system, you can just communicate the data through a serial port. Another option I have been tempted to go with is to use a SC18IM700IPW, which is a I2C-UART chip. Again, you just have to use a serial port to talk to it. But this would be more hardware design than the other option.

LabVIEW Community Edition (NI has strictly stated we should not call it "CE") is a full release. It is nowhere close to a beta nor a replacement for a beta. That said, I still have not heard anything on the upcoming beta. I will have to see if I can get a hold of somebody about this.

Sets and Maps were added in 2019. But just to throw a wrench into your dreams, you can get some interesting combinations when it comes to sets and maps. You could have a set of maps. You could have a map with a set for a key. I'm just saying, you would have to plan this out very carefully.

Shameless plug: Proper Way to Communicate Over Serial

This seems to work... CRC16-CCITT-FALSE.vi

But the real story: Harrison Ford was sick and so the director just off-the-cuff said to just shoot the guy. A big sword fight was originally planned, but instead we got one of the most iconic movie moments.

Looks like you have a few confirmations about the crash in 2019 but fixed in 2020.

The release cycle was changed so that the main release remained with NI Week. So there was no LabVIEW 2016 SP1 since NI Week was moved from August to May in 2017. AQ has told me that NI has a "quarterly" release cycle, so who knows when LabVIEW 2021 would be released (April? July? October? Never?)

No, you are not the only one. Unfortunately, this is the color scheme all NI products are going with. Have you seen the LabVIEW 2020 SP1 Getting Started Window?

My understanding is that NXG is a full platform effort, not just LabVIEW. The LabVIEW part was scrapped, not everything else. I suspect the devs for LabVIEW NXG have already been moved on to work on Instrument Studio, TestStand (2020 has the NXG look), VeriStand, Flex Logger, etc.

Now imagine a "Senior Engineer" being brought in on a project and being told to redo everything because you used an Event Structure. No, I am not exaggerating. He had issues with the Event Structure in LabVIEW 6 and swore them off forever. Good thing I didn't listen to him, managed to get him to leave me alone, and the project was successful. My point here is that titles should be taken with a grain of salt.

Coming from my personal experience, I still lean towards no. I had a discussion with Nancy Hanson about this and we came the the conclusion that the CLA was not a destination, but the opening of doors to learn (yes, this was alluding to the CLA Summits). Personally, I had 0 experience using OOP when I got my CLA. But after my second CLA Summit, I found an application that deserved a very basic OOP architecture. The CLA Summit opened that door for me. Now I would say ~50% of what I do is OOP. There is still A LOT you can do effectively without OOP. And keep in mind that part of a CLA is to make architectures that your less experienced developers can use and understand. If they can't use OOP, then your OOP architectures will not be effective. So should it be REQUIRED? No. Highly recommended? Absolutely.

Sounds like you should be handling your serial communications with a Queued Message Handler. Use queues to send message to other loops (the QMH) telling it to send, query, or just read the port. Your message could include a queue reference for returning the data. I covered this at my VI Week presentation: Proper way to communicate over serial

Not quite what you are asking for, but...LabVIEW FPGA IP Export Utility

It'll be amazing crossing 2 time zones (Central to Western US time zones) just by going to the other side of the couch. Our sincerest hope is you learn more of our perspective as developers and take it back to R&D.

You can use the Flush Event Queue function to clear out old events.

Sorry, but you can't state you have the "best" training when you don't even know how to spell LabVIEW.

I recommend you make a new VI to use the data block protocol. Here's the code I use for this. In short, you send your query command and read the # and the first number. This tells you how many bytes are in the "size" section. So you read that many bytes and convert that to a number. This will now tell you how many bytes are in the actual data. So read that many bytes and then 2 more to act as the termination character. Now a key here is you need to turn off the termination character so that you don't have to keep trying to read more data due to a data value just happening to match the termination character.

Just use the Array Max & Min PtByPt.vi. It does all of this for you. There is also the Data Queue PtByPt.vi that you might find useful.

This change happened in 2019. My suggestion is to start getting used to using Ctrl+U to clean up the wires (make sure the wires are selected first). I am pretty sure there is a LabVIEW.ini token to turn this off, I'm just having problems finding it.

Well, the developers of the two applications will have to agree to a protocol to communicating with each other. Once you have that figured out, go into the LabVIEW Example Finder and there is an example project for TCP/IP communications.

Bryan's suggestion is by far the simplest method. The other route would be to have the two applications communicate over TCP/IP.

CSV is a text file. So why are you stuck with Excel? It will not do what you want. What's wrong with making another viewer? Push back on this requirement to figure out what the real goal is.

UltraEdit is just a text editor (a REALLY good one, in my opinion). So I have had test results being saved to a text file and had the result file open in UE. I can look all I want and then reload the file whenever I want to see the updates.