G-CODE

I just posted this over on the NI forums. Can anyone else confirm. This seems really strange, but I still think I might be missing something. I've got a probe on a block diagram that doesn't agree with the data coming out of the VI that is the source. https://forums.ni.com/t5/LabVIEW/Parallel-Access-DVR-Bug-LV2017/m-p/3696695#M1039519

You can easily instantiate a child class at runtime. You can launch your application with only the parent class in memory until you specify which child class should be instantiated. Each of your child classes can be placed in their own libraries (LLB or packed project library 'should' work). The path to the class in the library can be passed to the 'Get LV Class Default Value' function as shown in attached. However, without looking into it more, I'm not sure this really solves your problem since you are trying to load code that is specific to a LabVIEW version. It sounds like you want to create a parent class that can be opened with either LV2013 or LV2015 and then dynamically load a child class that could have been created with either LV2013 or LV2015. Is that correct? -Eric

Do you observe the same behavior if instead of returning the 'AllObjs[]' property from the cluster and typcasting each to a control , you return the 'Controls[]' property instead?

Well that all depends. If you've got TDMS files that you want to post process and or analyze, Python might be exactly what you want. That was the case for this particular project. It was considered advantageous to not require LabVIEW. Plotly was just used as the visualization tool after post processing the data. If the goal is to create some data in LabVIEW and display it in Plotly, then I agree that you shouldn't need to bring another language into the mix. I still think it's great that Adam Reeve put a tool out there that allows us to read TDMS without requiring LabVIEW!

I've gone from TDMS to Plotly using Python. There's a guy who maintains a Python module for importing TDMS data to Python on GitHub. I've used it successfully on one project so far. https://github.com/adamreeve/npTDMS

I guess I'm waiting for the day where I see a case study of a medium to large size LabVIEW app with the UI completely developed with a JavaScript framework. (Angular, React, Vue, etc). If pressed for time, I can't think of a good reason to do this assuming a standard LabVIEW UI can meet all the requirements.

Shaun, would you be willing to elaborate on your process for doing this? Has this already been discussed and do I just need to be pointed to those discussions? I find this interesting, but it also seems like it would pose its own challenges. To do this it makes you a LabVIEW/front end web developer, right? Do you have a preferred JavaScript framework? Do you run into issues where browser updates break your UI? It seems like it would slow down development time so it might be a hindrance on customer projects that have aggressive delivery timelines. I probably shouldn't hijack this thread. If you'd be willing to discuss your methodology, I could start a new discussion. Eric

I guess I'd need to see your code. Are your modules simply VIs that you call? If that's the case, you don't need to user events at all. Just stick each module in a different case of your case structure then send the correct string: module1, module2, module3. There's less work involved in doing that than there is in sticking each of those modules in an event structure. I wish ShaunR would chime in and try to dissuade you from going down the path of trying to call into the EXE using references since I doubt he would try to solve the problem that way. He was just providing you with an explicit answer to your exact question. I doubt he would suggest doing that if he were considering the bigger picture of what you are trying to accomplish. Eric

Steven, I think this would be a useful feature. Don't we do this all the time on inputs by checking their values? Sometimes we are checking the values of inputs on VIs because we are actually concerned with the incoming value and sometimes we are checking because we want to know if the user of the function set the value (wired the input). Unless we actually comment our code well, it might not be immediately obvious what our intent was for checking the incoming values. The feature you describe would enable us to be more explicit about our intentions without actually adding code comments. Self documenting!! I remember sitting with Mike (VI Shots) once and he was wishing this feature existed. It was a couple of years ago so I'd be curious to see if he remembers saying that. Eric

BTW, while ShaunR did answer your exact question, I think you're going to hit a dead end pretty quickly if you try to go down that path. Notice one of the arguments required for that function is the user event ref. Since those references change every time you start your LabVIEW application you're going to have to first pass those references out of your LabVIEW application so that you know what to call from external code. If you know how to generate a user event, then you've already got everything figured out. Your Python code can send strings via TCP: command1, command2, command3. Your LabVIEW code can receive those strings to control a case structure. Each case fires a different user event.

