Reddit Highlights (March/ April 2026 ): The UL 891 Switchboard Landscape

May 3, 2026UncategorizedDrives & Systems

Summary: Lead times for Tier 1 equipment have hit a critical average in 2026, forcing engineers to navigate the complex selective coordination requirements of UL 891 through creative interlocking and regional shop pivots.

Series Overview

Once a month, I am pulling a Gemini summary of technical trends being discussed on reddit. This first one is focused on UL891 Switchboards.

Primary Sources: Professional discourse from r/electricians, r/PowerSystemsEE, and r/electrical.

1. The 12-Month “Lead Time” Floor

Supply chain discussions in April 2026 show a “new normal” where lead times for major manufacturers are hovering between 12 to 14 months for standard switchgear and transformers.

The Trend: To keep projects on schedule, there is a massive surge toward regional UL-certified custom shops.
The Advantage: These shops can often assemble a UL 891-compliant board in 8–12 weeks by using off-the-shelf components, bypassing factory backlogs.
The Field Insight: Commercial electricians report projects sitting idle for over a year waiting on substation-level gear, leading to a hunt for refurbished breakers in secondary markets.

Source Thread: Twelve month transformer lead time on our current project (r/electrical – March 26, 2026)

2. Selective Coordination

A recurring pain point is the struggle to meet NEC selective coordination requirements (Articles 700/701) using UL 891 gear compared to UL 1558 alternatives.

The Conflict: UL 891 switchboards are typically tested for a 3-cycle withstand. To protect the bus within this window, main breakers often require low “Instantaneous” settings.
The Risk: This causes the main breaker to “race” downstream branch breakers. If a minor fault occurs, the entire main trips, resulting in a total facility blackout.
Field-Tested Solutions: * Zone Selective Interlocking (ZSI): Utilizing restraint signals so the main breaker “waits” while the branch clears.
- Electronic Trip Units (ETU): Advanced units allowing for Short-Time region adjustments to carve out coordination paths.

Source Thread: Low Voltage Switchgear (UL 891) Selective Coordination and Field Testing (r/PowerSystemsEE – April 2026)

3. Data Centers “Hoarding” the 2026 Market

A massive percentage of industrial electrical equipment produced in 2026 is being funneled directly into AI and hyperscale data centers.

The Scarcity: Hyperscalers have pre-purchased entire manufacturing runs of switchboards and MV transformers, pushing small-to-medium facilities to “low priority” status.
Field Consensus: The industry is hitting an inflection point where the “interconnection queue” and equipment backlogs are making 2026 a year of strategic waiting.

Source Thread: US Data Centers facing delays due to electrical component sourcing (r/GenAI4all – April 6, 2026)

Disclaimer: This content is for informational purposes only and represents community trends as of April 2026. It does not constitute professional engineering advice. All electrical work should be performed by qualified personnel in accordance with NFPA 70E, local codes, and manufacturer specifications.

This is Part 1 of an ongoing monthly series. Stay tuned for future deep dives.

Control Panel Layout: Top Tips with some Photos

November 12, 2023Control panel, Systemscontrol panel, Motor Cables, PLC, vfdDrives & Systems

Amongst the control panel layout tips out there, some are practical, many are good and some are downright weird. There are is a wealth of it in the /PLC sub-reddit. Some of it is amusingly opiniated:

The following is my collection of top tips on control panel layouts. A few of the panel posts from Reddit are embedded below. Will add more pointers as I come across them.

Busbar candy
byu/Otherwise_Feed_3320 inPLC

1. Heat rises

Do the heat calculations. Enclosure vendors usually have free tools for this like this .

- If ventilation is needed, fan at the bottom, exhaust at the top, not the other way around. Hot air rises and leaves the panel, cool air comes in the bottom.

2. Power protection components at the top. Circuit breakers, disconnects. The temperature rating on circuit breakers are usually higher than the average PLC, drive or anything that has electronics for that matter. Example here – 30A breaker from SE has an operational ambient of 158 degF/70 degC. Accessibility and safety is also better with power devices at the top.

