question

Craig DIckson avatar image
8 Likes"
Craig DIckson asked anthony.johnson edited

Elimination of types for conveyor system components?

Can someone please tell me what the rationale for eliminating conveyor types, control point types, transfer types, and photoeye types in FlexSim 21 is? I use every one of those every day, and not having them will make modeling large distribution centers much more tedious and - even more importantly - a lot more error-prone. This seems like a major step back to the (lack of) functionality of FlexSim 7.

Yes, I realize that I can use (e.g.) functions to get back *some* of the functionality (and no, "Edit selected / copy from highlighted" is not the same) but it still requires several extra clicks for each and every object. Also, I suspect that many of my existing models will not run in FlexSim 21 because I frequently use custom trigger logic by type.

I was in the process of setting up set of conveyor types for my company's conveyor designers to use for rapid design and animation (instead of AutoCAD and 3dsMax). (read: more licenses.) Without types, I can't make this work easily enough to be worth it.

I will not be upgrading to FlexSim 21. I am absolutely stunned at this change and extremely frustrated.

P.S. -- This is compounded by the fact that starting in FlexSim 20 the ability to click on an arrow at the bottom of an object's form to get to the next object of that type was removed. This was another often-used way to easily make sure similar objects were similar - i.e. verifying a model.

FlexSim 21.0.1
flexsim 21.0.1conveyor types
· 8
5 |100000
Toggle Comment visibility. Current Visibility: Viewable by all users

Up to 12 attachments (including images) can be used with a maximum of 23.8 MiB each and 47.7 MiB total.

Jason Lightfoot avatar image Jason Lightfoot ♦♦ commented ·

@anthony.johnson

0 Likes 0 ·
Craig DIckson avatar image Craig DIckson commented ·

To put it another way, Types let me use Object Oriented programming techniques to build conveyor systems. In FS 21 conveyors will be built with programming techniques leftover from Pascal (at best) or maybe even ForTran.

0 Likes 0 ·
Jason Lightfoot avatar image Jason Lightfoot ♦♦ Craig DIckson commented ·

Craig - it wasn't very object oriented to have the parameters of a conveyor on another object, but I can see managing the group together that way is like managing a class. You could say, that by having all parameters on the conveyor objects is better object definition - you can copy the objects without having to copy all the types that are stored elsewhere (eg. between models)

I think the new parameters tables are meant to allow rapid changing/alignment of settings for groups of objects - conveyors included - perhaps Anthony has a view on this.

Also - in my quick tests on the parameter updates - it seemed to work okay for me in custom code on an entryTransfer Type and custom code on a custom type - so I'd see if that works first, and if not post the issue here - we may be able to figure out something to help.

We might be able to help with a more object oriented like management tool as well - I need to check our position.




0 Likes 0 ·
Craig DIckson avatar image Craig DIckson Jason Lightfoot ♦♦ commented ·

I'll also admit that this is mostly me venting, and not asking a specific question, and that there isn't really a dang thing I can do about it now except try to work with it.

I have been occasionally frustrated with FlexSim in the past for being somewhat crash-prone, but have always liked the functionality and the direction of the changes -- well designed to help an engineer/analyst.

Here it feels like the change was made for computer scientist/programmer reasons, not to support the analysts.


1 Like 1 ·
Show more comments
Show more comments
Ben Wilson avatar image Ben Wilson ♦♦ commented ·

Hi @Craig DIckson, was anthony.johnson's or Phil BoBo's answer helpful? If so, please click the red "Accept" button at the bottom one of their answers. 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.

0 Likes 0 ·
Matthew Gillespie avatar image Matthew Gillespie ♦♦ Ben Wilson ♦♦ commented ·

@Ben Wilson @Craig DIckson We're preparing to release the 21.0.2 bug fix release in the next few days which will include the update script mentioned by Anthony here https://answers.flexsim.com/comments/96425/view.html

0 Likes 0 ·

2 Answers

anthony.johnson avatar image
2 Likes"
anthony.johnson answered anthony.johnson edited

