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;
}
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:
- 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, ...) - 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
- 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
add a comment |
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:
- 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, ...) - 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
- 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
add a comment |
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:
- 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, ...) - 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
- 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
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:
- 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, ...) - 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
- 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
algorithm synchronization dynamic-programming production-environment state-machine
edited Nov 19 '18 at 8:52
asker
asked Nov 16 '18 at 14:39
askerasker
367
367
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
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.
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
add a comment |
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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.
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
add a comment |
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.
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
add a comment |
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.
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.
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
add a comment |
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
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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