Free 186 More Best Homemade Tools eBook:  
Get tool plans

User Tag List

Page 1 of 2 1 2 LastLast
Results 1 to 10 of 11

Thread: Creating a Shadow Model to Control Hardware That Cannot Respond back to the Software

  1. #1
    Supporting Member rgsparber's Avatar
    Join Date
    Nov 2012
    Location
    Phoenix, AZ
    Posts
    1,321
    Thanks
    778
    Thanked 2,840 Times in 670 Posts

    rgsparber's Tools

    Creating a Shadow Model to Control Hardware That Cannot Respond back to the Software

    Reliable hardware/software systems depend on the free flow of information. Recently I had to control a piece of hardware that did not return any status information. It then became a guessing game as to what state it was in. Although I could not completely solve this problem, I was able to improve on it.

    If you are interested, please see

    https://rick.sparber.org/ShadowModel.pdf



    Your comments are welcome. All of us are smarter than any one of us.


    Thanks,

    Rick

    186 More Best Homemade Tools eBook
    Rick

  2. The Following 3 Users Say Thank You to rgsparber For This Useful Post:

    Altair (Mar 20, 2020), Jon (Mar 11, 2020), Seedtick (Mar 11, 2020)

  3. #2
    Supporting Member jdurand's Avatar
    Join Date
    May 2019
    Location
    Krasnodar Krai, Russian Federation
    Posts
    1,469
    Thanks
    127
    Thanked 768 Times in 426 Posts

    jdurand's Tools
    Toggle systems with no feedback demand a lot of faith. Normally you would just keep a state machine in software.

    Most stepping motor systems work without feedback, it's simply assumed they are following orders.

    On an "intelligent" theatrical light I designed I had two stepping motors, one for an progressive neutral density filter for lamp brightness (arc lams don't dim) and a second for a color wheel.

    On that one I put a sensor that would send back a pulse when it passed a "home" position.

    On power up both wheels spun to find the pulse, then backed over it to find it in the other direction.

    After that, in use the wheel would turn in the shortest direction to get to the newly commanded setting and I would update where I thought it was whenever the home position was passed. If the lighting guy had a lot of moves that never passed home there was the possibility of never passing home so I had to put in a timeout, eventually it WOULD pass home.

    Mentioning lighting, the DMX-512a standard (ANSI E11.1) gets past no feedback by simply resending all commands at a rapid rate so if/when a light looses sync it's brought back after only a fast blip. There's also the possibility of feedback but it's mainly used for errors, status ("getting hot here, might want to change my air filter).

    2,000+ Tool Plans

  4. #3
    Supporting Member rgsparber's Avatar
    Join Date
    Nov 2012
    Location
    Phoenix, AZ
    Posts
    1,321
    Thanks
    778
    Thanked 2,840 Times in 670 Posts

    rgsparber's Tools
    jdurand,

    Thanks for confirming the technique. I was hoping to hear that there was a better way.

    I had not thought about the similarity to steppers but, sure, they run open loop too. I've been the victim of steppers that are run too fast and get out of sync. Not good.

    Rick
    Rick

  5. #4
    Supporting Member mklotz's Avatar
    Join Date
    Aug 2015
    Location
    LA, CA, USA
    Posts
    3,525
    Thanks
    362
    Thanked 6,559 Times in 2,161 Posts

    mklotz's Tools
    Unless the shadow model can COMPLETELY model all failure mechanisms in the hardware, which is probably impossible, your time is probably better spent instrumenting the hardware to return a state response.

    It all depends on the danger level of a hardware failure. If a failure is simply annoying the shadow approach is fine; if it's life-threatening then instrumenting the hardware is in order.
    ---
    Regards, Marv

    Failure is just success in progress
    That looks about right - Mediocrates

  6. The Following User Says Thank You to mklotz For This Useful Post:

    DIYer (Mar 11, 2020)

  7. #5
    Supporting Member rgsparber's Avatar
    Join Date
    Nov 2012
    Location
    Phoenix, AZ
    Posts
    1,321
    Thanks
    778
    Thanked 2,840 Times in 670 Posts

    rgsparber's Tools
    Marv,

    The hardware is a camera so rather harmless. If the hardware could hurt someone, I would flat out not use it.

    Rick
    Rick

  8. #6
    Supporting Member mklotz's Avatar
    Join Date
    Aug 2015
    Location
    LA, CA, USA
    Posts
    3,525
    Thanks
    362
    Thanked 6,559 Times in 2,161 Posts

    mklotz's Tools
    Quote Originally Posted by rgsparber View Post
    Marv,

    The hardware is a camera so rather harmless. If the hardware could hurt someone, I would flat out not use it.

    Rick
    Thanks for confirming my trust in you. I assumed you understood that this approach had limited application.
    ---
    Regards, Marv

    Failure is just success in progress
    That looks about right - Mediocrates

  9. The Following User Says Thank You to mklotz For This Useful Post:

    rgsparber (Mar 11, 2020)

  10. #7
    Supporting Member tonyfoale's Avatar
    Join Date
    Nov 2016
    Location
    Spain
    Posts
    1,607
    Thanks
    721
    Thanked 2,706 Times in 726 Posts

    tonyfoale's Tools
    Quote Originally Posted by jdurand View Post
    Toggle systems with no feedback demand a lot of faith. Normally you would just keep a state machine in software.

    Most stepping motor systems work without feedback, it's simply assumed they are following orders..
    I was about to reply almost the same, even with the stepper motor analogy.
    I cannot see that the state simulator does anything that you cannot do in the base software. It can only be reflecting the commands that you send out.
    You cannot replace a missing real world feedback loop with a virtual perfect feedback loop. Going with the stepper analogy, you command it to move 3 steps, the state simulator can only return that it moved 3 steps, but how many did the motor move. You gain no value by being told that it was 3.

  11. #8
    Supporting Member rgsparber's Avatar
    Join Date
    Nov 2012
    Location
    Phoenix, AZ
    Posts
    1,321
    Thanks
    778
    Thanked 2,840 Times in 670 Posts

    rgsparber's Tools
    Quote Originally Posted by mklotz View Post
    Unless the shadow model can COMPLETELY model all failure mechanisms in the hardware, which is probably impossible, your time is probably better spent instrumenting the hardware to return a state response.

    It all depends on the danger level of a hardware failure. If a failure is simply annoying the shadow approach is fine; if it's life-threatening then instrumenting the hardware is in order.
    Marv,

    The intent is to just follow along on the hidden state changes. The only failure mode I can detect is when the hardware has no power. If there was a failure within the hardware, there would be no way for the software to detect it.

    I do avoid failures in the hardware due to illegal state change requests by doing a translation in the driver. The user can request a move to any state and the driver will figure out how to legally get there.

    I have updated the article with a big red warning about safety. Thanks for the reminder.

    Rick
    Rick

  12. #9
    Supporting Member rgsparber's Avatar
    Join Date
    Nov 2012
    Location
    Phoenix, AZ
    Posts
    1,321
    Thanks
    778
    Thanked 2,840 Times in 670 Posts

    rgsparber's Tools
    Quote Originally Posted by tonyfoale View Post
    I was about to reply almost the same, even with the stepper motor analogy.
    I cannot see that the state simulator does anything that you cannot do in the base software. It can only be reflecting the commands that you send out.
    You cannot replace a missing real-world feedback loop with a virtual perfect feedback loop. Going with the stepper analogy, you command it to move 3 steps, the state simulator can only return that it moved 3 steps, but how many did the motor move. You gain no value by being told that it was 3.
    Tony,

    The strategy is that the user simply says what state they want to get to and the driver with its state machine figures out how to get there. By having all users pass their requests through the same high-level driver, I am able to prevent a user from changing the hardware and not updating the state machine.

    The intent was never to simulate the position on an output shaft. It is to control a RunCam2 camera. The low-level driver accepts a shutter-button push command or a mode-button push command and sends 80 ms pulses to the camera. These commands are meaningless without knowing the current state of the camera. I get that from the high-level driver which contains the state machine including the current (assumed) state of the camera. The user then just tells the high-level driver what they want to do and the high-level driver sends a series of low-level commands to the low-level driver to get there. All the while, it is updating its state machine to reflect what should be the current state of the camera.

    I'm not sure this is any clearer. I can say that this is not theory, I have fully tested these drivers and it works as expected.

    Rick
    Rick

  13. #10
    Supporting Member Saltfever's Avatar
    Join Date
    Apr 2012
    Location
    NorCal
    Posts
    401
    Thanks
    402
    Thanked 140 Times in 100 Posts

    Saltfever's Tools
    Many years ago I designed a toxic gas system with on/off valves. When I commanded an action I could see a delayed response by sensing other parameters like pressure changes, temp rise, etc. However, I wanted an instantaneous visual of the valve state. I marked up the company's illustrated parts breakdown of the valve with a drawing of the modification I wanted, and sent out an RFQ. Their answer was no-quote. The following year I received their new catalog showing a new valve incorporating my idea with their patent pending on it!

    Such is life . . . some things are not worth pursuing.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •