Control Point label not being assigned.

Question

question

Mike Mayer asked Sep 12, '17 Jordan Johnson commented Sep 13, '17

Control Point label not being assigned.

Hello,

In the attached model, OperatorJane is supposed to grab a brown box from ExitTransfer1 and put it on Processor1. She is attached to an AGV Process Flow "AGV" network. The error I'm getting is:
exception: FlexScript exception: label cp doesn't exist on token id: 4 at MODEL:/Tools/ProcessFlow/AGV/Does CP have Pickup Points?>variables/decision

After stepping through and running debugger, it appears that the label for token id:4 "cp" is not getting set in "Assign CP" in the Item Pickup process. If you click "Step" 22 times, the token id:4 should land on "Does CP have PIckup Points?", and clicking on the green token ball reveals that there is no label "cp", which should have been assigned from the step above, "Assign CP". Note that id:4 token does have two other labels - resource and item, which both seem populated OK.

If you click a 23rd time on Step, it will throw the System Console error above.

Interestingly, if in the "Assign CP" I change the Value "cpconnection(up(token.item), "Location", 1)" to simply be "BLAH", then cp does get assigned the string value "BLAH".

Have been looking at this for the last 2 days, can't see why it doesn't assign. Looking at the bigger picture, eventually, OperatorJane (and a second OperatorJohn) would be walking back-and-forth thru this U-shaped loop moving things from 12 exit transfers to 12 processors, in a looking-for-work fashion. Right now, I only have 1 built as you can see. The other 11 are simply disconnected sources & sinks from an earlier attempt.

Thanks for any guidance.

Mike Mayer

Goodyear

avg-u-loop.fsm

Software Version:

Choose One

agv

avg-u-loop.fsm (174.7 KiB)

Answer 1 · 2017-09-12T22:03:50Z

Jordan Johnson answered Sep 12, '17

First issue: OperatorJane is attached to both AGV process flows. I disconnected her from AVG2.

Second issue: The conveyor needs to be connected to a "NextLookForWork" point. A-connect from the decision point to the conveyor.

Third issue: There is a bug in the AGV template, dealing with dropoff points. I added a custom code block that calls transportincomplete(), so that the processor will open its input ports. We'll get that bug fixed.

Here is the fixed model: avg-u-loop-fixed.fsm

avg-u-loop-fixed.fsm (162.5 KiB)

Answer 2 · 2017-09-13T14:38:34Z

Mike Mayer answered Sep 13, '17 Jordan Johnson commented Sep 13, '17

One more thing I forgot to ask: When the model starts, OperatorJane moves the very first brown box right away because I set the Source12 for an arrival at time 0. She then continues walking around the U loop. During that time, a few more boxes show up on Station 12. When she arrives back at Station 12, she only moves 1 box, then again seeks more work. This leaves boxes that have not been moved by her (but should be). Is there a way I can tell the operators to move all items that may be queued-up on the conveyor? I.e., to do all available work before moving on to look for more work? The idea is that in a factory the operator would move all tires sitting on a queued conveyor before moving to the next one.

· 1

Jordan Johnson ♦♦ commented · Sep 13, 2017 at 06:55 PM

@Mike Mayer Could you ask this as a new question? I'm working on an answer for you, but other users will have a hard time finding the answer if it's at the bottom of a different question. I'll watch for your new question, and post the answer there.

0 ·

Answer 3 · 2017-09-13T14:33:01Z

Mike Mayer answered Sep 13, '17

That's pretty neat Jordan, thank you for having a look. After I posted my model, I realized I had that AGV2 stuck in there. I've removed it too as I was playing around on my own.

I now see my mistake on the A-connect. I did my A-connect from the ExitTransfer1 to the decision point, instead of from the conveyor to the decision point (which is what you did). Question: Does it matter the direction, whether you A-connect from Conveyor to Decision Point, or Decision Point to Conveyor? I know that makes a difference for port connections, but for AGVs and Network Paths a blue line shows up, which I suspect means it's OK to A-connect from either direction, as long as the blue line appears.

Thanks for the custom code block. I made a text note on the template so when I use it in another model I'll remember to retro-fit it to insert that code block too.

Question on AGV TE orientation. It's common for AGV's to go backwards, travel backwards, spin around, etc. due to turning around as they go back and forth. Since I'm using a human-looking transporter (OperatorJane) as the AGV, is there a way to always have OperatorJane travel facing forwards? In other words, prevent reverse direction travel (forcing it to always walk in a forwards direction)? It's probably visually OK for her to move backwards to move the brown boxes the short distance crossing the main U path from conveyor to processor (since that's how it would work in a tire factory moving tires a short distance from a conveyor to a stacking machine). But when OperatorJane seeks work by walking around the U, she starts walking backwards once she hits the other end of the U. Is there a way to get her to turn around and walk forward all the time?

I also tried using one AGV path crossing another (between the conveyor and processor), hoping to "glue" them together where they cross, with a control point. However that didn't work, so I had to go back to two separate short paths - one from the conveyor to the control point, and the other from that same control point to the processor. Thing is I'm not able to get those two separate line segments to "snap" end-to-end so as a result OperatorJane does a bit of an instant pirouettte between those two ends. That I think is what contributes to her also walking backwards depending on where those two short-line endpoints lie with respect to the main U path.

I am learning AGV's - and it's rather interesting the interplay and effect of paths on how the TE behaves.

question