Correct way to use OLA in Python in a threaded way?

[sdbbs]

I have tried for a while to make OLA drive DMX in a threaded way in Python - so I could do something else in my main code, and change DMX in the thread at times when needed. However, I also find it necessary because of this:

• If OLA has started sending DMX (say, by using the sliders in localhost:9090), then it keeps sending DMX, even if values are at 0.
• If OLA is in the previously described state, then doing say python ./ola/python/examples/ola_send_dmx.py, which does client.SendDmx only once, then the new value will be effectuated on device (via DMX) for about a second or less, and then DMX will revert back to the previous settings (those that are set on the sliders in localhost:9090)

... otherwise I might have decided not to use threads (if say, I could have just said SendDMX, and the DMX value is held by OLA indefinitely). I've observed the above with the ENTTEC DMX USB PRO as OLA DMX interface, and OLA built from commit f69e4a6.

The challenge otherwise seems to lie in:

• "python does not provide any direct method to kill threads."
• ClientWrapper.Run() is a blocking call (until ClientWrapper.Stop() releases it)
• "CRITICAL:ola:SelectServer called in a thread other than the owner"

Best I could do is the code posted below (posted with all comments/misses I've made in developing it) - it works most of the time, except occasionally it makes a blink (the blink showing the data set by the sliders in localhost:9090, so it is black if the sliders are all set to zero). The thing is, I can see sometimes the fade "drag along", which is expected because of the printouts delay - but I'm not sure why the blink appears (I doubt that the printouts cause that much delay).

So my question is - what is the right way to use OLA DMX sending in a Python thread?

(it would also be nice, if ./ola/python/examples contained an example of this).

Edit: forgot to say the below is written in python3, with the patch in #1615

import sys, os
import time

from ola.ClientWrapper import ClientWrapper
from ola.OlaClient import OlaClient
# for DMX (SimpleFadeController)
from ola.DMXConstants import DMX_MIN_SLOT_VALUE, DMX_MAX_SLOT_VALUE, DMX_UNIVERSE_SIZE

# Note: array('B', ...) is `unsigned char`
from array import array
import threading

DMX_UPDATE_INTERVAL = 25  # In ms, this comes about to ~40 frames a second

class MySimpleDMXController(object):
  def __init__(self, universe):
    self._universe = universe
    self._update_interval = DMX_UPDATE_INTERVAL
    self._data = array('B', [DMX_MIN_SLOT_VALUE] * 10) # 10 slots by default
    self._wrapper = ClientWrapper()
    self._client = self._wrapper.Client()
    self.myDMXthread = None
    self.cbDMXstatus = None
    self.isDMXrunning = False
    self.wait_dmx_sent = False

  def resizedmxarray(self, newsize):
    self._data = array('B', [DMX_MIN_SLOT_VALUE] * newsize)

  def setdmxarray(self, inarr):
    while(self.wait_dmx_sent):
      time.sleep(0.001)
    if (len(inarr) != len(self._data)):
      self.resizedmxarray(len(inarr))
    for i in range(len(inarr)):
      self._data[i] = inarr[i]

  def DmxSentCallback(self, status): # does not get called if no _wrapper.Run()!
    self.cbDMXstatus = status.Succeeded()
    print("dmx callback {}".format(self.cbDMXstatus))
    self.wait_dmx_sent = False

  def UpdateDmx(self):
    """
    This function gets called periodically based on UPDATE_INTERVAL
    """
    print("UpdateDmx")
    # Send the DMX data
    self.wait_dmx_sent = True
    self._client.SendDmx(self._universe, self._data, self.DmxSentCallback)
    # For more information on Add Event, reference the OlaClient
    # Add our event again so it becomes periodic
    if self.isDMXrunning:
      self._wrapper.AddEvent(self._update_interval, self.UpdateDmx)
    else:
      print("UpdateDmx exiting")

  #def UpdateDmxThread(self):
  #  print("UpdateDmxThread")
  #  t = threading.currentThread()
  #  # call once, so it starts the loop
  #  self._wrapper.AddEvent(self._update_interval, self.UpdateDmx)
  #  self._wrapper.Run() # the _wrapper.Run() command blocks, until _wrapper.Stop() is called! Also, this command triggers "CRITICAL:ola:SelectServer called in a thread other than the owner"

  def startDMX(self):
    self.isDMXrunning = True
    self.myDMXthread = threading.Thread(name = 'myDMXthread', target = self.UpdateDmxThread, daemon = False, args = ( ))
    self.myDMXthread.start()

  def stopDMX(self):
    # just set the variable - UpdateDmx should stop looping then
    self.isDMXrunning = False
    self._wrapper.Stop()
    if self.myDMXthread is not None:
      self.myDMXthread.do_run = False
      self.myDMXthread.join()
    print("DMX update thread stopped.")


  """
  # note: due to _wrapper.Run() blocking, best it can be done without threads,
  # is the below code; however, in that case, UpdateDmx printout hogs everything,
  # not even DmxSentCallback print has time to appear!

  def DmxSentCallback(self, status): # does not get called if no _wrapper.Run()!
    self.cbDMXstatus = status.Succeeded()
    print("dmx callback {}".format(self.cbDMXstatus))
    # if we stop the wrapper here, we won't get a loop, unless _wrapper.Run() is called from UpdateDmx!
    # but if we don't stop the wrapper, it hogs everything so much, not even the print in main loop has time to print out!
    # also, the _wrapper.Run() command blocks, until _wrapper.Stop() is called!
    self._wrapper.Stop()

  def UpdateDmx(self):

    #This function gets called periodically based on UPDATE_INTERVAL

    print("UpdateDmx")
    # Send the DMX data
    self._client.SendDmx(self._universe, self._data, self.DmxSentCallback)
    # For more information on Add Event, reference the OlaClient
    # Add our event again so it becomes periodic
    if self.isDMXrunning:
      self._wrapper.AddEvent(self._update_interval, self.UpdateDmx)
      self._wrapper.Run() # will block until stopped!
    else:
      print("UpdateDmx exiting")

  def startDMX(self):
    self.isDMXrunning = True
    # call once, so it starts the loop
    self._wrapper.AddEvent(self._update_interval, self.UpdateDmx)
    self._wrapper.Run() # the _wrapper.Run() command blocks, until _wrapper.Stop() is called!

  def stopDMX(self):
    # just set the variable - UpdateDmx should stop looping then
    self.isDMXrunning = False
    self._wrapper.Stop()
  """

def dmxFadeThreadFunc(controller):
  t = threading.currentThread()
  mydata = [0]*10
  for ix in range(0, 100):
    print(ix)
    mydata[2] = ix
    controller.setdmxarray(mydata)
    time.sleep(DMX_UPDATE_INTERVAL/1000.0)
  for ix in reversed(range(0, 100)):
    print(ix)
    mydata[2] = ix
    controller.setdmxarray(mydata)
    time.sleep(DMX_UPDATE_INTERVAL/1000.0)

# Note: with a simple olaObjThread, everything starts fine (without "CRITICAL:ola:SelectServer called in a thread other than the owner") - however, it is impossible to stop it (since _wrapper.Run() blocks, no way to intervene through a variable)
# (https://www.geeksforgeeks.org/python-different-ways-to-kill-a-thread/: "python does not provide any direct method to kill threads.")
def olaObjThread():
  controller = MySimpleDMXController(universe=1)
  print("startDMX")
  #controller.startDMX()
  controller.isDMXrunning = True
  controller._wrapper.AddEvent(controller._update_interval, controller.UpdateDmx)
  controller._wrapper.Run() # the _wrapper.Run() command blocks, until _wrapper.Stop() is called!

class OlaCtlThread(threading.Thread):
  def __init__(self, *args, **kwargs):
    super(OlaCtlThread, self).__init__(*args, **kwargs)
    #self._stop = threading.Event()

    # this here does not cause "CRITICAL:ola:SelectServer called in a thread other than the owner" - but cannot really control it:
    #self.controller = MySimpleDMXController(universe=1)
    #self.controller.isDMXrunning = True
    #self.controller._wrapper.AddEvent(self.controller._update_interval, self.controller.UpdateDmx)
    #self.controller._wrapper.Run() # the _wrapper.Run() command blocks, until _wrapper.Stop() is called!

    self.controller = None # just declare here; so stop has a reference

  def start(self):
    print("OlaCtlThread start")
    #self.controller = MySimpleDMXController(universe=1) # causes "CRITICAL:ola:SelectServer called in a thread other than the owner" even here
    #self.controller.isDMXrunning = True
    #self.controller._wrapper.AddEvent(self.controller._update_interval, self.controller.UpdateDmx)
    #self.controller._wrapper.Run() # the _wrapper.Run() command blocks, until _wrapper.Stop() is called!
    threading.Thread.start(self) # must be here, else run() does not execute! (this seemingly calls run())

  def run(self):
    print("OlaCtlThread run")
    self.controller = MySimpleDMXController(universe=1) # apparently, must instantiate here, so we don't get "CRITICAL:ola:SelectServer called in a thread other than the owner"
    self.controller.isDMXrunning = True
    self.controller._wrapper.AddEvent(self.controller._update_interval, self.controller.UpdateDmx)
    self.controller._wrapper.Run() # the _wrapper.Run() command blocks, until _wrapper.Stop() is called!

  def stop(self):
    print("self.controller._wrapper.Stop")
    self.controller._wrapper.Stop()

def main(args):
  # NOTE: this MySimpleDMXController *MUST* be instantiated in the thread that calls ._wrapper.Run() - else "CRITICAL:ola:SelectServer called in a thread other than the owner"!
  #controller = MySimpleDMXController(universe=1)
  #print("startDMX")
  #controller.startDMX()

  #olaThread = threading.Thread(name = 'olaThread', target = olaObjThread, daemon = False, args = (  ))
  #olaThread.start()
  #time.sleep(1)
  #olaThread.do_run = False
  #olaThread.join()

  # this is finally OK:
  #print("pre oc")
  #ocThread = OlaCtlThread()
  #print("pre oc start")
  #ocThread.start()
  #time.sleep(1)
  #print("pre stop")
  #ocThread.stop()
  #ocThread.join()

  print("pre oc")
  ocThread = OlaCtlThread(daemon = True)
  print("pre oc start")
  ocThread.start() # calls also run()

  while ocThread.controller is None:
    print("ocThread.controller is None")
    time.sleep(0.01)

  print("start dmxFadeThread")
  # somehow, things changed from 1 hour ago, so now tuple is not accepted for args - if using tuple, getting "TypeError: dmxFadeThreadFunc() argument after * must be an iterable, not MySimpleDMXController" - have to use list ?!?!
  fadeThread = threading.Thread(name = 'fadeThread', target = dmxFadeThreadFunc, daemon = True, args = [ocThread.controller] )
  fadeThread.start()
  print("wait for dmxFadeThread to terminate ...")
  fadeThread.join()

  print("pre stop")
  ocThread.stop()
  ocThread.join()


  #print("start dmxFadeThread")
  #fadeThread = threading.Thread(name = 'fadeThread', target = dmxFadeThreadFunc, daemon = False, args = ( controller ))
  #fadeThread.start()
  #print("wait for dmxFadeThread to terminate ...")
  #fadeThread.join()
  #controller.stopDMX()


# ENTRY POINT
if __name__ == '__main__':
  main(sys.argv[1:])

[brucelowekamp]

Have you tried without the sliders open? I believe the console UX simply sends their current settings once a second if left open, so you need to close that window if you’re not using it. I remember having that same issue when I accidentally left it open and couldn’t figure out why my code didn’t work. (I would think the console app could be changed to not do that, but never looked into it) Bruce

On Wed, Feb 12, 2020 at 6:16 AM sdbbs ***@***.***> wrote: I have tried for a while to make OLA drive DMX in a threaded way in Python - so I could do something else in my main code, and change DMX in the thread at times when needed. However, I also find it necessary because of this: - If OLA has started sending DMX (say, by using the sliders in localhost:9090), then it keeps sending DMX, even if values are at 0. - If OLA is in the previously described state, then doing say python ./ola/python/examples/ola_send_dmx.py, which does client.SendDmx only once, then the new value will be effectuated on device (via DMX) for about a second or less, and then DMX will revert back to the previous settings (those that are set on the sliders in localhost:9090) ... otherwise I might have decided not to use threads (if say, I could have just said SendDMX, and the DMX value is held by OLA indefinitely). I've observed the above with the ENTTEC DMX USB PRO as OLA DMX interface. The challenge otherwise seems to lie in: - "python does not provide any direct method to kill threads." - ClientWrapper.Run() is a blocking call (until ClientWrapper.Stop() releases it) - "CRITICAL:ola:SelectServer called in a thread other than the owner" Best I could do is the code posted below (posted with all comments/misses I've made in developing it) - it works most of the time, except occasionally it makes a blink (the blink showing the data set by the sliders in localhost:9090, so it is black if the sliders are all set to zero). The thing is, I can see sometimes the fade "drag along", which is expected because of the printouts delay - but I'm not sure why the blink appears (I doubt that the printouts cause that much delay). So my question is - what is the right way to use OLA DMX sending in a Python thread? (it would also be nice, if ./ola/python/examples contained an example of this). import sys, osimport time from ola.ClientWrapper import ClientWrapperfrom ola.OlaClient import OlaClient# for DMX (SimpleFadeController)from ola.DMXConstants import DMX_MIN_SLOT_VALUE, DMX_MAX_SLOT_VALUE, DMX_UNIVERSE_SIZE # Note: array('B', ...) is `unsigned char`from array import arrayimport threading DMX_UPDATE_INTERVAL = 25 # In ms, this comes about to ~40 frames a second class MySimpleDMXController(object): def __init__(self, universe): self._universe = universe self._update_interval = DMX_UPDATE_INTERVAL self._data = array('B', [DMX_MIN_SLOT_VALUE] * 10) # 10 slots by default self._wrapper = ClientWrapper() self._client = self._wrapper.Client() self.myDMXthread = None self.cbDMXstatus = None self.isDMXrunning = False self.wait_dmx_sent = False def resizedmxarray(self, newsize): self._data = array('B', [DMX_MIN_SLOT_VALUE] * newsize) def setdmxarray(self, inarr): while(self.wait_dmx_sent): time.sleep(0.001) if (len(inarr) != len(self._data)): self.resizedmxarray(len(inarr)) for i in range(len(inarr)): self._data[i] = inarr[i] def DmxSentCallback(self, status): # does not get called if no _wrapper.Run()! self.cbDMXstatus = status.Succeeded() print("dmx callback {}".format(self.cbDMXstatus)) self.wait_dmx_sent = False def UpdateDmx(self): """ This function gets called periodically based on UPDATE_INTERVAL """ print("UpdateDmx") # Send the DMX data self.wait_dmx_sent = True self._client.SendDmx(self._universe, self._data, self.DmxSentCallback) # For more information on Add Event, reference the OlaClient # Add our event again so it becomes periodic if self.isDMXrunning: self._wrapper.AddEvent(self._update_interval, self.UpdateDmx) else: print("UpdateDmx exiting") #def UpdateDmxThread(self): # print("UpdateDmxThread") # t = threading.currentThread() # # call once, so it starts the loop # self._wrapper.AddEvent(self._update_interval, self.UpdateDmx) # self._wrapper.Run() # the _wrapper.Run() command blocks, until _wrapper.Stop() is called! Also, this command triggers "CRITICAL:ola:SelectServer called in a thread other than the owner" def startDMX(self): self.isDMXrunning = True self.myDMXthread = threading.Thread(name = 'myDMXthread', target = self.UpdateDmxThread, daemon = False, args = ( )) self.myDMXthread.start() def stopDMX(self): # just set the variable - UpdateDmx should stop looping then self.isDMXrunning = False self._wrapper.Stop() if self.myDMXthread is not None: self.myDMXthread.do_run = False self.myDMXthread.join() print("DMX update thread stopped.") """ # note: due to _wrapper.Run() blocking, best it can be done without threads, # is the below code; however, in that case, UpdateDmx printout hogs everything, # not even DmxSentCallback print has time to appear! def DmxSentCallback(self, status): # does not get called if no _wrapper.Run()! self.cbDMXstatus = status.Succeeded() print("dmx callback {}".format(self.cbDMXstatus)) # if we stop the wrapper here, we won't get a loop, unless _wrapper.Run() is called from UpdateDmx! # but if we don't stop the wrapper, it hogs everything so much, not even the print in main loop has time to print out! # also, the _wrapper.Run() command blocks, until _wrapper.Stop() is called! self._wrapper.Stop() def UpdateDmx(self): #This function gets called periodically based on UPDATE_INTERVAL print("UpdateDmx") # Send the DMX data self._client.SendDmx(self._universe, self._data, self.DmxSentCallback) # For more information on Add Event, reference the OlaClient # Add our event again so it becomes periodic if self.isDMXrunning: self._wrapper.AddEvent(self._update_interval, self.UpdateDmx) self._wrapper.Run() # will block until stopped! else: print("UpdateDmx exiting") def startDMX(self): self.isDMXrunning = True # call once, so it starts the loop self._wrapper.AddEvent(self._update_interval, self.UpdateDmx) self._wrapper.Run() # the _wrapper.Run() command blocks, until _wrapper.Stop() is called! def stopDMX(self): # just set the variable - UpdateDmx should stop looping then self.isDMXrunning = False self._wrapper.Stop() """ def dmxFadeThreadFunc(controller): t = threading.currentThread() mydata = [0]*10 for ix in range(0, 100): print(ix) mydata[2] = ix controller.setdmxarray(mydata) time.sleep(DMX_UPDATE_INTERVAL/1000.0) for ix in reversed(range(0, 100)): print(ix) mydata[2] = ix controller.setdmxarray(mydata) time.sleep(DMX_UPDATE_INTERVAL/1000.0) # Note: with a simple olaObjThread, everything starts fine (without "CRITICAL:ola:SelectServer called in a thread other than the owner") - however, it is impossible to stop it (since _wrapper.Run() blocks, no way to intervene through a variable)# (https://www.geeksforgeeks.org/python-different-ways-to-kill-a-thread/: "python does not provide any direct method to kill threads.")def olaObjThread(): controller = MySimpleDMXController(universe=1) print("startDMX") #controller.startDMX() controller.isDMXrunning = True controller._wrapper.AddEvent(controller._update_interval, controller.UpdateDmx) controller._wrapper.Run() # the _wrapper.Run() command blocks, until _wrapper.Stop() is called! class OlaCtlThread(threading.Thread): def __init__(self, *args, **kwargs): super(OlaCtlThread, self).__init__(*args, **kwargs) #self._stop = threading.Event() # this here does not cause "CRITICAL:ola:SelectServer called in a thread other than the owner" - but cannot really control it: #self.controller = MySimpleDMXController(universe=1) #self.controller.isDMXrunning = True #self.controller._wrapper.AddEvent(self.controller._update_interval, self.controller.UpdateDmx) #self.controller._wrapper.Run() # the _wrapper.Run() command blocks, until _wrapper.Stop() is called! self.controller = None # just declare here; so stop has a reference def start(self): print("OlaCtlThread start") #self.controller = MySimpleDMXController(universe=1) # causes "CRITICAL:ola:SelectServer called in a thread other than the owner" even here #self.controller.isDMXrunning = True #self.controller._wrapper.AddEvent(self.controller._update_interval, self.controller.UpdateDmx) #self.controller._wrapper.Run() # the _wrapper.Run() command blocks, until _wrapper.Stop() is called! threading.Thread.start(self) # must be here, else run() does not execute! (this seemingly calls run()) def run(self): print("OlaCtlThread run") self.controller = MySimpleDMXController(universe=1) # apparently, must instantiate here, so we don't get "CRITICAL:ola:SelectServer called in a thread other than the owner" self.controller.isDMXrunning = True self.controller._wrapper.AddEvent(self.controller._update_interval, self.controller.UpdateDmx) self.controller._wrapper.Run() # the _wrapper.Run() command blocks, until _wrapper.Stop() is called! def stop(self): print("self.controller._wrapper.Stop") self.controller._wrapper.Stop() def main(args): # NOTE: this MySimpleDMXController *MUST* be instantiated in the thread that calls ._wrapper.Run() - else "CRITICAL:ola:SelectServer called in a thread other than the owner"! #controller = MySimpleDMXController(universe=1) #print("startDMX") #controller.startDMX() #olaThread = threading.Thread(name = 'olaThread', target = olaObjThread, daemon = False, args = ( )) #olaThread.start() #time.sleep(1) #olaThread.do_run = False #olaThread.join() # this is finally OK: #print("pre oc") #ocThread = OlaCtlThread() #print("pre oc start") #ocThread.start() #time.sleep(1) #print("pre stop") #ocThread.stop() #ocThread.join() print("pre oc") ocThread = OlaCtlThread(daemon = True) print("pre oc start") ocThread.start() # calls also run() while ocThread.controller is None: print("ocThread.controller is None") time.sleep(0.01) print("start dmxFadeThread") # somehow, things changed from 1 hour ago, so now tuple is not accepted for args - if using tuple, getting "TypeError: dmxFadeThreadFunc() argument after * must be an iterable, not MySimpleDMXController" - have to use list ?!?! fadeThread = threading.Thread(name = 'fadeThread', target = dmxFadeThreadFunc, daemon = True, args = [ocThread.controller] ) fadeThread.start() print("wait for dmxFadeThread to terminate ...") fadeThread.join() print("pre stop") ocThread.stop() ocThread.join() #print("start dmxFadeThread") #fadeThread = threading.Thread(name = 'fadeThread', target = dmxFadeThreadFunc, daemon = False, args = ( controller )) #fadeThread.start() #print("wait for dmxFadeThread to terminate ...") #fadeThread.join() #controller.stopDMX() # ENTRY POINTif __name__ == '__main__': main(sys.argv[1:]) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1616?email_source=notifications&email_token=ADNHN5J7MUK4U2GUIKJSTALRCQACVA5CNFSM4KT2SYY2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4IM6M3XQ>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADNHN5IADIP6Z7XKYJIDYLDRCQACVANCNFSM4KT2SYYQ> .

