Usage with Warehouse Control System

Hi,

I just found Factory IO yesterday. Looks nice.
However I’m not sure it covers my needs. I develop and maintain a largish Warehouse Control System. We adapt it heavily for each project - if needed.
It all depends on how the site looks like of course.

A very common scenario is that we are faced with one or two conveyor systems - pallets or totes -and some kind of storage system - like cranes or shuttles.

The problem is that is is very often a (to us) new vendor delivering the hardware. And almost all vendors are
thinking that their communicating protocol is the best there is.

So - adapting to new communication protocols are something we need to do in almost all projects.
Usually it is socket-based. Some kind of byte-array or text-string is exchanged,
with fields containing different data. Like assignment-id, from-location, to-location, loadcarriertype, height, weight, sizes, barcodes…
we’ve seen one with JSON, and another with XML. sometimes 1 socket , sometimes 2.

So for conveyor a telegram sequence like this is common
Pallet is introduce at an id-station
PLC sends a format telegram containing

  • location
  • barcode
  • sizes
  • errors (too wide/ bad runners etc)

WCS thinks bit and then replies with an Transport order with

  • an assignment-id
  • from-location
  • to-location

The conveyor system now moves the pallet towards the destination.
Once it has arrives it will send an Assignment completed tgm

  • assignment-id
  • location
  • Error-code

If this is not the final destination, the WCS does some routing calculation,
and sends a new Transport order, and waits for a new assignment completed

This can span over large areas, so the transport start in PLC 1 and passes
over the area PLC 2 and PLC 3 covers and ends up at PLC4.

for inbound transports, the pallet usually eventually is picked up by a crane.
The telegrams looks different, and it may be another vendor. But same priciples applies.

So I am after an emulation program that I can

  • draw the site into a model. 2d or 3d does not matter.
  • I like to communicate with the model - by sending
    data in the way that will be used on site.
    I like to send the site-specific telegrams mentioned above.
    The model then needs some logic to
  • understand the telegrams
  • carry out the commands in the telegrams
  • report back after movement.

This is done in PLC on site, but I want to be able to have that logic within the model.

Now - I don’t see that here, I see ‘connect the PLC to the model’
But we are not PLC-programmers. We just talk to PLCs we have no clue of programming them.

I can see that we need to create som middle-ware to have this chaing

WCS ↔ site cnv-protocol ↔ middle-ware ↔ model-protocol ↔ Model

where model-protocol would be generic like

  • MOVETO
  • REPORT-MOVE

and for cranes

  • PICKUP
  • REPORT-PICK
  • DEPOSIT
  • REPORT-DEPOSIT
  • REPORT-STATUS

Has anyone done this ?
is it possible? Or do we have to draw a full conveyor system that
moves pallets only by turning on Motors and reading sensors?
Or is this not the right tool?

What I am after is something that I can draw fairly fast. I does NOT need to be exact as the drawing. The logical message exchanges is what is important.
The way the PLC turns on/off motors are of no real interest here.

/Björn

1 Like

Hi bflundin;

Let’s take it step by step:

1- FACTORY IO covers almost 99% of your needs, provided you don’t need to connect more than one PLC at a time in the scene.

2- There’s no problem sending telegrams between PLCs and having them obey the telegram command.

3- The transport starts at PLC 1, passes through the area covered by PLC 2 and PLC 3, and ends at PLC 4, without any problems whatsoever.

4- I have no problem creating what you’re looking for: an emulation program that can do what you’ve described.

BUT…

You need to explain what you want to do more slowly and with a programmer’s mindset. In other words, don’t write it all at once like you did before. No, not like that. Think like a programmer. Break your case down into smaller parts and explain them here, calmly and without rushing.

Watch these videos, analyze them, and compare them to what you want to do, and then share your thoughts here:

Your wishes are a hobby for me.

Regards.

2- There’s no problem sending telegrams between PLCs and having them obey the telegram command.
But where is the PLC? within the model? or outside?
Is it programmed as a PLC or is there a way of programming PLC-logic in a non-PLC language within the model?

3- The transport starts at PLC 1, passes through the area covered by PLC 2 and PLC 3, and ends at PLC 4, without any problems whatsoever.
Sounds good. My focus here is not to test the PLC, but to test the WCS side of the protocol.

4- I have no problem creating what you’re looking for: an emulation program that can do what you’ve described.
This sounds good. Can you elaborate? Does this program control the model’s conveyor system?Are there ready-made components like a crane/racks and conveyor systems. I see conveyor systems in the video,
and I guess they are put together by ready-to-use sections.

Let’s look at a simple layout like below.
A pallet arrives at ID1. It appears by the model creating it.
This can be done by the model reading a file on disk with pallet properties,
or generated by the model.

Here I’d like the model to send a telegram with
relevant (faked) data to the WCS - prefferbly with a bespoke protocol.

The telegram will then be responded to by WCS sending a Transport order.
‘Please go to SP’

  ID1
   |
   |
   SP
   |
|---------|
|         |
C1        C2

The pallet then moves to SP and send an arrival telegram to WCS.
SP is a selection point, where WCS select a location within the racking,
and also the input conveyor to the crane (C1 or C2)

So new transport tgm to the model, to move to say C2.
Once there the model reports back arrival at C3 to the WCS

Next is the WCS to tell the crane at C2 to pick it up - with another protocol.
It replies to the WCS with status of the pickup.
if Ok, WCS tells it via a deposit tgm to move and put the
pallet into racking at a certain coordinate.
Once in the racking, the crane reports back the status.
The pallet is now stored, and we are done

The main question I have is

  • are there ready-made components like this?

  • if not - is it possible to create them, and reuse them?

  • and the programming - can it be done within the model in a high-level language?
    Or is it ladder-logic or structured text the way to program it?

  • And with that comes - are the consultants around that can do what I want?

  • The most important question is then - In order to make the
    pallet move from ID1 to C2 via SP, do I control all
    the conveyor sections on the way ? Or is the tgm from A → B possible
    to send without PLC logic being programmed.

>Break your case down into smaller parts and explain them here, calmly and without rushing.

I’m not after programming details now. I need to understand the overall architecture
before the details come into place.
I see that a model i Fabric I/O can be connected PLC - thus testing the PLC code.
But I’m after testing the other side of that PLC’s connection.
and have the PLC logic inside the model - with no PLC. Some vendors call it IT-testing

/Björn

Hi bflundin;

2-The PLC is inside the model and connected via Ethernet.

3-That’s what we’re going to do, the socket protocol that controls the PLC, the PLC is the least important thing.

4-Nothing is pre-assembled; you have to do it yourself with the existing tools. We’ll do it together, and you’ll see how it all falls into place…

Let’s see your design adapted to a scene:

The questions you have:

No, the tools to create them exist.

If they can be created, then we will.

Yes, the programming must be high-level: C#, .NET, ASP.NET, Python, JavaScript… logic and ST are not suitable for this type of programming.

There are no consultants for what you want; you must create it with existing tools.

This cannot be done without a PLC. Each part has its function and both must be coordinated.

The image shows the system architecture and assembly details.

Now I have a question:

Is this what you’re seeing in your idea? Have I understood correctly?

If so, implementing this requires 150 lines of code and takes approximately one hour.

Regards.

What you just did borders to fantastic.
I had in mind that the crane and rack was rotated 90 degrees,
and there are 3 cranes traveling i 3 aisles surrounded by 2 racks each.
This screen-shot below indicates what I meant.
However that is details, your rigg reminds me of a
large Swedish brand making washing machines. After they are completed, they
were (this is long time ago) put in a test rigg, washing some clothes before shipped to dealer.
And was very similar to your setup.

The PLC is inside the model and connected via Ethernet.
3-That’s what we’re going to do, the socket protocol that controls the PLC, the PLC is the least important thing.

And this is what I don’t understand. What is the role of the PLC here?
Why is one needed?
I think we come from different worlds so we may have different ways of thinking.
In the screenshot above you see some lines in the bottom were we have sent
telegrams to conveyor PLC and to the stacker cranes.
(the yellow and cyan thins are doors depalletized from pallet, and entering
a conveyor. the yellow doors are at selection points, waiting to
be picked up by transfer cars and then to be delivered to inbound conveyor of crane.
never mind the right part of the pic.)
The pic is from a tool we use sometimes - which I’m looking to replace.

Yes, the programming must be high-level: C#, .NET, ASP.NET, Python, JavaScript… logic and ST are not suitable for this type of programming.

So exactly what do we program here? The movement from ID1 to SP ?
how to interpret the tgms?

This cannot be done without a PLC. Each part has its function and both must be coordinated.

But what does the virtual PLC do - in detail?
Does it control the motors? Does the high level programming part involve
turning conveyor motors on/off and read sensors for item presence?

4-Nothing is pre-assembled; you have to do it yourself with the existing tools.
We’ll do it together, and you’ll see how it all falls into place…

But the orange crane you have in the pic - is that not a pre-made object?
Did you create this just now?
And I see roller conveyors/switches/chain conveyors.
Surely they already exist in some library?

The arrows you have drawn for the tgm exchange are between
different location in the layout and the WCS. That is fine,
and they are placed as I imagined it. So far so good.
Then there is the display labeled PC. I assume the model runs in there.
But again - I still don’t get the role of the PLC in the PIC.
What messages are sent between PLC and the model.

In the tool we have used, if you create a route between 2 location on the conveyor system, and send a pallet from one location to the other you program it in the model.

pallet.MoveTo(location2)

and then it moves. It handles routing itself. This is the kind of programming I’m after. So what is the role of the PLC in Factory I/O? Routing between locations?

When I asked about high-level programming I also mean
the emulation of the PLC on a high level.

If so, implementing this requires 150 lines of code and takes approximately one hour.

Impressing

There are no consultants for what you want

Hmm, too bad. This could be a business case.

Sorry for being a bit confused.
However I really see potential here

/Björn

Hi bflundin;

Don’t worry, you’ll understand it perfectly, from the PLC’s location to the system’s structure.

That’s why my channel presents the videos from beginning to end, so students can follow along.

I’ll finish contribution 112, which only requires the database, and then I’ll work on your project in phases.

Regards.

Hi bflundin;

I’m going to summarize your post; we’ll go step by step so you understand what we’re trying to do:

The PLC’s function is to act as an intermediary between the telegram and the machine motors, and simultaneously between the machine sensors and the telegram. The PC sends a “telegram” to the PLC to advance the part, and when the part reaches the sensor, the PLC sends a “telegram” back to the PC to indicate its arrival. However, both the “telegrams” entering and leaving the PLC are in the form of bits or memory words that the PC must interpret and display the result to the operator. This is where high-level programming comes in, and it cannot be done with ladder logic, ST, or even Grafcet.

As you can see, the PLC is essential to control all the motors and all the sensors and color detectors and other elements that may exist in the system.

We don’t come from different worlds because all programming is “the same”; obviously there are differences, but ultimately one is as good as another…

High-level programming involves sending and receiving messages. It receives messages from sensors or operators, and depending on what it receives, it sends them to motors or to operators in the SCADA or HMI system.

Factory IO objects, orange crane, tables, rollers, etc., are elements that Factory IO incorporates to create scenes. When I say there is no pre-configuration, I mean the telegrams; it would be the same as a database—what you need doesn’t exist, only the tools to do what you need.

Messages are sent between slave and master, with the slave in this case translating the telegram into bits or memory words.

In this case, no route is created between two locations because there is only one path. The pallet is sent and we wait for it to arrive at its destination. When that happens, the PLC detects it and sends the telegram to the PC. Therefore, there is no route to follow, as if it were, for example, an automatic baggage handling system. Here, there is a route, but it is a more complex issue because it has to be configured BEFORE the package leaves, which is not the case here.

The idea of ​​using 150 lines and doing it in 1 hour (that’s just an expression) is something I’ve already done; I just need to adapt it to your situation. Any other user of this site would take much longer. Besides, my library is perfectly structured to handle any eventuality, as was the case with you…

Consultants are scarce in these cases, and they’ll become even scarcer, I know from experience.

Don’t worry about your confusion; we’re going to clarify many things practically, not theoretically, which is the most common approach—lots of theory, but then there’s no way to know if it actually works or not.

We’re going to demonstrate that Factory IO is perfectly useful for analyzing systems like the one you mentioned, in a clear and easy-to-understand way, and we’ll leave its potential there.

Now that contribution 112 is finished, I’m going to start on your topic.

Regards.

Hi bflundin;

This is what the PLC does and what it’s used for.

Regards.

Hi bflundin;

We’re going to implement the project in two different ways: one where each operator controls only one part, and another where all operators control all parts. Obviously, the second approach requires some kind of chat system to reflect what each operator is doing. This chat should be shared by everyone and updated on all platforms.

This is an interesting project, especially because it has no limits, or very high ones. Furthermore, only a large industry can implement a system where machines communicate with operators about what to do and when to do it.

I appreciate your contribution. Of course, once we’re confident in our approach, I’ll create a series of videos about the project on my channel. For now, let’s analyze the case thoroughly.

I look forward to your comments and suggestions, as you know this system better than I do.

Regards

I’m really impressed by your enthusiasm :slight_smile:

I am in the process of getting ok to install Factory I/O on my work PC, but it is an IT-dept thing first. However I watched the video, and read up more on the documentation.