Do you need help figuring out how to generate a user event in LabVIEW? If so I can modify that example so after the message is received it generates a user event.

Allen, I spent some time looking at the python_labview_automation GitHub repo and actually trying to get the code to run. It looks like it was probably written in Python 2.X and I have 3.5.1 installed. I modified enough of the 2.X code to get it to at least establish a connection with LabVIEW. When fully functional, it looks like it is supposed to call a VI and set some control inputs. All the code on the LabVIEW side is based on actor framework which probably isn't even necessary for us since all we we want to do is create a TCP server in LabVIEW. To be honest, I think it's overkill for what you (and I) want to be able to do. It is dependent on some other libraries (hoplite, BSON) which make it more difficult to install and run. All we really need to be able to do is to call a function(with arguments) that executes some LabVIEW code. On the LabVIEW side of things we will know the data type of the arguments (received as string) so we can convert the arguments to their correct type. Then we need to send a response back to the Python function that is waiting for it. Once you receive the command in LabVIEW, you can do whatever you want with it including generating user events, notifiers, putting data in a queue... whatever. So I don't think the question to answer is how to generate a user event from Python. The question to answer is what's the best way to create a communication architecture between these two languages given that we want to call a function with arguments from Python and have it received by a process running in LabVIEW. As you'll see if you run the example code I attached to the other post, a simple version of this is really easy to implement. It will take a little bit more work to make it full featured enough so it is reusable and works well in our application. I'm thinking a community version of this on GitHub would be really useful and it's about time we have this. I'm not committing myself to doing that, just thinking about it. :-)

Here's a version that should work in 2014. I started with the LabVIEW TCP server example. Note that it's reading one byte at a time which is probably not how you would implement this in your application. If your messages from Python were terminated with CRLF then you can configure the TCP Read Function in LabVIEW to read until it sees the terminator character. Simple Server-14.vi

shoneill, Mercer said something prior to the sentence you quoted that is important to include in his statement about inheritance - specifically that it is "general" advice. I can think of a recent example where inheritance was a useful tool, but I broke from that convention. However, I would say that generally (most of the use cases I encounter) I would not want concrete classes inheriting from other concrete classes.

Argold, As I mentioned in your previous post, there are a couple of ways to go about this, but there's no magic command in Python that will trigger a LabVIEW event. Your best bet is to create a TCP server in LabVIEW then connect to that server with Python. I attached a quick and dirty example (LV 2015). Run the LabVIEW code first, then run the Python file. The LV code will read the message one byte at a time. Now that you've got Python and LabVIEW connected, you've got your work cut out for you to make it more robust and full featured so it works for your application. client.py Simple TCP - Server.vi

Argold, I've been thinking about this lately since I think it will become more common for developers to want to be able to do this. It appears that Enthought is trying to sell a toolkit, but it is for calling Python functions from LabVIEW, not the other way around. You want to be able to script LabVIEW functions from Python. JKI has the tools to do what you want as indicated on one of their marketing pages, but they don't make those tools available to anyone. I noticed NI has a page with links to some Python related tools: http://forums.ni.com/t5/Community-Documents/Python-and-NI-resources/ta-p/3536750 The most interesting link on that page is a GitHub repository that might be what you are looking for. I haven't tried it, but I'll likely download it and see what it does. Another thought I had was to look at Jack Dunaway's Featherweight framework. I believe it uses nanomsg under the hood as its messaging library and nanomsg has several language bindings including Python. Since I'm not completely certain about this, I would get Jack's input before proceeding down that path. Lastly, there's a way to architect your application so that whatever test sequence you script in Python doesn't have to concern itself or interact with the LabVIEW UI. Your LabVIEW test logic can be started and controlled either from a LabVIEW UI or from a Python script. There's a little bit of work to decouple the LabVIEW UI from the code that runs the tests, but there are a lot of benefits to doing that, including being able to control those tests from Python independent of any LabVIEW UI. Eric