-- Sent from my mobile

[sdbbs]

Many thanks @brucelowekamp :

Have you tried without the sliders open? I believe the console UX simply
sends their current settings once a second if left open, so you need to
close that window if you’re not using it. I remember having that same
issue when I accidentally left it open and couldn’t figure out why my code
didn’t work.

Amazing - this seems to have been it! I removed all printouts but those in main(), and closed the browser tab which had the OLA sliders open - and now, I've ran the code about 10 times, no blink (else it used to blink each 4th or 5th time)!

Still, it would be good to know what is the proper/recommended way to use threads as in the example, since I feel the example I posted jumps through way too many hoops ...

Thanks again!

[brucelowekamp]

My code just uses ClientWrapper to schedule events. What I’ve done with OLA hasn’t needed anything other than time-based events, so I just set things up and then run the ClientWrapper loop with the main thread. Nothing my code did was compute-intensive enough that I couldn’t do it in that event loop. But if I needed a multi-threaded app, I would route any interaction with OLA through ClientWrapper with 0 time interval. And don’t block callbacks from ClientWrapper, just extract the data, post it somewhere the rest of your code can handle it if it needs to do something, and let the event loop return. Python has several asyncio synchronization primitives like semaphores etc you could use to communicate across threads if you need that. Bruce

On Wed, Feb 12, 2020 at 7:12 AM sdbbs ***@***.***> wrote: Many thanks @brucelowekamp <https://github.com/brucelowekamp> : Have you tried without the sliders open? I believe the console UX simply sends their current settings once a second if left open, so you need to close that window if you’re not using it. I remember having that same issue when I accidentally left it open and couldn’t figure out why my code didn’t work. Amazing - this seems to have been it! I removed all printouts but those in main(), and closed the browser tab which had the OLA sliders open - and now, I've ran the code about 10 times, no blink (else it used to blink each 4th or 5th time)! Still, it would be good to know what is the proper/recommended way to use threads as in the example, since I feel the example I posted jumps through way too many hoops ... Thanks again! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1616?email_source=notifications&email_token=ADNHN5IACGNCBPON5BEKPBLRCQGWPA5CNFSM4KT2SYY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELRD5FY#issuecomment-585252503>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADNHN5ONJ7R2C3ZTYRYMNI3RCQGWPANCNFSM4KT2SYYQ> .

