Use Auto Schedule dynamic lock

[Nimgaard]

Hello

The setup is as follows:

My customer wants to run 4 individual test fixtures off the same PC. Each test fixture will run at least 4 parallel tests at the same time using the parallel model. For now we can assume that it is the same sequence that is executed across all sockets and fixtures. This may change but the same lock conditions will persist over different sequences.

What i need to do is to lock steps and resources, both internaly in a fixture and across all fixtures. Here is where my problem lies.

If i use a regular lock then i can acomplish this, all i need to do is keep track of what fixture is actually executing the steps. I can lock on a parameter, say Parameter.Fixture. Or just lock globaly ignoring what fixture is actually executing.

But if i try to Use Auto scheduling then this will not work. Im not all that familiar with the auto schedule functionality but it looks like if i use the same parameter, it locks on the actual parameter rather than the value the parameter holds. What i then tried was to use an array as the lock, the expression would then typically be Locals.Locks[Parameter.Fixture]. But this didnt sit well with the execution that threw me a -17502 Error. I cant use double lock expressions as that may allow a single fixture to aquire them both.

The customer would like to use auto scheduling to lower test times. Typically there would be a unique instrument used over all fixtures that would be treated as a single resource, while some test steps cant be executed at the same time within a fixture (radio tests which intereferes across sockets).

Anyone have an idea on how to create a dynamic lock expression that the step will accept, or have i missed something fundamental with the Auto Scheduling step?

/ Nimgaard

[James_Grey]

Each resource lock alternative is an expression, so it should be evaluating it. Are you incorrectly surrounding it with quotes?

If not, try posting an example file of what is not working for you.

[dowNow]

Hi,

Are you over-thinking it? The way I understand it you have 16 sockets and one sequence. One instance of the sequence runs on each socket.

Take all the other locks out and try putting one auto schedule resource section around each shared part of the sequence. You shouldn't need to know what fixture it is on, or any parameters, or dynamic lock expressions. If you are not familiar with auto schedule then run the AutoSchedule.seq example to figure out how to place the steps. I would run the example sequence on all your fixtures to really get the hang of it.

cc

[James_Grey]

Dow Now jogged my memory. You are correct in that the autoschedule does not support resource name expressions that evaluate to different values in different threads.It assumes each block is protecting the same resource in every thread.

There is currently an internal tracking record # 306805 for the suggestion of supporting this feature. If you would like to see this in a future version of TestStand, you might also want to post support for it on the TestStand Idea Exchange

[Nimgaard]

Thanks for the input.

@James: Ok, then i think i got it right. I will probably post in the suggestion as i think it would be better to support lock on what the expression evaluates to rather than the component of the expression itself. I can however see why it works as it does because if you got an instrument handle then its easy to just use that handle as the lock. And when you look at the examples, it looks like actual hardware on a single test environment is what was in mind.

@dowNow: I cant do that because each fixture has its own hardware. If i put a global lock they will wait for each other which will create unnecessary long test times, and if i put one lock/hardware then any fixture can access hardware it doesnt have physical access to. At the same time, the customer wants to run it all in one application on one computer, the idea is to be able to have an operator load the different fixtures and run the tests without having to run between stations/computers. I checked the example and placing the steps is easy enough. I also have it running correctly with regular locks but that will also increase the test times as the internal resources in the test equipment will have to wait in sequence instead of using the first available resource.

Another question:

The issue is obviously tied to the OI as they want to run it on one computer, if they didnt want that then it wouldnt be a problem really. As far as i can tell, all executions are shared within the same AppManager. Would it be right to think that sequences that run on different AppManagers wont share locks, and if so, is it possible to have more than one AppManager in a single application?

Another way to solve it that comes to mind is to have each fixture access a slightly modified copy of the master file with different names on the locks. Obviously not ideal to handle code like that though.

/ Nimgaard

[James_Grey · Accepted solution]

Note that you can get an effect similar to autoscheduling by  using locks with multiple threads (sequence calls have an option to run in a new thread). If each thread locks the resource it needs, it will run when the resource becomes available. The operations (threads) for one fixture might run in a different order than those for another, based on resource availability, thus optimizing throughput. If you want to force the operations to not overlap, say for a particular fixture, you can have each thread lock both the resource it uses and the fixture it uses.

[Nimgaard]

That might be a way to solve the problem. I will look into this when i start working on the solution again after the holidays. And it seems to a better solution than having multiple files, even if its perhaps a bit more complex than the auto scheduler, it still solves the problem in code.

Thanks for the input, and happy holidays!

/ Nimgaard

[Nimgaard]

I have looked into it a bit more and considering how it works with Autoscheduling i have marked your last answer as the solution James.

I found that i can speed up the execution a bit by using locks in new threads. However it will not easily do the same free execution as the auto-scheduler. I have to work a bit on optimizing it, its however faster than just locking in a more ordinary way.

Thanks again for all the input.

/ Nimgaard