crossrulz

You might want to monitor the communications with something like Wire Shark. You might find the instrument sent a command code and is waiting for you to confirm it.

As long as you don't need the command codes, just look to the TCP Client and TCP Server examples already built into LabVIEW. Telnet only gets complicated (at all) when the command codes are used.

I would stick with 32-bit. I have yet to see a reason to go 64-bit unless you are doing massive amounts of memory intensive processing (Vision immediately comes to mind).

You could probably get away with a simple Arduino or Raspberry Pi or even an office level PC.

My only TestStand roadblock so far (and has not been nearly as big of one as I expected) is the deployment license cost. Though, put that cost against a VST and it is a small drop in the bucket. (The VST is literally half of the cost of my current project's entire test rack.) As far as going away from TestStand, I have ran into a couple situations where I was told to use TestStand and I convinced the customer/management that the project really just needed a decent State Machine with a few other loops for logging and instrumentation. Sorry, no real ammo coming from me. But I am very curious about other people's reasons.

Or for those looking for the Developer Suite: http://search.ni.com/nisearch/app/main/p/bot/no/ap/tech/lang/en/pg/1/sn/n1:2018_Spring,n8:142,ssnav:pdl/

Sounds more like you need a NOT, not an OR. And what's wrong with using logic gates?

DVRs were introduced in 2009. I skipped from 8.6 to 2011, but I do remember having tons of issues with 2009. But we all know that the best "must have" feature of any LabVIEW version was the new icons that showed the version starting with 2014! Other notables: Vivado compiler for LabVIEW FPGA (2014), Channels (2016), Malleable VIs (2017).

Duplicate thread: ASCII into Hex

Do as ensegre shows or just use a normal string constant and set the display style to "Hex". Then type in those hex values. I also highly recommend you set the Visible Items->Display Style to make it more obvious that you are looking at the hex values and not ASCII characters.

How are we supposed to know? You still have not told us what you expect as an output with a specific input. As far as what is different between the two pieces of code you have there, you need to wire up an I32 constant to the top of the Type Cast, not a string. It will adapt.

You need to be A LOT more specific. I have seen at least 5 different definitions of "hex". Do you have an example of your data coming in and what you expect out? Doing this with a VI whose controls and indicators have set default values is by far the best way.

If you want to use Conditional Terminals, I would do something like this.

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