I think that what you call high-level is the programming of the user interface for the operators.

Then that communicates with the internal PLC

What I want to do is to have no user interface, and communicate directly to the internal PLC.

I see that there are ModbusTCP and OPC-DA/UA which we can use.

I was mostly looking around, and I think I need to play a bit with Factory I/O to get a grip of its capabilities. However - pressing projects takes most of my time right now.

I’ll see if I can pass the playing around to a colleague of mine - or I’ll pick it up during summer

/Björn

Hi bflundin;

This is the part about communication via telegrams. So far, so good?

This is a huge topic and allows for many possible continuations. Therefore, before creating a video series for students, I like to make sure everything is feasible. That is, I test all the shared contributions before creating the video series. Otherwise, it’s possible that a video can’t be followed from a certain point, and that would be a problem for the students. First, we ensure everything is possible, and then we create the series.

For this reason, I hope the user who started this thread, b.f.lundin, will provide feedback so that everything is as realistic as possible.

Regards

Hi bflundin;

Programming is my hobby; the more challenging and the broader the analysis, the better.

As you mentioned at the beginning, you were familiar with FactoryIO and unsure if it would work for testing your communications, waiting for its installation. I believe, as I mentioned, that it’s perfectly viable to use it to test your idea.

Indeed, the high-level interface is for HMIs and operator control; it’s what sends, receives, and manages system telegrams.

Therefore, you can’t connect to a PLC without a user interface. You can see this in the video; without being able to see or write TGMs, it’s simply not possible.

Yes, I think you should experiment a bit with FactoryIO and also with the high-level language, but don’t worry, take it one step at a time…

I’m going to continue working on your project. Now I want to have it so that, through permissions sent to the master, the master authorizes the operator only to the part of that permission. Therefore, we would be entering one of the ways we plan to implement it…

I like your project…

Regards

The second video is very close to what I want/need in a general sense.

You have split the intransport - ID3 → racking into 3 parts

  • Pallet appears and it move to the ID station
  • Here - you identify by colors.
  • It appears in the operator screen
  • The operator sends it to the first table
  • at arrival the screen is updated
  • the operator enters a destination where the crane will pick it up
  • it arrives, and it is presented on the screen again
  • the operator makes the final storage decision.

This mirrors my system very well - apart from we don’t have an operator.

The WCS system makes all these decisions, and gets all of the notifications.

Therefore, you can’t connect to a PLC without a user interface. You can see this in the video; without being able to see or write TGMs, it’s simply not possible

This I don’t get. I looked around in the docs and I think it describes OPC or ModbusTCP to communicate with the internal PLC. Both are supported for external PLC - as I understand it

Then I have a question about scalability. I think I saw max number locations in rack is some hundred location. We have sites with racks with 7000 to 10000 locations per rack. Some are double deep but still. Then they of course have many racks. and warehouse storage is like hard drives. it’s either new or full - meaning we have customers with more the 100_000 totes is the racking.

Is it technically possible to have this much?

I can imagine that I need to find a way around it.

But the real interesting part now for me is

  1. the layout is general enough - good :slight_smile:
  2. how does the actual PLC code look like?
  3. how does the interaction between HMI and PLC work?
  4. how does the messages between HMI and PLC look like?
  5. Can I communicate with the internal PLC from a program on another computer

Really good work

/Björn

Hi bflundin;

When we talk about an operator, it doesn’t have to be a person; it could be a program or a query to a database where decisions are recorded.

To do what you want, you need to use a programmer’s mindset, which is to break down a large problem into very small parts. Let me explain:

We have a text, which can be read by a person or a machine. If it’s read by a person, they will activate the next step. If it’s a machine, it would work like this:

If the text is “xxxxxx”, then go to the database and search it. When you find the text, do what it says in the adjacent cell, or directly, without the database, do this or that…

We already have the text, which is just a small part of your problem. Now tell me what you mean by “operator,” and how you want me to interpret the text. I assure you that whatever you tell me is the least of my problems, and I can adapt it to whatever you want without any issues. Do you see where this is going? We’re breaking down your big problem into many very small, manageable problems…

In short, someone or something must make the decisions AFTER reading the telegrams, but the first step is to obtain the telegrams.

All the racks you have can be controlled, and the entire system you mentioned can be controlled. It requires a large number of PLCs, components, and time, but as far as the sockets are concerned, there are no limitations, since one PLC with its slaves can control another PLC with its slaves, and those two combinations alone allow more than 500 PCs to control your system, which is a lot of control, don’t you think?

