DIAdem Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
Mike117

Use Python for scripting instead of VBScript

Status: Completed

With DIAdem 2020 is Python now also available in the SCRIPT module as an alternative scripting language to VBS. In the DIAdem settings, you only need to enable Python as the scripting language if you prefer to use this language. As with VBS, you can alternatively record scripts in Python syntax. The Python editor integrated in the SCRIPT panel offers the usual auto-completion and a tooltip with syntax information and a short command description.

I know this would be a major change. At least VBS is not proprietary like some other software that has a script interface, and at least VBS supports OOP.

 

But VBS is from the 90's, the documentation is from the 90's and early 2000's at best, with associated lack of support. The full potential of diadem is really limited by this. If I could use Python, a much better supported, easier to use language, I would be extremely grateful. All my data processing tools are written in Python. I'm just trying to automate test reports, get channel names to identify the data the user put in the Data Portal etc. I am willing to put in time to interface with APIs or DLLs if someone can point me in the right direction in the interim. 

 

To be brutally honest, it is almost laughable that with diadem 2017, it has a flashy UX/UI, yet uses this archaic language for automation, where most time is saved. A system is ony as good as its weakest link.

14 Comments
ledz
Member

I agree, and would welcome Python as a new scripting language. However,  VBS scripting support should then be maintained and not deprecated, if possible. That is, unless you want to force customers with possibly very large, incrementally developed libraries (read: lots of legacy code with no support) to port them to Python, which can be a large effort.

Leo Zschokke
Test Engineer C-EPS
ThyssenKrupp Presta AG
Mike117
Member

Yeah that would be up to their management what direction to take that. I would think a decent amount of continued support would be required, but the resources to do this seem much less than what is required to add a new language.

 

And yes, it would be a large effort to convert libraries, but a company could switch to Python, increasing productivity immediately, and then slowly build up their libraries. Any data manipulation is much easier to do in Python. Better support, better tools/IDEs etc. extremely widespread use. Of all the languages I've used/familiar with (C#, C++, VB.net, VBS, Matlab, Python), I would keep Python hands down if I could only have one. There are a select few times I would choose C++ for speed or low level operations, but Python wrapped C libs are getting so efficient there's almost no point. Timing isn't always the best due to GC but this is irrelevant in the vast majority of my programming tasks. I don't need a script interface/IDE like it has for VBS now, just an API to work with or something with more functionality than the OLE interface, which can be accessed with Python and COM.

Gabriel_H
Member

I Agree.

 

Coming from a background of embedded C, MATLAB and LabVIEW, I find Diadem's VB scripting off putting and un-intuitive.The VB documentation and help is brief and disjointed (compare to LabVIEW's, which is so much better, coherent and intuitive). The geting started guide's section on scripting just shows you how to record UI commands into a VB script, not how to actually start a script and where to get help, API command list etc. There isn't even a simple command line handler to try out commands, unlike MATLAB which gives you an intuitive place to play with commands before building scripts.

 

For a new comer it's a problem because the Diadem UI is fairly clean and intuitive, but the moment you try to do something not supported by a UI button or exting calcultation option, you're thrown into the dark (VB scripting). Something more intuitive like Python (even LabVIEW) would be much easier and more intuitive to make the jump from the UI to scripted commands/processing. I keep looking back at MATLAB where their scripting and integrated command line help is intuitive and makes stepping up the complexity of the analysis a walk in the park.

 

From a new comer's perspective, the current state of the VB scripting really holds Diadem back in terms ease of use and ability to help not hinder the analysis.

 

 

Mike117
Member

I wholeheartedly agree. A command line/console to test commands would also be welcomed. I currently paste something followed by an incorrectly typed command to cause script failure to test my code as I go. Sad.

 

Slowly working on hacks/workarounds to get the job done in a more capable language like Python (or LabVIEW). From what I understand, NI bought DIAdem from some entity and is not a 'native' product like LabVIEW, but nonetheless, if it has the NI name on it, it should be given sufficient attention.

Gabriel_H
Member

Thanks for the info on Diadem's origin. That makes more sense and why the scripting feels like standard VBscript has been beaten and forced into performing data analysis, instead of being natural and elegant at it.

 

I'm really trying to like Diadem, and I've been trying to put my finger on why the scripting and analysis feels off, slow and unituitive. I've realised that for general calculations there are only two options: the calculator (and calculation manager), or scripting. But in scripting, you have to call the calculator anyway. You can't just type a mathematical expression and have the scripting language evaluate it.

 

For example, if my data has two channels, power_in and power_out, to calculate efficiency in a script I have to:

(1) Check if the destination group exists, and if not, create it.

(2) Select the destination group.