Craig, I stand by my original explanation. Conveyor types were not an OOP design. In OOP design, a user can inherit from a parent class and then selectively choose what to override. Conveyor types, by contrast, were an all-or-nothing, arbitrarily defined sharing mechanism, and created just as many headaches as they solved. Take for example, our decision for locating the conveyor OnEntry, OnExit, OnItemBump, etc. triggers. If you notice, we put them directly on the conveyor from the beginning, not on the conveyor type. It seems, according to your logic, that we should have put those triggers on the conveyor type, so that they could be shared better. Let's say we had put those triggers on the conveyor types. Then, let's say you create a massive model with something like 30 different conveyor types, because there were 30 different configurations of max speeds, spacing, slug building, etc. Then you realize that you want to add logic to all of your conveyors' OnEntry and OnExit triggers, for statistical tracking. All of a sudden, this supposedly wonderful conveyor types feature is now working against you. Every time you want to change or adjust the OnEntry and OnExit triggers, you have to manually visit each one of your 30 conveyor types. You can't use standard FlexSim features like Copy From Highlighted, because that doesn't work for conveyor types. And, you can't use FlexSim's new property API, or object property tables, because all of those triggers are hidden behind a conveyor's single "Type" property. You must visit, one by one, each of those conveyor types. That's not OOP.

