Bean

40 minutes ago, xiongxinwei said:

Google search engine not available in China😅

And yet, for this year, Google shows peak monthly search interest for LabVIEW occurring in China.  Weird.  The following does not represent total search interest, but peak interest listed by Google in any given month this year:

Here's the data from the tree map above:

1    China    100
2    Taiwan    96
3    Tunisia    74
4    Switzerland    74
5    South Korea    67
6    Ecuador    58
7    Armenia    57
8    Mexico    57
9    Singapore    56
10    Germany    54
11    Slovenia    52
12    Lebanon    47
13    Austria    42
14    Hungary    35
15    Denmark    33
16    Norway    33
17    Czechia    32
18    Israel    32
19    Finland    31
20    Costa Rica    31
21    Ireland    30
22    Colombia    29
23    Sweden    28
24    Belgium    27
25    Romania    27
26    Malaysia    26
27    United States    25
28    Netherlands    23
29    France    23
30    Italy    23
31    Hong Kong    23
32    India    22
33    Poland    22
34    Peru    22
35    Canada    21
36    Portugal    21
37    Japan    20
38    Pakistan    20
39    New Zealand    19
40    Morocco    19
41    Spain    17
42    United Kingdom    17
43    Slovakia    16
44    Thailand    16
45    Russia    15
46    Algeria    13
47    Serbia    13
48    Australia    12
49    Iran    12
50    Greece    11
51    Egypt    11
52    Venezuela    11
53    South Africa    10
54    Vietnam    10
55    Philippines    9
56    Chile    9
57    United Arab Emirates    7
58    Brazil    6
59    Ukraine    6
60    Türkiye    5
61    Argentina    5
62    Indonesia    5
63    Saudi Arabia    4

Hi, LogMAN –

Thanks for sharing.

1 hour ago, LogMAN said:

These statistics can be very misleading

This is an important point.  One thing I've noticed with Google Trends is to be careful about selecting their suggested search term categories.  For example, "Python" vs. "Python Programming language" graphs look very similar; however, "C++" vs. "C++ High-level programming language" look very different.  Maybe it's the addition of "High-level" in the case of C++.  Either way, I like to look at the raw data so we're not prematurely filtering.  We can intuit some things from the shape of the graphs.  For example, are many more people searching for the python snake vs. the programming language today vs. 20 years ago?  Are people searching for "C++" for some other reason than the programming language?  Keeping these things in mind and looking at the raw plots, while risky, is at least a "known" risk.  What is "unknown" is how Google is deciding when a "C++" raw search gets categorized as a "High-level programming language".

1 hour ago, LogMAN said:

For the sake of completeness, this is the graph for Python:

And, here is the raw graph for LabVIEW, C++, Python, and C.  As you can see, C++ and C follow a similar trajectory, which hints, to me at least, that we're not talking about "the letter C".  Again, it's raw data with no categorization by Google, so who knows:

1 hour ago, LogMAN said:

I wonder if we should pitch a Python port of LabVIEW to NI... 😈

Looking at how LabVIEW disappears from view compared to C++, C, and Python, umm yes?  This is why I wanted to develop TestScript.  It's ~3,000 lines of Python code that lets us abstract sequencing logic away from LabVIEW.  Effectively making LabVIEW a manual-control-screen builder.  Again, I'm not there anymore but the tool is solid, in my biased opinion, and free:  https://www.genuen.com/products/testscript

For context, C++ was released in 1985, LabVIEW 1986, and Python 1991.

There should be plenty of work for LabVIEW pros for a long time to come maintaining all the code that's out there, especially as newer developers pass over LabVIEW for Python.  AI just makes coding in Python soooo fast.  I'm no longer at Genuen, but we did make a LabVIEW-Python connector for those who would like to cross the streams (e.g. run Python scripts that control your LabVIEW manual control screen).  It's solid.  I'm attaching a screenshot from Keywords Everywhere so you can see some numbers on search interest.  Yes, Google has adjusted the way it reports this a few times, but fwiw, they have Python heading the other direction.

