So thinking back to what the physical system, or the conveyor looked like. Now, my sc main on top I have to have that, and then I have those are my choice, top instant. This is what instantiated all of the three components in there. There's the bag of scanner instants, there's a conveyor segment instance. And, as I said, hopefully, in the future, I have a whole bunch of instances in there. And then there's the control system that makes the decision about to turn the conveyor on or off and send messages to the baggage scanner to tell them to start or stop. That it's okay to start scanning baggage or to stop scanning baggage. And then someone can try an example, but it works. And actually I have messages going and baggages being put into the system. I just don't have the baggage being tracked yet. So these modules, these instances communicate through what are called a primitive channel, called sc_fifos. So when the control system wants to send a control packet to the baggage scanner, to say, it's okay, turn the LED on or off, or LED red on, and green off, or vice versa. It's under control packet through this 5.0, of SE 5.0 type, and these modules have parts on it that the 5.0's connect to very, again it's very, very similar to hardware description languages, as is a lot of one to one correspondence. So there's this notion of ports and 250's one for command and response coming back for, I call them status coming back. So this is how the baggage scanner interacts with the main control system. And the conveyor's segment is exactly the same. Commands going one direction, and status comes back. So what I envision happening here is that the conveyor system will be every time a bag gets scanned, it will send a status message or it says, hey bag, with this bag ID read off the bag code, was just put onto the system so we know it's at the very beginning of the conveyor system. And as time runs, the conveyor will be reporting movement, and then I can go through my database of all the bags that aren't on the conveyor and update their position, advance their position by however many clicks the encoder has reported have gone by per unit time and figure out precisely where that bag is. That's the idea. So I have messages right now that can start and stop the conveyor system and tell the baggage scanner to go and yeah. The status messages come back containing position information, vibration, and temperature. Those are the three fields in the status message on the conveyor. So this is the model hierarchy that I used, to map that back to thinking about the physical system. And then the processes for each of the modules are these infinite loops that just run all the time. That's exactly how we created our processes in the behavioral model of the drives at C gate when we were there. All these little processes ran in a loop, looking for something to do. So in this process, for the baggage, it weights randomly between zero to two seconds I was thinking. Well, how long would it take a human being to lift a bag, scan it, and put it on the conveyor? I think, I don't know, anywhere between zero to two seconds seems about, you could argue maybe it should be up to five seconds. It's something in this order. That's about how quickly human being can scan a bag and put it on the conveyor. So it weights,cause the weight routine, this variable amount of delay. And then it looks first in its received FIFO to see if there were any in received control packets like turn off, for instance, stop scanning bags for a moment. If yes, then it updates its variables and takes the appropriate action, comes over here. And if we're running then it sends the status packet, AI just scanned that bag, put it on the conveyor system. We could argue these two should be reversed. For the conveyor instant, exactly the same notional structures here but the conveyors now sending status messages every one millisecond. I chose that as what I thought to be a reasonable rate a conveyor system should be communicating. Shouldn't be communicating every five seconds, because way too much happens in five seconds. But not very much happens, not very much movement takes place in one millisecond. So this one delays a millisecond. Again, it looks for a control packet to say whether to turn the motor on or off or not. If it's a control packet, it does its thing, updates its variables, takes whatever action is necessary. And if it's running, it sends status packets to update the position back to the main control system. And then it returns to the top and waits a millisecond again. And just does that over and over again, so in human land, we're going zero to two seconds. Conveyor system is sending status messages every one millisecond. And the control system is running much faster. It has some initialization that sends a control packet to turn on the baggage scanner and it sends a control message to turn on the conveyor. So the system is up and running and going. And then I chose to wait and 1,000 times faster here, so I'm going to delay 1 micro siding, because I don't want to miss anything from a real time perspective. So we've got our zero to two seconds of human activity taking place, conveyor moves a relatively modest amount in one millisecond, but I wanted the control system to be running at a much higher sampling and a much higher frequency so it doesn't miss anything. It can respond very quickly if it needs to. But the structure of these is exactly the same. It delays, it checks to see it got any received status messages from either of these two, if not, it just goes back. If yes, was it a baggage packet? Yeah, it was. Stores the baggage packet in the database and comes back over here. Was it a conveyor packet? Yeah, update all the baggage status. So this is traversing my data structure and moving all of the baggage positions, values and the data structures for each bag ahead by however much was in that status packet from the conveyor system. And should have been a line right there coming back over here so. This also checks for eventually will be in the code. To check conditions for over temperature and over vibration exceeding the threshold, it would send the shut down message to the baggage scanner and say don't scan anymore bags, we've had a malfunction. Shut the conveyor motor down and a service technician could go out and fix the encoder, fix the motor. Whatever needed to be repaired. So it's cool, it's free, and you can use it to model all kinds of stuff. I just wanted you to be aware of that. It's another tool you can have in your toolbox for problem solving when you get out in the working world.
