The big Factory I/O Wishlist

Claudio179, what you’re talking about are mostly libraries that work on the platforms and can’t be included in the simulator. There are many databases. I use ACCESS and EXCEL, but I actually use Notepad, for its ease and practicality. Now, which one do you add? DB2, MySQL, ORACLE?

On the other hand, everything you’re talking about is already done by FACTORY IO, and even more, for example, OCR (optical character recognition), speech recognition, handwritten text recognition. All of that is done by the simulator, and you can see it in my contributions because they’re actually external libraries. I also don’t see much use in adding drivers. In the same case with databases, there are many drivers, and when it comes down to it, you’ll have to adapt to the one you get.

This option would be very practical, as it prevents you from having to close each test and then go to the drivers and reconnect.

Hello:

Here’s another improvement to the simulator based on real, practical, and proven cases.

These improvements are what Factory IO needs, not 3D imports, whose editing of these types of objects is far from what students actually need.

This is my opinion, which may be wrong, but I don’t think so…

Hi everyone,
I would like to propose adding accumulation conveyor functionality to Factory I/O.

Most real industrial systems use zero-pressure accumulation (ZPA) or motor-driven roller accumulation, where zones can hold multiple boxes without collisions. This feature would make simulations far more realistic for training PLC logic, especially for users working with ZPA, sorter lines, and material-handling systems.

I hope the Factory I/O team and community can consider this improvement.
Thanks!

2 Likes

I think it would be beneficial in the drivers screen, to have the ability to combine sensors into a single feedback to a PLC, or other driver. It would also be nice to be able to invert the signal.

In the real world, we have some time of flight sensors that work very similar to the photoelectric sensor, but we have the ability to add muting. For example, I can have the sensor only detect when an object is closer than 1M, and more than 3M away. I could accomplish this in FIO by utilizing 2 photoelectric sensors, and OR-ing them together in the drivers table. We also have Limit switches and Reed switches that do similar aspects that we could simulate in FIO with some creative sensor placements.

Another thing that would be really cool, if we had an option on all the sensor equipment, is to make each of the sensors “invisible” to the physics engine. For example, the RFID sensor, if we wanted to limit the detection distance, but had a single part on the middle of the pallet, we could place the RFID sensor right in the middle of the conveyor, and it would still do RFID things, BUT, the pallet and part would pass right through them instead of hitting them like a physical object.

Another thing, similar to what you implemented for the N.O / N.C push buttons, It would be really nice to do that with the diffuse sensors, and retro reflective sensors. Currently I swap the type of sensor utilized, but some times I run into an issue with where to place the reflector, because they are made from some serious materials in FIO. I can tell you in the real world, they aren’t that strong. HAHA.

Hi Justin Anderson;

Give me an example of where this would be used? What would its usefulness be in a real-world scenario? What would it actually do?…

Regards

A post was merged into an existing topic: The big Factory I/O Wishlist (Discussion)

A post was merged into an existing topic: The big Factory I/O Wishlist (Discussion)

Cheers,

This thread is mostly meant for discussing objects that we see in the field, that we think Factory IO would benefit from implementing. There is also a little bit of banter/joking/conversation, but ideally we should want to keep this thread to Wishlist items. IF you see a suggestion, and have a work around that you have done before, that’s a great thing to share. If there are teaching moments, sometimes it’s worth starting a new thread to not derail this one.

Your image is pretty much accurate. I use them in the field for a few reasons, we use them to say that a part is not positioned correctly. If it’s too far away, the signal will be high, if it’s too close, it will be high. If it’s not going to cause an error, it’s low.(Usually the sensor is inverted so the logic works, but that’s apart of a different FIO request) I also use them where we used to use limit switches on moving pieces of equipment, but the limit switches fail consistently, or I am tired of dealing with passing signals through an energy chain. So I point the Time of flight sensor at the object, and use the sensor in a safe location to mimic the LS. There are other examples, but the example was just one of many other things I would utilize it for in Factory IO, so I don’t have to rescript different objects to do something similar.

We also use this kind of sensor for positioning tasks, they are great! You set a min and max distance, and then you set if you want a high or low signal for any measurement that falls within the min/max. So, I support this.

Also, I support your first part of your comment. I think this is the wrong thread to criticise and dissect the ideas put forth by others. We have the wishlist discussion thread for that!

2 posts were merged into an existing topic: Sensor’s window mode discussion