Just wondering about weighing hoppers

[Kizilelma]

Thank you for your answers, i wasn't expected any answer because this topic is old. I am going to check my code.

 

[Kizilelma]

Weigh_Algorithm.txt

[*]This subroutine does not exit when it finds a solution, so multiple solutions may be triggered on any one call.

[*]This subroutine does not test all combinations e.g. the sums of weights of the pair [0,9], or of the triple [7,8,11], will not be checked.


I didn't realize, i will work on it tomorrow, thank you


[*]Each sum could be calculated but once and incrementally at each loop level, instead of twice per IF comparison in the innermost loop, which would reduce the number of [+] operations by a few orders of magnitude.


Yeah, you are right. I didnt create this kind of ( 0<= a <= 10) in Gx Works 3 software, but for sure there is a way to write it and use less "+". I am trying it , thank you. I will check every advices.

 

[Kizilelma]

Weigh_Algorithm.txt

• This subroutine does not exit when it finds a solution, so multiple solutions may be triggered on any one call.
• This subroutine does not test all combinations e.g. the sums of weights of the pair [0,9], or of the triple [7,8,11], will not be checked.
• Look up the knapsack problem; I think this is related to that, and there may be better algorithms available.
• This brute force O(N⁵) algorithm could almost certainly be improved upon
• Each sum could be calculated but once and incrementally at each loop level, instead of twice per IF comparison in the innermost loop, which would reduce the number of [+] operations by a few orders of magnitude.
• Sums that exceed the upper limit in outer loops before reaching the inner loops could be skipped.

Those last four items are only about efficiency; if there are no watchdog timeouts, then brute force may be okay.

I updated it. Can you check it again ? and i want to make sure, is it correct way, or should i try for make sure? Thank you.

 

[Kizilelma]

Me again... This brute force code is improved and you can still see on github. But its scan time is 35 milliseconds. My chef said this is good but slow, then i researched about knapsack and subset sum algorithms.

Then i write C language code (subset sum-knapsack mixed). But i used recursive functions and my mitsubishi PLC didn't support it. Then i try iteration, but in for loop, i couldn't do some processes because of PLC don't support them. And last version, for loops become while loops. Now i have different algorithm and its scan time is 2ms. I will not share publicly because maybe we can make this machine. But i thank you all of you for your helps and your ideas. This project teach me about software developing and i gain more experience.

Now i can say, you can make it with PLC. Maybe you can add a program block in your packaging machine. Then use multihead weigher and your machine at the same time. It means you can repair and design it for your needs. But i heard mechanical parts are hard to design because of falling speed problems. There are some articles about it, a lot of mathematical formulas for designing a multihead weigher. I think we will not produce it for our machines, but i am gonna try.

 

[drbitboy]

i thank you all of you for your helps and your ideas. This project teach me about software developing and i gain more experience.

Well done!

Regarding recursion, I had the same problem with many years ago: the Fortran compiler I was using (VAX/VMS) did not allow direct recursion i.e. a subroutine calling itself. However, I found that if I used an intermediate routine, then I could get around the compiler's limitation and induce Fortran to implement indirect recursion. E.g.

SUBROUTINE self(arg1, arg2, output)
   IF arg2 .LT. 1 THEN RETURN  !!! Terminate recursion

   ...
   CALL self_intermediate(arg1, arg2-1, output)
   ...
   RETURN
END

SUBROUTINE self_intermediate(arg1, arg2, output)
   CALL self(arg1, arg2)
   RETURN
END

 

[Kizilelma]

Well done!

SUBROUTINE self(arg1, arg2, output)
   IF arg2 .LT. 1 THEN RETURN  !!! Terminate recursion

   ...
   CALL self_intermediate(arg1, arg2-1, output)
   ...
   RETURN
END

SUBROUTINE self_intermediate(arg1, arg2, output)
   CALL self(arg1, arg2)
   RETURN
END

Thank you @drbitboy for your help. I saved recursive function version in my pc. I am going to try it again on Monday. I think my company don't want to produce it, i will share it on gitHub if it works for me.

 

[Kizilelma]

@drbitboy , hello again. We didn't produce this machine but i am simulating it and scan speed in simulation mode is around 1ms. I am not sure is it good or bad. Do you have an idea about it ? My co-worker told me 30ms is slow, when i show him first prototype. Now i make it clear, adding some extra function and now i get between 0,5 ms - 6 ms scan time. Is it good ? I am still improving it, thanks and regards.

 

[drbitboy]

I think getting it down to half a ms from 30ms is excellent!

 

[Kizilelma]

I think getting it down to half a ms from 30ms is excellent!

Yes, sometimes scan time is going up, (like a pulse) but generally working around 0.50-1 ms.

I added something like filters. For example, if a hopper have less produce than %45 of target weight of a hopper, skip it.

And i deleted 5 hopper combination. Because it makes it 15 ms around. If you say it is okay, thank you. I will see what can i do with this project. Maybe i can find a new job lol