What does LabVIEW expect for the "target_name" argument in the python_labview_automation method "get_indicators"?

[ellc]

I'm trying to use the python_labview_automation package to read indicators and write to controls on a LabVIEW FPGA application. For debugging purporses I made a very simple vi with just a boolean control and a boolean indicator connected together. I don't have any hardware connected, so I don't understand what to put for target_name in this method. When I use this for my "real" application, I'm assuming this is the target FPGA? do I put something like "RIO0"? 

In general, I have only a fuzzy idea of how this package is meant to be used. This is how I think it's supposed to work: 

let's say I have an application that runs for a long time, ie an infinite while loop or something like that. 

If I try to use the method run_vi_synchronous, it will never return with any values, so I have to assume that I want to start it in a separate thread. 

Then let's say I want to read from indicators and write to controls, then I have to use the methods set_controls and get_indicators to continously find out what's going on in my other thread. 

Is there a way to get it to spit out what indicators and controls are available? what is the "run_options" parameter in run_vi_synchronous?

[ellc]

On another note, if I call run_vi_synchronous and the vi contains an infinite while loop, how would I kill this thread when I'm done? 

[tolltroll]

Hi ellc,

From the function definition, it does seem like the target_name is the name of your FPGA target. 

Unfortunately I'm not too well-versed in this Python wrapper, and after looking around it seems that the developers are not actively supporting the software. However, I'm totally able to discuss a more high-level implementation of your FPGA application. Can you describe a little bit about your setup and your application? What hardware are you planning to use, and how would you like to use it?

Nick

Applications Engineer

[rolfk]

I haven't looked through the entire package but it would seem unlikely that it would work on the FPGA at all. As far as I understand it this package installs a VI based deamon with a network listener on the target, that is then contacted through a BSON based network connection by the Python library to send commands there. As such it has to run inside a LabVIEW runtime environment, not on the FPGA fabric. So you will have to install the LabVIEW VI library inside your LabVIEW realtime application and let it run as an independent thread (LabVIEW loop or seperately started VI). Then you can connect with the Python library to this over the network connection. As such the "target" would be very likely the network address for your realtime target, which is best done in dotted IP4 notation, and generally not named as RIOxx at all, even if you should happen to have a DNS server running, which knows about your cRIO or similar realtime target by a name.

[ellc]

For the record, I did manage to get this to work. If you don't have a hardware target the resource name you should use is "My Computer". Also, it does work with FPGAs, but you should probably use this now instead: http://nifpga-python.readthedocs.io/en/latest/index.html#

The downside of the python-labview automation package is that it doesn't seem to open vi's in the context of their project, so if you have subvis, it thinks everything is broken and refuses to run it. I got around this by making a vi that is capable of opening a project and then opening the vi. I used python-labview-automation to launch this initial VI and then I was in business. My launching VI runs and then closes, so I don't have to worry about the run_vi() function going on forever.