-- Sent from my mobile

[peternewman]

(I would think the console app could be changed to not do that, but never looked into it)

Do you mean to stop sending when the tab was still open @brucelowekamp . I think the challenge would be working out if you'd faded to a blackout, or actively didn't want it to transmit.

@sdbbs see also a few other bits here:
http://docs.openlighting.org/ola/doc/latest/event_driven.html#event_Python
https://github.com/nomis52/ola-pixel-patterns
https://www.openlighting.org/ola/developer-documentation/python-api/

If you need more help with it, giving a high level overview of what you want your code to do might help us to guide you in the right direction.

[sdbbs]

Many thanks, @peternewman :

@sdbbs see also a few other bits here:
http://docs.openlighting.org/ola/doc/latest/event_driven.html#event_Python
https://github.com/nomis52/ola-pixel-patterns
https://www.openlighting.org/ola/developer-documentation/python-api/

Thanks for that - the event_Python has a neat thread example, but its in C++; ola-pixel-patterns looks very relevant, too, but I'll need some time to grok it.

If you need more help with it, giving a high level overview of what you want your code to do might help us to guide you in the right direction.

Generally, I want to automatize measurement of DMX-driven devices. Say I have an instrument (voltmeter, ampmeter etc) with some digital interface (USB/serial, i2c, etc); then essentially I want to do (pseudocode):