3. Incoming power. This really depends on the install site/location. If you have a choice, some would argue that’s it’s better for incoming power to come in from the bottom. With gravity, holes and inlets at the top of the panel have poor contingencies in the event of condensation or dirt coming in( or even water ingress- say NEMA 4/4X failure situations) .

4. Wire labels, terminals, and wire markers

- Avoid putting the label on the device. If the device gets replaced, the label goes with it.
- Sometimes end users may require label on device also. Check before it gets to the FAT
- Harmonize labelling such that it can be traced back to schematics. This will help with maintenance folks and any troubleshooting efforts.

5. Wireway

- Vertical runs should intersect with a horizontal run such that the horizontal run stops the vertical cover from sliding down
- Plan it out such that control wiring is separated from power wiring. If they intersect, make it perpendicular.
- Read on to number 6.

6. Electromagnetic interference

- - Separate 480Vac and 24Vdc ( control and communications) wires.
  - If they have to cross, it’s best done perpendicularly- ie. they cross at a 90 deg angle. Still avoid having them in proximity. Good explanation of this here
  - Additional sleeving or barriers for EMI mitigation if needed.

7. Spacing If the project allows for it, allow for some room between devices, PLC’s, drives, power supplies. This helps with maintenance accessibility. Also, it makes way for future expansions. More I/O if the PLC needs it, another drive …etc..

My new office 😉
byu/adi_dev inPLC

8. Ground connections

- Spec grounding washers installed and properly torqued to bite through the paint

9. Network cabling

Use pre-terminated cables where possible. From a good vendor, reliability is better.
From item 6 above, separate controls communications cables from the power wiring.

10. Maintenance and usability

Add a rack on door for reference material

“I´m tired boss…”
byu/andisosh inPLC

Will come back and add more as I find it…

VFD’s and Long Motor Leads

May 9, 2023VFDMotor Cables, Troubleshooting, vfdDrives & Systems

Recently I came across an application where multiple motors were failing at a single site. This facility utilized VFDs to control several rooftop AC induction motors. The repeated motor failures raised concerns about the possible causes, prompting a deeper investigation into the relationship between long motor leads, motor failures, and VFDs.

Long Motor Leads + VFD’s

The use of long motor leads can cause issues in VFD-driven motors. Voltage reflections and voltage magnification can occur, leading to voltage spikes that can exceed the motor winding insulation capabilities. These spikes, if left unaddressed, may result in premature motor failure due to insulation degradation.

VFD Strategies for Long Motor Leads

Adjusting Carrier Frequency: Reducing the carrier frequency of the VFD can help minimize the impact of voltage reflections and the risk of motor failure due to long motor leads. However, this may result in increased audible noise and reduced motor efficiency, so finding an optimal balance is crucial.
Motor Chokes: Installing motor chokes, also known as output reactors can help mitigate voltage reflection and reduce the risk of insulation breakdown.
Motor Insulation Ratings: Using motors with higher insulation ratings, such as those designed specifically for use with VFDs, can help protect against voltage spikes and reduce the risk of motor failure.
Proper Grounding: Ensuring proper grounding practices can help minimize bearing currents and their associated motor failures. While this is not directly related to motor lead length, longer lead lengths can contribute to conditions that cause bearing currents. Some examples of ‘fluting’ and bearing issues here: https://empoweringpumps.com/est-aegis-protect-motors-from-variable-frequency-drive-induced-bearing-damage/
Cable Shielding: Using shielded motor cables can help reduce electromagnetic interference and protect the motor from high-frequency voltage pulses.

For reference, the formula for the reflection coefficient is below. The greater the mismatch, the greater the voltage amplification factor.

R = (Z_load – Z_source) / (Z_load + Z_source)

where:

R represents the reflection coefficient

Z_load is the impedance of the load (in this case, the motor)

Z_source is the impedance of the source (in this case, the VFD)

The formula for the voltage amplification factor:

V_max = 1 + |R|

where:

V_max represents the maximum voltage on the line

|R| is the absolute value of the reflection coefficient

Another important note is in situations where there are multiple motors driven by a single VFD, the length of cable to each VFD is summed up as the total motor cable length calculation.

