Hi Kevmi2ca,
A few things I noted while traveling down a path similar to yours.
1. When I tried disabling the sockets too early in the batch model it didn't work. In your case, maybe the disable flag is being overwritten sometime after the "Get Model Options" location.
2. Tried to modify the "Initialize TestSocket" sequence but caused a number of unwanted effects.
3. I also tried to disable sockets and the standard serial number popup dialog by modifying the "Run Batch Info Dialog" called by the "Start Batch Info Dialog" step. I caused the model to run in an endless loop when I disabled the "Run Dialog" step and added a socket disable statement.
4. Based on some info I found here, I tried using the PreBatch callback. From the batch model FileGlobals, I pass a boolean array called SlotActiveArray (True = Slot is active) to the PreBatch callback through parameters. I set up a PreBatch callback in my client sequence and use a statement with a fixed loop to set the disable.
Parameters.ModelData.TestSockets[Locals.LocalCounter].Disabled != Parameters.SlotActiveArray[Locals.LocalCounter]
Note: I found that if I disable all slots then the software goes into an endless loop during execution. So I added some steps to my PreBatch callback to check Parameters.ModelData.TestSockets.Disabled to make sure they are not all disabled. If they are, I terminate the sequence with a message to the operator.
Don't know if this is useful as I am relatively new to modifying process models but the callbacks seem to be pretty powerful. I modified my project to include a single top-level client sequence that calls all of the other test sequences just to let me take advantage of the callbacks.
Good Luck,
Steve S.
