jzoller

The student version's been around for quite a while. And it's been crippled the whole time. I was thinking more like the original thread from the idea exchange.

ShaunR: Thanks! Your work on systems has been awesome to watch from afar. Thanks for taking part in making the JSON stuff into a real library. Unfortunately for me, most shops seem to be an either/or proposition on the languages they use. gleichman: Ah, I see. So: there are many more jobs. The pay is better. I can program nearly full time without needing to do sales/project management/QA/manufacturing/PCB design/what have you... that is, the job IS largely programming. LabVIEW can't seem to get away from the "programming as a second job" mentality, where the heavy lifting belongs to the consultants. And since I'm not really happy consulting... <shrugs>. As far as LabVIEW, I've always suffered from wanting it to be a general purpose programming language. Alas, it never happened. Even the hobbyist version got nixed.

<rereads post>... Hrm. I guess you could read it that way, if you wanted. Actually, I was working with C++ in parallel with LV on a multi-platform thing. It was fun. And, as tempting as it is to be that guy, I'll pass on the gripe list. Feel free to fill in your own.

After 15 years of making LV do oddball things, I'm moving on to text coding for my day job. I may still do a bit of LV here and there, but not much anymore. I hope LV can catch up in features and ecosystem to some of the languages that have surpassed it. It's an amazing language... I just wish it were used in more places, for more things. Thanks, everyone, for the insight, advice, and fun over the years. You all have my deepest respect for the amazing things you've done for the language and the community. Joe Zoller joe at underflow_software dot_com (no spaces or underscores)

Hi Sebastian, You can translate the xml to labview using the scripting functions. It's not trivial, though. You'll need to understand VI server and references reasonably well. You can turn on the scripting functions in more recent versions of LV under Options>>VI Server>>VI Scripting. It's a little dated, but check the GenINI code at http://lavag.org/topic/11920-genini-generate-readwrite-code-for-ini-files/. In particular, how typedefs are generated. Joe Z.

A Boulder, CO company that I'm familiar with is looking for a Test Engineer. Likely technologies are LabVIEW and Python, with a good amount of hands-on manufacturing work. Send inquiries to lboehnke at symmetricom dot com. Principals only. This is a cross-functional position, requiring collaboration with stakeholders spread across multiple organizations and disciplines. The candidate will work to achieve the following goals: · Create, enhance, and maintain automated and semi-automated production test systems that support a wide variety of new and existing products · Develop an automated regression framework and tests to support functional verification of new products and product modifications (hardware, firmware, and software changes) · Recommend, design, and develop interfaces and processes that improve manufacturability of new and existing products · Validation of product functionality, features, and performance The Test Engineering position includes the following roles: · Interface closely with software, firmware, hardware, and mechanical design engineering, and manufacturing in the fulfillment of position responsibilities · Design, develop, and review flexible product test strategies, processes, and methods · Design, implement, and maintain test automation software and hardware · Design, setup, and upgrade test fixtures · Actively support problem resolution activities, including recreation, debugging, and collaborating with development engineers and manufacturing · Seek out and implement enhancements to existing test and measurement systems · Run automated and manual tests as part of functional verification and manufacturing process verification · Document results and work closely with others to analyze and debug issues · Provide guidance to development on decisions that affect product quality and manufacturability, including common failure modes, easing failure debug, correct confusing diagnostic logging, etc. · Support test technicians on the operations floor · Involvement in creation and improvement of all engineering changes relating to test documentation · Participate in the capital equipment process · Contribute to cost estimates and reductions for all present and future products · Lead the creation/maintenance of test plans and schedules, coordinating multiple projects, reporting status / progress to management · Initiate and drive the development and review of test processes, plans and procedures following the test platform

Request deallocation can also be a huge time hit. I've tried it several times on 2D arrays of strings in different situations, and it's... well, not ideal. I ended up writing my string array to a file, and storing an array of mapped integer file offsets. The deallocation problem first showed up with some changes in LV6.1... apparently, it's either not soluble or not a priority.

Always love your insights, Tomi. Thanks for blogging again!

Not sure here, it won't install on my work machine. It appears to be interacting poorly with something from my IT group. I'll try again when I really need it.

If you can handle some Python programming... The simplest way I've found to do this is to build a socket listener in Python. It opens a TCP port, and waits for commands to come in. You can see the basic idea at http://docs.python.org/3.3/howto/sockets.html. On the LV side, you send commands to the Python socket using the TCP functions (http://www.ni.com/white-paper/2710/en/). When the Python side receives a command, it breaks it down, and routes it to the right dll call. When the dll call finishes, Python might send a message back to LV with results, if needed. There are always a lot of little details to handle, but if you get the basics of this down, it works very well.

I just wanted to chime in and say I think this is a fantastic idea. It's something I've been looking at and tinkering with for a while (using kineticjs), particularly a re-visualization of the profiler and trace execution data to a format that's more connected to how the diagram and hierarchy look. No time until the new year, though... making money interferes with all the fun stuff.

Congrats!

Given NI's tendency to litigate and their patent portfolio in the US, I don't predict smooth sailing for this company.