So, since we decided to put conveyor triggers directly on the conveyors (and I'm glad we decided to put them on the conveyors), we're left with this ugly chimera where some things are defined on the type, and some things are defined directly on the object, and which one is which is decided arbitrarily, by us. That is not OOP, that is hard-coded inflexibility.

We have had many users complain "why can't I copy the conveyor speed from my highlighted conveyor to all of the other selected conveyors?" Well, sorry, new user, but you should have realized that the conveyors are designed differently than all of the other objects in FlexSim, and copy from highlighted doesn't work for them. Is that really supposed to be our answer to new users? Further, expanding the conveyor type design to everything else would be a time-intensive error-prone backwards compatibility nightmare, where we are making the same arbitrary decisions for inflexible sharing that we had to make for conveyors.

All of the things you could do previously with conveyor types, you can now do (or will soon be able to do) with object property tables. Just set up a group of conveyors that represents what previously would have been your type. Then add an object property table that filters by that group. You can quickly get conveyor basic properties from the conveyor's Conveyor Behavior panel and clicking the button on the top of the pane, then choose "Create New Property Table > Basic Conveyor Properties". Then change the property table's filter to filter by the group (click the filter button and select General > Group, then enter the group name). Once you have that table set up, you can both view and change the properties you need to for that group. Whenever you later need to make new changes, you can just reopen that property table and update the values. In the next version (unfortunately I didn't have the time to put it in this version), you will also be able to edit/add/remove trigger logic to these objects.

I totally get your desire for shared behavior/properties. We have thrown around various ideas for implementing better shared behavior. Object process flows go a long way toward that, but there is still more space for improvement. But conveyor types were not even close to being that feature. Further, if we are to do that type of feature at some point, it would have to work for all objects, and therefore we would have to break away from conveyor types anyway. We felt that, with the new addition of property tables, users had capability parity with what they could previously do with conveyor types. And since not making a change would have perpetuated users' inability to edit conveyors, decision points, photo eyes, etc. through the new property tables, we decided to go ahead and make the leap.

As far as backwards compatibility, as long as you have not dug into the undocumented internal structure of the conveyor types, models should update properly, even with triggers.

And, as far as the next/previous buttons, we realized that you get the same functionality by simply clicking on the conveyors in the model that you want to edit, because the properties immediately update in the properties pane on the right. The next/previous buttons arbitrarily decided on the next object based on model rank. Clicking on an object in the view is a much more intuitive way for the user to decide which object's properties to edit.


propsbutton.png (773 B)
· 3
5 |100000
Toggle Comment visibility. Current Visibility: Viewable by all users

Up to 12 attachments (including images) can be used with a maximum of 23.8 MiB each and 47.7 MiB total.

Craig DIckson avatar image Craig DIckson commented ·

I have to say that's a surprisingly defensive answer.

In my long experience (I've been programming simulations since 1987 in everything from SIMAN to Quest to AutoMod to AnyLogic), the best simulation analysts as far as *actually solving problems* are engineers first and computer scientists second. This all sounds like the opposite - the CS side is driving instead of the engineering/user side.

But beyond that, I disagree with several of your examples.

First off, building with types can absolutely be thought of as object oriented if you think of the object as being the *type*, not as "conveyor". Anything you set locally is then a property. I can tell you that any conveyor engineer thinks this way (it's how they build designs in ACAD). If the tutorials had talked more about types I suspect they would have been used. (The current tutorials are far better than they used to be though.)

Second, having some of your users complain because they fail to use an available feature isn't a good reason to kill that feature. You could have made "copy to selection" change the type to "custom", which was always a valid type option. (Or you could have taught them about types. See my previous comment about tutorials.) And as I mentioned before, I often wished for types for eg processors.

Regarding manually changing all types -- the scenario you described of needing to add logic to all types simultaneously is extremely uncommon. In the real world I am far, far more likely to want to change the speed of e.g. all the speed-up belts in a system, and they are scattered here and there throughout. Finding and selecting each one is ridiculously tedious. So I guess I could remember to put each one in a group as I draw it (but it's easy to forget since being in a group doesn't change the visual while type does). To an engineer it's a lot more steps and less intuitive. (Also, with types I can change the speed on the fly using code with a single statement; with groups I think I'd have to write code to loop through each item in the group that represents the type.)

I'll have to find out the hard way about compatibility I guess, but the release notes do suggest that there could be issues.

Regarding next/previous, this is not so annoying for conveyor, for the reasons you state: lots of individual beds which are in a pretty random sequence in the tree), but it is a royal pain for processors, queues, control points, PEs etc. Clicking on the object in the model is not as easy as you imply, because the objects are often all over the 3d space, but since there are typically not that many of them, they are usually near each other in the tree. It was a useful shortcut, and was *at least* three clicks fewer each time. (By the way, this is when Types for processors, queues etc. would have been nice too.)

So enough venting now, what's done is done (though still disappointing.) You mentioned property tables as the new solution (though it sounds backwards to me - draw the conveyors and then add to the group/table, rather than define the types and then add the conveyors.). Is there a tutorial on their use? Doesn't sound at all intuitive.

1 Like 1 ·
anthony.johnson avatar image anthony.johnson ♦♦ Craig DIckson commented ·

We don't have a bonafide tutorial for object property tables, but the reference topic on object property tables shows you the different ways you can create property tables, and documents how to use them.

The change to conveyor types was brought about specifically from users' feedback on the limitations of conveyor types, specifically because the sharing mechanism was so inflexible. This was not something we "CS" people just decided out of the blue. It was based on real feedback from users. Further, object property tables enable users to treat the objects in their model essentially like a database. What "analyst" doesn't like a good database? I would argue that object property tables empower analysts and engineers even more than conveyor types did, because they give those analysts and engineers more visibility into, and control over, the data stored in their model objects.

And finally, we do appreciate your feedback. After more discussion, we're also going to add "default groups" properties to the conveyor system, which will replace the old "default conveyor type" etc. This will automatically add new conveyors, decision points, etc. to the groups that you define, leaving one less step you have to make to get your property tables up and going (I wonder if that might be a good general mechanism, but for now we'll just make it a conveyor-specific property).

0 Likes 0 ·
anthony.johnson avatar image anthony.johnson ♦♦ commented ·

Craig, after discussing this with the dev group, I'm going to add an update script that will create a group for all of the previous conveyor types. This will make it easier to create your object property tables once the models have been updated to 21.0.

0 Likes 0 ·
Phil BoBo avatar image
0 Likes"
Phil BoBo answered Craig DIckson commented

There's a discussion regarding this change in the FlexSim 2021 Beta thread that includes Anthony's explanation for why this change was made: https://answers.flexsim.com/comments/93300/view.html

· 2
5 |100000
Toggle Comment visibility. Current Visibility: Viewable by all users

Up to 12 attachments (including images) can be used with a maximum of 23.8 MiB each and 47.7 MiB total.

Craig DIckson avatar image Craig DIckson commented ·

I read the rationale there, and it's just completely backwards: the answer could just as easily have been to ADD types for processors, not kill them for conveyors. I had often wished for that and absolutely would have used it.


0 Likes 0 ·
Craig DIckson avatar image Craig DIckson Craig DIckson commented ·

Plus a conveyor model would quite reasonably have thousands of individual conveyor beds and hundreds of PEs; it would be an unusual model that had more than 50 processors.

0 Likes 0 ·