The part you’re interested in:

1- I think I understand what you want to do. Obviously, this situation is a demonstration of what’s been presented regarding Factory IO and is limited to a demonstration exercise for automation students and professors.

2, 3, and 4- To answer these, we need to break the question down into many simpler questions and understand programming concepts from the beginning. You can’t understand this type of project if you don’t know what a bit is, or how to connect a motor to a PLC. First things first…

5- Yes, it’s possible. In fact, that’s what you’ll see in the next video. Notice that access control has been programmed for the machine’s components, all registered from the server. The server authorizes access based on the key sent via the telegram, specifying which parts of the machine are permitted.

Each slave is a different PC that connects to the master via IP address and port. All slave IP addresses must point to the master’s IP address and use the same port. If using Ethernet and all on the same network, the port doesn’t need to be opened on the router. However, if access is from the internet and outside the network, the port must be opened on the router.

And now my question:

What controls the telegrams, if not a human operator?

I like your project…

Regards

Hi bflundin;

Here’s the second method I was talking about, where everyone can access the entire machine simultaneously, but with the ability to see the operations performed through the chat between the slaves and the master.

From here, we’ll see what happens…

Now tell me, what’s the next step?

However, I think I already have enough information to create a series of videos for my channel, and even another contribution to Factory IO based on what we’ve covered so far…

Regards

You can’t understand this type of project if you don’t know what a bit is, or how to connect a motor to a PLC. First things first…

Well I do know what a bit is. And a byte. I started with programming programs that talked to PLCs 30 years ago. During the years that been serial comms like with Siemens S5 with the protocol s3964r, and socket based with passing bigEndian byte-arrays to an S7 over socket. Or OPCDA and UA sending single bits and bytes.
I also talked to PLCs via socket and plain text or sockets with JSON (yes really)

What controls the telegrams, if not a human operator?

Well programs of course.

One program to keep track of and select a free location in the rack.
Another to figure out in what order to send commands to the crane.
A third one figure out in what order to send commands to the conveyor.
A forth one to handle the info given at the ID and set some properties on the pallet object.
A fifth one to keep track of the workflow between these processes like

First gather data from ID station (format-program)
Then send pallet to SP (cnv-program)
Then select the location (seletor-program)
Then send pallet to crane-pickup (cnv-program)
Then tell crane to pickup and deposit pallet to racking - the previously chosen location(crane-program)

Tsually there also separate programs to transfer the data to and from PLC,
the tgms that the cnv-program or the crane-programs created.
These programs have only message-transfer logic.

A normal project have 30-40 programs with different tasks.
No manual intervention.
These programs communicate with each other via named pipes

So I’ve seen some really nice things in your videos
But if we look at your master-program
How does it communicate with the PLC?

From my point of view, your master-program is the equivalent to
my communication programs, and your slaves - with operator input -
is my cnv-program and crane-program.
It differs only by what makes up the logic behind the decision.
An operator or an algorithm

/Björn

Hello bflundin;

There’s something that doesn’t add up in your answer. From what you’ve said, you have several programs involved in the process. These programs, as you’ve explained them, are intertwined. One collects data (formatting program), then another sends the pallet (CNC program), another selects the location (selector program), then the CNC program sends the pallet to the crane to pick it up, and finally, the crane program tells it to pick it up. This is the reason you want to change the system, because all those intertwined programs must be difficult to maintain and explain to the operators, who obviously must be there.

It would be very different if each of the steps you mentioned were managed by a different program; it would be a modular system, used to control very complex processes. Processes that are already complex cannot be managed correctly by programs that depend on each other. Instead, these programs must be specialized in each step of the process without interfering with each other. Obviously, there must be a PC that controls all the others, but the programs within the process cannot interfere, which is what is happening to you, as you mentioned.

Consider this scenario: three types of boxes and three types of parts are sorted simultaneously. Each type of part occupies a specific portion of the warehouse, and when that portion of each part is filled, the remaining parts are sent to another warehouse.

Let’s say we want to apply your system to this scenario. The typical setup would be:

One program to control inbound shipments.

One program to control sorting.

One program to control parts sorting.

One program to control crane operation.

One program to manage warehouse inventory.

One program to control outbound shipments.

If these programs don’t interfere with each other, the system is viable. However, if these programs interfere and depend on one another, then I understand your question; it’s clearly demonstrated.

Your question about how the master communicates with the PLC:

It communicates the same way it did 30 years ago, as you mentioned in your first paragraph, by sending bits and memory through sockets. It can also be done with plain text, but in this case, there’s no plain text. Obviously, with better PCs and better PLCs, everything has changed. With plain text, it would look like this:

My master program in your system would be the main PC controlling everything. Each independent slave program you mention would then be a specific part of the system. However, keep in mind that slaves can also be masters of other slaves; that is, the slaves don’t have to be identical. They can be different programs as long as the IP address and port match the master’s, which indicates the system’s capacity.

In short, you want to simplify the system because things don’t work as they should every time you change the company controlling everything. I recommend not mixing process controls across multiple PCs, including multiple points for different processes on the same PC. This won’t…

However, I have enough information to create a new project for students and teachers that meets two criteria:

1- It’s of an intermediate to advanced level.

2- It can be simulated with Factor IO.

I look forward to seeing your progress here once the simulator is installed on your work PC. We’ll keep you updated.

Regards

Well, no. I did not explain the entire architecture here, I was just explaining that it does not have to be operators. And there would only be one program communication with the plc.

In fact - this system may be used in dark stores - warehouses with no personell and actually the light turned off (hence dark). the decision making is done by programs - not operators

What I tried to describe is a workflow where the essential part is an assignment (managed in a database)

It is maintained by a workflow engine that send telegrams to the other processes (via pipes).

the assignment will be created with info from PLC at ID1
PLC → cnv_io → format_process

some admin process decides it should go to storage.

from-location is ID1, to-location is the racking-area

in order to get there. the workflow engine (WE) will send tgm via pipe to cnv-program,
which will find out the next location (going from ID1 to crane) - which is SP

WE → cnv_program → cnv_io → PLC

the tgm cnv_io → PLC contains ID1 and SP, and say assignment id 123

pallet arrives at SP

PLC → cnv_io → cnv_program

cnv_program now updated current location to SP and tell WE it is done

cnv_program → WE

time to select a location in racking, and the transfer location

WE → selector-program (which does the selection and figures out the transfer to use)

select-program → WE (location selection done for asm 123, loc 43, via C2)

WE → cnv_program (please take 123 to C2)

cnv_program → cnv_io → PLC (send 123 from SP to C2)

pallet now moves to C2.

pallet arrives at C2

PLC → cnv_io → cnv_program

cnv_program now updated current location to C2 and tell WE it is done

cnv_program → WE

WE now tells crane to store it

WE → crane-program → crane_io → cranePLC (move 123 from C2 to 43)

crane picks up and deposits.

cranePLC → crane_io → crane-program → WE (done move 123 from C2 to 43)

WE notifies whoever decided the pallet should go in that it is stored. could be a WMS or ERP system

As you see here all communication to/from PLCs is done by 1 program per PLC

  • cnv_io
  • crane_io

all other communication between process to keep the workflow going does not concern the PLCs.

It is local IPC-comm within a system. The bridge to PLC is via these I/O programs.

Think of the I/O program (one per PLC) as you master. and the other ones are making decisions that end up in plc as simple MOVE(assignment, FROM,TO) where the FROM and TO changes when the previous part is done.

So - there is no interference or mixups with the PLC.

Again - this is why the protocol you use is interesting to me.

/BJörn

Hello bflundin;

Now I understand. As I mentioned in the previous post, all the information is in a database. Depending on the message, it searches the database, and when it finds what it’s looking for, it executes the action in the adjacent cell, which could be one or more instructions. This database is very flexible because there are many possible combinations, and it must be located in only one part of the system. To compare it to the chat in my protocol, you can’t query other PCs about the chat; instead, all PCs must read the same file, both for writing and reading. It must always be the same file for the entire system, and your case is the same.

Now, I’ll tell you that there’s another way to do what you’re describing, but it’s more laborious until the routes are controlled. Instead of creating a program that controls everything, it involves creating an algorithm dijkstra that generates the routes from the given points along the entire path. That is, if you want to go from point A to point B, the algorithm dijkstra will calculate the possible routes, even if some are not possible because they are already in use.

Check out this video with Factory IO that controls a SATE (Surface-to-Air Terminal) by finding the shortest unoccupied path from A to B, unless you know of the possibility of programming it with an algorithm dijkstra:

This project was done using that method on a SATE system:

Regards

Yes - we use Dijkstra as well to do the routing.

We added load-carrier type and congestion s well, so not to route a tote on a pallet conveyor,

and load balancing - avoiding congestion. the more totes on between two nodes - the more expensive it becomes to use it.

But that is not really the issue here