Emerson Exchange 365

DVLive Async functions not correctly waiting

Hi all,

I've got a variant of the PCSD EM faceplate for a different library based on earlier PCSD v12. The 'Release' button script sometimes fails to write OWNER_ID, result in a situation where both OWNER_ID and PREV_OWNER have a value of 'Operator'. This renders the buttons useless and requires intervention. But the script is very similar to the PCSD stock script for the same function, so I can't seem to figure it out. In essence, it reads OWNER_ID and PREV_OWNER, then if OWNER_ID = "Operator", switch the values. Code below:

let sPreOwner = await DLSYS.CondReadAsync(Dsp.Tag+'/PREV_OWNER.CV',undefined);
let sCurOwner = await DLSYS.CondReadAsync(Dsp.Tag+'/OWNER_ID.CV',undefined);
let sQueue = await DLSYS.CondReadAsync(Dsp.Tag+'/ARB_MOD.CV',undefined);

if (sPreOwner != undefined && sCurOwner != undefined && sQueue !== undefined){
if (sCurOwner == "Operator" && sQueue == ""){
await DLSYS.WriteAsync(Dsp.Tag+'/OWNER_ID.CV', sPreOwner);
await DLSYS.WriteAsync(Dsp.Tag+'/PREV_OWNER.CV', sCurOwner);
}
else{
await DLSYS.WriteAsync(sQueue +'/'+ Dsp.Tag+'/PRIO_REQ.CV', 5);
await DLSYS.WriteAsync(sQueue +'/'+ Dsp.Tag+'/RELEASE.CV', "(None)");
}
}

This problem only happens the first time the faceplate is opened during a DVLive session, and seems the problem is always failure of the line where sPreOwner is being written to OWNER_ID. What am I missing?

Phil L

• 8 Apr 2022 7:07 PM
• Cancel

7 Replies

• Matt Stoner

  

  • 8 Apr 2022 7:40 PM

  Based on your logic it will only do the logic if the OWNER_ID is "Operator" and then it writes whatever is in the PREV_OWNER which you describe it being "Operator" so it is doing the write but taking the "Operator" from PREV_OWNER and writing it to OWNER_ID and then writing the same value of "Operator" back into PREV_OWNER.
  
  I think you should be setting PREV_OWNER in the 2nd write to '(None)' and then it should work properly.

  • Cancel
• Phil L

  

  • 8 Apr 2022 8:28 PM

  In reply to Matt Stoner:

  The scenario this comes into play is primary held batch processing. The Hold logic enables the operator to acquire the EM, so OWNER_ID becomes ‘Operator’ and PREV_OWNER usually has a value of the containing unit module (for instance ‘UM_SUB-03’.
  
  The RELEASE button is only visible with OWNER_ID = ‘Operator’. So the intent is to return the previous owner to the current one, and shuffle ‘Operator’ into the PREV_OWNER parameter.
  
  That’s why I have the async reads at the top- to store the “starting” values in temporary variables and allow me to write both of them later without one write impacting the other.
  
  The conditional to check “!= undefined” is intended to wait until the earlier reads complete. The fact that anything is happening at all means I’m satisfying that, but somehow the line setting OWNER_ID = sPreOwner is failing and I don’t understand why. It’s also only failing the very first time the script is run, so I feel like it’s a problem in how the variables are being initialized. It’ll run 100 times consecutively after that with no errors.

  • Cancel
• Matt Stoner

  

  • 8 Apr 2022 9:14 PM

  In reply to Phil L:

  The != undefined only does that check on the result of the async read. I can't remember for sure but I think there was an issue awhile back with async reads/writes so make sure you are on at least workstation hotfix 25 on the LTS release.

  • Cancel
• Phil L

  

  • 2 May 2022 6:00 PM

  In reply to Matt Stoner:

  I've been battering my head against the wall for a couple weeks now, and still no luck. My system has both the PCSD-variant I asked about earlier, as well as stock PCSD. Here's the 'stock' PCSD script:

  let bOvrEnab = await DLSYS.CondReadAsync(Dsp.Tag+'/OVR_ENAB.CV',undefined);
  
  let sPrevOwner = await DLSYS.CondReadAsync(Dsp.Tag+'/PREV_OWNER.CV',undefined);
  
  let sQueue = await DLSYS.CondReadAsync(Dsp.Tag+'/QUEUE/RELEASE.CV',undefined);
  
  if (bOvrEnab != undefined && sPrevOwner != undefined){
  
     if (bOvrEnab && sPrevOwner !== ""){
  
         await DLSYS.WriteAsync(Dsp.Tag+'/OWNER_ID.CV', sPrevOwner);
  
         await DLSYS.WriteAsync(Dsp.Tag+'/PREV_OWNER.CV', '(None)');
  
     }
  
     else{
  
         if(sQueue != undefined)
  
            {
  
             await DLSYS.WriteAsync(Dsp.Tag+'/QUEUE/RELEASE.CV', '(None)');
  
            }
  
          await DLSYS.WriteAsync(Dsp.Tag+'/OWNER_ID.CV', '(None)');
  
     }

  This script also malfunctions the very first time it's executed after opening the FP. The result here is that both OWNER_ID and PREV_OWNER result in values of '(None)', which causes an inescapable hold loop. The equipment this code runs on has a drastically lower rate of holds, so this bug appears to have been undetected for 2 years.

  Reproducibility:

  1) Set OVR_ENAB = 1, OWNER_ID = "TEST_STRING"

  2) Open Faceplate, hit 'Acquire' button [OWNER_ID = Operator, PREV_OWNER = TEST_STRING]

  3) Hit 'Release' button [script waits extra time, OWNER_ID = (None), PREV_OWNER = (None)

  • Cancel
• ShaneG

  

  • 2 May 2022 6:31 PM

  In reply to Phil L:

  I think it may be due to comparison operator !== in the line #9 "if (bOvrEnab && sPrevOwner !== ""){ ...
  Perhaps try using !=

  • Cancel
• Matt Stoner

  

  • 2 May 2022 8:37 PM

  In reply to Phil L:

  The script is correct as written but have you logged a call with the GSC on this issue as this seems to be a product issue?
  
  You have found an instance but I would be worried that there could be other instances in the system performing like this unnoticed.

  • Cancel
• Phil L

  

  • 2 May 2022 9:02 PM

  In reply to Matt Stoner:

  I just uncovered the PCSD implications today, going to go through GSC tomorrow. Here's to hoping there's simply a hotfix we're missing.

  • Cancel