Allocate a Carrier Slot
medium
Stores a part in the first empty carrier slot and reports whether it was accepted.
What it teaches
A storage rack may have holes, so appending to its end is not enough. Search for the first empty position, then claim only that position. A fresh request must search the current rack rather than reuse the previous match.
Parameters
| Tag | Direction | Type | Default | Description |
|---|---|---|---|---|
| In_Store | Input | BOOL | 0 | Request to store a part |
| In_PartId | Input | DINT | 101 | Positive ID to store |
| Sts_Accepted | Output | BOOL | 0 | One-scan successful store indication |
| Out_Index | Output | DINT | 0 | Last requested slot, or -1 on rejection |
| Ref_Slots | InOut | DINT[8] | — | Caller-owned rack: 0 means empty; positive values identify parts |
Required behavior
- A request acts once on a change from 0 to 1. Holding it high does not repeat the action.
- On a rising In_Store with In_PartId > 0, place the ID into the lowest-index slot containing 0. Set Out_Index to that index and Sts_Accepted to 1 for one scan.
- A full rack or nonpositive part ID rejects the request: Out_Index = -1 and Sts_Accepted = 0, with the rack unchanged. Duplicate positive IDs are allowed.
- Out_Index is -1 before the first request and holds the latest result between requests. Sts_Accepted is 0 without a new successful request.
- The caller may free or fill slots between requests. Preserve every slot except the one allocated.