Labview. Attractive for speed of initial development. Ugly for debugging and adding new features and 'reading' an old vi. Attractive for reliability when used with NI hardware and some of the more common 3d party instruments. Ugly where each version iteration of windoze and/or LV breaks your existing systems. Ignore the GUI - the analytic comparisons should NOT be graphical vs. textual; it should be dataflow vs. imperative.
VB or C#. Attractive for the surprisingly effective and elegant IDE (Visual Studio). Ugly for programming languages that are a non-standard standard and being depending on the windoze platform. Would suggest C# over VB any day of the week. Attractive for a large body of proven code. Ugly for a problematic licensing scheme found in most C# technical libraries. Tile. Previously discussed in this venue. Attractive for being the most likely candidate as an industry standard. Ugly for being convoluted and butt-ugly ugly ugly. Other stuff. No significant experience or exposure. Suggestions. 1. DIY. Domain-specific development assumes you have a domain-specific expert that can code monkey; and if not available, hope your boss is very patient while you stumble around learning the tool-chain or learn EMC theory and standards. So no DIY unless you have The Person or an understanding (?) boss. If you are capable enough for a DIY solution, then you probably already know that many systems that actually work are typically done using stuff such as ISO C/C++ and Python. Abundance of code available for the common instruments. Write small single type-test programs to start and build your tower of babel from there. And use version control. And do not use windoze. 2. Canned Code. Do not just ask in this listserv. Go look at the stuff used in your local labs. Ask opinions and technical questions of the people that actually use this stuff. Look at licenses, version control, version compatibilities, platform dependencies, instrument libraries, and the vagaries per the Klingon Rite of Ascension. Brian From: James Pawson (U3C) [mailto:[email protected]] Sent: Tuesday, August 01, 2017 5:41 AM To: [email protected] Subject: [PSES] EMC Measurement Software Hello group, I'm investigating upgrades to my existing EMC measurement software (R&S ESXS-K1) and have found the following options: * R&S Elektra (new) / ES-Scan / EMC32 * Dare RadiMation * Toyo EMC measurement software * ETS Lindgren TILE! * Nexio BAT-EMC * NI LabView and develop own routines * Write own from scratch (VB / C#) Are there any others worth considering? What "gotchas" or issues am I likely to run into? It needs to drive a R&S ESHS 10 (conducted) and a ESVS 10 (radiated). Bonus points for support for R&S FSP 30 and custom turntable control. Many thanks in advance! James James Pawson Unit 3 Compliance - ---------------------------------------------------------------- This message is from the IEEE Product Safety Engineering Society emc-pstc discussion list. To post a message to the list, send your e-mail to <[email protected]> All emc-pstc postings are archived and searchable on the web at: http://www.ieee-pses.org/emc-pstc.html Attachments are not permitted but the IEEE PSES Online Communities site at http://product-compliance.oc.ieee.org/ can be used for graphics (in well-used formats), large files, etc. Website: http://www.ieee-pses.org/ Instructions: http://www.ieee-pses.org/list.html (including how to unsubscribe) List rules: http://www.ieee-pses.org/listrules.html For help, send mail to the list administrators: Scott Douglas <[email protected]> Mike Cantwell <[email protected]> For policy questions, send mail to: Jim Bacher: <[email protected]> David Heald: <[email protected]>
