Hello everyone, I'm seeking guidance on how Wonderware Intouch handles strings and where I might be making a mistake. I am attempting to compare two strings in a Schneider Quantum 984 PLC - one inputted through the SCADA system and the other obtained from an RFID tag. The communication between the SCADA and PLC is done via Modbus TCP. An issue arises when the PLC reads the registers from the RFID tag, as any empty spaces in the string are converted to 0's within the PLC. However, when the same string is entered through the SCADA, the empty spaces are converted to hex code 20 (spaces). For instance, the string spans across 4 registers: - RFID I/O Message: 400001-400004 - SCADA I/O Message: 400101-400104 RFID Read Tag: 400001 = 3537 Hex (57 ASCII char) 400002 = 3333 Hex (33 ASCII char) 400003 = 0000 Hex (ASCII char) 400004 = 0000 Hex (ASCII char) SCADA Entered Tag: 400101 = 3537 Hex (57 ASCII char) 400102 = 3333 Hex (33 ASCII char) 400103 = 2020 Hex ([space,space] ASCII char) 400104 = 2020 Hex ([space,space] ASCII char) Upon reviewing the diagnostics in the smc, it is clear that the SCADA input includes additional spaces (R/H justified |). RFID = 5733 | SCADA = 5733 | I am seeking advice on how to prevent the SCADA system from adding these spaces automatically. Any insights or suggestions would be highly valued. Thank you.
To enhance tag name efficiency, consider utilizing a script employing Left, Mid, and Right String functions to eliminate any spaces. For more guidance on Wonderware programming steps, check out http://wonderwareintouchusers.com/wonderware-programming-step-learning-guide/. Thank you.
Appreciate your response. I recently tried using the StringTrim function to eliminate spaces in the mimic. However, despite the removal of spaces, the hex code 20 still appears in the PLC registers. It seems like this could be a unique feature of the DASMBTCP driver or possibly how Wonderware handles empty spaces in messages when transferring to registers.
It's never too late to identify the problem for future reference. In C programming, the string variable style should be chosen according to the PLC string-data format. You can select the style used by the device to store strings in its registers, which can be either full length (space padded), C style (null terminated), or Pascal style (includes length specifier). The default style is full length.
I think your issue stems from the fact that Wonderware Intouch pads strings with spaces as it sends them to the PLC. A quick workaround might be to write a script/function block in your Quantum PLC to replace any Hex 20 (ASCII space) values with zeroes. This way, the comparison in the PLC wouldn't fail due to those added spaces from SCADA inputs. However, it might be more effective to address the source and alter how the SCADA system handles string inputs. You could also contact Schneider tech support to inquire if there's a setting to change this default behavior.
Hey, it sounds like you're dealing with a common issue when handling strings in SCADA systems. The spaces being added to your data may be a result of how SCADA systems typically handle strings - they often pad out string data with spaces to meet some required data width. A quick solution would be using a script in your SCADA system to trim the spaces before comparing it to the RFID sting. Alternatively, you may want to check if your PLC has a handle to parse the input removing the trailing zeros or replacing them with spaces. A deeper examination of your Modbus TCP communication setup might be useful too. Also, consider revising the PLC or SCADA settings to match the data formatting between the systems. Good luck!
It seems that your SCADA system is padding the strings with spaces to fill the register. Instead of trying to prevent the SCADA system from adding these spaces, consider making your PLC interpret the hex code 20 as empty, just like it does with zeros. This way, it won't matter if the SCADA system adds the spaces or not. Alternatively, there might be a setting in your SCADA system that controls how it handles the padding of strings, you might want to look into that. Despite this, I recommend the first solution as it makes the system more robust and immune to similar issues in the future.
✅ 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: - The issue arises due to how the Schneider Quantum 984 PLC handles empty spaces in strings received from an RFID tag (converted to 0's) compared to those inputted through the SCADA system (converted to hex code 20, spaces).
Answer: - The additional spaces added by the SCADA system can lead to discrepancies in string comparison and processing within the PLC, affecting the expected results.
Answer: - To prevent the SCADA system from automatically adding spaces to strings, adjustments may need to be made in the configuration or settings of the SCADA system or during the data transmission process.
Answer: - Implementing a standardized format for string handling, such as converting empty spaces to a consistent representation before transmission or ensuring consistent data handling protocols, can help maintain uniformity in string formatting between RFID tag communication and SCADA input.
Join hundreds of satisfied customers who have transformed their maintenance processes.
Sign up today and start optimizing your workflow.