Launch an Excel file from an HMI Run object with a joined path

Can an HMI open Excel on a file the operator picks?

Yes, a Run object in the HMI software starts Excel. An expression joins the Excel executable path to the operator's workbook path so the workbook opens as a separate command-line argument. One space character after the executable path is what separates the two.

The Run object starts a Windows program, and its Command Line accepts an expression, so the line can carry a value the operator typed. Two objects do the whole job: a text-entry object that holds the workbook path or file name, and a Run object that fires the joined line.

Expect the machine screens to take the display back when Excel closes, and test that hand-back on the target computer before operators rely on it. The hand-back belongs to the installation, and no expression sets it. The command line chooses the file, not the window size: if the workbook has to fill the screen, size the window once on the machine computer with Excel's own controls, close Excel normally, and retest the launch.

What do you need on the machine computer first?

Before you build anything, confirm four things on the machine computer: Excel installed with its full executable path, an operator account that can read and write the data folder, a text-entry object for the file name, and a Run object to fire the command line.

1. Excel, with its path. The documented example path is C:\Program Files\Microsoft Office\Office\EXCEL.EXE, an older installation layout. Yours may differ, so confirm the path on that computer before you type it into any expression.
2. Folders and rights. A template workbook in a controlled folder, plus a production data folder. Test read and write from the operator account itself, because that is the account the launch runs under.
3. A text-entry object bound to a text value. The documented example names it TextEntry1; any name works, but the value must be plain text with no quote marks in it.
4. A Run object. You create both objects from the Object»Create command in the menu bar, as the Using LookoutDirect manual chapter documents.

How do you join the Excel path and the workbook path in one expression?

The join is one expression: the executable string first with its trailing space kept inside the quotes, then the ampersand, then the text-entry value. The Run object receives the workbook path as a second argument and Excel opens that workbook instead of a blank sheet.

Exp1 = "C:\Program Files\Microsoft Office\Office\EXCEL.EXE " & TextEntry1

TextEntry1 holds the complete workbook path, for example C:\YourData\Data1.xls. The space sits inside the quotes, after .EXE, and it is the argument separator, not decoration. Leave it out and the two paths merge into a single path that names no program Windows can start. No quote marks go into the text entry, because everything typed there joins the command line exactly as typed.

To keep the later examples short, call that whole first string, trailing space included, ExecPath. Every expression below starts with it.

Build it in this order:

1. Create the text-entry object and the Run object with Object»Create.
2. Confirm the installed Excel executable path on the machine computer.
3. Build Exp1 starting with the executable string, trailing space kept inside the quotes.
4. Add the ampersand and the text-entry name, so the operator's path becomes the second argument.
5. Assign Exp1 as the Run object's Command Line.
6. Fire the object once with a test path before the floor sees it.

If operators tend to type a bare name, fix the folder and the extension in the expression instead, and ExecPath still leads:

Exp1 = ExecPath & "C:\YourData\" & TextEntry1 & ".xls"

Now the entry holds only the name. That cuts directory typos and also locks the choice to one folder and one extension. Pick one convention, label the field on screen to match it, and do not run some operators on full paths while others type bare names.

How do you give the operator a NEW or EXISTING choice?

Build the choice as two expressions, not one clever command line: a fixed expression pointing at the approved template for NEW, and a joined expression building the path from the operator's file name for EXISTING, with the resolved path shown on screen before launch.

NEW points at the template with fixed text after ExecPath:

Exp1 = ExecPath & "C:\YourData\Template.xls"

Template.xls stands in for your approved template. Keep the real one in a controlled folder and never save production data over it. EXISTING keeps the joined expression from the last section, driven by the entry.

One choice field selects which line the Run object fires. Put the resolved path on the screen as text before launch, so the operator catches a wrong selection while it is still cheap. The NEW pass ends with Save As under a production name; test that Save As lands in the production folder and leaves the template unchanged.

Worked example: what command line does Excel receive?

