Hello!
How does the line of code should read for a conditional decide to check for the photo eye state?
Photo Eye State logic:
On Clear -> Release child token
On Block -> Wait for event
TY
Happy Holidays!
Conditional decide to check photo eye state
FlexSim 20.0.0
Hi @Roberto Z, was jason.lightfoot's answer helpful? If so, please click the red "Accept" button on their answer. Or if you still have questions, add a comment and we'll continue the conversation.
If we haven't heard back from you within 3 business days we'll auto-accept an answer, but you can always unaccept and comment back to reopen your question.
Here's an example for you, but this is similar to the default behaviour without a photoeye, and will break with simultaneous arrivals.
You took the sublflow from this post which was testing if the queue was full and waiting for an exit event.
The closest test to that is to test if the photo eye is clear ("state" variable) and if not wait for it to clear as shown in the model.
Moves the object onto the conveyor's entry transfer. The source doesn't release the item in this example - if it did the PE would be controlling nothing.
I realized that you control the source with something called process flow instances, unfortunately that was not covered in the core training :( and in this particular simulation I consume and create flow items using the combiners which forces me to mix up process flow and port connections logic.
If you go look the process flow named "Clamp" I added a subflow named "PE1 Clear" that is meant to stop the operator from completing its task sequence in case the Photo Eye "PE1" is on block.
Can you please take a look to it and recommend what condition should I put in place to make it work?
My goal is to stop the activities downstream in a sequential manner once a bottleneck upstream gets created.
Thank you!
Are you updating this in order to avoid using both Process Flow and 3D? In case you are, it's important to know that here aren't any problems with mixing Process Flow and 3D logic. You just need to make sure there aren't any redundant or conflicting commands.
Instead of using your "PE1 Clear" subflow, you could add a trigger that listens to the Photo Eye "PE1". If "PE1" is blocked, it causes the operator to stop whatever he's working on and wait until "PE1" is clear. Just an alternate idea.
Thanks for your feedback. I wasn't trying to avoid port connections despite the fact that imo controlling things with process flow is a much cleaner way of working, making it easier to catch up any mistakes and it's visually more pleasing by eliminating clutter from port connections.
I actually used your answer from this post to complete the simulation. This way as bottlenecks get created downstream the operators don't have any space to discharge and eventually they stop working.
Thank you again!
12 People are following this question.