Now that we're Genuen, here's a new link to TestScript.  The download has been updated to include a simplified example (Scripting Example.vi) and a PDF you can share with your colleagues who may be skeptical about using Python and LabVIEW together. 

-------

Notes:

You can run multiple python scripts simultaneously.

TestScript has two fundamental parts that can be run on separate PCs:

1. LabVIEW server
2. Python server

You generally start the Python server from within your LabVIEW application (see aforementioned example), but you can also launch it via the command line on the target machine like this:

• python TestScript_gui_and_exposed_functions.py [LabVIEW server IP address] [port 1] [port 2] [port 3]
• python TestScript_gui_and_exposed_functions.py localhost 9007 9008 9009

Python scripts must be instantiated from the LabVIEW server (vs. something like PyCharm or the command line) --> so, while it does not feature “launch script from somewhere else” functionality at this time, you can send back script updates to your UI so you can see status (see example).

Thanks GWiking and nice work Darren!

-Jason Benfer

I agree:  WYSIWYG DevX and parallelized UI, control, DAQ, and logging meets a readable, exploding, scientific text-based sequencing environment!

TestScript lets you expose any number of LabVIEW actions (flip relay, read DMM, turn on power supply, etc.) and call those directly in your Python script:  xFlipRelay(), xReadDMM(), xPowerSupplyOn().  We recommend having, for example, the front panel button that flips your relay call the same code as the corresponding Python function.  This way, the code behaves identically whether it's being called via manual control screen or Python script.

Please check out the examples, and reach out with product ideas!  We're already folding TestScript into our own projects and loving it.

Jason

That's great insight.  At the end of the day, the Enthought toolkit and the LabVIEW 2018 Python Node are optimized for directly calling Python functions from LabVIEW.  Pretty cool.

TestScript is optimized for running Python scripts from LabVIEW which can call Python functions or custom LabVIEW functions.  If you return values (scalars or arrays) back to LabVIEW at the end of a script, they are returned as a string.  Example script we include (where we pass an array of numbers as a script argument when launching it from LabVIEW):

---

# Use list comprehension to create a list of floats to sum up.
addends = [float(i) for i in locals()['arguments']]

script_update(str(sum(addends)))

---

Since you're familiar with the tools, I'm interested in your feedback if you get a chance to checkout TestScript.  Just email testscript@winemantech.com to connect!

Jason

For clarity:

Currently:  The Enthought Python Integration Toolkit for LabVIEW lets you "Call Python functions directly from LabVIEW, and pass arrays and other numerical data natively" in both Python 2.7 and 3.6, is available for sale at ni.com, includes the Canopy development environment, and from what I understand helps solve some deployment headaches (e.g. Python packages).

The Python node that got released with LabVIEW 2018 lets you call Python functions from LabVIEW in Python 2.7 and 3.6.

TestScript is a free tool that lets you use LabVIEW to run Python 3.x scripts (that call Python functions) and retrieve the results back in LabVIEW ***and also*** lets you launch a Python script from your LabVIEW application that calls LabVIEW functions (that you expose from your application) from Python (e.g. to automate your LabVIEW manual control screen behavior on-the-fly:  flip relay, acquire data, log data, repeat overnight).  Examples included.

TestScript is written in Python 3.  If you are looking at calling Python 2.7 modules from LabVIEW, this is what Enthought's tool does (at present, anyhow).  TestScript enables you to use simplified Python 3 scripts to control a LabVIEW application or use a LabVIEW application to run and get results from a Python 3 script.  Because we've defined the Python-to-LabVIEW interface internally, scripts can literally be one line:

myVoltage = xDMMRead()

We can do this since, with comments and whitespace, TesScript contains 3,000 lines of Python code under the hood.  Can you write in Python 3?

