Set Pulse duration not correct when used alongside "Low when not running" and Safeguard Stop event

Steps to reproduce:

  • configure DO0 to have “Low when not running” action enabled
  • Create an empty Program
  • add Set node, pick Set Single Pulse, choose DO0
  • add Wait node, choose 10s
  • Run program, go in IO tab, observe the DO0 toggling HIGH/LOW for 5s long
  • When DO0 toggles HIGH, pause program, DO0 toggles to LOW
  • Resume program execution, DO0 does not toggle back to HIGH, causing the Pulse length to be potentially much shorter than programmed and causing unexpected behavior

Expected behavior:
Set Pulse should guarantee the chosen duration, even in case of pause or safeguard stop when the “Low when not running” action is selected. We have a project where we risk overheating part of the tool if the Tool Out stays HIGH too long, the pulse duration has to be strictly never exceeded, so to prevent the output hanging HIGH in case of Safeguard Stop triggered by a safety scanner, we added the option “Low when not running” to make sure the output goes LOW and we do not overheat the tool. Problem is when program resumes the output does not go back HIGH and it can cause a crash since the tool is not enabled.

Actual Behavior:
The “Low when not running” action toggles the output LOW and it never returns to its HIGH state after resuming, causing unexpected behavior. The Set Pulse does not respect the chosen pulse duration.

Workaround Suggestion:
Set Pulse should guarantee that the output keeps its proper state even in case of program interruption such as Safeguard Stop or Pause. We currently have implemented a workaround by toggling a variable True/False when needing the beginning and end of the pulse, and a Thread watches this variable and sets the output HIGH or LOW, the output properly goes LOW when not running, and when resuming it goes back HIGH. But this would be easier to simply specify the Pulse duration.

Robot Serial Number:
observed on UR10 CB3

Affected Version(s):

  • Polyscope 3.15
  • tested also in Polyscope 5.13 simulator to check, the issue is still there