SoftControl User Manual

Be clear whether you are acting as an operator or an administrator.

1. If you only need opening, closing, playback, lighting, and navigation, focus especially on Chapters 3 and 8.
2. If you need to add devices, create commands, design pages, configure timers, or import licenses, read the whole manual in order.
3. If you are delivering the project to a customer, prepare both a device address sheet and a handover checklist before you configure anything.

• You know whether you should be entering Runtime pages or the admin area.
• You have a device list ready before you start building pages.

• Entering the editor before collecting IP addresses, serial settings, and command syntax.
• Training front-desk operators to edit configuration instead of only using the Runtime interface.

Create an implementation sheet that can be used directly for command entry.

1. List every device with name, brand, model, physical location, and project purpose.
2. Record the protocol for each device: UDP, TCP, PJLink, Serial, WOL, Modbus TCP, or Modbus RTU.
3. For network devices, record IP address, port, whether a response is expected, and whether delays are required.
4. For serial devices, record COM port, baud rate, data bits, stop bits, and parity.
5. Group devices by zone or workflow, such as Entrance Area, Hall A, Projectors, Lighting, Opening Flow, and Closing Flow.

• You can explain how each device is supposed to be controlled.
• You can already divide the project into pages or workflows instead of keeping everything in one screen.

• Keep the device sheet in a spreadsheet so later edits remain traceable.
• If third-party systems will trigger actions, decide the external interface naming rules early.

Confirm the environment is healthy before doing project work.

1. On Windows, extract the package and verify the required runtime is installed. If a DLL error appears, fix that first.
2. On Android, allow the app to complete its initial setup on the first run.
3. After launch, confirm the home screen appears normally and shows the expected entry points.
4. Let the application generate its default configuration on first run instead of manually replacing files immediately.
5. Open the system info page and confirm device ID, version, and license state are visible.

• The app reaches the home page without crashing or opening to a blank screen.
• The system info page shows a device ID, which means the licensing path is working.

SoftControl stores pages, components, commands, and group data in the configuration directory. Once the default project is created successfully, later work builds on those files.

Complete your first usable project without creating unnecessary cleanup work.

1. Enter the admin area and confirm language and license status first.
2. Go to command management and enter single device commands one by one.
3. Create command groups for multi-step flows such as opening mode and closing mode.
4. Open the Visual Editor and create your page structure and backgrounds.
5. Add buttons and text, then bind each button to navigation, command lists, or grouped logic.
6. Switch back to Runtime mode and test each page.
7. Only after the main control flow is stable should you add timers and third-party integration.
8. Export and archive a backup at the end.

• You have a complete implementation order from low-level commands to high-level UI.
• You are no longer trying to finish the visual interface before the device logic is proven.

Learn the full cycle on a small, realistic example.

1. Create a home page with Enter System, Opening Mode, Closing Mode, and Admin buttons.
2. Create a device control page for projectors, PCs, and players.
3. Create a lighting page with All On, All Off, and one or two single-circuit buttons.
4. Add a clear return path so the user can always get back to the menu or home page.
5. Make sure each page works functionally before refining its appearance.

• For your first project, prioritize reliability over visual complexity.
• If one button controls multiple devices, use grouped logic rather than duplicating commands across multiple buttons.

• Trying to build a large multi-zone system before learning the minimum closed loop.
• Designing backgrounds and decoration before the command chain is tested.

Complete a safe and repeatable opening routine.

1. Open the home page and confirm there is no license-expired message or major error prompt.
2. Use the one-touch opening button if it exists. If not, perform the sequence manually page by page.
3. For a manual flow, the recommended order is PCs, projectors, players, lighting, then other environmental devices.
4. After each button press, wait for the physical device to respond before pressing again.
5. Once opening is complete, verify the main display, audio, and lighting states in the actual space.

• Projectors are on and showing the expected source.
• Content playback and lighting are both in their opening state.

• Sending source or playback commands before the projector is ready.
• Repeatedly pressing the same button because the result is not instant.

Close the space without leaving devices in a bad or half-active state.

1. Stop playback or switch back to the standby content state first.
2. Turn off lighting or move to the closing scene.
3. Power down projectors and let them enter their own shutdown process.
4. Shut down PCs and any remaining devices last.
5. Even if you use a one-touch closing button, still confirm the key devices actually turned off.

• Playback has stopped or returned to the standby state.
• Projectors, lighting, and PCs are in their intended closing state.

• If PCs need a normal shutdown window, keep them at the end of the sequence and add delay when needed.
• Always do one final walk-through after closing.

Use the Runtime interface confidently and verify outcomes correctly.

1. Navigation buttons normally lead into a zone, return to a menu, or go back home. Learn the main page path early.
2. Playback pages often include play, pause, stop, mute, volume up, volume down, and content selection buttons.
3. Lighting pages usually separate batch controls like All On and All Off from single-circuit controls.
4. After every action, look at the physical result instead of the button state alone.
5. If nothing changes immediately, allow one to three seconds before retrying.