Motor Issues Not Caused by the VFD

There are other motor failure scenarios that get misattributed to VFD’s. These may continue occurring even with mitigation techniques above. As such, it’s important to rule these out beforehand. Some common examples:

Environmental Factors: Exposure to harsh environmental conditions, such as extreme temperatures, humidity, or contaminants, can cause motor failures. These issues may be mistakenly linked to VFDs when they are actually the result of inadequate motor protection or improper maintenance practices.
Mechanical Failures: Mechanical issues, such as misalignment, imbalance, or excessive vibration, can lead to motor failures. These problems may be incorrectly attributed to VFDs when they are actually caused by issues within the mechanical system, such as worn-out bearings, loose components, or improper installation.
Overloading: Overloading a motor, either by exceeding its rated capacity or by running it for extended periods at high loads, can result in overheating and failure. This type of failure might be incorrectly attributed to VFDs when it is actually due to improper motor sizing or incorrect application.
Electrical Issues: Motor failures caused by electrical issues, such as short circuits, phase imbalances, or power quality problems, can also be mistaken for VFD-related failures. These issues may stem from faulty wiring, improper grounding, or voltage fluctuations in the electrical supply.
Inadequate Lubrication: Insufficient or improper lubrication can lead to bearing wear and premature motor failure. This type of failure may be misattributed to VFD-related bearing currents when it is actually caused by poor maintenance practices or the use of inappropriate lubricants.
Design or Manufacturing Defects: Motors with inherent design or manufacturing defects may experience premature failure. These failures can be incorrectly linked to VFDs when they are actually the result of flaws in the motor’s construction or assembly.

Conclusion:

While long motor leads can pose challenges for VFD-driven systems, by understanding the risks, adjusting VFD setup and settings, and taking appropriate preventative measures, it is possible to mitigate the risk of motor failures. Additionally, recognizing motor failures that are commonly misattributed to VFDs can help ensure accurate diagnosis and effective solutions. By incorporating proper grounding, choosing the right motor insulation ratings, and utilizing motor chokes and cable shielding, you can enhance the performance of your VFD-controlled moto

Unlocking the Power of AI at the Edge: Essential Data Points for PLC-based Applications

March 31, 2023PLCAI, dataDrives & Systems

The buzz around Artificial Intelligence (AI) has been hard to ignore, and it’s not just the trade publications fueling the hype. As someone who has been cautiously optimistic about AI, I can’t help but feel myself leaning more towards a pro-AI stance as I witness its transformative impact. With the advent of cutting-edge AI-based tools like ChatGPT, it’s clear that AI is no longer just a futuristic concept, but a powerful tool that’s already changing the game.

While AI has been steadily making its way into automation applications, particularly in vision systems, there are countless other use cases for machine learning and AI at the edge. For years, the limitations of memory, processing power, physical form, and price have hindered progress at the edge. However, with advancements in PLC products, these barriers are rapidly being overcome. The question now is, what data do you need to effectively implement an AI application at the edge?

To answer this question, the table below was compiled based on AI applications in industrial automation application.

AI Application	Data Points Needed for Implementation
Predictive maintenance	Real-time sensor data, historical maintenance records, equipment operating conditions, and environmental conditions.
Fault detection and diagnosis	Sensor data, historical data on faults, and their root causes, machine operating parameters, environmental conditions.
Quality control	Real-time sensor data, historical quality control data, product specifications, process parameters.
Energy optimization	Real-time sensor data on energy consumption, machine operating conditions, historical energy consumption data, environmental conditions.
Production planning and scheduling	Production data, inventory data, supplier data, machine data, order data, production schedules, and delivery schedules.
Asset tracking	Real-time sensor data on asset location, usage, and maintenance records.
Supply chain management	Historical sales data, real-time demand data, inventory data, supplier data, shipping data, transportation data.
Process optimization	Real-time sensor data on machine operating conditions, production data, quality data, historical process data, environmental conditions.
Root cause analysis	Historical production data, fault data, maintenance records, quality control data, environmental data.
Machine learning-based control	Real-time sensor data on machine operating conditions, historical machine data, environmental conditions, and production data.
Automated decision-making	Real-time sensor data, historical data on machine performance, historical maintenance records, production schedules, and delivery schedules.
Real-time monitoring	Real-time sensor data on machine operating conditions, production data, quality data, and environmental conditions.
Autonomous robots	Real-time sensor data, machine operating data, production data, environmental data.