In this example the operator types Data1 into the text-entry field, the expression joins a 51-character executable string to a 21-character workbook path, and Excel receives one 72-character command line that opens C:\YourData\Data1.xls directly.

The executable string is 50 characters:

C:\Program Files\Microsoft Office\Office\EXCEL.EXE

Keep the separator space inside the quotes and the string carries 51 characters into the join. The operator's entry, C:\YourData\Data1.xls, is 21 characters. The joined command line is therefore 51 + 21 = 72 characters, carrying two arguments: the program path and the workbook path. Excel opens C:\YourData\Data1.xls and nothing else.

Drop the space and the same join produces 50 + 21 = 71 characters with no boundary in it: ...EXCEL.EXEC:\YourData\Data1.xls. That single string starts like a program and ends like a workbook, and the launch fails before Excel is even found.

The filename-only variant lands on the same 21-character argument by a different road: the fixed folder C:\YourData\ is 12 characters, the typed name Data1 is 5, the fixed extension .xls is 4, and 12 + 5 + 4 = 21.

Counting characters is also the fastest diagnosis on the floor: display Exp1 as text on the screen, read the boundary between the two paths, and a missing space shows up immediately. When a joined line opens nothing or the wrong file, Excel's own Workbooks.Open reference is where the workbook-opening requirements are written down.

How does the PLC get checked values before the cycle runs?

Opening the workbook transfers nothing: the PLC should hold the machine until it sees a complete, range-checked data set plus one acceptance indication. Keep the machine in hold while the operator edits, and let the sequence step forward only after the handshake completes.

Opening, editing and saving are file operations, and the PLC sees none of them until your defined transfer path reads the values and writes them. Put the checks on the PLC side: required fields present, values inside their ranges, units right, and one completion indication that only sets when every check passes. That is the safety rule of this setup: the workbook is an editor, the acceptance indication is the permission.

The discipline is the same one that keeps panel writes safe anywhere on the floor: prove the writes to the PLC before motion depends on them, as testing writes before motion on a panel-to-PLC link lays out. If the project's tag list is still being wired, importing a PLC tag file into an HMI project and verifying it covers the verification half. And when the data is really recipe quantities, ask whether Excel needs to be in the path at all: saving operator recipe values from an HMI with no save button keeps the values inside the HMI instead.

A workbook that opened and saved is not proof the PLC holds the new values. Check the acceptance indication, then run one test cycle on the controlled data set.

How do you test launch, save and screen return end to end?

Prove the setup with one controlled pass through five checks: existing file, template and Save As, controlled test data, close, and return of the machine screens with PLC acceptance set, before you enable the cycle.

1. Confirm the executable path, the template folder and the production folder. From the operator account, open and save a throwaway workbook in the production folder, then delete it.
2. Run the EXISTING pass: type the known test file into the entry, fire the Run object, and confirm Excel opens that workbook and no other.
3. Run the NEW pass: confirm the template opens, Save As writes a separate production file, and the template still holds its original content.
4. Enter a controlled test data set, save the workbook, and close Excel normally.
5. Confirm the machine screens return, the PLC shows the test values, the acceptance indication sets, and one test cycle runs on that data.

If step 5 stalls with the screens gone, close every Excel window and retest the close; a workbook left open holds the display. Run this sequence on the actual machine computer, because the hand-back and the folder rights belong to that installation.

What breaks this setup in the field?

Six field failures cover nearly every call on this setup: a missing separator space, quote marks in the entry, a wrong executable path, a name the folder does not hold, production data saved over the template, and a workbook that holds the display after close.

Recommendation: build the launch as two expressions, one fixed on the template for NEW and one joined from a filename-only text entry for EXISTING, show the resolved path on screen before launch, and hold the machine until the PLC sets its acceptance indication. If the values the operator edits are recipe quantities, leave Excel out of the path and keep them in the HMI's recipe storage.

More setups and fixes for screens on the shop floor sit in the shop-floor screens category.

Questions