Efficiently Transferring Tags from FactoryTalk Optix to SQL Database

Question:

Greetings everyone, I find myself in a challenging situation. I have been given the task of transferring a significant amount of tags, ranging from 500k to 1mil, from FT Optix to an Azure database at a rate of 1000 tags per second. As a web developer with limited experience in PLC, I am currently using FT Logix Echo with four controllers that collectively have 60k tags. Additionally, I have set up ten bare metal workstations running Echo, connected via NAT and accessible through VPN. To achieve the required tag count, my initial approach was to install all 40 controllers in Optix. However, this caused a strain on my system as 16 controllers consumed 40% of my 64GB memory, rendering my PC unusable. As a solution, I am considering setting up a local Optix instance on each bare metal workstation. Virtual machines are not a viable option due to the heavy GPU resources required for running digital twins. Putting Optix aside for a moment, let's imagine I only have 4 controllers emulated in Echo. How can I extract all the tags from these controllers into a SQL database? Do the bits need to be modified before polling, or can I efficiently transfer all tags via EthIP to the database? Is OPC-UA a suitable alternative? I would greatly appreciate any guidance or assistance on this matter. Thank you.

Top Replies

I may not be the best person to assist with the Rockwell side of things, but it appears that you are facing a challenging situation. When someone says "get me everything," it often suggests that they may not fully understand their exact requirements. It may be helpful to provide some education on PLC tags, as many of them may not actually be relevant to your needs. Best of luck!

The sheer magnitude of data being collected is staggering, and it is essential to understand the reasons behind the necessity for such a vast amount before moving forward.

Thank you everyone for your input. I must admit, as a new and enthusiastic freshman in this field, I find myself facing a daunting challenge. The company I am working for has unexpectedly thrust upon me the task of coding mobile apps, claiming it is similar to coding PLC systems. Despite my lack of knowledge in this area, I am now dealing with a massive increase in tags from 20k to 500k, all because of an overzealous sales pitch from a Rockwell representative who claimed that "Optix can handle an unlimited amount of tags". I am not asking for a solution to this problem, but rather seeking guidance from those with experience in the industry. The company I am currently working for seems ill-equipped to handle the situation, so I simply want to gather enough information to support my decisions and request the necessary resources from my project manager. Thank you all for your assistance, and I look forward to continuing to expand my knowledge in this ever-evolving industry.

escodsm shared how the number of tags escalated from 20k to 500k due to a misleading statement from a Rockwell sales representative who claimed that "Optix can handle an unlimited amount of tags." It's crucial to consider your audience before making such bold claims to avoid being thrown under the bus. This situation is reminiscent of being in Anderson's boat. For more entertaining short comedy sketches and films like "The Expert," be sure to subscribe to our channel. Explore our collection of Expert shirts and hoodies at our online shop for a good laugh during your next funny business meeting.

As an approved systems house for a leading blue chip company, we were tasked with developing interface software for data capture. Despite the company's preference for using their own PLCs, we faced challenges due to the large size of the software and the complexity of the control programs. The system was designed to send all data to a higher level system, resulting in over 120 PLCs on site with thousands of I/O points. After realizing that most of the data was unnecessary, we proposed sending only useful information to their systems. However, the project was eventually abandoned in favor of installing separate SCADA terminals to collect and organize the essential data in SQL format.

Hi there, this does indeed seem like a challenging situation. First, allow me to address your question about extracting the tags directly into a SQL database. If your controllers support it, try using an SQL link directly. With the appropriate drivers, you should be able to select tags and pull data directly into your SQL tables. You might not need to modify the bits before polling if your SQL driver understands the tag data types. As for your OPC-UA question, yes, it’s a viable route if it’s well supported in your environment, as it's designed to encapsulate and transmit machine data across various platforms. Alternatively, rather than having every controller in Optix, you could consider having a centralized server that handles communication with all your controllers and pushes the data to Azure. You'd have better control and less strain on your PC, but it does bring another layer of complexity into your architecture. Bear in mind these are suggestions based on the limited information I have, so ensure to validate across documentation or with an expert. Good luck with your project!

Hey there! It sounds like you're in quite a complex situation. Given the huge volume of data you're processing, hardware limitations can indeed pose a challenge. Your idea of setting up a local Optix instance on each bare metal workstation makes sense, as it distributes the load instead of overloading a single setup. As for transferring tags from your controllers to the SQL database, typically this is achieved by reading the tag values and writing them directly into your database. No bit modification is necessary, unless your system requires a specific format or datatype. The method of transfer will depend on Echo's capabilities - I'd recommend looking into Echo's API or SDK to see if there's a built-in function for transferring or syncing data to other databases. In terms of alternatives, OPC-UA might work, though it'll largely depend on compatibility and how much extra coding you're prepared to do. It could add another layer of complexity to the setup but the advantage is its wide acceptance and ability to communicate with varied systems. Make sure you thoroughly assess the requirements and compatibility of all systems involved before making a decision. Remember, tackling a task of this magnitude will require careful planning and a lot of testing, so take your time to ensure a solid setup. Good luck!

Hello! To extract tags from your controllers directly into a SQL database, you could benefit from protocols like MQTT or OPC-UA, as they can move data from controllers to databases more efficiently. OPC-UA is particularly well-suited to this task due to its improved security, robustness, platform independence and interoperability features. On top of that, OPC-UA also supports complex data types. Regarding modifying bits before polling, it might not be necessary unless your controller or database requires it for compatibility reasons. If you're dealing with extensive data, consider designing a well-optimized schema on your SQL database for efficient handling. As for your Optix strain problem, spreading the load over multiple physical machines (each having local Optix instances) quite a reasonable strategy. Do keep in mind the potential administrative overload of managing many physical machines though.

Hey there! It sounds like you're managing quite a complex setup. Given your constraints, I suggest considering OPC-UA; it’s designed for interoperability and can handle large tag transfers efficiently. If you go that route, you wouldn’t need to modify the bits—OPC-UA should manage data types inherently during transfer. You could set up an OPC-UA server on your controllers to stream data directly into your SQL database. Just make sure your database can handle the influx and perhaps implement some batching to avoid overwhelming it. Also, if you're still facing performance issues with Echo, having those local Optix instances could distribute the load better. Good luck, and don't hesitate to reach out for more specific questions!

Hey there! It sounds like you’ve got quite the project on your hands. If you only have those 4 controllers running in Echo, one efficient way to get the tags into your SQL database would be to use OPC-UA, as it offers a robust and standardized way to communicate and access data from your PLCs without overwhelming your system. It would allow you to read all the tags directly, and if you structure your queries well, you shouldn't need to modify the bits too much beforehand. Make sure to optimize your batch requests to reduce the load and improve transfer speeds. You might also consider implementing some kind of data aggregation, pulling only the changes or updates, which could help manage bandwidth and processing requirements too. Good luck!

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. How can I efficiently transfer tags from FactoryTalk Optix to an SQL database?

Answer: - One approach could be setting up a local Optix instance on each bare metal workstation to distribute the load and prevent strain on the system. Alternatively, consider extracting tags from controllers emulated in Echo and transferring them to the database using EthIP or OPC-UA.

FAQ: 2. What is the recommended rate for transferring a large number of tags from FT Optix to an Azure database?

Answer: - Aim for a rate of 1000 tags per second to meet the target of transferring 500k to 1mil tags efficiently.

FAQ: 3. What are the limitations of using virtual machines for this task?

Answer: - Virtual machines might not be feasible due to the heavy GPU resources required for running digital twins, making bare metal workstations a more suitable option.

FAQ: 4. How can I handle the strain on system resources when working with multiple controllers in FT Optix?

Answer: - Distribute the workload by setting up local Optix instances on separate bare metal workstations to avoid overwhelming system memory.

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  â†’