_Mike_

Great news @Michael Aivaliotis! @LogMAN thanks for supporting the process and publishing transformation code. Should we then wait with potential forking an merge requests for all the git-housekeeping of the repo?

Hello, I have recently hit a peculiar issue when I was deploying a source distribution (SD) on a PXI Target running PharLap. The source of SD contained vis from NI's httpClient library, so the SD itself contained (among many others) two files Get Lib.vi and GET.vi in one folder. Upon attempt to upload the SD to target via FTP, I have seen no errors no warnings, but trying to dynamically launch a file from SD that used httpClient resulted in thread stack overflow. By close inspection I have found out that I miss GET.vi file on the target. Moreover I was unable to upload this file by FTP. Then I run code from snippet on the target can see Error 10 (duplicate path) appearing each time I want to create a file which name part matches "part before a spacebar" of existing file. This "feature" prevents me from using httpclient library on RT target, that I am heavily dependent upon. Is there a way to overcome this problem ?

After consultation with @Steen Schmidt I've learned that there is no API to do it, and the way to create a project including target consisting of few c-modules from limited poll would be by directly examine project's xml file. I will go that way.

Thanks for reply. However it's not that I want to detect actual layout. I have a textual description what modules should be at which slots from another team, and I would like to programmatically create a project and build a bitfile.

Hi all! Does anyone know how one can programmatically add a given chassis to a target and fill it with a set of C-modules and FIFOs? I attempt to programmatically create a bitfile for a target when I know the set of modules I want to install in e-rio based remote I/O system. I do have standardized vis for interfacing each module (via FIFOs).

especially when it comes to week numbering ;]

Considering your slow rate - why you want to depend on "in general" unreliable UDP instead of TCP? At such rate TCP's overhead should be of no matter, so - if I may ask - what are the benefits you are looking for? Or it's more matter of "curiosity" that UDP in principle should work byt ARP protocol interferes it?

Hello, I am having a big problem in unpacking a zip file containing subfolders on PharLap. Unpacking attached zip file results in error: Open/Create/Replace File in ZLIB Read Compressed File__ogtk.vi->ZLIB Get File__ogtk.vi->ZLIB Extract All Files To Dir__ogtk.vi->Untitled 2.vi<APPEND> C:\q\qqqqqq/IOExport.csv It seems that the separator decoding does not work properly, so I have looked inside lvzip.llb\ZLIB Common Path to Specific Path__ogtk.vi: Here I see no case for Pharlap (neither for modern windows), while I guess that it should convert common path "/" separator to PharLap's "\". Is my guess correct? I am using ZLIB version 1.2.3 and LabVIEW2017 q.zip

The sole advantage in my opinion is ability to connect LabVIEW application with systems that use MQTT. I see no point in using MQTT for connecting between two LV applications.

I have worked extensively with LabVIEW and MQTT. Indeed LabVIEW does not have any really good libratry for that. I have worked a bit with @cowen71 to put together some good functionality. We wanted to make it more "reusable" and release it to broader public, but when it reached the amount of features that served our private purposes - the momentum stopped. Here is a library https://github.com/mradziwo/mqtt-LabVIEW/ which is not perfect as I say, but allows for asynchronous calls to MQTT, and some event-based callbacks. If you would be willing to join the team to bring it to "publication" state, we would be more than happy to collaborate on that.

Most likely library calls, or names of .Net classes. In the first case make sure that all pointers are 64bit, in the latter one need to make a switch case or object based solution to choose proper constructors based on "bittyness" of the LV execution system.

Hello Neil, I do some DL programming mostly based on TensorFlow through Python. If ML/AI group will be created, I'd definitely would like to join it !

I can also report similar behavior. What is more - by complete random choice of constructor - I have got a I32 output rather than reference.

That sounds indeed like a gap-matching tool when it comes to calling LabVIEW code from Python! I am urged to try it out ASAP, as I see that romance between LabVIEW and Python has already started, but still misses the spark. TestScript indeed promises a lot to kindle up this fire.

Is there a possibility in your library to get a sub element as json formatted string. I mean to get from json string: { "field1": 1, "field2": { "item1":"ss", "item2":"dd"} } the item field2, and expect it will return a string containing: { "item1":"ss", "item2":"dd" }