Traditional PLCs: Outdated and Unresponsive to Modern Needs

As you know, traditional programmable logic controllers (PLCs) have remained stagnant for decades, adhering to the same standard established 40 years ago. In today's rapidly evolving and internet-connected world, this lack of innovation is unacceptable.

• NodePLC: A Revolutionary Approach to Industrial Automation

Inspired by the groundbreaking Node-RED programming tool, NodePLC offers a revolutionary approach to industrial automation. With an intuitive interface and familiar drag-and-drop functionality, NodePLC empowers even novice users to create complex automation systems with ease.

• Real-Time Control and Node-RED Integration

Unlike Node-RED, NodePLC places a strong emphasis on real-time control, making it ideal for mission-critical industrial applications. Additionally, NodePLC seamlessly integrates with Node-RED, enabling you to leverage the best of both worlds.

Unlock Your Imagination and Transform Your Industrial Processes

With NodePLC, the possibilities are endless. Combine the power of real-time control with Node-RED's extensive library of nodes to bring your wildest automation dreams to life.

* NodePLC: The Future of Industrial Automation is Here.

Key Features:

• Intuitive Node-RED-like interface
• Real-time control capabilities
• Seamless Node-RED integration
• Extensive library of nodes for various industrial applications
• Easy to learn and use, even for beginners
• Scalable to meet the needs of any project

Benefits:

• Increased productivity and efficiency
• Reduced costs and downtime
• Improved flexibility and scalability
• Enhanced security and reliability
• Future-proofed automation solutions

Learn More:

Visit our website to learn more about NodePLC and how it can revolutionize your industrial automation processes.

Contact Us:

Get in touch with our team today to discuss your specific requirements and get started with NodePLC.

NodePLC: The Future of Industrial Automation is Now.

NodePLC is a Raspberry Pi-based PLC that can be programmed using a low-code, or flow-based development environment.

At this time, the OS is only for test, development, and demonstration. The features and capabilities will change over time.

1. Because NodePLC is a PLC product, the OS is created with the Linux Realtime Kernel (i.e. PREEMPT_RT) to optimize for realtime control.
2. The OS reserves the 4th core for the realtime control task. This allows the realtime control task to have the 4th core all to itself, thus reducing the likelihood it is interrupted by other processes running on the system.
3. The OS is read-only so the NodePLC hardware can tolerate an abrupt loss of power without file system corruption, and does not need to be shutdown by the user.
4. The OS has been reduced to only essential software to reduce contention for resources and competition with the realtime control task, but also because most of the software in the original OS is simply not needed. The original OS consumes about 300MB of memory, while this OS consumes only about 100MB of memory. The original OS has almost 200 running processes, while this OS only has about 20.
5. The OS does not have a desktop environment. It boots directly to the NodePLC Dashboard Application. This will be the users' primary interface to configure, control, and monitor the system.
6. The RS-232 port is currently configured as a console port (baud 115200). Customers need a way to configure the system (e.g. configure the IP address), update the OS and software, troubleshoot, and many other tasks. The dashboard application can also be used for such tasks, but field application engineers (FAEs) do not typically carry a monitor, keyboard, and mouse with them. They usually just have a laptop. An SSH terminal could be used, but what if TCP/IP isn't working?
7. The RS-485 port is used to communicate with IO control modules. Currently, only Modport is supported.
8. Any CPi-A, CPi-B, CPi-C, or CPM500 hardware can be used, but you must update the /boot/config.txt file with the model-specific one in the OS image's /boot/ folder.

• There is currently no authentication for the web-based UI. This will need to be added later.
• There is currently no HTTPS encryption on the web-based UI. If the customer needs encryption, they will need to purchase an HTTPS certificate and enable Nginx or Apache reverse proxy. See https://learn.microsoft.com/ko-kr/aspnet/core/host-and-deploy/linux-nginx?view=aspnetcore-7.0

