Use a variable for Lock Alternerative in Use Auto Scheduled Resource step

[I_Break_Things]

I'm trying to use a variable to define the "Resource Lock Alternative" in a "Use Auto Scheduled Resource" step and it's not resolving the variable name into a value.  What I mean is this.  I'm running Parallel Model and I've established a string variable FileGlobals.LockName.  In a Statement step, this variable is assigned a value of ("Lock" & Str(RunState.TestSockets.MyIndex)) So I'll get string values of Lock0, Lock1, Lock2, etc... for each parallel socket of the sequence.  However, when I look at the value of "Acquired Lock" output from the Auto Schedule step, the lock assigned is litterally "FileGlobals.LockName" and not Lock0, Lock1, etc... 

What I want to happen is this.  I want a lock that is active within each parallel socket, but not across sockets.  Each UUT has an RS232 serial device connected to it.  For a given UUT there is a sequence called as a new thread sending a command to the serial device to request a status update every 5 seconds.  The main sequence will occasional send a command to make an adjustment to the serial device.  So within a given UUT, I need to put a lock on the serial device when sending/recieving the various commands to avoid COM erros.  However, since there is a seperately connected device for each UUT, I do NOT want to lock across the sockets as this would create unecessary delays.  Since the auto schedule step is naming the lock "FileGlobals.LockName" it IS using the same lock across all sockets. 

Feels like a bug to me that it's using the variable name and not the variable value as the string. 

I've attached a simple sequence to demonstrate (yah, infinite loops are bad).  A watch on the 3 FileGlobal variables will help see what's happening (AL = Acquired Lock).  As attached I've skipped the "Call Sequence" step.  Using the parallel model with 3 test sockets, I expect to see 3 pop ups, one for each socket.  They would say Main0, Main1, and Main2.  Instead, I only see one at a time because the lock applies across all sockets.  If I abort all then set run mode back to normal for the skipped sequence call, I expect to see 3 pop ups again, but they would say either Main or Other.  So I might have something like Main0, Other1, Main2.  If I acknowledge Main0, I should then see Other0, Other1, Main2.  Acknowledge Other0 and I go back to seeing Main0, Other1, Main2.  That's not what is happening.

Anyone know how to get the Auto Schedule to work or do I need to have a completely different way of doing this?

[Daniel-E]

Hey I_Break_Things,

Generally, the Auto Schedule function is intended for situations where you have several steps or sets of steps that all needed to be completed, but the order is not important. Generally, the locks will be shared across sockets to ensure that none of the tests are executed on more than one socket at the same time.

It sounds like your application is a bit different; you want to execute your tests in a specific order, but there may be some situations in a test sequence where you need to communicate with a device and you want to ensure none of the other threads in that socket are accessing it. If that is the case, I think you would be better off implementing the lock yourself. You could use a Create Lock step at the beginning of the sequence to generate a new lock for each socket.

The reason you see "FileGlobals.LockName" in the Acquired Lock output is because that output contains the exact, unevaluated lock expression used. For further information on that, please see the Help page for the step.

I hope this helps, and let us know if you have any further questions, or if I misinterpreted your goal with the test sequence.

[I_Break_Things]

Thanks for the prompt reply. 

I had considered creating locks manually and tried it too.  However, I didn't see the behavior I wanted and after a few iterations I always get an error message (see attached).  The way I tried is attached as LockStep_BasicLock.seq.  I've always used autoschedule so I am admittedly not as familiar with building the locks manually.  You will likely spot a glarring error in what I've done with this sequence.

I did find one way that gives me the exact behavior of what I'm looking to do by using the Synchronization Property of the step I want to put the lock on.  See LockStep_SyncProp.seq.  Notice how each socket has it's own pair of Popups that alternate as you acknowledge each one.  There is a lock within each UUT, but it doesn't have an effect on the other UUT's.  This might be my best hope, but I need to have a Time Out on the lock.  Doesn't matter for the simple example, but the timeout is my way of detecting that a serial communication error has occured in the actual test application I'm writing.  Since the real application step is an action to call a VI, I can probably implement some logic in the VI to handle the timeout for me.  Seems like the long way around though. 

Still would like to know why the variable name I created (FileGlobals.LockName) would work as the name of the lock for the sync property of a step and not work for the name of the lock in the auto schedule step. Even if the Acquired Lock output only shows the unevaluated lock expresion, shouldn't the step itself actually be using the evaluated value?

And one other thing.  Your understading of my application sounds almost correct.  However, there isn't a specific order of test execution. I just have to make sure that two threads within one socket don't try to talk to a device at the same time.  One thread talks to the device on a very reagular basis (a timed loop).  The other thread sends commands at unknown times based on a variety of sensor feedback from the UUT.