setDmx(dmx_data_array)
doMeasurement & getMeasurementResults

... repeatedly - and I just want a "setDMX" command in that loop as far as OLA is concerned, and no other OLA stuff (to keep cognitive load lower).

However, I'd like the DMX to be pumped continuously to the device - and in principle, I'd like to use this in a dynamic setting, say in a fade. So in the example I posted, that would be equivalent to:

def dmxFadeThreadFunc(controller):
  t = threading.currentThread()
  mydata = [0]*10
  for ix in range(0, 100):
    print(ix)
    mydata[2] = ix
    controller.setdmxarray(mydata)
    measurement_array.append( Get_Measurement_Results() )
    time.sleep(DMX_UPDATE_INTERVAL/1000.0)
...

This should in principle work with the example I posted - but again, I'm not sure I've found the right way to use OLA in the threaded context in Python, which is why I'd appreciate some sort of an example/guide to what would/should be the proper way.

(I would think the console app could be changed to not do that, but never looked into it)

Do you mean to stop sending when the tab was still open @brucelowekamp . I think the challenge would be working out if you'd faded to a blackout, or actively didn't want it to transmit.

OK, this was interesting - I looked a bit more into this, and I think I finally get it. I did this experiment:

---

• Turn everything on; do not open http://raspberrypi:9090/ ; then:

pi@raspberrypi:~ $ python ola/python/examples/ola_send_dmx.py
Success!

... here lamp shines constantly.

• Open http://raspberrypi:9090/ -> lamp still shines;
• click Universe 1 -> lamp still shines;
• click DMX Console -> lamp still shines;
• Drag DMX Console sliders down to 0 -> lamp is dark now;
• Run:

pi@raspberrypi:~ $ python ola/python/examples/ola_send_dmx.py
Success!

... now the lamp blinks to the values of ola_send_dmx.py, and quickly thereafter goes down to 0 (dark).

• Either: Change tab in OLA Admin webpage to DMX Monitor ; try ola_send_dmx.py again - lamp shines constantly!
• Or: Close web browser tab (OLA Admin) on http://raspberrypi:9090/; again:

pi@raspberrypi:~ $ python ola/python/examples/ola_send_dmx.py
Success!

... now lamp shines constantly again!

• If OLA Admin is active, same (blink) happens for say ola_set_dmx -u 1 -d 50,50,50
• If then I close the OLA Admin web browser tab, and run ola_set_dmx again - then the change persists (lamp shines constantly).

---

So, what this experiment reminded me of, is that OLA is a client/server architecture - and considering I'm not a lights guy (so I don't have any ArtNet "baggage" if you will, as a network-oriented layer over DMX), I keep forgetting that - because I see USB/serial, I think "yeah, serial ports have exclusive access in the OS".