While this list is a higher level view of relevant data for different applications, there are other data factors. These include data quality, quantity, and accessibility, as well as considerations around data privacy and security. In some cases, a data storage device may be needed from which data is pulled back into the PLC as needed. Also ,the elephant in the room is what type of algorithms and AI functions can a PLC actually execute. More to delve into on all these points. One thing is for sure, the final solution is going to be much more involved than a two letter acronym (AI) infers.

Moving forward, my aim is to be concise and informative in posts. If you’re interested in learning more about the trends, challenges, and opportunities in AI implementation at the edge, be sure to subscribe. In future posts, we’ll explore other aspects of AI at the PLC, and I welcome your comments and requests for specific topics.

Back on the blog, ChatGPT and Real-time Industrial Comms. Protocols

March 23, 2023PLC, SystemsChatGPT, Ethercat, EthernetIP, Sercos IIIDrives & Systems

After a 5 year break from Drives & Systems, I’ve returned!

I’ve stayed active in the industrial automation space and worked through a range of machine automation projects at Schneider Electric over the last few years. From robotics and motion through HVAC and pump control systems. Lots learnt and and a lot to capture. Hopefully capturing some of it here comes as a benefit to others.

Wasn’t sure what I was going to find here but I have come back to some interesting stats on the site. Also some good insight around PLC programming topics users engaged with most here. For instance users seem to have landed here while googling for info on Codesys arrays. This is a promising development in the industrial controls world, knowing that data structures are being used more at the PLC level. Will expand on some of this insight and the topic of arrays in PLC programming in a future post.

For today, I’ve been exploring the usage of ChatGPT in industrial automation. The combination of large language model processing and reinforcement learning along with what seems to be a substantial data set has led to a pretty amazing outcome. More importantly, it will have some strong use cases in industrial automation too. The use cases from code generation to building specifications, data collection to troubleshooting will likely unfold more and more in the coming months and years.

A query I took to ChatGPT recently was to compare a few different real time Ethernet communication protocols. While some of this may be outdated since the data references are from September 2021, the output generated was quick and definitely a great reference for automation industry folks.

Whether working through a specification or just looking to learn about the different protocols, this will come in handy.

One important point, the quality of the query makes all the difference. For example when I queried a comparison with Sercos, the outcome was totally different from Sercos III which is newer. So be precise on the query.

Network	EtherCAT	SERCOS III	Ethernet/IP with CIP motion
Architecture	Centralized controller to multiple devices	Centralized controller to multiple devices	Distributed control system (devices communicate directly)
Topology	Line, Tree, Star	Line or ring network	Star, Linear, Ring
Data Transmission	Asynchronous	Asynchronous	Synchronous
Data Transfer Rate	Up to 10 Gbps	Up to 100 Mbps	Up to 100 Mbps
Cycle Time	100 ns	31.25 μs	Up to 16 μs
Determinism	Highly deterministic	Highly deterministic	Moderately deterministic
Jitter	Very low	Low	High
Synchronization	Hardware-based	Hardware-based	Software-based
Scalability	Good	Limited	Good
Real-time Communication	Yes	Yes	Yes
Security	Good	Good	Good

Descriptions of each area of comparison:

Row	Description
Architecture	The relationship between the central controller and the network devices, including whether the network is centralized or distributed, and whether devices communicate directly with each other or through the central controller.
Topology	The physical layout of the network, including whether it is a line, ring, or star network, and how devices are connected to the network.
Data Transmission	The method used to transmit data on the network, including whether it is synchronous or asynchronous.
Data Transfer Rate	The maximum rate at which data can be transferred on the network, typically measured in bits per second (bps) or megabits per second (Mbps).
Cycle Time	The time it takes for one complete cycle of communication on the network, including the time it takes for the central controller to send a command to a device and receive a response.
Determinism	The degree of consistency in the time it takes for communication to occur on the network, with high determinism indicating a consistent and predictable communication pattern.
Jitter	The amount of variation in the time it takes for communication to occur on the network, with low jitter indicating a consistent and predictable communication pattern.
Synchronization	The method used to synchronize communication between devices on the network, including whether it is hardware-based or software-based.
Scalability	The ability of the network to accommodate a varying number of devices without significantly impacting its performance or requiring major changes to the network architecture.
Real-time Communication	The ability of the network to support real-time communication, which is critical for industrial automation applications where precise timing is necessary.
Security	The level of security provided by the network, including measures to prevent unauthorized access, data loss, or data corruption.

References:

EtherCAT: “EtherCAT Technology Group – Basics of EtherCAT” https://www.ethercat.org/en/basics.html
SERCOS III: “SERCOS International – SERCOS III Overview” https://www.sercos.org/technology-overview/sercos-iii/
Ethernet/IP with CIP motion: “ODVA – EtherNet/IP Overview” https://www.odva.org/Technology-Standards/EtherNet-IP/Overview-of-EtherNet-IP/

Troubleshooting industrial control systems – Tips and pointers

December 6, 2017HMI, PAC, PLC, Systems, VFDDrives & Systems

Everything is hooked up but something isn’t working. It worked before but not right now. Or, it’s a new system and you haven’t got it working yet. In any case, troubleshooting industrial controls systems usually involves a repeatable approach or pattern of actions.

1. Break the system down into components.

There is a root cause to what is going wrong. Each system is made of of multiple components – software and hardware. To zero in on the root cause, check if each part/component/sub-part of the system works. Example: PLC not communicating with VFD over Modbus. Questions to ask and things to check:

Check if the VFD responds to Modbus polls from a Modbus simulator on your computer.
Alternately, if there is another PLC, preferably identical, hook it up to the drive and download the same program. Check if it communicates.
If there is another VFD available, preferably one that is known to be functional. Also preferable if its of the same type, hook that up to the PLC. Check if it communicates.

Note: Check that the communication settings in the PLC and VFD are correct.

The concept here is to test individual components to zero in on the root cause.

2. Go deep into the workings of each sub-component- including inputs, outputs and the software when possible.

This becomes easier if you know which subsection of each component may be suspect. To the communications breakdown example above, it could be the serial port ( hardware) or the serial communication settings( software). This provides for immediate leads to follow.

In any case, when troubleshooting industrial controls address the obvious first, and then go deeper into each sub-component. Confirm that everything is plugged in and powered up correctly. Can’t count the number of times something wasn’t working … because it wasn’t powered up.

3. Bring in alternative/replacement components, if available.

This includes replacement cables. Depends on the stage / I.e development, legacy/installed. This is noted described in item 1 above. The implication here is to consider carrying spare parts to a site when possible. If this is not possible, consider alternatives like software to test for specific functionality.

4. Don’t alter too many characteristics at a time.

Issues are sometimes a combination of two things happening. Example: PLC won’t communicate with an HMI. The HMI was replaced and the problem persists. The old HMI was connected back in and the PLC replaced,- the problem remained. Replaced the PLC and HMI and figured out that some kind of wiring issue had taken out the serial ports on both devices. Moral of the story: Check one component and then consider combinations.

5. Use software where possible.

One example noted in item 1 above. Another example for ethernet communications troubleshooting is a tool like Wireshark.

Use case: Watch communication lines for packets coming through and sequence of events.

6. Document testing and troubleshooting efforts.

Write down the sequence of tested items. Makes a big difference after you go through several hours of troubleshooting and forget what has been tested. Also, take pictures as much as possible. Helps when recapping items covered or when researching sub components in front of your computer.

7. Consider the environment, timing and non- obvious of issues.

Time and space are at the core of things. Noise from close by systems, or an environmental effect at the same time of day may cause intermittent issues. This goes back to non-obvious factors to consider.

There may be non-obvious factors that may affect things. One example is a electrical noise issues. Co-located power wiring or bad grounding practices could affect this.

