Hello everyone! Let me delve deeper into this topic. Imagine a scenario similar to tracking a part on a fast-moving conveyor belt. I utilize a High-Speed Counter (HSC) to receive encoder input and increment a value. The Sequential Timer Instruction (STI) set to 1 ms manages all tracking logic in real-time. Additional tasks such as reading sensors, capturing inputs, and setting outputs are handled within this 1ms timed interrupt loop. To optimize performance, I limit the number of bit shift events to 1000 per minute due to PLC limitations. Various techniques are implemented to ensure this loop remains under 1 ms. Unfortunately, replicating this setup in the Compact or Control lines presents challenges due to differences in I/O structures. Despite these obstacles, I am eager to explore the possibilities offered by the advanced 5000 series functionality.
Hello everyone! Let me provide a more detailed explanation. Imagine tracking a part on a fast-moving conveyor belt using a High-Speed Counter (HSC) for encoder input incrementation. To handle the tracking logic, I utilize a 1 ms Single Time Interval (STI). By incorporating bit shifts, I can monitor presence, pass, fail, and more efficiently. During the 1 ms timed interrupt, I capture inputs, read sensors, latch on bits using indirect offsets, and calculate output states. To comply with PLC limitations, I limit bit shift events to 1000 per minute. Implementing various techniques, I ensure the loop remains under 1 ms. I'm exploring ways to replicate this process on Compact or Control lines. The challenge lies in the I/O bus setup and the absence of sub-millisecond HSC events and immediate I/O functionality. Perhaps considering PLCs with faster scan times could eliminate the need for workaround solutions and maximize the 5000 series capabilities.
Utilizing the High-Speed Counter (HSC) for quicker input pacing events compared to the Programmable Logic Controller (PLC) makes logical sense. It seems plausible that a similar approach could be successful in the CompactLogix/ControlLogix systems, as long as these PLCs are capable of driving a 1ms Single Timer Interrupt (STI). By streamlining the high-frequency interrupt routine through index updates to model stationary conveyor belts and moving frames, the code complexity can be minimized.
One potential challenge with Logix PLCs is the asynchronicity of their I/O with the continuous program scan, resulting in interruptions and value changes during program scans. However, this issue can be managed through buffering. If you are already familiar with managing STI routines in MicroLogix, you may find a similar solution applicable here.
An alternative to STI is having the HSC trigger an interrupt routine each time the accumulator reaches a small preset value (such as 2 or 3), resetting the counter value to 0. Additionally, the Event Interrupt (EII) feature can be used to call an interrupt routine on the rising edge of high-speed inputs, similar to the HSC Interrupt with a preset of 1.
When it comes to ControlLogix and CompactLogix, there are limitations to consider. While CompactLogix only supports Instruction Event Interrupts, ControlLogix offers support for Motion, Consumed, and Data Change on an Input. It is possible to set up Periodic tasks to run as frequently as .1ms, but caution must be exercised to prevent task overrun. The logic executed in the Periodic task should have a scan time shorter than the periodic value. For example, if a .1ms periodic is set, the logic execution must be less than .1ms, worst-case scenario. However, overcoming the RPI limitation of the CLX/CPLX backplane remains a challenge. Even the 1756-HSC card has a minimum 2ms RPI, meaning the controller only polls the HSC card for data every 2ms.
drbitboy: I am unclear on how updating an index functions. Is there a reliable resource you can recommend for further information? In the past, I encountered a problem using the HSC interrupt directly, as the encoder would occasionally move too quickly, leading to PLC faults. However, with STI, the speed is limited to 1000 IPS, reducing the occurrence of faults. It is possible that the Compact/Control Logix now have quicker I/O scan times. I will need to investigate this further. Thank you for your insights. Please advise on utilizing the index and any additional information you may have. Larry
Thank you, robertmee, for addressing my specific concerns regarding Allen Bradley/Rockwell products. I have sought direction from our representative in the past, but your explanation is much clearer. I was hopeful for a faster version of the 1400 with implicit EIP capabilities, though it seems that they may be phasing out in favor of the 800 series. Unfortunately, the 800 series lacks several functions that are essential for my needs. Larry.
Larry Wright expressed gratitude towards Robert Mee for providing specific solutions to his concerns regarding Allen Bradley/Rockwell products. Despite hopes for a faster version of the 1400 with implicit EIP, it seems that the 800 series may be phased out soon. However, the 800 series lacks some essential functions needed by Larry. One key question arises from the description: how do the encoder counts move within a 2ms timeframe, and could this pose a challenge? It is possible to run a periodic task every 1ms, but the data from the HSC would update at a slower rate. The HSC offers four immediate outputs for tasks like cam control, which operate faster than the 2ms limit. Integrating them with an Input module set to COS (change of state) could provide instant data updates in memory without waiting for the RPI. While there may be potential solutions through various settings and modules, achieving the same ease of use as the ML1400 may not be as straightforward.
In a forum post, user LWright responded to user drbitboy's question about updating an index and shared a link to an old thread that may provide some guidance. The discussion revolves around modeling products on a conveyor using an array of 20480 bits on a MicroLogix PLC.
Each bit in the array represents a discrete position on the conveyor, with the 20479th bit symbolizing the upstream end and the 0th bit representing the downstream end. The values of the bits indicate the state of the products on the conveyor, such as detecting broken bottles.
The process involves shifting the bits when the conveyor moves, simulating the movement of products relative to the conveyor frame. Stations along the conveyor, like an inspection station or a reject/divert station, have fixed positions relative to the frame.
One approach discussed involves using variable indices to represent fixed positions relative to the conveyor frame, updating an END_INDEX variable to track the movement of the conveyor frame. This method simplifies the process by incrementing the END_INDEX value and calculating absolute index values for specific positions on the conveyor.
Overall, the key concept is to use fixed indices to represent positions relative to the conveyor frame, allowing for efficient modeling of product movement on the conveyor system. This approach eliminates the need to shift all 20479 bits at every shift event, streamlining the code execution process.
To enhance efficiency and accuracy in tire sorting systems, consider creating a memory map for each conveyor and utilizing an encoder to control a pointer within the map. This method was successfully implemented in a complex PLC-5 system for tire sorting in the past. By incorporating offsets for different tire drop locations along the conveyor, new data could easily be integrated into the map as tires entered the system. Photocells were strategically placed at the end of each section to facilitate data retrieval for each tire and its transfer to the succeeding map.
The resolution for the map was set at 1 foot, with each integer element representing a foot of conveyor space. When a tire entered the system, its drop offset was added to the encoder-driven pointer, adjusted to the nearest foot. As tires exited a section, the data corresponding to the nearest value within three elements in the file was transferred to the next section before being cleared. To ensure smooth operation, the pointer would wrap back to the beginning when it exceeded the section length.
Though challenging to explain, this method can be better understood through visualization. It offers a simpler and efficient solution compared to other methods, even for high-speed systems with a more detailed map. Consider implementing this approach for improved tire sorting efficiency and accuracy.
Robertmee provided valuable insight into the incremental range and pulse timing. By expanding to 2ms, the range per pulse could potentially increase to 1.6mm, which could be a viable solution. However, there were concerns with the increased time delay for the I/O when adding expansion modules in the past. This required 3 or 4 modules to address. These factors will need to be taken into consideration moving forward. Thank you for the input.
Thank you drbitboy and OkiePC for your assistance. I need some time to fully understand this feature and how it could potentially benefit me. For a visual demonstration, you can watch some older videos of the process on LinearGS(dot)com.
Moreover, a key benefit of implementing the variable index technique proposed by OkiePC and myself is that it allows for flexibility in handling potential missed counts of the High-Speed Counter (HSC) by the Programmable Logic Controller (PLC) during scans. By simply increasing the END_INDEX by the inter-scan count increment (e.g., 2) instead of by 1, any missed counts can be easily accounted for. While this approach may result in some gaps in the data, such as discrete bits from camera inspections with a value of 1 not being recorded, this can be mitigated by using a pulse stretcher on the input. Additionally, it is advisable for the code to write multiple values of 1 to the array near the inspection station, as adjustments may need to be made based on various unpredictable delays. This fine-tuning process is typically done through empirical adjustments to optimize performance.
In conclusion, that is the gist of it!
I echo the sentiments expressed in the video about the challenges faced by the PLC due to being overwhelmed. I have experience in developing real-time operating systems (RTOS) and kernels, utilizing linked lists on a microprocessor to effectively manage delays. This is a crucial aspect of how RTOS function, utilizing timer/clock or encoder counts to keep track of delays.
- 09-01-2025
- Peter Nachtwey
In some aspects, ControlLogix and CompactLogix have limitations. While CompactLogix only supports Instruction Event Interrupts, ControlLogix offers support for Motion, Consumed, and Data Change on an Input. It is possible to configure Periodic tasks to run as frequently as .1ms, but it is important to beware of task overrun. The logic executed in a Periodic task must have a scan time shorter than the specified periodic value. For example, if a .1ms periodic is set, the logic must execute in less than .1ms at worst. However, it is challenging to work around the RPI limitation of the CLX/CPLX backplane, as even the 1756-HSC card has a minimum 2ms RPI. This means that the controller only polls the HSC card for data every 2ms. Some Compactlogix models (such as the 1769-L1 series and the 5069-IB16F) support limited Input interrupt events, but similar to CLX, they require a minimum of 2ms.
It seems that my work is truly one-of-a-kind for Rockwell to no longer support this feature. The website displays videos of components being monitored by the ML1400. I am contemplating a shift to an FPGA or microcontroller if feasible. Peter Nachtwey: I am in favor of the RTOS strategy. Thank you.
In response to LWright's comment about Rockwell discontinuing a certain functionality, Peter Nachtwey suggested looking into FreeRTOS as an alternative. Implementing a Real-Time Operating System (RTOS) can be complex, so utilizing a pre-written one like FreeRTOS is recommended. The RTOS organizes future events in a linked list, with the lowest encoder count event being prioritized. This efficient approach allows for motion controllers to run at 1ms updates with the advancement of low power 32 bit ARM chips. Additionally, options like the propeller chip or a commercial package such as LynxOS may also be suitable for implementing an RTOS system. Explore LynxOS as it offers a reliable and cost-effective solution with a long-standing presence in the market.
- 09-01-2025
- Peter Nachtwey
In a recent discussion, LWright shared their approach to tracking logic using an STI set with a 1ms timeframe. By employing bit shifts, they can effectively monitor presence, pass, fail, and more within this short interval. One question raised was whether, within a single 1ms STI event, LWright occasionally shifts the array of bits by multiple positions.
Larry, a forum user known as LWright, raised an issue regarding tracking utilizing an encoder and bitshift register with a Compact or Control Logix PLC. Several years ago (>5), attempts to use these PLCs were unsuccessful due to I/O scan time limitations compared to the ML1400. The ML1400 can track over 300 objects at a rate of up to 1000 increments per second with 20480 bits (5 x 4096). Additionally, the system features multiple attached devices for time and distance event checks. The goal is to maintain a 1ms cycle time and potentially increase the number of shifted bits. Has anyone achieved this successfully? Overcoming the I/O limitation and receiving guidance on implementing this in a Compact or Control Logix PLC would be greatly appreciated. Thank you, Larry.
Adding unnecessary information to the conversation, an option is to link a Compact or ControlLogix HSC module's inputs to an EVENT trigger in Logix, which leads the processor straight to the EVENT task handling code without any additional steps or financial gains involved.
Injecting some interesting facts into this discussion, it is possible to link a Compact/ControlLogix HSC module's inputs to an EVENT trigger in Logix. This setup will prompt the processor to immediately execute your designated EVENT task handling code. The Event trigger is dependent on the Tag value from the module, which is updated according to the RPI value. However, there may be a delay of 2ms or more between the actual input and the Tag value. Furthermore, when dealing with the encoder channel of the HSC, the pulse rate could change more rapidly than the execution time of the event task. This can lead to the triggering of multiple event instances before the initial one is processed, resulting in task overruns and minor faults. If you have any suggestions on how to circumvent these issues, please share your expertise.
Robertmee mentioned that the Event trigger is still dependent on the Tag value from the module, which is impacted by the RPI Update. The Tag lags the actual input by at least 2ms. Furthermore, if focusing on the encoder channel of the HSC, the pulse rate may change faster than the execution time of the event task. This could result in multiple instances of the event being called before the first one is processed, leading to task overruns and minor faults. If there are suggestions on how to prevent this issue, any guidance would be appreciated.
It appears that @JeremyM is recommending that the PLC should identify the interrupt at the rising edge and only perform minimal processing in the triggered interrupt task routine, such as incrementing the base index in the circular array and handling wraparound before exiting. Beforehand, in the continuous task, it is advised to buffer (CPS*) the current base index to prevent interruptions from causing disruptions.
Additionally, it is worth noting that the 2ms RPI may establish the time resolution limits for any approach. In a previous experience with the MicroLogix 1400, it was observed that the code utilized the "immediate input" of the HSC count, which potentially bypassed RPI limitations. This methodology is reminiscent of thread coding in Linux/Unix systems, where a deep understanding of the hardware and operating system is essential, albeit the process can become intricate and complex rapidly.
By utilizing immediate I/O for rapid data reading and writing, as well as performing bit shifting and logical operations, it is feasible to prevent PLC faults caused by tracking logic delays in the ML1400 model, which typically takes 1/2 to 3/4 of a millisecond. By capturing moves faster than 1 ms using interrupt-based add functions, I am able to efficiently process each move within the 1 ms STI period. This approach ensures that sufficient processing time is allocated for the PLC to complete its regular scan, minimizing the risk of program interruptions.
The 1ms STI routine analyzes the variance in HSC count since the last STI event and incorporates this variance into an accumulator. Subsequently, the continuous task gradually decreases the value in the accumulator to zero by decrementing it with each shift operation. Does this explanation align with your understanding?
In a discussion about PLC interrupts, drbitboy agreed with @JeremyM's suggestion that the PLC should be able to detect interrupts at the rising edge and perform minimal processing in the triggered interrupt task routine, such as incrementing the base index in a circular array and handling wraparound before returning. However, it is important to note that the HSC card only has the encoder pulse train as an input. Even if the input change was not bound by RPI, the frequency of the A/B channel may exceed the possible event task scan time. The frequency of the encoder is a crucial factor that needs to be considered. Implementing an event task on the HSC encoder input change would essentially create a 2ms periodic event, as the event would only detect a change at the RPI interval. Setting periodic events themselves to less than 2ms would not provide any speed advantages for the HSC event task. The only potential benefit would be increased utilization if the machine is not running and the HSC card is not experiencing any changes.
We appreciate your input regarding the RPI limit and the potential I/O limitations in the Micrologix system. With a 2ms HSC interrupt and considerations for data synchronization, it's essential to understand how input and output delays can impact the overall performance. The immediate input and output instructions on the ML1400 offer direct I/O to the controller, reducing the need for I/O scan considerations. Expansion I/O on the ML1400 is also subject to the cycle time of the I/O scan.
JeremyM, thank you for sharing the informative content found on "https://rockwellautomation.custhelp.com/." According to the information provided, the embedded I/O on certain CompactLogix controllers supports COS, including the 1769-L16ER-BB1B, 1769-L18ER-BB1B, 1769-L18ERM-BB1B, and 1769-L19ER-BB1B models. I plan to delve deeper into the concept of "embedded I/O" as it could potentially align with my current requirements.
Achieve a lot within a 5000 program cycle. The key concern lies in the IO module's RPI, rather than the program scan time. Ensure your Event task efficiently manages the response to a detection. It's worth noting that a 1400 is utilized for optimal performance.
JeremyM discussed the potential capabilities within a 5000 system, highlighting the importance of the IO module's RPI over program scan time. In the Event task, responsiveness to detections can be effectively managed. However, utilizing a 1400 system may pose challenges in achieving a 1ms data update requirement due to the minimum 2ms RPI constraint. Additionally, continuous pulsing at 10KHz from HSC's local address as the encoder input may result in task overrun issues.
Hello everyone, I have predominantly worked with a ML1400, and I am pleasantly surprised to discover that it excels in one aspect compared to more costly models. Even Rockwell - Allen Bradley representatives assumed the same, but none have been able to provide assistance. It could be the terminology confusing me, but I am intrigued by the potential of "embedded I/O" featuring the "IIM" (Immediate) instruction on the I/O. It seems that only the "embedded I/O" models support "in which (Change of State) is supported", and I have yet to delve into this further. I am considering exploring JeremyM's suggestion of using an input to trigger an event, although I am unsure of how that would function. Despite my uncertainty, I am determined to investigate further and explore the potential of the RTOS system. Larry.
Hello everyone, I am amazed to discover that the ML1400 outshines pricier models in a particular aspect. Despite the assumptions made by Rockwell - Allen Bradley representatives, none have been able to assist me with this. I believe the terminology may be causing confusion, but I am curious about the unique capabilities of the "embedded I/O" in terms of the "IIM" (Immediate) instruction. It seems that only the "embedded I/O" models support "in which (Change of State)", which intrigues me. While I haven't had the opportunity to delve into this further, I am considering JeremyM's suggestion of using an input to trigger an event. I will explore this concept to better understand its functionality and also evaluate the RTOS system.
Unlike the need for a universal backplane design in other models, the ML1400 stands out for its embedded and streamlined design specific to the MicroLogix. The CLX L7 and L8's, on the other hand, cater to larger processes, motion control, and multi-device control, making them enterprise solutions. This distinction is akin to comparing a formula 1 car to a vehicle suited for a demolition derby. Each serves a unique purpose based on its design and capabilities.
In a discussion, robertmee pointed out a potential issue with the RPI for the 5069-HSC module, highlighting the need for a 1ms update on data. The local address from the HSC serves as the encoder input, posing a challenge if the encoder pulses at 10KHz. This could lead to task overrun. It's important to note that the minimum RPI available for the 5069-HSC is 0.2 ms, and the address struct holds the configured event output data, not raw pulses.
I would love to see a "thumbs up" or a "thank you" feature added to the platform. It would be great to have more interactive options for expressing gratitude and approval.
LWright mentioned that the ML1400 surprisingly outperforms more expensive models in a specific aspect that even the Rockwell - Allen Bradley representatives were not aware of. The "embedded I/O" feature may hold the key to its unique capability, possibly allowing for the use of the "IIM" (Immediate) instruction on the I/O. Further research is needed to fully understand why only the "embedded I/O" models support "in which (Change of State) is supported". Following JeremyM's suggestion of using an input to trigger an event could be a potential solution, although the mechanics still need to be explored. Additionally, considering the RTOS system may provide further insights.
The suggestion is to configure the HSC module's properties for the lowest RPI possible, ideally 0.2 ms. It is recommended to install the card close to the processor to minimize data travel through other IO cards' backplane ASICs. For more configuration options, refer to page 32 of the manual: https://literature.rockwellautomation.com/idc/groups/literature/documents/um/5069-um006_-en-p.pdf
Moreover, the card itself includes 4 outputs that can be programmed to react based on predetermined conditions, eliminating RPI worries. This allows for a separate device to await a single 24V signal and take action accordingly.
If you're seeking adventure, consider implementing a Compact 5480 system and wiring the HSC output to the controller's UPS 'B' input. Set up a highly regular periodic task, utilizing the GSV function with specific parameters such as HardwareStatus and UPSBuffering. This will trigger an event task tied to YourTag, ultimately eliminating the need for RPI altogether.
In a forum thread, JeremyM pointed out that the lowest achievable RPI for the 5069-HSC module is 0.2 milliseconds. The address struct holds the programmed event output data, rather than a raw pulse signal. The 1756-HSC module, on the other hand, has a minimum RPI of 2ms. To address this issue, consider setting up an output to a specific count (previously discussed) and linking it to the event for a potential solution. Thanks for highlighting the difference in RPI between the two versions.