While it doesn't answer your question... I recommend not using the profiler. It's measuring something like processor time, rather than wall-clock time. The profiler doesn't account for long disk accesses, slow serial connections, memory teardown time, etc, etc. This ends up very misleading. Depending on what you're trying to measure, instrumenting your code is usually a more accurate, if somewhat tedious, way of doing things.

I've been down this road, too. Windows has a number of third party SSH tools (cygwin, TeraTerm, etc), but all of them are encapsulated in their own little universe and don't interact with other code well. Tunnelling sounds like a good solution. Because I'm not that smart , I ended up bridging LV with Python, and using the paramiko package to handle the ssh connection.

My favorite from the comments: #define HaltAndCatchFire for(; fork();

Thanks for the feedback AQ. The detail is appreciated. And I understand what you're saying. There's a big distance, though, between saying "This shouldn't be implemented in a VI" and "The project system is the best of all worlds!". Project comes with it's own set of quirks (And crashes. Ah, manually repairing XML). More to the point, project fragments the views and manipulation of classes... some over here in this New wizard, some in this VI, some in this .ctl, a bit in this hierarchy dialog, and a whole bunch hidden under this oddly-inconveniently-placed-and-totally-unremarkable-yet-massively-important Properties menu item. And basic things, like accessing base class data in an inherited class, are going to take me nineteen steps and eight wizards and six saves to string together. The project system is too much overhead. So, VI's aren't a better way... is there one? (Now, if you told me "It's project, or implement an entirely new mechanism and we're a year behind and sales said if we didn't have it done by Saturday our defense contracts were all leaving...", THAT I would understand.)

JackDunaway, I would love an intermediate, user-land language for LV. DFIR's fun to look at, but it's really a compiler toy. (If I recall correctly, WriteDFIRDot=true and graphviz can make for fun afternoon of spelunking.) So, here are some ideas. Would it work? If I knew, I wouldn't have asked the question . In addition to defining LV classes in LV, there are two other goals. First, the entire system of creating and managing classes should be simpler than the existing system. Second, the system should be more in line with the existing LV paradigm. (Python uses the term "Pythonic", but there's nothing equivalent in LV that doesn't sound graceless. L-Vesque?) The whole notion hinges on a special type of VI for class definition. It acts like a .ctl with a block diagram. That is, it's not *run*, rather, it's compiled to a static form when it's saved. Unfortunately, it might look like a constructor, but it's actually equivalent to a "class" declaration in other languages. For behavior in the IDE, though, the class definition VI is a lot like any other VI. It uses wiring to define its logic. It's saved/moved/deleted like any other VI. It only has a single entry in the project, and carries most of its information in the VI itself. The interpreter provides a broken run arrow when the definition is not valid. When the definition VI is dropped on a normal VI, it gives an instance of the class. The simplest possible class is: < Drop and populate cluster, save and you're done. There's no conn pane, either. It's not going to get much simpler than that... but it's not very much like LV. No output. No wires for logic. Not much to work with. So how about we change it to something like this: There's data, a node to work with, and an actual output. Still pretty simple, and it looks a lot like LV. It gives something to hang onto: I've tossed in a probe prototype, because it's trivial to do within the editor. A surprising number of class properties (locked, protected, icon, documentation, etc) can be handled in the same way every other VI handles them. Others, like wire type, friends and items are going to need to use property nodes. I think the idea falls down a bit here, because LV's expression through property nodes is rather inefficient. Particularly if you end up wandering down a hierarchy (see: .NET, scripting). The methods that belong to the class need to be specified. How about dropping them right on the diagram, like any other subVI? There are a lot of questions to ask and corners to fill. How do you view the class hierarchy? How do you handle access levels on methods? How do you handle property node access to private data? And of course, there are certainly things I'm not seeing. Joe Z.

Thanks for the replies. My boss wants something done so we can make money... I'll post a bit more this evening.

Syntactic distance But this avoid the question. Given multiple representations of the the same information, why not use the more familiar one?

I could use some help from the experts in understanding this. When defining classes is most other languages, you simply use the language itself to specify class behavior. In LV, there's this meta-language of project and dialog, with underlying xml, before you can get to an actual instance. It's... aggravating. The G language is certainly capable of representing the concepts in a class definition. Why isn't there a "class definition" VI?

As far as hardware is concerned... this USB over Network tool is on my list to check out. I've also found that a serial console server is nice for remoting in to system serial ports.

http://www.ni.com/pdf/forms/us/license_transfer.pdf

Thanks AQ. I'm stuck in Colorado, I'm afraid. It's a good idea, though. I'll check to see if any local university has a similar program. My normal process is to skim through a lot of books and find the ones that make sense to my particular mindset. Starting with Accelerated C++ (http://www.amazon.com/dp/020170353X) and picking a random project to work on. JZ

After a decade of working mostly with LabVIEW, it looks like I'll be getting back into C++ (Linux environment, mostly). I've done some C++ before, but I've never been good at it... does anyone have favorite resources, classes, or project lists that a lost LabVIEW programmer can use to come up to speed in C++? Thanks, Joe Z.