Figure out asynchronous in a production line





.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}







0















There are 2 cameras Cam1 & Cam2 mounted in a production line. They are provided with sensors those signal my program once a product touches one of them. Those cameras are placed one behind the other.



After Cam2, a balance B is installed and provided with a sensor as well. When the product arrives there, the product will be weighed and signal my program with the weight. Then my program must do the evaluation for this product based on the two captured images and data received from B (weight).



Actually, one/two products can fit between Cam1 & Cam2. and also one/two products can fit between Cam2 & B.



I faced some difficulty to find a stable algorithm to figure out if the images, as well as the weight, belong to the same product. There are some hard conditions cannot be changed inside the factory:




  1. Undefined speed for the line. (the line can be stopped for any
    reason at any time, it can accelerate/speed down, it can be moved manually by the workers there, ...)

  2. a product can be removed after Cam1:


    • between Cam1 & Cam2 ==> only captured by Cam1 BUT no image from Cam2 and no data from B

    • between Cam2 & B ==>
      captured by Cam2 & Cam1 BUT no data from B



  3. no way to stick such kind
    of readable chip with unique number so we can read on Cam2 & B to
    make sure for synchronicity.


This problem must be solved programmatically. The factory has fully obstacles that avoid me to make any modification there.



My initial solution is to assign a FIFO for each camera, FIFO_Cam1 & FIFO_Cam2. once my program receives the signal from one of the cameras the convenient FIFO enqueues the captured image of the product.
Then, when I receive a signal from B, I dequeue the top image from each FIFOs and consider they belong to the same product which has the weight received with the last signal too.



Unfortunately, my consideration can only solve the problem of speed (Nr. 1) but not all cases of (Nr. 2).



I tried to make a threshold when the number of products saved into FIFO_Cam1 exceeds 5, I will signal the line with DESYNCH but doesn't work properly and cannot solve the most of cases.



Any help or idea would be appreciated!



Thanks.










