Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Bean last won the day on May 15 2018

Bean had the most liked content!

Community Reputation


About Bean

  • Rank
    More Active

Profile Information

  • Gender
  • Location
    Raleigh, NC

Contact Methods

LabVIEW Information

  • Version
    LabVIEW 2015
  • Since

Recent Profile Visitors

2,345 profile views
  1. 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.
  2. 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 f
  3. 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 cal
  4. 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?
  5. 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 Pyt
  6. 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.
  7. 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 yea
  8. 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 Whit
  9. This link appears to be working for the traditional method: http://ftp.ni.com/evaluation/labview/ekit/other/downloader/2015sp1LV-WinEng_downloader.exe
  10. Updated VIs to obtain hwnd by FP.NativeWindow as suggested above. Saved in LV 2013 SP1. Only tested with Windows 7 64-bit and LV2013 SP1 32-bit. Set Calling VI Wnd Top & Active.vi Set Calling VI Wnd Topmost & Active.vi Cancel Calling VI Wnd Topmost.vi
  11. 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).
  12. 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.
  13. I don't upgrade until SP1 either. For future reference, SP1 released March 5 for second year in a row.
  14. 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 und
  15. 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?
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.