pawhan11

Thanks for comment. I have tried this approach but outcome is the same. Tried full version names like v4.8.4084.0 etc

I am trying to build Labview library and call it from .NET application. My app is build in .NET 4.8 but labview builds my library to 3.5. Is there a way to change it?

I remember having one cRIO that crashed randomly, it turned out it was somehow related to reading ini file. For some reason this ini was read from time to time in app, when it was changed to read only once at startup it solved the problem. When we got desperate we started to add syslog messages for all state machines states and logging it into db to see if it was related to some code...

Problem is that System is aware of ITransport that does not have IDispose. It would require cast after uninject function to TCP to call dispose.

I started to play with LabVIEW interfaces and have some general architecture problems. Assume we have - IDisposable interface with single Dispose method used to clear resources - ITransport interface with Read and Write methods to pass some data - ISystem interface with ReadTime method - TCP transport implementing IDisposable and ITransport - System implementing IDisposable and ISystem TCP is injected into Sysem by main method, who should be responsible of calling Dispose on TCP? My thinking is that object that was responsible for its creation - in this case main.vi. But this leads to problem of passing TCP class on main.vi Shall ITransport implement IDisposable? My thinking is it should not - we have no guarantee that all Transport will require Dispose. The same goes for System. This leads to problems of having to pass concrete implementation all over the system just to close it when required. Another solution would be to implement additional factory classes that would move instantiation of Transport into System, but then it must implement IDisposable. What would be the best way to approach it? For now I enforced IDisposable on ITransport and ISystem Example.7z

@Gribo Have You used OpenTAP in commercial applications? Are You able to compare it to NI Teststand?

Thanks for sharing !

Mostly cutting costs and company wants to go into open source solutions. Existing systems will stay as they are now until decommissioned, hardware will be reused where possible , question is about how we approach new projects. NI is too expensive compared to other vendors on the market and we are not having complex systems that require high end hardware they offer. For example we have high end pxi scope cards to measure ac frequency and phase rotation from the grid And also other our observations of NI software portfolio in general: - LabVIEW is in decline, from what i hear they dropped support for universities, in EU they closed offices in many countries. We are trying to develop new test systems in .net and see how it goes. - No significant new features and roadmaps, unknown future of the language. They killed NXG and announced it on forum post!... Hope this new NI Conect will change my mind.

Has anyone here successfully migrated from TestStand to some open source automation frameworks? In our hardware test we have a lot of things happening in parallel and so far I haven't found reliable alternative for TS.

Attached working proof of concept with LabVIEW CLI, To make it work: Disable Error message on logger instance (FGV in C:\Program Files (x86)\National Instruments\Shared\LabVIEW CLI\Operations\Utilities\Logger) Enable multiple instances of LabVIEW Spawn few labview processes that will run Builder.vi and pass instance parameter eg \..\..\Labview.exe \..\..\Builder.vi -- 1 Copy ExecuteBuildSpecAsync_class folder to C:\Program Files (x86)\National Instruments\Shared\LabVIEW CLI\Operations Start it the same way from labview CLI but use ExecuteBuildSpecAsync insstead of ExecuteBuildSpec, should compile on free running builder or throw exception builder.zip

Seems that it is not possible directly using LabVIEWCLI, i managed to 'cheat it' by starting multiple LV instances, one instance was building big proj that takes 30 min, another instance did simple library that takes 40sec, they seemed to work independently and time of individual builds did not increase.

I have app with 30 PPLs that have to be compiled before main application. It takes huge amount of time (30min) for build, probably due to heavy use of classes. I use simple powershell script to execute those builds in order, but most of them could be executed in parallel. Is it possible to start multiple instances of LabView CLI to 'cheat' this?

@ShaunR I might have formulated question incorrectly 😁 I want 3 separate functions that have: - variant input and return 1d array of variants when input variant is array (any dimension any data type in array) - variant input and return array of variants when input variant is set (any data type in set) -variant input and return variant pairs of key values when input is Map (any data type of key and value in map) For Maps and Sets I can get type info using Type Parsing Library but not the actual, the only way i see is digging into type descriptors...

Nice, but I require the input to be variant, not an array.

For arrays i came up with this, dimensions are handled up to 10 For maps and sets it seems there is no way to cast them to variant arrays... Edit. I am lost now, according to my logic 2 on the bottom should be possible: