LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Simultaneous multi-channel operation

Hello All,

Looking for some guidance here. A simplified summary of the application is the user scans a unit SN (battery equalizer) and the channel on a 10-channel rack. This creates a Test Id and calls the control vi asynchronously (call and forget), there is a separate identical control vi for each channel. Each non-reentrant control vi runs independently and completes 80 minutes of various tests. The subvi's in the control vi that do not use a hardware resource I have made reentrant vi's, the vi's that cannot be reentrant (use a hardware resource - DAQ for measurement or relay switching) I am calling asynchronously (call and forget). There are also some non-reentrant vi's that need to complete before moving to the next step, so I am calling these by reference so I can close the reference after they complete. These are very simple vi's that run very quickly but I think this is where the issue is, these vi's seem to be held too long. Everything works but I am seeing some performance issues because of "subvi waiting to run" but I haven't been able to identify what is holding the vi. I am not against completely refactoring the application. As a last resort I could switch to testing in batch mode to maintain sequential flow, but I would prefer to maintain individual channel control. I am using global variables, but I don't believe this is the cause of any issues. A GV channel status is shown on the front panel (available, testing, pass, fail) and a GV stop flag exists for each channel to stop the control vi if there is a test failure.

0 Kudos
Message 1 of 5
(144 Views)

Hi Shawn,

 


@ShawnH wrote:

Everything works but I am seeing some performance issues because of "subvi waiting to run" but I haven't been able to identify what is holding the vi.


I guess another "control VI" running in parallel is blocking the subVI from running…

 


@ShawnH wrote:

Looking for some guidance here.


Guidance for … what exactly?

 

It's hard to guide when you don't show any code…

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 2 of 5
(127 Views)

It was not allowing me to edit the posting, but I attached a control vi here. I still need to do the vi cleanup and documentation, but the test rack functionally works as designed on all channels. It's just the more channels you scan in, the slower things process. This application is intended to run 10 control vi's simultaneously but independently. When I scan in 3 channels the timing is minimally affected but that increases with every channel scanned. For a point of reference, I am controlling about 50 pieces of equipment and using the DAQ to measure voltages and currents through shunts and current sensors and saving all the data to a database. All of my test platforms I have built to date were single channel with sequential flow, so simultaneous multi-channel control new to me. It has been a fun project, but I would like to wrap it up now.

0 Kudos
Message 3 of 5
(67 Views)

Hi Shawn,

 


@ShawnH wrote:

It was not allowing me to edit the posting, but I attached a control vi here.


Mind to downconvert your VI for LV2019? I don't use any of the latest LabVIEW versions yet…

 


@ShawnH wrote:

When I scan in 3 channels the timing is minimally affected but that increases with every channel scanned. 


Isn't this behaviour "as expected"? (From your description it sounds like there are shared resources and you need to process/handle the hardware sequentially…)

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 4 of 5
(29 Views)

There are shared resources, but the subvi's process very quickly so I wouldn't expect them to substantially slow down the main vi's. LabVIEW automatically queue's up calls to non-reentrant vi's and processes them sequentially. This is where I don't have a full understanding yet, this automatic queue and dequeue seems to be taking too long and I believe this is what is causing my issue.

If I can't get this figured out, I may refactor the project and use 1 control vi that is a for loop inside of a while loop. Each iteration of the for loop would manage 1 channel. This would maintain sequential flow and solve the issues I am having now. I just have put a good bit of work into independent channel control by using 10 simultaneous threads and would like to see if I can get the performance I want in this manner.

 

GerdW

I will down convert the vi and add it, but they may not be today.

0 Kudos
Message 5 of 5
(16 Views)