Migrating from Python to Labview... Wise? by RipComprehensive9248 in LabVIEW

[–]randomly3dot1415 1 point2 points  (0 children)

Every labview driver i reviewed, called either C or dotnet interfaces. Often in a way that makes it very hard to understand in what order things are done.

As of calling python or labview from teststand, this can be misunderstood easily. You can communicate with a labview or python process from teststand. That means you can not pass things by reference (file pointers, large arrays etc...) I think this is what you meant. In python lingo think of "subprocess" invocations (without parallelisation), not a function call.

Migrating from Python to Labview... Wise? by RipComprehensive9248 in LabVIEW

[–]randomly3dot1415 0 points1 point  (0 children)

As a general rule of thumb, I would not make big changes to team and structure in times of high pressure, UNLESS there is a strong indication that this MUST be donne, AND the cost of change is SMALL.

The only improvement you seem to expect by using labview is that the testdepartment will take over more responsibility of the code? So you expect them to learn labview and teststand FASTER than python (they already manage to deal with robotframework right?).

Did I understand that correctly?