The row limit on an HMI recipe table is set in the project and cannot grow from the screen. Agree the maximum recipe count before the machine ships, size the records against the panel's documented word budget, prefill the spare rows, and mark every record with an occupied flag in PLC storage, because a blank name is data and decides nothing.
A machine that tests water pumps ships with 100 recipe rows on its operator panel, and the customer cannot yet say how many pump types the machine will meet over its life. The question behind that handover is what a recipe table's row limit actually limits. The answer: the row count is a project setting. The panel can fill, edit and load every row the project created, and it cannot create row 101. Capacity grows only through a project edit, a recompile and a download, with matching storage in the PLC. This page explains where the limit comes from, how to size records against it with real arithmetic, and how to mark spare rows so operators can find them.
Where the row limit comes from
An HMI recipe object reads and writes records held in the panel's own recipe database, and both the record count and the database size are fixed in the project. Panels publish ceilings for them: recipe database manuals commonly cap a single database at a few thousand words and state that data beyond the cap fails to compile, and recipe tutorials document row ceilings in the region of 1,000 rows per recipe sheet. Read the two ceilings for your panel from its own manual; the published figures show the magnitude to expect.
Exceeding the word ceiling stops the project compiling, so an oversize table is caught on the engineering PC, before any download. That makes the row count a commissioning decision. Growing it later means editing the project, recompiling, downloading to the panel and enlarging the PLC storage to match, because the record count on the panel and the record space in the PLC have to agree. The screen itself never adds a row. Mapping row N to its storage words is index arithmetic; saving HMI numeric entries to an indexed PLC table shows the pattern field by field.
What the limit counts
The row ceiling and the word ceiling are different units, and the word ceiling usually binds first. Numeric fields use a known number of words: a 16-bit value takes 1 word, a 32-bit value takes 2. Strings are the expensive part, because a declared string field reserves space for every character it can hold, typed or empty. Words per record is the string fields' character counts divided by characters stored per word, plus each numeric field's word width. Multiply by the agreed maximum row count, add one flag element per row for the occupied markers, and compare the total with the database budget. Past the budget, the project will not compile, and the fix is to bring the word total back down before download; the example below shows the move that usually works.
Example: 100 pump recipes against a 2,000-word budget
Scenario: a pump test bench, with a maximum of 100 pump recipes agreed before the machine ships. Each record holds a 16-character pump name, four 16-bit test values (voltage, current, pressure, flow), one 16-bit diaphragm code and a 16-character seal name. Assume ASCII stored at two characters per 16-bit word, a common convention; take the real figure from your own project before you commit to a number.
The arithmetic, word by word:
- Pump name: 16 characters ÷ 2 characters per word = 8 words
- Seal name: 16 ÷ 2 = 8 words
- Four test values plus one code: 5 words
- Record total: 8 + 8 + 5 = 21 words
At 100 recipes the table needs 21 × 100 = 2,100 words against a 2,000-word budget, so the project does not compile. As drawn, the budget holds 2,000 ÷ 21 = 95 records, and 95 × 21 = 1,995 words; pump 96 is the first the bench cannot store.
Shorten both string fields to 12 characters. Each drops to 12 ÷ 2 = 6 words, a record takes 6 + 6 + 5 = 17 words, and the full table needs 17 × 100 = 1,700 words. The remaining 300 words hold 2,000 ÷ 17 = 117 records in total, so the same budget now carries all 100 agreed recipes plus 17 spare rows. Pump 101 becomes row 101, entered from the screen with no download.
The decision: the strings were the binding limit, not the row count. Cut declared character lengths first, then spend the saving on spare rows. These field sizes are the example's assumptions; your project's words-per-field figures and your panel's budget replace them.
What the limit changes on the machine
Inside the configured count, the screen is a full editor: open a record, change values, load it to the PLC. Past the last configured row there is nothing to open, so the add-a-pump workflow ends at row 100 until someone downloads a bigger table. Design the screen to say so. Keep an occupied-row counter in the PLC and have the new-record button compare that counter with the configured maximum before it writes. At the maximum, the message should say the table is full and a project download is required, because that is what happened; a generic invalid-entry error sends the operator hunting for a mistake that is not there.
Test the boundary at commissioning, while the machine is still yours. Fill the final configured row with a complete record, save it, leave the recipe sheet and reopen it, and confirm every field kept its value. Load that recipe to the PLC and compare the values the PLC received against the screen. The final row is where an off-by-one error in the row-to-address mapping shows up, and the same row exercises the release test below.
Spare rows: occupied flags, not blank names
A spare row is useful only if operators can tell it apart from an occupied one. A blank name cannot be that marker. Once spare rows are prefilled so they are editable, every spare shows a blank name, and so does an occupied record whose name was cleared. Treat the name as data, one field among the rest, and put the marker outside the record text.
Give every row an occupied flag in PLC storage, written when a record is saved and cleared when it is released. Panel documentation treats record handling as a set of project actions: recipe management references list load, store, copy and delete as the supported operations on stored recipes, so use your panel's documented action for each. Retiring a pump then reads: run the documented delete action on the record, clear its flag, reinitialize its fields. Adding a pump reads: pick a row whose flag shows free, enter the pump name and test values, save. The flag turns occupied and the counter behind the new-record button rises by one.
The pump name travels to the PLC with the numbers when the recipe loads; passing a recipe name from an HMI to a PLC variable covers that handoff. Record the flag convention in the project notes: the address range, the value that means free, the value that means occupied.
What to settle before the machine ships
Recommendation: agree the maximum recipe count with the customer before the machine ships, then configure that maximum plus at least 20 percent spare rows, provided the word total fits the panel's documented budget. Run the words-per-record arithmetic with the project's real string lengths and numeric widths, add one flag element per row, and if the total exceeds the budget, shorten the declared string lengths first, because they use the most words per field. If the panel publishes only a row ceiling, size to that ceiling and let the compile confirm the words. Hand over with the occupied flags live and the spare rows prefilled, so the first new pump is an operator task and not a service visit.
Four commissioning checks close the job. Save a complete record and reopen it with every field intact. Load it to the PLC and compare received values. Fill and read back the final configured row. Release a record through the documented action and confirm the flag reads free and the row edits again. A save or reopen that fails has causes of its own; fixing the CODESYS Recipe Manager when files will not save covers that path for projects that keep recipes in CODESYS.
Where a separate screen earns its place
The HMI is the editor, not the noticeboard. When the line also needs the active recipe or the shift's counts readable from a distance, put that job on a separate shop-floor display. The shop-floor screens and andon-style boards category is the starting point, and factory data table signage for offline screens explains how a notice display gets table content without a network connection.
Questions
What happens if the recipe database exceeds its word limit?
The project fails to compile on the engineering PC, so the oversize table never reaches the machine. The fix happens in the project: shorten a declared string field, move fields to a second database, or cut the row count, then recompile and download. Keep the words-per-record arithmetic in the project notes so the next capacity change starts from numbers instead of from a compile error.
How much PLC storage does the occupied flag need?
Plan one flag element per row: 117 configured rows need 117 flag positions. Keep them in one contiguous block so the screen can index flag N against row N with a single offset, and count the flag words in the same budget arithmetic as the record words. A large spare allocation moves the end address of the flag block, so set the block size after the row count is final.
What goes on the handover sheet for recipe capacity?
Write down the agreed maximum row count, the configured spare rows, the words per record, the total words against the panel's documented budget, and the flag block's address range with the values that mean free and occupied. Add the date and result of the final-row test. The next capacity change, whether row 101 arrives in a year or in five, starts from that page.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.