I am facing challenges with establishing communication between a VersaMax Micro PLC and a custom Operator Interface through Port 1, which has an RJ45 Connector. Despite setting the default communication parameters to 19200BPS, Odd Parity, 1 Stop Bit, and 8 Data Bits, I am unable to make my Microcontroller Based HMI/OI interact with the PLC using SNP and SNPX Protocols. To initiate communication, I follow specific steps. Firstly, I send a Long Break signal by holding the TxD Line in the SPACE state for 50ms (equivalent to three character times at 19200BPS). Then, I wait for T4 duration (100ms) before transmitting the Attach Message (for SNP) and X-Attach Message (for SNPX) with the PLC CPU ID set to NULL for Point-to-Point Communication. Subsequently, I wait for T1 time (10ms) and check for an Attach Response (or X-Attach Response). Regrettably, I have not received any response from the PLC. As per the SNP Communications User's Manual, no response is expected in case of an error in the Attach Message. For other messages, an error message or NAK is usually received, allowing identification of the issue. I have included the SNP and SNPX message streams sent for the Attach and X-Attach Messages for reference. I seek assistance in troubleshooting this matter promptly. Your guidance in pinpointing my errors would be greatly appreciated. Thank you for your prompt assistance. Best regards, P.Mani.
I cross-checked the checksum for the X-Attach message and it matched yours. Have you verified the cable connections from your HMI to the RJ-11 connector? It's common to misalign the pin numbers. Is it possible that your microcontroller is flipping the high and low bytes, causing 1B to be transmitted as B1? I recommend linking your HMI to a computer with a terminal emulator like PROCOMM or Hyperterminal to monitor the actual transmission data.
In response to Mr. Bailey, I want to express my gratitude for your timely reply. I tested my program using Hyperterminal right after encountering the issue. Communication at 19200BPS with Hyperterminal was successful, indicating that my program is functioning correctly. The bytes sent from my microcontroller to the PC are not swapped, as confirmed through Hyperterminal. Despite using the TestComm PC utility from the GE Fanuc website to communicate with the PLC, I am still unable to establish a connection with my microcontroller. It is puzzling where the error lies. I remain hopeful for a resolution to this issue soon, as I am eager to have this application up and running by the end of the month.
If you are experiencing issues with data transmission between your microcontroller and TestComm utility through Hyperterminal, it is important to check for consistency in characters and checksums. Additionally, consider if your microcontroller is adding CR/LF characters at the end of the data string. It is also wise to inspect the TxD line using a scope to ensure the signal is being transmitted at the correct voltage levels. Compare the output waveform of your microcontroller to that of the computer running the TestComm utility to identify any discrepancies that may indicate a hardware issue.
Continued PLC-HMI Communication Issue Thank you once again for your prompt response. 1) The TestComm utility is indeed transmitting the same checksum as I have calculated. This can be observed in the utility window, which displays the characters being transmitted to the PLC on the PC screen. 2) My microcontroller does not send a CR/LF character after each character or sequence of characters. I have verified this through my experience with MODEM interface projects where I utilize AT commands. Unless I include the ASCII code 0Dh (Hex) for "Enter" in the message string, the microcontroller does not add it. 3) I will follow your suggestion, Mr. Bailey, and check the TxD line signal on the Oscilloscope, which I have not tried before. I have successfully interfaced with MODEMs without encountering any Tx/RX signal issues. Thank you for the advice. 4) I utilize either SNPX or SNP protocols to communicate with the PLC. I have attempted communication using both SNP and SNPX Protocols. 5) Thank you for informing me that VersaMax supports Break Free SNP/SNPX operation. As a newcomer to PLCs, I was unaware of this capability. 6) I will keep you updated on my progress with the GE Fanuc PLC and if I am able to get the HMI functioning properly. Any additional tips, suggestions, or solutions you can provide would be greatly appreciated. Thank you, Mani Parthasarathy.
The potential issue may lie in maintaining accurate voltage levels, as mentioned by Steve. Have you considered employing a driver/receiver to serve as an RS-232 interface connecting the PLC and microcontroller? In my setup, I utilize a Maxim 233 for interfacing between the microcontroller and a Micrologix 1200.
Hi P.Mani, From what you've detailed of your process, it sounds like you've got the correct base method. One error could potentially be with your CPU ID set to NULL, though it is indeed usually correct for Point-to-Point Communication. Nonetheless, different PLCs sometimes have subtle differences in communication setup. Look into verifying if NULL is the correct setup for your specific VersaMax Micro PLC model. Also, check your wiring and ensure that structure and termination is correct. Another possibility could be power interruptions or fluctuations that could disrupt communication initiation. Double-check these factors and let us know if the situation improves. Looking forward to your update!
Hi P.Mani, It appears you've taken quite a thorough approach to diagnosing the issue so far, so well done with that. It might be worth double-checking the physical connection—sometimes even a slightly loose cable can cause communication issues like the one you're experiencing. Additionally, it's possible your HMI software might not support the NULL CPU ID for Point-to-Point Communication. It's mostly a standard feature, but there are always exceptions. Lastly, ensure whether your custom OI supports the said SNP or SNPX protocol. I hope this address some of the problem areas. Happy troubleshooting!
Hey P.Mani, it sounds like you’ve done quite a bit of groundwork already, but let’s see if we can get this sorted. First, double-check that the baud rate setting on both the PLC and your HMI match exactly; even a small mismatch can cause communication failures. Also, ensure that your cable connections are good—sometimes a loose RJ45 can be misleading. Have you tried using a simple terminal software to send basic commands directly to the PLC? This could help isolate whether the issue lies within your custom implementation or if there’s a deeper configuration problem. Lastly, examining the error logs, if available, might give a clue about what’s happening. Good luck, and keep us posted!
Hi P.Mani, it sounds like you're taking all the right steps to establish communication, but I wonder if there might be any issues with the parameters or the setup itself. Since you're using the default communication settings, ensure that the PLC is indeed set to expect the same baud rate and parity—sometimes these can be overlooked. Additionally, double-check the wiring and connections on the RJ45 port; a faulty cable can cause major issues. You might also want to use a logic analyzer to see if your messages are being sent correctly and if any signals are being received at all. If nothing works, testing with a different cable or PLC software diagnostics might help narrow down the root cause. Keep us updated; I hope you get it sorted out!
âś… Work Order Management
âś… Asset Tracking
âś… Preventive Maintenance
âś… Inspection Report
We have received your information. We will share Schedule Demo details on your Mail Id.
Answer: Answer: The default communication parameters are typically set to 19200BPS, Odd Parity, 1 Stop Bit, and 8 Data Bits when connecting a VersaMax Micro PLC and a custom Operator Interface through Port 1 with an RJ45 Connector.
Answer: Answer: The steps involve sending a Long Break signal, waiting for a duration, transmitting the Attach Message (for SNP) and X-Attach Message (for SNPX) with the PLC CPU ID set to NULL, waiting for a specific time, and checking for an Attach Response (or X-Attach Response).
Answer: Answer: If no response is received, it can be due to an error in the Attach Message. According to the SNP Communications User's Manual, no response is expected in case of an error in the Attach Message. For other messages, an error message or NAK is usually received.
Answer: Answer: Troubleshooting communication issues may involve reviewing the message streams, verifying
Join hundreds of satisfied customers who have transformed their maintenance processes.
Sign up today and start optimizing your workflow.