And it's free.

https://www.winemantech.com/blog/testscript-python-labview-connector

From release blog...

Summary: Test engineers typically add manual-control screens to LabVIEW applications. While it would be helpful to repetitively execute varying parts of those manual-control screens, LabVIEW is not optimal for dynamic scripting, or on-the-fly sequencing with flow control.  (Imagine editing the source code of Excel each time you wanted to create a macro.)  And while Python is built for scripting, it requires advanced custom coding to interface with LabVIEW. 

Announcing TestScript: a free Python/LabVIEW connector from Wineman Technology that is simple to add to your existing LabVIEW application and abstracts complex Python coding,  allowing you to easily use Python to control LabVIEW or vice versa.

7 hours ago, bbean said:

Doing a google search resulted in this possible link to purchase:

Microsoft MSDN Platforms License & Software Assurance 1

Is that a similar license to what you are using?  

Looking at another purchasing note, I see:

"MICROSOFT MSDN OPERATING SYSTEM LIC AND SW ASSURANCE"

So, it's at least similar.  Since SWI was listed on the Microsoft website and dealt specifically with Microsoft licensing, we leaned on their understanding about what was required for compliance for our specific circumstance.  If there is a more cost effective alternative, I'm interested in hearing the details.

Bean,

Yesterday when I checked the "Find a Reseller" list, SWI was listed but the link was dead.  Today, they're not in the list.  Maybe because SWI has been acquired by Crayon:

http://www.crayon.com/en/news-and-resources/crayon-acquires-software-wholesale-international/