(3) Check if the destination channel ("efficiency") exists, and if not, create it.

(4) Create an array of channel objects, containing the two source channels and the destiantion channel.

(5) Call the calculate function, give it the formula string "eff = p_out/p_in", give it the array of channels and an array of corresponding symbol names ("eff", "p_out", "p_in").

 

In MATLAB, I just write this into a command line:

efficiency = power_out ./ power_in;

And it's done. Simple, no messing around with making VBscript understand how to process a formula. If I want the calculation added to a script, I just copy the command out of the command line history and into an m file, no changes.

 

It's this clunkness that is taking a huge amount of time to analyse and manipulate the data, and scripts become very long when stuffed full of boiler plate code...

 

The other gripe I have about existing scripting, is that the concept of "recording GUI interactions" doesn't cover all GUI interactions. For example, in REPORT if I have 3 or 4 pages of identical looking 2D plots, but I want to increase the font size of the axis labels, I can't record that in the GUI for one plot and repeat on the others... So I either do it manually on all plots, or I have to dig into the VBscript documentation to find out which commands I have to call to do that...

JoshRew
Member

Preface: Opinions expressed are solely my own and do not express the views or opinions of my employer.

 

I can back up ledz in that the company I work for has a large library of incrementally developed code that would need converted if they dropped VBS support.  I'm personally in favor of moving forward with new technology (such as they've already done with deprecating the old REPORT commands), but even that scale of change (re-writing report generation) takes quite a long time for a small team to fully write out and test across a large library.

 

I expect that they would support both in the short term if they were to do so, then possibly fully switch in the long term (as they did with REPORT object-oriented).  This would allow for a more natural conversion (switching languages as new tools are developed and old tools are re-written), and the possibility for them to introduce a conversion tool that you can test.  Speaking personally again, I would think from a business perspective they would not want to force a full library conversion at one time because that level of effort and expense gives an opportunity for evaluation of other tools, basically opening room for the question "if I have to re-write my entire library, are there other applications I should consider re-writing it in?".  That question doesn't really come up if you're just adding a feature and naturally switching to the better option.  The fact that Microsoft Windows Script Debugger DIAdem uses has been deprecated shows that they'll need to move beyond it someday.

 

A few tips, in case they might help someone new:

  • Install the Microsoft Windows Script Debugger to be able to step through scripts line by line.
  • The Record capability is extremely useful for getting to know the code behind manually executed commands, but not very useful for Report/View.  For Report/View, press Ctrl+Shift+C when you're in the "Display..." dialog for whatever object it is you want to change, then exit the dialog and paste it into a blank script.  It'll probably give you a lot more code than you need, but what you wanted to edit should be in there somewhere so you can copy it out to a more purposeful script.
  • If you press Ctrl+Shift+F1, it opens a command window where you can view/edit the contents of variables and execute individual script commands.
  • ChnCalculate is a single-line solution to all 5 steps Gabriel_H mentioned above:
    • Call ChnCalculate("Ch(""Outputs/Power_Out"") = Ch(""Power_Out"")/Ch(""Power_In"")")
    • So long as the input channels exist, it will create the "Outputs" group (if necessary) and create/overwrite the Power_Out channel when it executes the code.  This is the same syntax as recorded in script from the channel calculator (except requires double-quotes because it's an enclosed string), and can also be used in the Ctrl+Shift+F1 window.
    • FormulaCalc is another option, but uses a different syntax so isn't directly recordable from the Calculator.
    • I'm not saying it's as straightforward as Gabriel_H's Matlab code, just that this might help make it a little less painful.

So while I'm deeply embedded into the existing VBS way of doing things, it'd be interesting to learn a new language, especially if there's a performance/usability benefit!

 

-Josh

Walter_Rick
NI Employee (retired)
Status changed to: Under Consideration

Hello MIke,

Thank you for your request. NI R&D has read this suggestion and will give it serious consideration for future DIAdem versions, although we cannot commit to a timeframe at this time.

Greetings

Walter

Walter_Rick
NI Employee (retired)
Status changed to: In Beta

Please have look at the DIAdem 2020 Beta to check the implementation regarding this request.

To participate at the DIAdem Beta Program, please register yourself at ni.com/beta

Greetings

Walter

Walter_Rick
NI Employee (retired)
Status changed to: Completed

With DIAdem 2020 is Python now also available in the SCRIPT module as an alternative scripting language to VBS. In the DIAdem settings, you only need to enable Python as the scripting language if you prefer to use this language. As with VBS, you can alternatively record scripts in Python syntax. The Python editor integrated in the SCRIPT panel offers the usual auto-completion and a tooltip with syntax information and a short command description.

markwkiehl
Member

Yea!