How progress, prompts and alarms share one display area

Contents · 中文版

The previous lesson followed program start, pause, resume and stop. Now look at how those states affect the long bar near the top of the main screen. It can show a filename and a line of G-code, change to a process prompt, or flash an alarm. Clicking it can also clear a message or open a related file.

All of these uses belong to the same native control, progressBar_3. Its design teaches a useful technique: prepare several kinds of content for one area, choose what matters most, and give it suitable colors and click actions. This lesson uses the existing UI and scripts. The filenames, line counts, buffer values and messages marked “Example” illustrate the display rules.

1. Locate the display area

Click the screenshot to view the original image.

In env/maininterface/maininterface.ui, the control is a QProgressBar named progressBar_3.

Start by separating four jobs:

A nearly full bar does not necessarily mean machining is nearly complete. It may simply be displaying a message.

2. Read the original control rules

These are the original rules in the control's accessibleDescription. The UI file stores some characters as XML entities such as < and &; the property editor presents them as the corresponding characters below.

-C1,2(#9997!=" "&&#9990==0)
-C3,2(#9997!=" "&&#9990==1)
-C2,4(#9997unit!=""&&#319item3==1)
-C0,3(#945item0==1)
-C0,0((#319.item3==1&&#319.item10==0)||(#319.item3==0&&#319.item7==1))
-C0,1(1)
-T(#9048.permission-#9048.channel<<#9048.permission<<" "<<" ["+#9047/"/"/":"+"] "+#324.item0)
-T(#[#337_item2].item19<<100<<" "<<" ["+#9047/"/"/":"+"] ")
-T(99<<100<<" "<<#9997)
-T(0<<100<<" "<<" ["+#9047/"/"/":"+"] ")
-T(99<<100<<" "<<#9997unit)
-A: (clickedEvent:/env/browseFile3[1])
-A: (dblClickedEvent:/env/browseFile5[1])
-D

There is no need to memorize the whole block. The five -T entries are numbered 0, 1, 2, 3 and 4, from top to bottom. Six -C rules select the content. -D keeps the display updated, and the two mouse actions call existing scripts.

In the original notation, #9997unit and #9997.unit read the same property, as do #319item3 and #319.item[3]. The explanations below use the dotted form where it is easier to read. Original code is reproduced unchanged.

3. How one -T supplies both the fill and the text

All five entries use this four-part form:

-T(current value<<maximum<<" "<<display text)

Here, << separates parts; it is not a numerical comparison.

The third part is not used as display text by this four-part progress-bar handling. Keep the original " " in place. Removing it changes the number of parts, which selects different handling.

For example:

-T(99<<100<<" "<<#9997)

This fills almost the whole bar and displays the text in #9997. The number 99 does not mean “99% machined.” Nor does the bar automatically add “99%” to the text: part 4 already specifies the text to show.

The UI designer's saved value=24 is only an initial control property. Once the page runs, the selected -T updates the value. Changing that 24 does not change how machining progress is calculated.

4. Where the five kinds of content come from

4.1 Content 0: progress based on program lines

-T(#9048.permission-#9048.channel<<#9048.permission<<" "<<" ["+#9047/"/"/":"+"] "+#324.item0)

Break it into these parts:

This design uses two properties of #9048 to hold display information: .permission holds the total line count, and .channel holds the displayed line index. In this rule, these properties do not mean operator permissions or a communication channel. Read them according to how this function uses them.

For example, a total of 100 and a .channel value of 30 give a bar value of 70 with a maximum of 100. The index starts at zero, so index 30 corresponds to line 31.

Click the screenshot to view the original image.

As the displayed line advances, this difference normally becomes smaller. The fill therefore usually shrinks. It depends on line numbers, not on each line's travel distance, feedrate or waiting time. It cannot tell you how many minutes remain.

The machining process updates the filename, line position and G-code text; progressBar_3 does not execute or read the program line by line itself. Single-block operation, subprograms and different machining modes also affect those updates. The bar is not a universal completion percentage for every machining task.

4.2 Content 1: interpolation-buffer occupancy during MDI execution

The main execution use of this content is MDI: an ordinary program shows program-line progress, while MDI shows interpolation-buffer occupancy. Both use the same bar, but the displayed values mean different things.

First compare the two original rules responsible for this choice:

-C0,0((#319.item3==1&&#319.item10==0)||(#319.item3==0&&#319.item7==1))
-C0,1(1)

When MDI starts, #319.item[3]=1 and #319.item[10]=1. Neither “started and not MDI” nor “not started and paused” in the first rule is true. Unless an earlier alarm, process prompt or RTCP handwheel condition takes priority, the second rule therefore selects content 1:

-T(#[#337_item2].item19<<100<<" "<<" ["+#9047/"/"/":"+"] ")

#337.item[2] holds the number of the motion-status parameter table. If it contains 1021, #[#337_item2].item19 reads #1021.item[19]. This “read a number, then read data from that numbered parameter” form avoids fixing the status-table number in the UI.

The current controller-status receive code converts the FIFO count into an integer percentage, count × 100 ÷ 2048, and puts it in this field. Think of the FIFO as a buffer of motion data awaiting further processing.

Click the screenshot to view the original image.

A buffer value of 25 does not mean that an MDI command is 25% complete. The fill follows the amount of buffered data; it need not increase steadily from zero to 100.

MDI also includes NC actions called by the configuration. For example, env/edit_x_end in the coordinate-input lesson selects #404="edit_x.nc", then sets both MDI mode and the started state to 1. That action sets a coordinate; a lack of visible buffer fill does not establish that MDI failed to execute.

The standard interface puts this display under the final constant condition, -C0,1(1), so it is not exclusive to MDI. It is also selected while idle and not paused, provided no earlier condition applies. MDI is its main execution use; the fallback condition is how the UI implements the selection. The filename still comes from #9047, rather than directly from the MDI filename in #404. Running edit_x.nc, for example, does not require this bar to display edit_x.nc.

4.3 Content 2: alarm or diagnostic text

-T(99<<100<<" "<<#9997)

#9997 holds the message. Controller errors, program-interpretation errors and standard IO alarms can all write here. It is a shared system message location, so do not use it as a general calculation-result variable.

4.4 Content 3: filename only in RTCP handwheel mode

-T(0<<100<<" "<<" ["+#9047/"/"/":"+"] ")

When #945.item[0]==1 and no higher-priority message applies, the value is fixed at zero, the maximum is 100, and the filename remains visible.

Click the screenshot to view the original image.

This is a display choice for that mode. It does not indicate an RTCP calculation failure or that machining progress has been reset. This lesson covers the display choice; RTCP handwheel operation belongs to its own feature description.

4.5 Content 4: a prompt during processing

-T(99<<100<<" "<<#9997unit)

This reads #9997.unit, rather than the main value of #9997. The standard configuration uses different locations in one parameter for alarm text and process prompts.

Click the screenshot to view the original image.

Here, unit stores a prompt, rather than a physical unit such as millimeters or degrees. First look at when that prompt is selected; then trace who writes it.

5. Read the six conditions like an ordered set of IF statements

-Cstyle number,content number(condition) selects both appearance and content. For example:

-C2,4(#9997unit!=""&&#319item3==1)

When the condition is true, it selects style 2 and content 4. The 4 is the index of the fifth -T, not the fourth entry.

For this control, read from top to bottom and use the first true condition. A later true condition does not replace the earlier selection.

The three machining-state fields used here are:

#319.item[3]    Started state
#319.item[7]    Paused state
#319.item[10]   MDI mode

The first half of condition 5 requires “started is 1 and MDI is 0.” Its second half requires “started is 0 and paused is 1.” Thus, after an ordinary program pauses, this control can retain the program-line display when no higher-priority information applies. During MDI execution, both started and MDI are 1, so condition 5 is false and condition 6 displays buffer occupancy. A process prompt written during MDI still takes priority through condition 3; an alarm takes priority through conditions 1 and 2.

The last rule, -C0,1(1), provides the fallback and must follow these conditions. Moving it to the top would make its constant true condition select content 1 before anything else.

6. How a machining program sends a message here

Take this existing statement from env/slib-6003.nc:

#9997.unit=#1105.itemtitle[141]

It copies an existing language string into the process-prompt location. The same number is defined in the two language packs as follows:

Follow the message from program to display:

1. The machining macro assigns the text to #9997.unit.
2. The control refreshes and finds a nonempty prompt with #319.item[3]==1.
3. If neither earlier alarm condition applies, it selects style 2 and content 4.
4. When the prompt is finished, clearing #9997.unit to "" allows the later conditions to select the display again.

The macro library also contains paired “set prompt → process → clear prompt” sequences. For example, the spindle-related code in env/slib-m.nc includes:

#9997.unit=#1107.itemtitle[60]
G04P#338.item[3]*1000
#9997.unit=""

These three lines are part of the original spindle sequence, surrounded by mode checks and other actions. They illustrate where a prompt is set and cleared; they are not a complete spindle-control program. A prompt tells you that a program wrote those words. It does not replace an actual position, speed or signal check. Updating the message does not mean that the subsequent device action has completed.

In addition, env/timer clears #9997.unit when the started state is zero. Distinguish two jobs: the control's condition decides whether the text may appear now; the clearing statement decides whether the text remains stored. Even if an old prompt remains in the parameter, display condition 3 is false while the started state is zero.

Text written and cleared very quickly may not remain visible long enough to read. Associate a process prompt with a meaningful start and end, rather than adding arbitrary machining delays just to keep words on screen.

7. Why the alarm flashes, and why one frame appears blank

The first two conditions both select content 2, but choose styles 1 and 3:

-C1,2(#9997!=" "&&#9990==0)
-C3,2(#9997!=" "&&#9990==1)

The software periodically switches the main value of #9990 between zero and one. Under normal timing, it changes about every 0.3 seconds, making the control alternate its colors.

These are the relevant settings in the original style sheet. chunk means the filled portion of the bar:

QProgressBar::chunk[style="1"] { background: #FFFF00; }
QProgressBar::chunk[style="3"] { background: #FFFF00; }
QProgressBar[style="0"] {
    background: #FFFFFF; color: #000000;
    text-align: left; font-weight: bold;
}
QProgressBar[style="1"] {
    background: #FFFF00; color: #FF0000;
    text-align: left; font-weight: bold;
}
QProgressBar[style="2"] {
    background: #FFFFFF; color: #FFFF3B;
    text-align: left; font-weight: bold;
}
QProgressBar[style="3"] {
    background: #FFFFFF; color: #FFFF00;
    text-align: left; font-weight: bold;
}

Click the screenshot to view the original image.

Click the screenshot to view the original image.

Figure 7 does not mean the message has been cleared. The parameter still contains the same text, but its color matches the fill underneath it. The red words reappear when the control returns to style 1.

Style 2 uses yellow prompt text. It does not specify a separate yellow fill in this style sheet, so Figure 5 retains the native interface's default blue fill. Text color, control background and fill color are separate settings.

There is another easily missed rule:

If the main alarm value is cleared to "", it still differs from " ". An alarm condition remains true, potentially producing a flashing bar with no text. Spaces are part of the data in these comparisons.

8. Why a click sometimes opens a file and sometimes only clears text

The original event rule is:

-A: (clickedEvent:/env/browseFile3[1])

It calls the complete env/browseFile3 script below:

IF#9997==" "GOTO1
IF#9997.item[1]==-1GOTO1
system[#418,9997,0]
N1
#9997=" "
#9997.item[0]=" "

Read it in the same order as a macro program:

An error can store location information alongside its text:

#9997            Displayed message
#9997.item[0]    Associated filename
#9997.item[1]    Associated line; -1 skips opening by line number

When a program-interpretation error occurs, the software writes the filename and line number into these locations. The area can therefore tell the operator what went wrong and retain a way for a developer to inspect the file.

The second argument of system[#418,9997,0] is the number 9997, which selects a parameter table. It does not pass the alarm sentence in #9997 directly to the editor. The function selects entries whose itemversion is zero, prefixes each value with its itemdesc, and passes the results as separate arguments. In the standard saved configuration, the line prefix is -n; a filename of bracket.nc and line 12 therefore produce the arguments bracket.nc and -n12. The actual prefix must match the selected external editor.

Starting the external program is asynchronous. After making the request, this script continues and clears the text. It does not wait for the editor to close or the file to be repaired. A disappearing message therefore proves neither that the editor opened successfully nor that the error was fixed.

Click the screenshot to view the original image.

This explains why clicking does not always return to a filename. A qualifying process prompt is selected first; otherwise, selection continues through the later conditions.

Notice that browseFile3 does not reset #9997.item[1] to -1. The standard env/clearwaring script does include that step:

#9997=" "
#9997.item[0]=" "
#9997.item[1]=-1

The two scripts have related purposes but clear different data. They should not be described as identical.

Clearing displayed text is not a reset and does not remove an actual fault. If an IO condition remains abnormal, the standard monitoring script can write the alarm again. The standard env/start script also checks whether #9997 contains the blank-space value. Always address the cause of the message.

9. Which file a double-click actually requests

The original rule and its script are:

-A: (dblClickedEvent:/env/browseFile5[1])

system[#418,#405+"input/in"+[#1031+1]+".nc",0]

This uses another existing entry, env/browseFile5. It combines the environment directory from #405 with the current value of #1031 to form an input-IO script path.

The standard env/param/iofunc.ui also calls this script. When a row is clicked there, #1031=%% tells the script which entry was selected. The main screen's double-click rule does not include that row-selection assignment. Do not describe it as automatically locating the input responsible for the current alarm, or as necessarily opening the machining file in #9047.

There is also a filename detail to watch. The original script appends [#1031+1] directly, without using INT[...] to obtain integer text. With the current interpreter's numerical string-concatenation rules, #1031=2 can produce input/in3.000.nc. By contrast, the standard env/timer uses INT[#1031.channel+1] when forming input-script names, producing the input/in3.nc form. Before using this maintenance entry, compare the actual generated name with the files in the directory. “Entry 3” alone does not establish that the names match.

Mouse timing matters too. This progress bar calls clickedEvent on mouse press. A double-click includes the first press, so an existing error with file-location data can cause browseFile3 to run before browseFile5, producing two external-program requests. Do not assume that single-click and double-click actions exclude one another.

10. Follow a complete change of display

Suppose an ordinary program is running, then a process prompt and an alarm appear:

There is no step that hides a progress control and shows a separate alarm control. The same control remains in place while its selected content and colors change.

11. What to learn from the existing design

When reading or maintaining a similar display area, use this order:

1. List the content first. Number the -T entries from zero and record which parameter each reads, what text it shows, and what its value means.
2. Arrange the priorities. Put information that needs immediate attention first, and leave the constant true fallback last.
3. Separate the fill from the words. Check whether parts 1 and 2 really represent progress, and whether part 4 contains a filename, G-code or a prompt.
4. Find both the write and the clear. Trace the original script or machining macro that sets each parameter, and when it clears it. The UI alone cannot explain how long a message remains stored.
5. Read the click scripts last. Establish whether they open a file, clear text or request an action, and whether single-click and double-click actions can occur in sequence.

These techniques do not require a new interface. Existing parameters, a few conditions, several content entries and two scripts create a useful display area. When customizing it, preserve the original roles of system-state parameters. Do not change started, paused or reset states merely to alter the display.

Use these checks for common symptoms:

12. Return to the files

This lesson covers what appears, why it changes, and what clicks do. Review machining controls for start, pause, resume and reset. The external-program reference (Chinese) explains the system arguments. Next, move to Teach and follow how input parameters become a program.

Previous: Start, pause, resume and stop · Next: The basic Teach workflow · Reading guide