gleichman

Here's some pictures from the year twitter was created.

We used to get a bus and I thought NI used to arrange it for us even though it was not an NI event.

Back to the Salt Lick?

I also had these same issues. Mine was due to a bad beta install and was so bad NI PM would not work which created a interesting catch-22. I finally got NI PM working and was able to uninstall everything and re-install. https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019R9WSAU

It does work if typed in the same format as the display format. For example, if you type in 00:5 it will display "00:05", but if you type in just "5" LabVIEW sees it as an incomplete input and reverts to the last value. It works the same in LV16. I don't have older versions at home to test. NI will probably say that this is the more correct way of operating even though it is less optimal for your users. You could create an xControl that mimics the LV12 mode of entry.

Nice example of a VIM. I'm finding VIMs to be very useful. I think they be the best new LabVIEW feature since the event structure.

I've done something like this with a MultiColumn Listbox to show the configuration as plain text and a Tab or SubPanel for editing the selected line of the MCL.

I ran DETT and found a reference leak. I fixed it and verified the fix with DETT, but I still have the same GDI object leak afterwards.

I run the system as an executable and it has the same problem. I was hoping to find out what kind of LabVIEW functions create new GDI objects. This is probably something bad that my code is doing, but my system is large and it has been difficult to isolate the culprit.

I have a program that is creating about 200 new GDI Objects an hour. After about 24hrs of execution the GDI Objects exceeds 5000 and LabVIEW crashes (Sorry for the inconvenience). I disabled all of my UI updates and it continues to leak. Are there non-UI actions that create new GDI objects?

The computers are attached to two networks and I had the cables swapped on one of the computers. After swapping the cables, ping and everything else works.

I have two programs written in LabVIEW that share data via UDP. The data is being shared successfully when they are both running on the same computer, but not when separated. Some facts: This has worked in the past on different systems Both computers are on the same subnet Both computers are Win7SP1 Pro with the firewall and virus scanner off The computers are connected together with a TP Link TL-SG108 switch with no other computers connected I don't receive a valid response from ping between the two computers I like donuts Any clues would be appreciated.

You read the value by unbundling it from the display state cluster. Then in your facade you have to display the change by writing it to your control in the 'Display State Change' case. I've attached a simple example. xControl Demo.zip

Can you post some pictures?

I wasn't looking for gripes against LabVIEW. I was asking what features of your new environment made it worth the learning curve, but it sounds like you changed due to things you didn't like about LabVIEW.

It seem's that you've already given your farewell speach. http://lavag.org/topic/16486-back-to-c/#entry100884 So, what are the features that LabVIEW is lacking that are crucial to completing your projects?

The policy was updated 3-4-14 (CLA summit?). CLAD - 2 years (same as before) CLD - 3 years CLA - 4 years http://www.ni.com/white-paper/9605/en/ I like this change. The two year renewal always seemed to sneak up.

Use "Format Into String" with a format string of "%04d"

If you have a timed loop with an event structure set to 0 seconds then it will execute as follows. Event Waiting? Yes - Execute Event code [*]Wait for (elapsed time - timed loop time) If you use a while loop with the event stucture it executes the same as above without step 2, so you are adding overhead and increasing the time to react to event by using a timed loop. This would only make sense if you want your PID to not operate faster than a specific frequency.

Why? Do you want to execute it on a defined core? Otherwise you are just adding delay in execution.

If you're running this on a computer with the LabVIEW IDE installed, why do you need to create an exe?

Why would you want to do this? The block diagrams won't even exist if the executable isn't created with "enable debugging".

I ran it from my desktop and a directory off the root and they both gave similar results (~330x). LV2013 and Win7sp1. Did you run it both times from inside the project?

It looks like Majo has two problems. The myDAQ is too slow to properly generate or read a 50KHz triangle wave. The analog out channels of the myDAQ have a max update rate of 200KHz, so you will need the additional hardware as todd suggest and to verify the waveform a faster DAQ device is needed like a real scope.