Another example of a non-obvious factor may be related to people or process factors. Example: an operator may be shutting down a device or parts of a system and not powering them up again correctly.

Another example: someone updated the firmware to one of the devices and it doesn’t communicate to the other devices any more. The problem here may be more of a process issue but knowing if the firmware was recently updated provides leads for next steps.

PLCTalk Pick of the Week: PLC programmer Laptop Specs- 2016 edition

August 29, 2016UncategorizedDrives & Systems

PLC programming, CAD drawings, SCADA packages and virtual machines. These are some of the resident software suites on the average automation or control professionals computer today. This post is mainly about the hardware needs to get the job done.

Picking a laptop for automation and control engineers

Based on recent discussions on PLCTalk, the specifications vary based on preference. Some of the common requirements mentioned:

Screen Size:

A 15″ screen laptop is the sweet spot for ease of travel and ease of troubleshooting while onsite. Anything less makes the onsite work, specifically if programming is involved, a little harder. Anything more makes for a bulky laptop to travel with.

Last year, I had two programmers show up in PLC programming classes with Surface Book style tablets. With the i7 processors, the Surface performed well. With the screen size, they struggled in maneuvering through the programming environment. Followed up with one of them this year and they had moved back to a larger screen laptop. PLC Programming with the magnifying tool in Windows is not practical.

Processor

The recommendation is a i7 type processor with 3GHz clock. My current machine has a 2.8GHz spec and has been great. Performance with 2 VM’s , HMI software and PLC software running simultaneously noted on screen cap below.

For the MacBook folks, this article talks a bit more about picking processors.

RAM

The RAM requirements vary. With virtual machines being a common place to house several different control software suites- PLC and SCADA environments, RAM requirements are a minimum of 16GB .

PLC Programmer Laptop RAM considerations — Firing up a single VM with some PLC and HMI software running on the host machine. There could be a need to refer to a program in a VM while writing another program.

Based on a the Windows performance monitor, having one HMI software, one PLC programming environment and one VM took the memory usage up to about 14GB. Note, this number is based on the allocation on your VM’s. Also, it may vary based on the various software suites.

A PLC programmer laptop option needs to have lots of RAM. I would recommend 32GB.

Hard drive

The SSD seems to be the way to go. They are generally more shock resistant. Working with PLC’s often means being onsite at various locations. This may even apply to plant based folks who may have to carry Also they are quieter.

Requirement would be at least 500GB.

Operating System

Most industrial automation software suites have traditionally been Windows based. Having said that, much feedback I have received regarding MacBook (Pro’s) have been quite positive in terms of performance. That sentiment it shared on this thread.

Mac users may use Boot Camp to get Windows running. Alternatively, many do report using VM’s.

I use Windows 7 Professional. Windows 8 compatibility is common among software suites out there currently. Some even support Windows 10. Having said that, industrial automation is usually slow to adapt to new OS versions. Some have reported good results and some report problems. This uncertainty keeps me at Windows 7.

Battery Size:

Hooking up to a power source onsite can sometimes be cumbersome. The tradeoff on some of the more powerful machines has been that the battery drains quickly. Consensus is that the MacBook Pro runs all day on a single charge. This goes back to the OS discussion above.

My quad core Lenovo W541 holds a charge for about 1.5 hours. I don’t hold the battery requirement to high on my priority list. If you do, check it out while shopping. Be cautious, as the advertised values might not hold true. They are dependent on your performance and usage.

One absolute comparison, is to check the ampere-hours (Ah) ratings among your options.

Connection Ports:

Forget the serial port. Get an adapter.

Get a machine with at least 3 USB ports.

Some other considerations:

Numeric keypad might help for some work functions. If the laptop doesn’t come with one, there are USB connectable options online.

DVD players can be left out as Installers are increasing available in downloadable software packages. If required, a portable DVD player can be used.

Back-lit keyboards may be useful for work in environments that are not well lit. Not a requirement I considered but noted in the thread.

The actual picks:

Lenovo P50

Dell Precision

MacBook Pro

Dell E6440

I’ve used Dell’s, HP’s andLenovo’s in recent years. My pick for stability and performance right now is the Lenovo. It may be biased to the hardware specs on this current unit. The previous units also had good specs for their time.

