crossrulz

I have been using the default with a few additional abstractions I wrote. And, yes, that does have a DLL call in the end, so won't work with RT. All of my applications lately are on PC, so no issues there. If going RT, I would look into the JKI XML and the GXML libraries. From my quick looking, those are completely written in LabVIEW.

I am using the DOM parsing, especially since I need to interface with other places that generate XML and my structure can change based on several factors. So it is easier to maintain the 1 library. I do want to find some time to investigate the JKI XML toolkit to see if it will simplify some things, but I am swamped through at least July.

I have been using ini files for all of my applications. But I recently ran into needing of a hierarchy for a few of my settings. So I am transitioning to XML. I am currently in the in-between stage of using both an ini and a XML file for my settings (a lot of libraries to update to change to full XML, but no time to do it). I have been using XML Notepad for editing my XML files, making them super easy to make. Ultra Edit also has some nice features to edit XML files, most notable for me has been the column editing. SQLite might be a bit overkill because I want to be able to update settings with a text editor. Otherwise, I would need to create a database editor for each and every application. That would not be good for my plugins. I am sure there are ways, but probably more complicated than it is worth.

Thread in question. Once the stomping was fixed in the Delete From Array (supposedly in 2014), that became a lot faster than any other method.

Download the vipc from here: LabVIEW Task Manager (LVTM)

There is also the Data Queue VI in the PtByPt palettes. Personally, I found a fixed sized lossy queue to work very well as a circular buffer.

You can resize the loop itself and then move things around as needed.

You could use something like Hex Edit to look at your file. Personally, I am a fan of Ultra Edit, which has a hexadecimal view.

Brittle? Highly Coupled?

You could also try clearing the class mutation history and see what that does.

AristosQueue swears that they are useful. He mentions it in almost every event I have seen him at.

The only real issue I have had with 2017 was The distribute object tools often crashes LabVIEW 2017

In LabVIEW 2017, there is the Malleable VI (vim). This will adapt to the input type. In previous versions, this was a hidden feature called "macros".

There were several improvements that were made due to the Champions griping enough and actually got some R&D ears. I do not remember if those made it into 2017 or if they were pushed to SP1. The new feature in 2017 that annoys me is the autowiring when you drag code into an out of a structure. You can turn that off by pressing W during the drag.

A few things need to be discussed here: 1. Does your message protocol have a Termination Character? This is common for ASCII messages and is typically a Line Feed. If you are using a binary message protocol or your message does not have a termination character, then you need to turn it off (boolean input at the top of Configure Serial Port). 2. If you know how many bytes you are to receive in a message, then tell the VISA Read to read that many bytes. If the termination character is involved, then you tell it to read more than you expect and the termination character will stop the read. Regardless, because you are using a command-response protocol (the instrument only sends you data when you request it) you should let the timeout tell you there is no data.

Discussion on the NI forums: LabView vulnerability allows hackers to hack your computer And the patch that is due out sometime: Incomplete RSRC Validation in LabVIEW

Not that I am aware of. But yourscheme is not much better. You really should have descriptive names for your VIs.

If you are just adding to the end of the enum, I don't think the enum constants are supposed to reset. I have ran into issues when changing names and/or adding in the middle, but the Update Typedef tool is used to fix those. Now I have to go play around with this...

If going that far, I would just add the Open and Close cases as well and then just leave the file open. It would be a little faster as it avoids all of the opening the file and parsing the data etc.

cross point on the dark side: CRC-16 Calculation from C code

Sounds like the classic floating point accuracy issue to me.

I tend to bound back and forth depending on the application. At some point, it just becomes way too many User Events to try to keep track of when you use individual events. I think I only had 1 application where this became an issue. But on the other hand, it is quite nice to only register for the events/messages that that specific process cares about instead of having to process all messages.

Here is my 16-bit CRC saved in 2009. 16-bit CRC.vi

crosspost on the dark side