• You can find the correct page without guessing.
• You know which device behavior confirms success for each action type.

Frontline operators should not be entering the admin area or changing page and command logic during normal operation.

Reach the admin home page and identify the major modules.

1. Open the home page and select the admin entry.
2. Enter the admin password. The default is often 123 and should be changed in production projects.
3. Once inside, identify the main modules: Visual Editor, Command Management, Command Groups, Timers, Config Management, Licensing, Logs, and Network Diagnostics.

• You can reach the admin home page successfully.
• You know which module to open for pages, commands, logs, timers, and licensing.

• Editing a live project while operators are actively using the Runtime interface.
• Keeping the default password after handover.

Finish the initial safety and environment setup for the admin area.

1. Open system info or licensing to confirm whether you are running a trial or a production license.
2. If this is a delivery environment, import the production license before deeper setup.
3. Adjust the interface language for the team who will maintain the system.
4. Change the admin password immediately and document it in the project handover materials.

• License state, device ID, and version are confirmed.
• The admin password is no longer the default.

• If multiple maintainers will support the project, agree on password ownership early.
• Even in a trial environment, learn the license limitations first so you do not mistake them for bugs.

Know when a restriction is a license issue and when it is a real configuration fault.

1. Open licensing and copy the device ID when a production license must be requested.
2. Import the provided license file using the license import function.
3. After import, confirm the license state has updated and restricted features are now available.
4. If the license is expired, solve that first before investigating UI behavior or timers.

• You know whether the project can use timers, config export, and the full editing workflow.
• You can distinguish license restrictions from broken logic.

When a license expires, Runtime access and timer execution may both be affected. Licensing should be the first stop in that situation.

Create one command that can be tested independently and succeeds reliably.

1. Open command management and add a new command.
2. Name it clearly using a device-plus-action pattern such as Projector_1_Power_On.
3. Choose the correct protocol: UDP, TCP, PJLink, Serial, WOL, Modbus TCP, or Modbus RTU.
4. Enter the target address. Use the device IP for network protocols and the COM port for serial protocols.
5. Enter the port or baud rate exactly as provided in the device documentation.
6. Enter the command text in the required format for the device.
7. Adjust delay, timeout, retry count, response waiting, response timeout, and response encoding if needed.
8. Save and test the single command before attaching it to any page button.

• The device performs the expected action when the command is tested directly.
• A matching record appears in the system log.

• Using vague command names such as Button 1 or Power Button.
• Attaching an unverified command to a UI button before proving that the command works on its own.

Use a repeatable troubleshooting order instead of guessing.

1. Confirm the device is online, powered, and ready to accept commands.
2. Verify the protocol type is correct.
3. Verify IP address, port, COM port, and baud rate against your implementation sheet.
4. Check command text formatting, including case, spacing, terminators, or hex format if required.
5. If the device starts slowly, add delay before follow-up actions.
6. Open the log page to confirm the system actually sent the command.
7. Use network diagnostics to verify reachability for network-controlled devices.

• You can narrow the fault down to connection, parameter, or page-binding scope.
• You are using logs and diagnostics, not trial-and-error alone.

• For TCP devices that return feedback, enabling response waiting can make commissioning easier.
• Do not create complex groups until every underlying single command is stable.

Use the right tool for the right task.

1. Use a command group when one button must run a series of device actions.
2. Build opening mode, closing mode, meeting mode, and demo mode as grouped flows.
3. Use Modbus point management when the project includes PLCs, sensors, or status polling.
4. Assign external interface IDs to components when SoftPlayer or other systems need to trigger their actions remotely.

• You know when to create a single command and when to create a grouped workflow.
• You are no longer mixing status polling, UI logic, and third-party integration into one layer.

The default external interface ports are UDP 8818 and TCP 8819. Interface IDs must stay unique and alphanumeric.

Create a page structure that matches the real workflow of the space.

1. Open the Visual Editor and inspect the existing pages in the left-side page list.
2. Create core pages first: home, menu, and one page per major function or zone.
3. Name each page by its actual function, such as Home, Device Control, Lighting Control, or Projection Control.
4. Select a page and choose the appropriate background image if one is needed.
5. If no background is ready yet, continue with a functional layout first and add artwork later.

• You can explain what each page is for without opening it.
• The project structure makes sense before detailed component design begins.

• Using page names like Page 1 and Control Page 2.
• Designing a lot of components before deciding how pages relate to each other.

Place a clear and maintainable layout on each page.

1. Add components to the selected page from the canvas workflow.
2. Use text components for titles, guidance, and fixed labels.
3. Use button components for all actionable items and keep similar actions styled similarly.
4. Position components with drag-and-drop, then fine-tune with arrow keys.
5. Use Ctrl+C and Ctrl+V when repeating a style pattern.