In all, the package is probably going to be about USD$2000 or higher. Shopped during the Black Friday sale last year and Lenovo had a great deal on the W series. Probably due to that series being phased out. The price was down to $1700-ish for a 32GB RAM, i7, 500GB SSD setup.

The threads discussing the topic on PLCTalk are here and here.

PLCTalk Pick of the Week: Modbus Simulation Software

August 13, 2016UncategorizedDrives & Systems

The PLCTalk forum pick of the week this week is about Modbus simulator software.

The question

What software out there scans Modbus registers from a PC and provides confirmation of a good connection?
Do any of the software options scan registers on a slave/node? ( automatic scanning inferred)

In a typical setup, the PLC would be connected to a computer with a USB -RS232 adapter or a USB-RS485 adapter.

4 Modbus Simulation Software options

1. http://www.win-tech.com/html/demos.htm

This site seems to offer Modbus simulator and OPC tools. With the Modbus tool, there is an indication of a succesful connection. There is an evaluation version of the software downloadable. The full version is not free.

2. modbustools.com

There seem to be several Modbus simulators and polling tools offered here. This software is also not free. There seems to be a trial version that works for 10 minutes at a time for the first 30 days. This software includes options to log data to Excel and text files. It is unclear if there is confirmation of ‘good connection’ provided per the original question.

There is also an option create a custom frame which might be useful for testing and debugging purposes.

3. https://sourceforge.net/projects/qmodmaster/

This is a free, open -source project built on a framework called qt. New to me, interesting concept. There is a bus monitor to see live frames. The latest update was in February 2016. Seems promising mostly 4 and 5 star ratings from its 9 reviews.

4. http://www.schneider-electric.com/en/faqs/FA180037/

Finally, the software I have used for Modbus TCP testing. Schneider Electric has a free serial and Modbus TCP tester software. Unlike ModScan and some of the other options out there, this tool doesn’t include a live frame by frame view of communications.

In all cases, the option to automatically scan ‘live/open’ registers on a network didn’t seem to be something common on the market ( keyword:automatic). For Modbus networks with communications already up and running, the best bet would be to use a a communication viewer screen. This would show the frames on the network with addresses, commands and responses.

Link to the actual thread on PLCTalk.

PLC Programming Languages and Google Trends

August 6, 2016PAC, PLC, ProgrammingDrives & Systems

Based on Google Trends, ladder diagram seems to be the most searched language. However, past PLC programming trends are no indicator of future requirements.

Each language has its pros and cons. With most 61131-3 compliant environments, the great thing is that each part of a PLC program can be written with a different language. This allows for the usage of the right language for the right purpose or application.

PLC’s continue to have more features, and applications are increasingly applying these new features. Examples: Data handling with arrays, sequencing state diagrams, more math, … A ladder diagram is not a good way to utilize or apply some of these functions. Fortunately, the alternative is not too difficult to pick up.

What are some of the underlying factors that keep the ladder diagram preference going?

Ladder diagram is similar to a electrical control schematic with rails on each end. This makes it a easier for maintenance folks and electricians to troubleshoot it if the need arises.
A large proportion( PLC count) of PLC’s sold go into ‘simpler’ applications. These applications are covered by the small and mid-range PLC market. The applications may be start/stop, sequencing and boolean logic based for the most part. These are great application grounds for ladder diagrams.
Some PLC programming environments have a strong ladder editor. That combined with other features such as a live, animated view of the system when logged in with the ladder environment make it appealing. Other environments animate when logged in using any of the languages.
We all like what worked before. Even when it doesn’t work well enough anymore. Until we have to do something different to stay in business. And then change is imminent and accelerated.

Why will the industrial control world need more than ladder diagram moving forward?

Much more connectivity. PLC’s handle much more than just logic. They connect to other devices on the factory floor and at the plant level or even remotely.
Data handling. PLC’s today have sufficient memory to track and control thousands of data points. The tools to handled these data points are best applied in non-ladder languages. Example: Arrays, file handlers, math functions..

Based on the above evolutions in industrial control, the following points need to be considered:

Every language has its benefits, don’t get intimidated just based on familiarity.
Consider what needs to be done before picking a language
Stay open minded.

Ladder is good for viewing inputs and outputs and basic functions with triggers and timers. Structured text is good for math and data manipulation. Function block diagram is good for getting a graphical overview of a system. Sequential function chart is good for state based system organization. On larger PLC programs, all of them can be used for different parts.

The following Automation.com article covers the languages at a high level, with some details on pros and cons of each.

Going back to some of the other PLC programming trend observations

Interestingly, the term ‘structured text’ is strongly related to ‘CODESYS’ and ‘61131’ search terms. Note: The table embedded below shows the ‘Rising’ terms by default. Click on the ellipsis like button on the bottom right and select ‘Top’ to see the others.

Another interesting observation with regards to search cycles. July and December seems to be down-cycle parts on most years. Might it be tied to mid year and end year vacation times? Summer and winter breaks maybe?

On average, ladder diagram gets nearly double the search volume compared to structured text. This is followed by function block diagram which got about one third of the search volume relative to ladder diagram. Sequential function chart is a faraway fourth with about one tenth of the search volume relative to ladder diagram. Note, these are averages and there may be measurement errors due to exact search terms and various languages. Also, various vendors do have slightly different names for the languages compared to the IEC61131-3 names.

If you have a specific reason why you pick one language over another, leave a comment below.

PLC Program State Diagram : CASE Structures in Structured Text

July 30, 2016PAC, PLC, Programming, SystemsIEC61131-3, PLC Programming Patterns, Structured TextDrives & Systems

There are several ways to implement a PLC program state diagram. One of the best ways is using a CASE structure in Structured Text. This statement is specifically true for PLC programs that need to handle a state -to-multi-state system. The benefit of good state-based organization makes troubleshooting easier. It also helps with readability and maintainability of a program.

IEC61131-3 helps with organizing PLC programs

The IEC61131-3 software model helps the organization and sequencing. It defines the ability to ‘divide and conquer’ a larger system down to individual program units ( program organization units or POU’s in 61131-3 lingo). Also, the ability to have multiple tasks helps organize the sequence of the execution of program units. The standard also specifies Sequential Function Chart as the environment to organize a PLC program.

Having said that, if you are to build a sequence with a point -to-multipoint state diagram, a CASE structure in Structured Text is probably the most effective way to do it. We shall examine this in a little more depth.

Why CASE structure in ST?

When one state executes, all other states do not. This is unlike the ladder diagram environment where a rung is within the execution path even if the logic within it is not currently active.
Any state can be transitioned to any other state and vice versa.

Example:

PLC program sequence with multiple states — Some systems require for one state to be able to transition to multiple other options for states.

Example: While running, a machine has to operate several different sequences:

one sequence for when there is a power loss condition
a different sequence when a jam is detected
another sequence when an analog input goes below a threshold

This does not mean that the entire program has to be in Structured Text

One of the benefits of the 61131-3 standard is that each program organization unit can be written in a different language. The I/O interface can be written in ladder diagram. This helps maintenance folks provide the first line of troubleshooting by checking I/O statuses.The main program operation can be written with the step/state based Sequential Function Chart. The RUN operation with all the logic

There is much confusion on the internet and probably in perception among PLC programmers about which language is best for a step/state based program. Ladder diagrams have been around for a long time which has led to much bias towards it. Also, it is relatively easy for maintenance personnel to work with it. However, all facts considered, it is not the best for organizing a state based system. The preference for ladder ( besides the above points) is also strongly tied to the way one of the major PLC programming platform is/was structured.

Moving forward, a mixed programming language approach is best. It helps speed up troubleshooting and development of PLC programs. It also will cover better analytics and data handling in PLC’s with the usage of arrays.

What would a CASE structure for a Multi-State PLC Program Look Like?

The frame of one might look like follows:

Frame of a State Diagram with a CASE Structure in ST

There are going to be programmers who use SFC for state diagrams. Then there is a part of the community who ( for various reasons) will be using ladder logic. If there is a point to be made for any of these selections, submit your thoughts in the comments section below.