However, as OLA is a server/client architecture, the OLA server can basically accept (set_dmx) commands from multiple clients, then interleave them, then - as it is the OLA server that has exclusive access to the USB/serial DMX interface (say ENTTEC DMX USB PRO) - it can propagate all these changes to serial DMX.

So, this issue with the blink, is basically having two clients setting each their own DMX to the device: the OLA Admin DMX Console page (say) pumps continuously DMX with all slots 0, then ola_set_dmx/ola_send_dmx.py comes in, sets a value - then OLA Admin DMX Console page continues and keeps sending zeroes, for as long as it is active.

Is the above analysis correct? If it is - then I'm not sure I'd necessarily want to turn off the OLA Admin DMX Console: I've had OLA scripts crashing before, where I wanted to keep the process alive for debugging purposes - but that also meant that there would be lamps at wattage being turned on for a while; and in that case, I have used the DMX Console sliders with success, to at least turn the light down while debugging.

---

What I personally think I'm missing, is a way to be reminded of this client/server relationship in the (G)UI (given I tend to forget it) - maybe some sort of a warning: say, for as long as you have only one client online, then everything proceeds as its done now. As soon as a second client shows up targeting the same Universe (and/or same DMX slots), then:

• In OLA Admin webpage, you'd get a warning sign next to the given Universe (say 1) in the left menu; if you click on it, below the Save button, there'd be a warning message:
• From command line, at first instantiation of OLA, if OLA notices an existing client already, we get immediately dumped to the terminal (similar to "CRITICAL:ola:SelectServer called in a thread other than the owner") a warning message:

Warning: there seem to be more than one client(s) targetting Universe 1 - this may lead to interleaving of data from both clients, and thus unexpected results. Proceed with caution (please see: link_with_more_details_and_examples).

Of course, this is tricky, since - say - DMX Console is a "continuous" client, while ola_set_dmx/ola_send_dmx.py is an "instantaneous" client (last very short time while active). So as far as the console is concerned, we just dump a string to terminal - but how long should one keep a warning in the OLA Admin page, in case of a "conflict" like this?

The above suggestion is probably best for a new Github issue, but I just wanted to put it out there now that I thought of it.

Thanks again for the feedback!

[shenghaoyang]

I've skimmed a bit, so forgive me if someone else already gave this suggestion:

If you're just sending data to OLA to get it pumped out via another interface, why not try using IP based protocols such as E1.31? I rarely use the Python API unless I have to receive DMX data or poke at something else that these protocols can't do.

Presumably, the IP communication can easily be done concurrently to whatever else it is that you're planning to do.

[sdbbs]

Thanks @shenghaoyang :

If you're just sending data to OLA to get it pumped out via another interface, why not try using IP based protocols such as E1.31? I rarely use the Python API unless I have to receive DMX data or poke at something else that these protocols can't do.

Mostly because so far, I've also interfaced to instruments through Python, so everything can sit nicely in one script. On the other hand, I'm not all that versed in E.131 (so it would also increase my cognitive load :) ), and I try to not introduce another layer of indirection that could be a source of problems eventually (for instance, see above for me missing the interleaving of DMX data on the OLA server level (provided my analysis was correct)).