Unknown Exception; Exception caught in TreeNode::receivemessage()

Question

question

Robert F2 asked Jun 3, '20 Robert F2 commented Jun 9, '20

Unknown Exception; Exception caught in TreeNode::receivemessage()

I have a strange problem that I have been unable to solve in my model where at random points I will get these "Exception Caught in" errors.

If I reset and run the model, I get the same errors except that the time the error occurs happens at a different time. Sometimes the model will get stuck soon after starting it, other times the model can run for days without error.

I found other posts about this type of exception, but those were people not using the newest update of FlexSim. My current FlexSim version is 20.1.2 which I believe is the most recent version yet I still get these exceptions when running the model.

Can anyone help with this issue?

Thanks

Software Version:

FlexSim 20.1.2

flexsim 20.1.2 exception caught

pic1.png (137.7 KiB)

robotfinished.fsm (612.4 KiB)

· 6

tannerp commented · Jun 03, 2020 at 07:03 PM

@Robert F2,

Most of the errors seem to be surrounding Queue78, Queue79, Queue76, and the entry transfers just before them. Do you have a version of the model that doesn't throw exceptions? I think that some of the custom code may be interfering with the 3D objects' logic and causing the errors, but I'm not sure where to dig into the code. That's why it would be helpful to have a version without the error to compare to.

Also, just curious if you could add references to the posts you found about this error in a comment. It's probable that the error is going to be the same in older versions if it's due to custom code and 3D objects conflicting in their logic.

0 ·

Robert F2 commented · Jun 04, 2020 at 08:32 PM

Hi @tanner.p,

After looking at an earlier save of the model, I think this error can be narrowed down to the custom code in the Entry triggers of Queue1 and Queue78. I am still not sure what is wrong with this code, though, since it seems to work correctly at points but then not work correctly at other points.

I appreciate your help!

0 ·

tannerp Robert F2 commented · Jun 04, 2020 at 09:29 PM

That's where I ended up narrowing it down to as well. I'm not sure whether it's the timing of the open and close port commands or something else, but it must be related to the custom code. What is the custom code in those triggers designed to do? Maybe we could accomplish the same thing using Process Flow and avoid compromising the default 3D logic (there's a lot going on in the background for 3D objects).

0 ·

Robert F2 commented · Jun 05, 2020 at 02:44 PM

The custom codes in Queue1 and 78 are designed to first check if the part type has changed to prevent two different part types from being placed on the same pallet. If the part type did change, the queue's batch size is updated to the conveyors current content. Then, the downstream combiner has its target quantity set to equal the queue's batch size.

As you said, there is quite a lot going on in the 3D objects' backgrounds. I would have preferred to use the process flow for this particular concept but I had no luck creating it. If you have any other questions please let me know.

0 ·

Robert F2 Robert F2 commented · Jun 05, 2020 at 02:46 PM

Also, here is a reference to a similar problem I saw on here.

0 ·

Robert F2 Robert F2 commented · Jun 08, 2020 at 08:15 PM

@tanner.p

I have been unable to replace this process using Process Flow, do you have any idea how we could recreate this without the custom code?

0 ·

Answer 1 · 2020-06-09T03:06:12Z

tannerp answered Jun 9, '20 Robert F2 commented Jun 9, '20

@Robert F2,

Thanks for the updates and the description. So the way I understand it is that if the PartType label on an item is different than the last one, you just want to finish combining the downstream items and send them to the sink? I've updated your model to reflect that logic. If that's not quite it, I suggest we schedule a Zoom meeting where we can discuss alternatives to the custom code.

Here's the updated model. Note that I also updated some logic on Processor1 and Processor2 so the entry triggers weren't throwing errors.

robotfinished (3)_2.fsm

robotfinished-3-2.fsm (618.5 KiB)

· 1

Robert F2 commented · Jun 09, 2020 at 06:21 PM

Thanks so much! You've been a huge help and my model is working great now.

1 ·

question