Greetings, everyone! Today, I am dealing with a specific issue regarding Modbus ProSoft for the first time. The customer's setup is confusing, but we have to work with it. Typically, in a complete Modbus setup with a Schneider PLC and a Magelis/Harmony screen, I follow a certain process for commands. On the screen, I set _CMD with %MXXXX to 1. The PLC then receives this command, pulses the "usable output" of the CMD block for 3 seconds (while %MXXXX is high), and then sets %MXXXX back to 0 after the 3 seconds, indicating that the screen is ready for the next command. This process ensures that the command is not lost between Modbus scans and prevents it from being latched in the PLC if communication with the HMI/SCADA is lost. Now, when it comes to the Modbus ProSoft on a 1756 rack, there are separate data arrays for Read and Write commands. One array is for Read commands (Read commands and SP from screen), while the other is for Write commands (Write statuses to the screen). I am unsure if what I want to achieve can be done with this setup. If not, I would appreciate guidance on best practices for commands in such a setup. Currently, I am facing an issue where changing a "read" value from the screen in the PLC is not reflecting on the screen due to communication limitations. I am exploring options to resolve this issue, such as manipulating the read/write arrays over the same register. If this proves to be complex, I am considering alternative methods for achieving the desired outcome. Any suggestions or insights on pulsing from InTouch would be greatly appreciated. Thank you.
InTouch tags offer the flexibility of being both read and write enabled, allowing InTouch to activate a PLC bit and the PLC to reset it. Additionally, InTouch allows for the utilization of momentary bits for enhanced control.
Robertmee pointed out that InTouch tags are capable of both reading and writing, allowing InTouch to activate a PLC bit and the PLC to reset it as well. It is also possible to create momentary bits in InTouch. However, there seems to be an issue with Prosoft as it features two different INT register arrays: 0-999 for reading from the HMI and 1000-1999 for writing to the HMI. This causes a problem where the command read from the HMI remains at a value of 1 in the internal Prosoft database even after attempting to reset it to zero, resulting in the HMI value staying high. Despite attempts to overlap the registers to troubleshoot the issue, there are doubts about its effectiveness.
dalporto mentioned a challenge with the Prosoft system, which features two INT register arrays: 0-999 for reading from the Human-Machine Interface (HMI) and 1000-1999 for writing to the HMI. The issue arises when a command is read from the HMI and set back to zero, but remains at 1 in the internal Prosoft database. This causes the HMI value to stay high, even though it appears as 0 in the Programmable Logic Controller (PLC). One potential solution is to overlap the registers to see the outcome. Additionally, setting up momentary Push Buttons (PBs) in Intouch or using On mouse down script to write a value of 1 and On mouse up to write a value of 0 on the same action can create the desired "pulse" effect. Another option is to use the PLC to read the status of an Input bit and then set an output bit back to the HMI. In the HMI, a condition script can be implemented to reset the input bit when the output bit is 1. This approach can help resolve the issue and ensure smooth communication between the PLC and HMI.
Robertmee suggested utilizing the PLC to monitor an input bit's status and send the corresponding signal to the HMI. By implementing a condition script in the HMI, the input bit can be reset when the output bit is activated. This solution serves as a backup plan, with considerations for a separate button to clear all commands in case of communication failure leading to unresponsive commands. Despite challenges in overlapping read/write registers for command execution, addressing the issue of switching between 3 control authorities (Local-Station-Remote) without disruption remains a top priority. Seeking assistance from Prosoft for a possible solution, a Teams meeting has been scheduled for further discussion on achieving seamless control transitions.
To achieve your goal, consider using conditional scripts with ControlLogix and InTouch. Trigger a button to set HMI2PLC, with a conditional script for PLC2HMI that resets HMI2PLC to 0 when the button is pressed. Are you unable to use ABCIP or DACIP in this version?
Hi there! I can relate to your issue as I've dealt with something similar with the Modbus ProSoft on a 1756 rack before. A potential solution could be using a software interlock. In other words, you could program the PLC to look for changes in the screen’s command value, rather than just the command value itself. When it sees a change, it triggers the output sequence and then sets a PLC memory bit to match the new command value. If the command value changes again, the system repeats the process; if not, then it does nothing. This method prevents the command from being lost or duplicated. It might require some tweaking to fit your exact situation but hopefully, it steers you in the right direction.
Hi there! Based on your description, it sounds like you're grappling with some intricacies of the Modbus ProSoft setup, especially the confusion between Read and Write commands. From my own experience, the trick is to manage both arrays appropriately within the PLC's programming structure. You might need to set up an interlock through a separate register to capture the change from the PLC side and pass it over to the screen. Regarding InTouch, you could try setting up a discrete trigger tag that sets and resets based on the pulse from the PLC. This method has worked for balancing the communication limitations between PLC and HMI in my setup, allowing for a smoother operation. I hope this could add some value to your task. Good luck!
Hey there! It sounds like you’ve got a pretty tricky setup on your hands. I’ve run into similar issues with Modbus before, especially when the communication pathways aren’t clear. One thing to consider is ensuring that your read/write arrays are correctly synchronized; sometimes, you might have to implement a handshake mechanism to confirm that values are sent and received properly between the PLC and HMI. Also, to avoid the staleness of data on your screen, it might help to introduce a regular polling interval that updates the display regardless of direct commands. If you’re looking to pulse commands, maybe consider using a timer function in the PLC that can handle the read commands while also checking the communication status with the HMI. Hope that helps!
Hey there! It sounds like you're navigating a tricky setup with your Modbus ProSoft and the PLC. For the issue with the read value not reflecting on the screen, you might want to double-check your mapping between the arrays to ensure that the PLC is correctly updating the intended registers for the HMI to read. Instead of manipulating the read/write arrays over the same register, which can get confusing, consider using flags or status bits that explicitly indicate when data updates should happen. Also, make sure your communication settings, like the timing and polling rate, are optimized so the screen can read the latest values without delays. If possible, adding some logging can help you track where things might be falling through the cracks. Good luck!
Hi there! It sounds like you're dealing with quite the challenge, especially with the Modbus ProSoft setup. One thing you might consider is looking into how the timing of your read/write operations is set up—sometimes, issues with values not updating can stem from timing mismatches between the PLC and the HMI. If you're having trouble with values not reflecting on the screen, it may be worth investigating if the PLC is correctly updating its internal registers before the HMI performs its read operation. Also, using separate registers for read and write might be complicating things, so ensure they are properly synchronized and that you’re triggering appropriate updates on the HMI side. If needed, pulses could be sent as flags that tell the screen when to refresh its display. Good luck, and I hope you find a smooth solution!
Hey there! It sounds like you're navigating a pretty intricate setup with Modbus and ProSoft. One thing that might help is ensuring that your read and write operations are properly synchronized and that there's a clear distinction between the two processes in your PLC logic. Since you mentioned communication limitations, it might also be worthwhile to check the timeout settings and ensure the ProSoft interface is configured to handle the message traffic effectively. If you haven't already, try using an intermediate flag or status bit to manage communication between the PLC and HMI; it can help bridge any lags in data transfer. Lastly, if you're looking at pulsing from InTouch, maybe implementing a frequent status poll could keep the values in sync better. Good luck!
✅ 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 Modbus ProSoft setup on a 1756 rack involves separate data arrays for Read and Write commands, which may require different command strategies compared to a setup with a Schneider PLC and a Magelis/Harmony screen.
Answer: Answer: In a Modbus ProSoft setup on a 1756 rack, it may be necessary to consider strategies such as manipulating the read/write arrays over the same register to prevent commands from being lost between Modbus scans.
Answer: Answer: If you are facing communication limitations where changes in values are not reflecting on the screen, consider exploring alternative methods or adjusting command strategies, such as pulsing from InTouch, to achieve the desired outcome.
Join hundreds of satisfied customers who have transformed their maintenance processes.
Sign up today and start optimizing your workflow.