Use Auto Scheduled Resource Blocks Not Using All Available Resource Lock Alternatives

[Will_S.]

Hello,

I am attempting to use TestStand with the Batch process model. I will be running batches of 8 DUTs. Most of my tests have dedicated hardware, some use shared resources. As far as I can tell (and according to NI support) the fastest way to execute my test is to configure all tests in Use Auto Scheduled Resource blocks, and simply create enough Resource Lock Alternatives for the 8 DUTs to use dedicated resources in parallel. 

If I create a single Use Auto Scheduled Resource block with 8 Resource Lock Alternatives, it works perfectly. All 8 DUTs run the test in parallel. However, if I add a second Use Auto Scheduled Resource block with 8 Resource Lock Alternatives (named the same as in the first block, or with new unique names) TestStand only uses 4 of the 8 Resource Lock Alternatives and my test takes twice as long as it should. 

Is it possible I am missing a setting, or am configuring things incorrectly? I have attached a simple sequence that demonstrates what I am trying to do, and a screenshot of how TestStand is executing it. TestStand 2014.

Thank you for the help!

Will

[~jiggawax~]

If it were me I would only use the auto-scheduler for shared resources.  Why would you need it for non-shared resources.  That doesn't make sense.  It's just extra code that is not necessary.

Regards,

[Will_S.]

By autoscheduling with non-shared resources I can organize my test execution more efficiently. Otherwise I would have a block of parallel tests followed by a group of tests that wait for shared resources. By mixing them I can execute tests with shared resources while others are using dedicated resources.

[~jiggawax~]

Understood.

I learned something about the Auto Scheduler here.  Basically, it is smart enough to know that if a Resource section, regardless of how many locks, is being used then it goes onto the next Resource section.  This is why you are seeing that behavior.  Only when it circles back around does it enter that Resource section if a lock is available.

I've attached a modified sequence file that demonstrates this.

So basically you are seeing the behavior you coded!

BTW- you do not need to have different lock names for each Resource section.  See my attached sequence.  Also notice that one of the sections is just using 1 lock (Trying to simulate your environment)

Hope this helps,

[Will_S.]

Hi Jigg,

I'm sorry but I guess I don't understand how I coded the behavior to not execute steps in parallel? If I use your sequence and replace the dialog boxes with waits, or with LabVIEW action steps, I still see the sequential execution of the various steps (and sometimes it just hangs on the DMM step indefinitely), instead of parallel execution.

If I only have 1 test step, it will execute all of the DUTs in parallel, as desired.

Thanks again, 

[~jiggawax~]

So it is understandable that you are only using 4 of the resource locks.  Each socket doesn't care which lock it uses.  It just grabs the first one that is available.  And because the auto scheduler is smart enough to level load the sockets for each of the Resource sections then with 8 sockets you will only use the first 4 locks for each section.  Because there will only be 4 locks in a section at a time (assuming each section takes the same amount of time).  If they don't take the same amount of time then you will see all the locks get used.  For instance you could set one section to have a 15 second wait and the other section to have a 1 second wait.  You will then see all the locks get used in one of the sections.

I'm curious how you came to the conclusion that it takes twice as long?  Of course it takes twice as long because you have 2 sections instead of 1.  Look at your execution times on the report.  They should be the same for all sockets.  And when I run your sequence file they turn out to be what I expected.  Approximately 3 seconds each.

Maybe I'm misunderstanding your concern here?

[Will_S.]

This is what I have, what I expect, and what I see:

What I have:

1.    2 Use Auto Scheduled Resource Blocks

2.    Each block is configured with the same number Resource Lock Alternatives as there are DUTs (i.e. 4 DUTs, 4 alternatives)

3.    The first Use Auto Scheduled Resource Block contains a Wait of 2 seconds

4.    The second Use Auto Scheduled Resource Block contains a Wait of 5 seconds

What I expect:

1.    There are enough Resource Lock Alternatives to execute each DUT in parallel, so the total test should take 2 + 5 = 7 seconds, regardless of execution order. Maybe a little longer for overhead.

What I see:

1.    TestStand only uses half of the available Resource Lock Alternatives at any given time.

2.    As a result, the test takes more than twice as long (18 seconds in the case of 4 DUTs)

This behavior doesn't change if I use a Reentrant VI in a LabVIEW Action Step, or if I configure the step explicitly to run in parallel. 

As you can see in the attached screenshot, there are periods when a DUT socket isn't executing at all, even though there is an available Resource Lock Alternative for it to execute the remaining test.

[~jiggawax~ · Accepted solution]

I can't reproduce your behavior.  I have a quad core with all "logical" threads turned on.  So a total of 8 threads.  I modified your sequence file to do 16 UUTs to see if it would slow down.  I still see around 7 seconds per report.

We know it isn't the sequence file, since I'm running your sequence file.  My guess is there is another setting somewhere.  Either in TestStand or in your OS that is causing this.

Have you modified the Batch Model?  I am using the out of the box one.  Which version of TestStand?  I have 2014.  In Station Options>>Preferences what is your CPU Affinity set to?  Mine is -1.

Regards,

[Will_S.]

Aha! That is indeed the disconnect. Moving to a quad core certainly helped. On top of that, I noticed that my Batch Model had default batch synchronization to Parallel. Switching it to No Synchronization pushed it the rest of the way. I now execute all items in the appropriate amount of time (using half the resources, as would be expected). Issue resolved.

Thanks, jigg!

Will