• Users can instantly distinguish between information and controls.
• Buttons of the same category look consistent in size and visual weight.

• Keep the home page simple, large, and obvious.
• Place return buttons in a consistent position on every page.

Make every button predictable, testable, and easy to maintain.

1. Select a button and open its action configuration in the property panel.
2. If it should move to another page, choose page navigation and set the correct target page.
3. If it should show guidance or a note, choose show text and enter the content.
4. If it should control devices directly, choose command execution and attach the correct command list.
5. If it should run a workflow such as opening mode, prefer the grouped logic you already tested.
6. After binding each button, test it immediately in preview or Runtime mode.

• You can explain exactly what each button does before clicking it.
• Button names and action bindings agree with each other.

• A button labeled Opening Mode actually navigates to the wrong page.
• Several buttons share similar names, making troubleshooting difficult later.

Build a habit of making one change set at a time and confirming it.

1. Preview a page as soon as its main buttons are ready.
2. Save after the preview passes rather than accumulating unverified edits.
3. Return to Runtime mode and run through the key user path after every major page update.
4. Only move on to the next page after the current one is stable.

• Edited pages behave correctly in the real Runtime flow.
• You are validating a section before starting the next section.

The editor supports undo, delete, copy, and preview. If a layout becomes messy, step back to a known-good state instead of forcing more edits on top of it.

Automate recurring actions without creating hidden failure points.

1. Open timer management and review existing tasks before creating a new one.
2. Name the task clearly, for example Daily Opening 08:30 or Daily Closing 18:00.
3. Set the trigger time and recurrence.
4. Reuse an already tested button or command group instead of creating a brand-new unproven flow inside the timer.
5. Use manual trigger to test the task once before enabling it permanently.
6. After enabling it, review the execution history to confirm the scheduler is actually running it.

• The task succeeds when manually triggered.
• Execution history confirms the task is active and running.

• Using new untested commands directly inside scheduled tasks.
• Skipping the license check and assuming timer failure is a system bug.

Make the project restorable, portable, and safe to hand over.

1. Export a configuration backup whenever the project reaches a meaningful milestone.
2. At minimum, preserve page, component, command, command group, component group, and Modbus point data.
3. Import the backup into a spare or test environment once to prove it can actually be restored.
4. When moving to a new device, import first and then verify network addresses, serial settings, and license matching.
5. Keep both a final accepted version and a rollback version.

• You have a verified backup, not just a live device with an undocumented setup.
• The backup has already been tested on another environment.

• Always export before large edits so you can roll back quickly.
• After migration, verify IP addresses, COM ports, and licensing before anything else.

Deliver a project that another person can operate and maintain.

1. Keep the log page visible during commissioning so you can watch key actions succeed or fail.
2. Use network diagnostics alongside logs when working with network-controlled devices.
3. Create a handover checklist for opening, closing, emergency stop, and reset behavior.
4. Deliver the admin password, license state, device address sheet, backup location, and daily-use notes together.
5. During training, let the customer perform a full opening and closing flow by themselves.

• You have delivered maintenance information, not only a visual interface.
• The customer knows where licensing, logs, and diagnostics are located.

A mature project is one that someone new can maintain later with the documentation and backups you leave behind.

Decide whether the fault is in the button, the command, the network, or the device.

1. Open the log page and confirm whether the button press generated an execution record.
2. If no log exists, the problem is likely in page binding or action configuration.
3. If a log exists but shows failure, inspect protocol, address, port, command text, and device state.
4. If the device is network controlled, use network diagnostics to check reachability.
5. If the device is serial controlled, confirm the COM port is correct and not occupied by something else.

• You have narrowed the issue down to UI binding, command parameters, or device connectivity.
• You are not rebuilding pages just to see if that helps.

Restore page clarity and logical consistency quickly.

1. Return to the Visual Editor and inspect the button name first.
2. Check whether the action type is navigation, command execution, or grouped control.
3. If navigation is wrong, correct the target page binding directly.
4. If multiple buttons are ambiguously named, rename them before more testing.
5. Preview immediately after each correction instead of batching many edits together.

• Clear button and page names prevent most operator confusion and much of later maintenance overhead.
• Keep the home page, menu page, and return path consistent across the project.

Go to the right diagnostic entry point for system-level issues.

1. If the system shows an expired or restricted state, open licensing before changing any project logic.
2. If timers are not running, verify license capability first, then task enable state, then execution history.
3. If a migrated project behaves differently on a new device, confirm the backup import, then verify network settings, serial settings, and licensing for the new machine.
4. If the project appears to reset to defaults on startup, verify the configuration path and the actual file location before editing pages.

• You know exactly where to inspect licensing issues, timer issues, and migration issues.
• You are no longer treating every system-level issue as a vague reliability problem.