Efficient Data Storage for Schneider M340 Modbus TCP Communication

Question:

Hello! I am currently working on a project that involves gathering data from three separate devices using Modbus TCP protocol. The data collected will be read by a Citect server connected to a PLC, which will then handle the information in the SCADA system. No writing is required, only reading. I am relatively inexperienced with Schneider PLCs and am utilizing Unity Pro XL software. During testing, I successfully connected to and read/wrote data from a Modbus simulator running on a PC. However, I do not have access to the actual devices in the office. Currently, I am facing a challenge in storing the data in the PLC memory so that it can be accessed by the SCADA system. One approach I am considering is storing approximately 10,000 registers from each device in three large arrays starting at %MW0-%MW20000 to ensure complete access for the SCADA. I would appreciate any advice on a more efficient way to handle this data storage process. Additionally, I am curious if storing the data types in the arrays as INT could potentially cause any issues. Thank you for taking the time to read this.

Top Replies

The maximum number of addressed %MW registers in the M340 PLC is 32768. Data can also be read into un-addressed arrays, and Citect can retrieve un-addressed data from Schneider PLC using the Schneider OFS server. It may seem excessive for the PLC to have 60,000 tags, as it likely isn't utilizing all of them. It would be more efficient for Citect to directly read the 20,000 tags from each of the three devices. Using an M340 PLC for this task may not be the most suitable choice, as there may be simpler solutions available with the right hardware or software.

Thank you for your response. This is just a small component of a larger project where we do not have control over hardware and design decisions. Like you, I have questioned why the data cannot be directly extracted from the units. However, the project manager insists on following the project documentation, and I do not have direct communication with the SCADA developer. The reason for wanting to access numerous registers is to comply with the project requirement of sending all device data to the SCADA system. With approximately 4000 different parameters on each device spread across various registers, the task of sorting and extracting only relevant parameters for all three devices is substantial. This is why I considered mirroring the entire address space. It may be necessary for me to reevaluate my approach to managing this project.

It appears that the Scada developers are delegating some of their tasks to you, which is a common occurrence. For instance, I once worked on a project where we had to install a Data concentrator PLC to collect data from over 35 PLCs, which was then integrated with the on-site Scada system.

Skypher mentioned that he is currently working on a project that involves gathering data from three separate devices using Modbus TCP. The PLC is connected to a Citect server, which will collect and manage the data in the SCADA system. Skypher, who is new to Schneider PLCs and using Unity Pro XL, has successfully connected to a Modbus simulator on a PC for testing. One challenge Skypher faces is how to store the data in the PLC memory to make it accessible to the SCADA system. One solution considered is storing the data from each device in three large arrays starting from %MW0 to %MW20000. However, Skypher is looking for a more efficient method and is wondering if using INT data types in the arrays will cause any issues. Furthermore, Skypher inquires about the specific PLC hardware being used for the devices. It is important to keep in mind that Modbus has a limit of 125 words per read, so transferring all the data to a central point may take some time.

With 4000 tags per device, there are potentially 32 reads per device if the registers are contiguous, although it seems like they are not. To efficiently read all these modbus registers, it is recommended to use 2 or 3 NOE modules for the IO scanning function. Using READ_VAR blocks in logic for this task can be time-consuming and less reliable.

This is certainly an interesting challenge you're facing! It's good that you're thinking about efficiency in data storage, as this can impact the performance of the entire SCADA system. Since you're dealing with such a large volume of registers, you may want to consider using Modbus function code 23 (Read/Write Multiple registers). It could allow you to read the data and then write it to a different memory block in a single command, which might streamline your process. For the data types, using INT shouldn't typically cause any issues, although you should confirm that all the data you're dealing with will fit into the INT data type's range to avoid potential truncation or overflow errors.

Hi! It sounds like you're on the right track, using arrays to store your Modbus register data can be a good solution. However, keep in mind that effectively managing such a large chunk of data may require some careful planning. Depending on the speed at which the data needs to be updated in the SCADA system, it may be beneficial to use interrupt-based updates in the PLC. If the PLC and SCADA allow, you might consider using a publish-subscribe protocol, such as OPC UA, instead of Modbus TCP for more efficient data handling. As for storing your data as INT, it depends heavily on what kind of data you're dealing with. Generally, if your data fits within the range [-32768, 32767], INT should suffice. Otherwise, you might run into overflow issues. Just be diligent in knowing what kind of data you'll be receiving from your devices! Good luck with your project!

It sounds like you're diving into an interesting project! Storing data in large arrays can definitely work, but keep in mind that 30,000 registers (10,000 for each of the three devices) could consume a significant portion of the PLC's memory, especially if you’re also dealing with other tasks or functions. You might want to consider a more segmented approach, like using smaller arrays or structures to group similar data together, which can improve readability and organization. As for data types, using INT for registers is typically fine, but be cautious about overflow if your registers exceed the range of INT. You might also explore using structures or UDTs (User Defined Types) in Unity Pro XL for better data management, especially if the registers represent related parameters. Good luck!

Hey! It sounds like you're on the right track with collecting data from your Modbus devices. One suggestion to improve efficiency could be to implement a ring buffer or FIFO queue for storing your registers instead of using vast arrays that may not be fully utilized; this could help manage memory better while allowing you to access the most recent data easily. Also, regarding data types, if you're only dealing with INT values and the expected range fits within that, it should be fine, but keep an eye on any potential overflow if you ever decide to change the data format or add more complex data types in the future. Don’t hesitate to reach out if you have more questions as your project progresses! Good luck!

It sounds like you’re off to a solid start with your project! Storing all those registers in large arrays is a common approach, but you might want to consider a couple of things to keep efficiency in check. Instead of using one big array, think about segmenting your data into smaller, more manageable chunks based on the device or application needs—this can improve access speed and reduce complexity. Regarding data types, using INT should be fine as long as you're aware of the range limitations—just make sure that the actual data values from the devices don't exceed those bounds. It might also be worth looking into how Citect handles large data sets and whether it can improve your access or visualization needs. Good luck with your setup!

More Replies →

Streamline Your Asset Management
See How Oxmaint Works!!

✅   Work Order Management

✅   Asset Tracking

✅   Preventive Maintenance

✅   Inspection Report

We have received your information. We will share Schedule Demo details on your Mail Id.

To add a comment, please sign in or register if you haven't already..   

Frequently Asked Questions (FAQ)

FAQ: 1. What is the project about and how is data being collected from devices using Modbus TCP protocol?

Answer: The project involves gathering data from three separate devices using Modbus TCP protocol. The collected data will be read by a Citect server connected to a PLC, which will handle the information in the SCADA system. Only reading data is required, not writing.

FAQ: 2. What software is being used and what is the current challenge faced in storing the data in the PLC memory?

Answer: The user is using Unity Pro XL software and is facing a challenge in storing the data in the PLC memory so that it can be accessed by the SCADA system.

FAQ: 3. What approach is being considered to store the data in the PLC memory, and is there a more efficient way to handle the data storage process?

Answer: The user is considering storing approximately 10,000 registers from each device in three large arrays starting at %MW0-%MW20000. They are seeking advice on a more efficient way to handle this data storage process.

FAQ: 4. Could storing the data types in the arrays as INT potentially cause any issues?

Answer: The user is curious if storing the data types in the arrays as INT could potentially cause any issues.

Ready to Simplify Maintenance?

Join hundreds of satisfied customers who have transformed their maintenance processes.
Sign up today and start optimizing your workflow.

Request Demo  â†’