A C-more Micro communicates with a PIC by having the HMI project issue Modbus requests; the PIC firmware must respond as the Modbus device. Set the communication parameters to match, confirm the HMI’s client/master role, and prove one register read before building out the screen.
Set the HMI and PIC roles before changing the serial link
The C-more Micro is the Modbus master, also called the client. It initiates each transaction. The PIC must act as the responding slave/server: receive a request, process the requested register or bit operation, and return a valid response. Two masters cannot exchange requests as peers, and a PIC that only prints or accepts custom text commands will not answer Modbus requests.
Keep the task split in two: configure the HMI project to request data, and write or configure the PIC firmware to implement the matching Modbus device behavior. The HMI project software manages its protocol transactions; the screen object identifies what data to read or write. The PIC firmware still needs to parse requests and provide the requested data.
- Confirm that the PIC firmware is intended to respond as a Modbus device rather than as a raw command-line interface.
- Choose one test value the PIC can expose, and identify the Modbus data item the firmware will use for it.
- Keep a record of the PIC serial settings and the register or bit address assigned to that value.
Check: You can state which side initiates a request, which side responds, and which PIC data item the first HMI object will read.
Match the serial settings at both ends
For a serial Modbus connection, the two endpoints need compatible communication settings. The project configuration instructions for this C-more Micro setup identify the Panel settings tab as the place to configure the panel port. Set the panel-side values to the settings configured in the PIC, not to values copied from an unrelated serial project.
Record and compare the settings shown by both endpoints, including the serial mode and the communication parameters the device exposes. Do not guess an unprovided baud rate, parity, stop-bit count, or physical interface. Read those values from the PIC firmware configuration and the C-more project or its help file. Also confirm that the cable and electrical interface match the selected ports; correct software settings cannot compensate for incompatible wiring or an unsuitable interface.
HyperTerminal can help when testing a PIC that accepts a documented text command, but that test does not prove Modbus communication. A terminal session does not automatically generate the Modbus requests an HMI client sends. Use a Modbus-capable test client if you need to isolate the PIC from the HMI, and configure that test client as a client/master with the same settings and address conventions.
Check: Compare the panel and PIC configuration side by side. Confirm that each listed setting agrees and that the selected panel port is physically connected to the intended PIC interface.
Build one read object around a known PIC value
Start with a numeric display, as in the basic C-more Micro test workflow. Assign it the Modbus register address for the known PIC value. A display makes a useful first test because it exercises the request path and shows whether the returned data has the expected value.
- In the C-more Micro project, add a numeric display to a test screen.
- Configure its device or communication target for the PIC connection, if the project requires that selection.
- Enter the register address that corresponds to the test value in the PIC map.
- Set the display’s data format and range to match how the PIC represents that value.
- Download or run the project using the normal workflow for the panel, then observe the display.
Address notation is a common source of mismatch. A register map, HMI driver, and PIC firmware may present addresses using different conventions, such as a reference number versus an offset. Use the C-more help and the PIC’s map to determine how the configured number maps to the actual Modbus data item. Do not adjust addresses randomly; change one mapping at a time and record the result.
Check: The HMI display matches the PIC’s known test value. If it does not, leave other screen objects out of the test and troubleshoot the single read first.
Make the PIC return the expected Modbus data
The PIC firmware must implement the same data model and address that the HMI object requests. Modbus defines different data areas for bits and registers; the HMI object type and PIC map must refer to compatible data. A numeric display expects a register-style value, not an unrelated coil or a text string generated by a custom serial protocol.
Confirm in the firmware that it recognizes the request, uses the intended address, returns the current value, and forms a valid response. Check the device address and the selected Modbus serial mode against the HMI configuration. If the PIC code uses a library, verify the library’s address indexing and data representation rather than assuming its internal index equals the address shown in the HMI editor.
Start with a fixed test value or a controlled value that can be observed independently in firmware. Once a read succeeds, test writes separately. For writable data, confirm that the HMI object sends the intended write operation and that the PIC accepts it, updates the intended variable, and reports the resulting value on a subsequent read. Do not use a live machine output as the first write test.
Check: For a read, compare the PIC’s internal test value, its returned data, and the displayed number. For a write, compare the entered value, the firmware variable, and a read-back result.
Diagnose a blank or incorrect display by symptom
Use the symptom to choose a measurement. A blank display does not identify whether the fault is in the port, protocol role, address, or data formatting.
| Symptom | Likely cause to test | Next check |
|---|---|---|
| No value or a communication indication | Settings mismatch, wrong port or wiring, or PIC not responding as a Modbus device | Compare endpoint settings and port selection; confirm the PIC receives and answers a request. |
| Communication succeeds but the value is wrong | Wrong register mapping, address convention, or data interpretation | Compare the HMI address with the PIC map and inspect the returned value. |
| Text terminal test works but HMI communication fails | The PIC may be responding to a custom text command rather than Modbus | Test the PIC with a Modbus client and inspect its Modbus request handling. |
| Read works but write does not | Wrong object/data type, non-writable data item, or PIC firmware not implementing the write | Verify the mapped item and write behavior in firmware, then read the value back. |
Change one variable per test. First establish that the PIC receives a request, then confirm that it recognizes the request and address, then verify its response, and finally compare the returned value with the HMI display. If the panel reports a diagnostic or communication status, record its exact text and consult the project help for its meaning rather than inferring a fault from the screen alone.
Check: The next test is tied to one observed failure point, and the result distinguishes that point from the stages already proven.
Prove the complete read and write path before expanding the screen
After the single-register test passes, add additional objects gradually. Give each object a documented PIC data item and verify it before adding another. This keeps an address or representation error localized instead of making several failing objects look like one communication fault.
- Read the known PIC test value and confirm the displayed value.
- Change the PIC test value independently and confirm that the display updates as expected.
- If the application requires HMI writes, use a controlled writable test item and confirm the PIC accepts the value.
- Read the written item back and compare the HMI entry, PIC variable, and displayed result.
- Repeat the test after the final project download and record the working port settings and data map.
Keep separate records for the HMI project configuration and PIC firmware map. When a later change breaks communication, these records let the next shift compare the working settings, object addresses, and firmware behavior without rebuilding the test from memory.
Check: A read and, where required, a controlled write/read-back succeed with the final project and PIC firmware—not only with an isolated bench test.
Know when to stop and escalate the C-more Micro fault
Stop changing addresses or serial settings when repeated tests cannot establish whether the panel transmits, the PIC receives, or the PIC responds. Capture the project settings, PIC port and Modbus configuration, address map, exact panel diagnostic, and the result of a Modbus-client test before contacting the product manufacturer’s official support channel.
Frequently asked questions
How do I connect a C-more Micro to a PIC microcontroller?
Configure the C-more Micro project as the Modbus master/client and configure the PIC to respond as the Modbus slave/server. Match the serial settings, then test one numeric display using a known PIC register.
How do I set the C-more Micro serial communication settings?
Use the Panel settings tab in the project software for the panel port, and copy the settings configured in the PIC. Read the actual mode and serial values at both ends rather than choosing values by guesswork.
How do I test a PIC Modbus connection without the HMI?
Use a Modbus-capable client configured to initiate requests with the PIC’s settings and address mapping. A text terminal can test a custom command interface, but it does not by itself validate Modbus requests or responses.
Why does the HMI show the wrong PIC register value?
Check that the display points to the same data item the PIC firmware maps, then verify address indexing and data representation in the driver help and firmware map. Compare the returned data with a known PIC value before changing other objects.
When should I stop troubleshooting C-more Micro Modbus?
Stop when you cannot determine whether the panel transmitted, the PIC received, or the PIC responded, or when a controlled single-register test still fails after checking settings and mapping. Send the manufacturer’s official support channel your project configuration, PIC map, diagnostic text, and Modbus-client test results.