1. NodePLC Hardware - For now, a CPM500 or CPi panel PC can be used, but the /boot/config.txt must be replaced for each model. See the /boot/ folder for several pre-made config.txt files.
2. MODPORT Header Module - We do not currently have any modules, so the Modport is used as a substitute. It is connected the NodePLC's RS-484 port (e.g. /dev/serial1)
3. MD-DOS08 Output Module - Configured as Modbus slave address 1
4. MD-DIDC8 Input Module - Configured as Modbus slave address 1
5. Console Terminal - Connected to the NodePLC's RS-232 port for configuring, monitoring, controlling, and troubleshooting the system.
6. Web-based Dashboard application - Used to configure, monitor, and control the system via a GUI. This is the default application displayed on the local HDMI port. However, because it is a web-based application, it can also be viewed by an external PC, tablet, or smartphone.
7. Web-based Designer application (To be developed soon) - Used to program real-time tasks and GUI applications via a flow editor.

The operating system runs 2 primary processes:

• A web server for displaying the dashboard and designer applications.
• A realtime control task for all I/O control.
  • If it can communicate with a Modport as configured in the image above, each iteration of the realtime control task will communicate with the Modport.
  • If it can't communicate with the Modport, each loop iteration will sleep 200µs. This is useful for measuring the jitter of the hardware and OS.

The dashboard is used to configure, monitor, and control the system. It can also be used to monitor and control the realtime task.

<html> <style> div.dokuwiki ol ol { list-style-type: decimal; } </style> </html>

1. URL of the dashboard application so it can be opened via an external PC.
2. General system information
3. Realtime information about the performance of the system
4. Control and monitor the realtime task.
   1. The amount of time the realtime task has been running
   2. The number of errors that may have occurred while the task was running
   3. The minimum time it took for one iteration of the main control loop to run
   4. The average time it took for one iteration of the main control loop to run
   5. The maximum time it took for one iteration of the main control loop to run
   6. Start or stop the realtime task. Restarting resets the information above.
   7. The current state of the MD-DIDC8 Modport module's inputs
   8. The current state of the MD-DOSO8 Modport module's outputs. Click each output to toggle its state.

The following demonstration illustrates the current capabilities of the realtime OS.

• Due to the realtime requirements of a PLC, we can't tolerate CPU frequency scaling. Therefore, the CPU will always be running at its highest capable frequency and a superior cooling solution will be important if we want to maintain a high operating temperature specification.
• Customers will probably demand an RTC, but the CPM500 doesn't have one. Please consider adding an RTC to the hardware.
• We need a way to update the OS and NodePLC firmware without destroying the users configuration and program. Is there a way to have a separate disk to store the customer's configuration data?
• Consider adding a dedicated serial console port. Customers need a way to configure the system (e.g. configure the IP address), update the OS and software, troubleshoot, and many other tasks. The dashboard application can also be used for such tasks, but field application engineers (FAEs) do not typically carry a monitor, keyboard, and mouse with them. They usually just have a laptop. An SSH terminal could be used, but what if TCP/IP isn't working?
• Please consider using the CM4.
  • Supply of the CM3 is uncertain and will reach end of life in a few years
  • The CM3's RS-485 port has many limitations. The CM4 UARTs do not have any limitations.
  • The CM4 has 6 full UARTs, which could prove quite useful for future expansion.
  • The CM4 is faster and causes less jitter for the realtime task
  • The CM4 built-in Ethernet is quite fast
• Module Communication Protocol
  • SPI would probably be faster than I2C or serial
  • If we need to query each module individually, the realtime control task will be slow. It would be best if we could create a protocol that can write IO state and read IO state from all modules with a single query/response. Is it possible to use hardware flow control (e.g. RTS, CTS, etc.) for this?
  • If we had full-duplex communication, modules which have already read their data can begin responding while other modules are still reading their data.
• The OS uses very little memory, so we should not require Raspberry Pi Compute Modules with more than 1GB of RAM, thus reducing cost.
• Is power over Ethernet (PoE) possible? That would probably be a nice distinguishing feature.