According to an internal purchasing note, we bought the "MICROSOFT MSDN OPERATING SYSTEM LICENSE AND SOFTWARE" (not sure if that's what SWI called it) from SWI:

https://www.software-intl.com

Maybe give them or Crayon a call?  The unit price at the time was $450, which I'm thinking is per person per year.

-----------

Aside:  I'd like to know from others who advocate VMs for development whether they are paying the annual fees (ultimately to Microsoft) to be legally compliant, and if so, through what means (e.g. MSDN)?

-Bean

Hi bbean,

The only cost effective and legitimate way we've found to run Windows on development VMs is through an MSDN account.  Purchasing info:

https://www.visualstudio.com/products/msdn-platforms-vs

That page also says:

"Visual Studio and MSDN licensing
For an overview of the Visual Studio 2013 product line, including MSDN subscriptions, and the licensing requirements for those products in common deployment scenarios, download the Visual Studio 2013 and MSDN Licensing white paper."

And, according to that white paper (i.e. "Visual Studio 2013 and MSDN Licensing Whitepaper - January-2015", page 14):

"User Licensing
Licensed for Design, Development, Testing, and Demonstrating Your Programs
All MSDN subscriptions and Visual Studio Professional are licensed on a per-user basis. Each licensed user may install and use the software on any number of devices to design, develop, test, and demonstrate their programs. MSDN subscriptions also allow the licensed user to evaluate the software and to simulate customer environments in order to diagnose issues related to your programs. Each additional person who uses the software in this way must also have a license.
What Software is Included and Downgrade Rights
For MSDN subscriptions, the software that is included is defined as any software that is available to the subscriber via MSDN Subscriber Downloads"

This link appears to be working for the traditional method:

http://ftp.ni.com/evaluation/labview/ekit/other/downloader/2015sp1LV-WinEng_downloader.exe

I have a VI that I use for renaming when Tortoise flakes out.  Open, populate the path controls (repo folder path, old file path, new file path), and run.  I can't seem to figure out how to post it here (VI nor snippet).

 

....If I want to rename a file that is in the repository then I would use the Mercurial Rename function so that all the history is kept....

 

Martin

LabVIEW 2013 | CLA

Open the VI in the LabVIEW project.

Rename through TortoiseHg.

From the VI:  File » Save As » Rename » select the file on disk that you just renamed via TortoiseHg

(Do not revert if prompted.)

From TortoiseHg, commit changes with "Renamed VI" comment.

Aside:  I've been having issues with renaming through Tortoise lately, so you may have to use the command line.

I don't upgrade until SP1 either.  For future reference, SP1 released March 5 for second year in a row.

Thanks for the heads up.

"Searching for text in an enum that resides within a typedef will cause changes to the values within the enum" is particularily disturbing to me as almost all my enums are typedef-ed and I search some of them fairly often.

Found this old thread as I was searching for any new patches for LV 2011 SP1.

Before submitting the corresponding CAR, this one destroyed my code base.  Basically searching for your type-def'd enum value would either change or in case of arrays possibly empty the array each time you pressed Ctrl-G to go to the next instance.  What made this so insidious was when you arrived at the next search instance there was no way to tell that the array of values (imagine array of 5 states/commands) had been altered or emptied.  The bug was unpredictible, undetectable, and did *not* register in the undo stack.  So the next time you saved, the code was hosed.  Upon discovery, I had to check the logic of every state transition.

For some reason it took months for NI to roll out the patch.  So, there could be sections of code written in LV 2011 SP1 out there that have been affected but not yet discovered because you have to know to even go looking for the changes.  By far the worst bug I've experienced.  Maybe like coding pre-undo only LabVIEW makes random changes?

LV 2011 SP1 crashes regularly.  Is LV 2012 stable?  Conditional loop indexing looks great.

• New - Flush Event Queue Function
  

Did a project in 2007 where a slider was linked to the amplitude of an analog output.  Sliders generate thousands of events which overfed the consuming hardware actor.  Each time I got a slider-value-change event, I unregistered, updated the AO, and re-registered for value change.  There were other requirements with this method which were necessary to ensure that I got the latest value when the operator was finished dragging.  Maybe this challenge would be better handled today by flushing specific events instead of managing registration?

Found LV 6.0 and 8.2 versions posted on the following page:
http://zone.ni.com/devzone/cda/epd/p/id/4935

LV 4.0.1 version located here:

http://digital.ni.com/public.nsf/allkb/2986FC3AE5CC1E3C86256C3F006EE656

See attached for each one.

Because of the title of this thread, I had in my head that I was looking for some really old version called "lvwutil32.llb", which turns out not to exist.  Looks like the main difference between LV 6.0 and LV 8.2 versions is the replacement of "/" in filenames with "-".  As you know, LLBs supported "/" in names but Windows doesn't - and, as folks started moving away from LLBs for LVLIBs, the habit of using prohibited characters stopped making sense.

Aside 1:  In this LV 5 code (by Aivaliotis, ironically) one of the LLB files I'm missing is "Extract Window Origin - Size.vi" (not "Extract Window Origin / Size.vi", as I'd expect).
Aside 2:  Mike, if you're listening, would appreciate a version of "DIC Software Library" that includes "D Sort 2D(SGL) array by row or column.vi", ...

lvwutil32_4.0.zip

lvwutil32_6.0.zip

lvwutil32_8.2.zip

Working on code that called "lvwutil32.llb".  Unfortunately, it's missing from the source.  Could someone post a copy of lvwutil32.llb?  FYI - this is circa LV 5.

I installed from the downloaded versions of SP1 and the patch and do not have a problem.  Note: I had not installed LabVIEW 2012 before installing LabVIEW 2012 SP1.

LabVIEW 2012 SP1

http://search.ni.com/nisearch/app/main/p/bot/no/ap/tech/lang/en/pg/1/sn/ssnav:pdl/q/2012/

Note:  For some reason when I loaded the downloads page it did not appear, but searching 2012 and then clicking Clear All fixed this.  Maybe something's cached funny with the browser.

Already a patch for it:

http://joule.ni.com/nidu/cds/view/p/id/3803

For reference, this was solved / contributed by Ton:

Mercurial Provider

Mercurial API