share|improve this question































    0















    There are 2 cameras Cam1 & Cam2 mounted in a production line. They are provided with sensors those signal my program once a product touches one of them. Those cameras are placed one behind the other.



    After Cam2, a balance B is installed and provided with a sensor as well. When the product arrives there, the product will be weighed and signal my program with the weight. Then my program must do the evaluation for this product based on the two captured images and data received from B (weight).



    Actually, one/two products can fit between Cam1 & Cam2. and also one/two products can fit between Cam2 & B.



    I faced some difficulty to find a stable algorithm to figure out if the images, as well as the weight, belong to the same product. There are some hard conditions cannot be changed inside the factory:




    1. Undefined speed for the line. (the line can be stopped for any
      reason at any time, it can accelerate/speed down, it can be moved manually by the workers there, ...)

    2. a product can be removed after Cam1:


      • between Cam1 & Cam2 ==> only captured by Cam1 BUT no image from Cam2 and no data from B

      • between Cam2 & B ==>
        captured by Cam2 & Cam1 BUT no data from B



    3. no way to stick such kind
      of readable chip with unique number so we can read on Cam2 & B to
      make sure for synchronicity.


    This problem must be solved programmatically. The factory has fully obstacles that avoid me to make any modification there.



    My initial solution is to assign a FIFO for each camera, FIFO_Cam1 & FIFO_Cam2. once my program receives the signal from one of the cameras the convenient FIFO enqueues the captured image of the product.
    Then, when I receive a signal from B, I dequeue the top image from each FIFOs and consider they belong to the same product which has the weight received with the last signal too.



    Unfortunately, my consideration can only solve the problem of speed (Nr. 1) but not all cases of (Nr. 2).



    I tried to make a threshold when the number of products saved into FIFO_Cam1 exceeds 5, I will signal the line with DESYNCH but doesn't work properly and cannot solve the most of cases.



    Any help or idea would be appreciated!



    Thanks.










    share|improve this question



























      0












      0








      0


      0






      There are 2 cameras Cam1 & Cam2 mounted in a production line. They are provided with sensors those signal my program once a product touches one of them. Those cameras are placed one behind the other.



      After Cam2, a balance B is installed and provided with a sensor as well. When the product arrives there, the product will be weighed and signal my program with the weight. Then my program must do the evaluation for this product based on the two captured images and data received from B (weight).



      Actually, one/two products can fit between Cam1 & Cam2. and also one/two products can fit between Cam2 & B.



      I faced some difficulty to find a stable algorithm to figure out if the images, as well as the weight, belong to the same product. There are some hard conditions cannot be changed inside the factory:




      1. Undefined speed for the line. (the line can be stopped for any
        reason at any time, it can accelerate/speed down, it can be moved manually by the workers there, ...)

      2. a product can be removed after Cam1:


        • between Cam1 & Cam2 ==> only captured by Cam1 BUT no image from Cam2 and no data from B

        • between Cam2 & B ==>
          captured by Cam2 & Cam1 BUT no data from B



      3. no way to stick such kind
        of readable chip with unique number so we can read on Cam2 & B to
        make sure for synchronicity.


      This problem must be solved programmatically. The factory has fully obstacles that avoid me to make any modification there.



      My initial solution is to assign a FIFO for each camera, FIFO_Cam1 & FIFO_Cam2. once my program receives the signal from one of the cameras the convenient FIFO enqueues the captured image of the product.
      Then, when I receive a signal from B, I dequeue the top image from each FIFOs and consider they belong to the same product which has the weight received with the last signal too.



      Unfortunately, my consideration can only solve the problem of speed (Nr. 1) but not all cases of (Nr. 2).



      I tried to make a threshold when the number of products saved into FIFO_Cam1 exceeds 5, I will signal the line with DESYNCH but doesn't work properly and cannot solve the most of cases.



      Any help or idea would be appreciated!



      Thanks.










      share|improve this question
















      There are 2 cameras Cam1 & Cam2 mounted in a production line. They are provided with sensors those signal my program once a product touches one of them. Those cameras are placed one behind the other.



      After Cam2, a balance B is installed and provided with a sensor as well. When the product arrives there, the product will be weighed and signal my program with the weight. Then my program must do the evaluation for this product based on the two captured images and data received from B (weight).



      Actually, one/two products can fit between Cam1 & Cam2. and also one/two products can fit between Cam2 & B.



      I faced some difficulty to find a stable algorithm to figure out if the images, as well as the weight, belong to the same product. There are some hard conditions cannot be changed inside the factory:




      1. Undefined speed for the line. (the line can be stopped for any
        reason at any time, it can accelerate/speed down, it can be moved manually by the workers there, ...)

      2. a product can be removed after Cam1:


        • between Cam1 & Cam2 ==> only captured by Cam1 BUT no image from Cam2 and no data from B

        • between Cam2 & B ==>
          captured by Cam2 & Cam1 BUT no data from B



      3. no way to stick such kind
        of readable chip with unique number so we can read on Cam2 & B to
        make sure for synchronicity.


      This problem must be solved programmatically. The factory has fully obstacles that avoid me to make any modification there.



      My initial solution is to assign a FIFO for each camera, FIFO_Cam1 & FIFO_Cam2. once my program receives the signal from one of the cameras the convenient FIFO enqueues the captured image of the product.
      Then, when I receive a signal from B, I dequeue the top image from each FIFOs and consider they belong to the same product which has the weight received with the last signal too.



      Unfortunately, my consideration can only solve the problem of speed (Nr. 1) but not all cases of (Nr. 2).



      I tried to make a threshold when the number of products saved into FIFO_Cam1 exceeds 5, I will signal the line with DESYNCH but doesn't work properly and cannot solve the most of cases.



      Any help or idea would be appreciated!



      Thanks.







      algorithm synchronization dynamic-programming production-environment state-machine






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Nov 19 '18 at 8:52







      asker

















      asked Nov 16 '18 at 14:39









      askerasker

      367




      367
























          1 Answer
          1






          active

          oldest

          votes


















          0














          You need a signal to let you know the line stopped or slowed down dramatically.



          So to take care of missing products I would store a timestamp of when the picture/measurement was taken.



          If the line goes at the same speed you should always see the same time difference between the events. If a product goes missing then the next measurement will come at about 2x the time required, so you can look in your fifo for an item that would match the time delta you're expecting. You can also keep track of consecutive timestamps in the same queue. It would also tell you how many products were likely skipped.



          To allow for some change in the line speed you should update the time delta on an ongoing basis (last X successful items). Obviously if the line stops you need to allow for the stopped time (that's why you need a signal for it, I assume it would be easier the tagging every product). If you can measure the line speed it would be even better as you can adjust your expected deltas more accurately.



          This is still somewhat approximate solution. Make sure you allow for some error in the measurements. If the line speed changes dramatically or if the number of removed products is too high this might still not work. For example, say the first camera scanned 10 products, then the line stopped for a while then starts at a different speed, somebody kicked 8 products off the line and now you get the next 2 picture. It's impossible to say for sure how to pair the later pictures to first ones.






          share|improve this answer
























          • Thanks for your contribution. Actually, as i already explained, i need a solution as software, even it is too hard or complicated. The factory has fully obstacles that avoid me to make any modification there.

            – asker
            Nov 16 '18 at 20:33











          • Secondly, i failed to find out a profile for the delta time. It was pretty random. I need to go with some complicated algorithm or maybe state machine that can 90% solve this issue

            – asker
            Nov 16 '18 at 20:37











          • Ok, that makes it a bit harder. Take a look at the delta time from the first camera and compare it with the delta time from the second camera, preferably on a portion of time when all the items are present. If the differences are well correlated you can apply the same idea, but use the delta time from the first camera instead of a fixed timespan. Still won't be able to cope with line stopping if you don't know that it stopped.

            – Sorin
            Nov 19 '18 at 8:50












          Your Answer






          StackExchange.ifUsing("editor", function () {
          StackExchange.using("externalEditor", function () {
          StackExchange.using("snippets", function () {
          StackExchange.snippets.init();
          });
          });
          }, "code-snippets");

          StackExchange.ready(function() {
          var channelOptions = {
          tags: "".split(" "),
          id: "1"
          };
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function() {
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled) {
          StackExchange.using("snippets", function() {
          createEditor();
          });
          }
          else {
          createEditor();
          }
          });

          function createEditor() {
          StackExchange.prepareEditor({
          heartbeatType: 'answer',
          autoActivateHeartbeat: false,
          convertImagesToLinks: true,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: 10,
          bindNavPrevention: true,
          postfix: "",
          imageUploader: {
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          },
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          });


          }
          });














          draft saved

          draft discarded


















          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53339963%2ffigure-out-asynchronous-in-a-production-line%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown

























          1 Answer
          1






          active

          oldest

          votes








          1 Answer
          1






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes









          0














          You need a signal to let you know the line stopped or slowed down dramatically.



          So to take care of missing products I would store a timestamp of when the picture/measurement was taken.



          If the line goes at the same speed you should always see the same time difference between the events. If a product goes missing then the next measurement will come at about 2x the time required, so you can look in your fifo for an item that would match the time delta you're expecting. You can also keep track of consecutive timestamps in the same queue. It would also tell you how many products were likely skipped.



          To allow for some change in the line speed you should update the time delta on an ongoing basis (last X successful items). Obviously if the line stops you need to allow for the stopped time (that's why you need a signal for it, I assume it would be easier the tagging every product). If you can measure the line speed it would be even better as you can adjust your expected deltas more accurately.



          This is still somewhat approximate solution. Make sure you allow for some error in the measurements. If the line speed changes dramatically or if the number of removed products is too high this might still not work. For example, say the first camera scanned 10 products, then the line stopped for a while then starts at a different speed, somebody kicked 8 products off the line and now you get the next 2 picture. It's impossible to say for sure how to pair the later pictures to first ones.






          share|improve this answer
























          • Thanks for your contribution. Actually, as i already explained, i need a solution as software, even it is too hard or complicated. The factory has fully obstacles that avoid me to make any modification there.

            – asker
            Nov 16 '18 at 20:33











          • Secondly, i failed to find out a profile for the delta time. It was pretty random. I need to go with some complicated algorithm or maybe state machine that can 90% solve this issue

            – asker
            Nov 16 '18 at 20:37











          • Ok, that makes it a bit harder. Take a look at the delta time from the first camera and compare it with the delta time from the second camera, preferably on a portion of time when all the items are present. If the differences are well correlated you can apply the same idea, but use the delta time from the first camera instead of a fixed timespan. Still won't be able to cope with line stopping if you don't know that it stopped.

            – Sorin
            Nov 19 '18 at 8:50
















          0














          You need a signal to let you know the line stopped or slowed down dramatically.



          So to take care of missing products I would store a timestamp of when the picture/measurement was taken.



          If the line goes at the same speed you should always see the same time difference between the events. If a product goes missing then the next measurement will come at about 2x the time required, so you can look in your fifo for an item that would match the time delta you're expecting. You can also keep track of consecutive timestamps in the same queue. It would also tell you how many products were likely skipped.



          To allow for some change in the line speed you should update the time delta on an ongoing basis (last X successful items). Obviously if the line stops you need to allow for the stopped time (that's why you need a signal for it, I assume it would be easier the tagging every product). If you can measure the line speed it would be even better as you can adjust your expected deltas more accurately.



          This is still somewhat approximate solution. Make sure you allow for some error in the measurements. If the line speed changes dramatically or if the number of removed products is too high this might still not work. For example, say the first camera scanned 10 products, then the line stopped for a while then starts at a different speed, somebody kicked 8 products off the line and now you get the next 2 picture. It's impossible to say for sure how to pair the later pictures to first ones.






          share|improve this answer
























          • Thanks for your contribution. Actually, as i already explained, i need a solution as software, even it is too hard or complicated. The factory has fully obstacles that avoid me to make any modification there.

            – asker
            Nov 16 '18 at 20:33











          • Secondly, i failed to find out a profile for the delta time. It was pretty random. I need to go with some complicated algorithm or maybe state machine that can 90% solve this issue

            – asker
            Nov 16 '18 at 20:37











          • Ok, that makes it a bit harder. Take a look at the delta time from the first camera and compare it with the delta time from the second camera, preferably on a portion of time when all the items are present. If the differences are well correlated you can apply the same idea, but use the delta time from the first camera instead of a fixed timespan. Still won't be able to cope with line stopping if you don't know that it stopped.

            – Sorin
            Nov 19 '18 at 8:50














          0












          0








          0







          You need a signal to let you know the line stopped or slowed down dramatically.



          So to take care of missing products I would store a timestamp of when the picture/measurement was taken.



          If the line goes at the same speed you should always see the same time difference between the events. If a product goes missing then the next measurement will come at about 2x the time required, so you can look in your fifo for an item that would match the time delta you're expecting. You can also keep track of consecutive timestamps in the same queue. It would also tell you how many products were likely skipped.



          To allow for some change in the line speed you should update the time delta on an ongoing basis (last X successful items). Obviously if the line stops you need to allow for the stopped time (that's why you need a signal for it, I assume it would be easier the tagging every product). If you can measure the line speed it would be even better as you can adjust your expected deltas more accurately.



          This is still somewhat approximate solution. Make sure you allow for some error in the measurements. If the line speed changes dramatically or if the number of removed products is too high this might still not work. For example, say the first camera scanned 10 products, then the line stopped for a while then starts at a different speed, somebody kicked 8 products off the line and now you get the next 2 picture. It's impossible to say for sure how to pair the later pictures to first ones.






          share|improve this answer













          You need a signal to let you know the line stopped or slowed down dramatically.



          So to take care of missing products I would store a timestamp of when the picture/measurement was taken.



          If the line goes at the same speed you should always see the same time difference between the events. If a product goes missing then the next measurement will come at about 2x the time required, so you can look in your fifo for an item that would match the time delta you're expecting. You can also keep track of consecutive timestamps in the same queue. It would also tell you how many products were likely skipped.



          To allow for some change in the line speed you should update the time delta on an ongoing basis (last X successful items). Obviously if the line stops you need to allow for the stopped time (that's why you need a signal for it, I assume it would be easier the tagging every product). If you can measure the line speed it would be even better as you can adjust your expected deltas more accurately.



          This is still somewhat approximate solution. Make sure you allow for some error in the measurements. If the line speed changes dramatically or if the number of removed products is too high this might still not work. For example, say the first camera scanned 10 products, then the line stopped for a while then starts at a different speed, somebody kicked 8 products off the line and now you get the next 2 picture. It's impossible to say for sure how to pair the later pictures to first ones.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Nov 16 '18 at 16:05









          SorinSorin

          9,8191322




          9,8191322













          • Thanks for your contribution. Actually, as i already explained, i need a solution as software, even it is too hard or complicated. The factory has fully obstacles that avoid me to make any modification there.

            – asker
            Nov 16 '18 at 20:33











          • Secondly, i failed to find out a profile for the delta time. It was pretty random. I need to go with some complicated algorithm or maybe state machine that can 90% solve this issue

            – asker
            Nov 16 '18 at 20:37











          • Ok, that makes it a bit harder. Take a look at the delta time from the first camera and compare it with the delta time from the second camera, preferably on a portion of time when all the items are present. If the differences are well correlated you can apply the same idea, but use the delta time from the first camera instead of a fixed timespan. Still won't be able to cope with line stopping if you don't know that it stopped.

            – Sorin
            Nov 19 '18 at 8:50



















          • Thanks for your contribution. Actually, as i already explained, i need a solution as software, even it is too hard or complicated. The factory has fully obstacles that avoid me to make any modification there.

            – asker
            Nov 16 '18 at 20:33











          • Secondly, i failed to find out a profile for the delta time. It was pretty random. I need to go with some complicated algorithm or maybe state machine that can 90% solve this issue

            – asker
            Nov 16 '18 at 20:37











          • Ok, that makes it a bit harder. Take a look at the delta time from the first camera and compare it with the delta time from the second camera, preferably on a portion of time when all the items are present. If the differences are well correlated you can apply the same idea, but use the delta time from the first camera instead of a fixed timespan. Still won't be able to cope with line stopping if you don't know that it stopped.

            – Sorin
            Nov 19 '18 at 8:50

















          Thanks for your contribution. Actually, as i already explained, i need a solution as software, even it is too hard or complicated. The factory has fully obstacles that avoid me to make any modification there.

          – asker
          Nov 16 '18 at 20:33





          Thanks for your contribution. Actually, as i already explained, i need a solution as software, even it is too hard or complicated. The factory has fully obstacles that avoid me to make any modification there.

          – asker
          Nov 16 '18 at 20:33













          Secondly, i failed to find out a profile for the delta time. It was pretty random. I need to go with some complicated algorithm or maybe state machine that can 90% solve this issue

          – asker
          Nov 16 '18 at 20:37





          Secondly, i failed to find out a profile for the delta time. It was pretty random. I need to go with some complicated algorithm or maybe state machine that can 90% solve this issue

          – asker
          Nov 16 '18 at 20:37













          Ok, that makes it a bit harder. Take a look at the delta time from the first camera and compare it with the delta time from the second camera, preferably on a portion of time when all the items are present. If the differences are well correlated you can apply the same idea, but use the delta time from the first camera instead of a fixed timespan. Still won't be able to cope with line stopping if you don't know that it stopped.

          – Sorin
          Nov 19 '18 at 8:50





          Ok, that makes it a bit harder. Take a look at the delta time from the first camera and compare it with the delta time from the second camera, preferably on a portion of time when all the items are present. If the differences are well correlated you can apply the same idea, but use the delta time from the first camera instead of a fixed timespan. Still won't be able to cope with line stopping if you don't know that it stopped.

          – Sorin
          Nov 19 '18 at 8:50




















          draft saved

          draft discarded




















































          Thanks for contributing an answer to Stack Overflow!


          • Please be sure to answer the question. Provide details and share your research!

          But avoid



          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.


          To learn more, see our tips on writing great answers.




          draft saved


          draft discarded














          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53339963%2ffigure-out-asynchronous-in-a-production-line%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown





















































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown

































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown







          Popular posts from this blog

          Bressuire

          Vorschmack

          Quarantine