Hello everyone, I am facing an issue with a system that has two encoders from different manufacturers connected to two separate 1734-VHSC cards on different nodes within the machine. Every 1.3 to 1.5 seconds, the cards register a double count. This means that the count goes from 4000 to 8000 and then back to 4000 on the next scan. The trends show a consistent pattern until this interval, where there is a sudden spike in the count. I have experimented with various filter settings on the cards, but they only result in the cards stopping the counting process altogether. Adjusting the RPI and routine periods has also been unsuccessful in resolving the issue. When the RPI and routine periods match, the intervals are consistent. However, when they do not match, the system behaves erratically and produces double counts at random intervals. Current system configuration: - Processor: 1756-L72S V.30.11 - Rack Comms: 1756-EN2TR - Cards: 1734-VHSC24 in separate nodes with 1734-AENTR communication modules - Card RPI: 50ms - AENTR RPI: 20ms - Routine periods: 50ms - Encoder 1: Beta LaserMike laser encoder set for 10k pulses per foot - Encoder 2: Dynapar 10k PPR rotary encoder with 4.25" diameter wheel
Looking for the best practices for encoder signal wiring? Learn about encoder wiring tips from Dynapar here.
The encoders are connected to inputs a, a not, b, and b not. The cards are configured for encoder x1, with a roll over setting of 16777216, a preset value of 0, and an attenuator set to 1. This same setup is also applied to x4. Initially, I tried using x1 due to its capability of handling frequencies up to 1Mhz, while x4 is limited to 250Khz. Shielded cables are utilized for connecting the encoders to the cards. One of the cables used is a factory-made AMCI cable for the dynapar encoder, while the other cable for the laser encoder is a Belden cable with 3 shielded pairs. The wiring is positioned away from any 480v lines and servo motors to avoid interference. The laser encoder is connected to a dynapar splitter card, which then sends the signal to both the VHSC card and a flying cut off controller. The cut off system is functioning properly. Despite observing periodic spikes on both encoders, I suspect that the issue may not be related to electrical noise but rather a communication setting problem.
Have you disabled the default AC 50hz filter? This setting can lead to inaccurate counts at higher speeds. If direction sensing is not required, try switching to Count mode to troubleshoot the issue further.
I turned off the filters because the card stops counting when any filter is activated. I will test the count mode on Monday. The direction is not important, as I just require the speed and distance data.
Welcome back to the PLCTalk forum community! When the RPI and routine periods are in sync, the system operates smoothly. However, if they don't match up, the system can become erratic and result in sporadic double counts. The primary function of the 1734-VHSC modules is to accurately count up to a specific pulse number, typically representing a distance, and quickly activate onboard outputs. Alternatively, they are proficient at measuring rates. Due to only reporting accumulated values via the module RPI, these modules may not be ideal for most distributed motion applications and do not support true "motion control" with CIP Motion. Regarding the Card RPI (50ms), AENTR RPI (20ms), and routine periods (50ms), it is crucial to focus on the module DPI and routine for effective operation. Adjusting the RPI for both VHSCs to 25 milliseconds or less may help ensure a data update between routines. Utilizing the Copy Synchronous (CPS) instruction to transfer data into a UDT before running logic can also improve performance. Additionally, incorporating GSV instructions to monitor EntryStatus for the 1734-VHSC modules every 5 or 10 ms can help prevent connection issues. Setting up a mirrored Ethernet switch port and using Wireshark to analyze traffic on one of the 1734-AENT adapters can identify any glitches in the data transmission process. by analyzing the EtherNet/IP traffic, any frequency of glitches can be easily identified.
From the symptoms you're describing, it does seem like a possible synchronization issue caused by the RPI mismatch you mentioned. This might be triggering the double count spike you're observing. It's generally advisable to have the RPI of your communication module match or exceed the RPI of your cards to reduce potential interruptions or inconsistencies. Additionally, it might be worth double-confirming that both encoders are correctly configured and providing input at the expected rate. If this doesn't solve the problem, perhaps consider looking into possible software bugs or hardware faults with the cards themselves.
This is an intriguing issue. One possible point of investigation could be the encoder's pulses per rev (PPR). The Beta LaserMike and Dynapar having different PPR settings might cause a conflict when syncing up with the 1734-VHSC cards, leading to the double counting. I would also examine any grounding aspects, as discrepancies can sometimes cause intermittent spikes. Though less likely, have you ruled out any chances of time synchronization errors occurring between the two nodes in your system? It's not unheard of for inconsistent timing to result in lurches or jumps in count values.
It's interesting that you're seeing this consistent double count pattern. One thing I noticed is the mismatch between your card RPI and AENTR RPI. The RPI of the card is higher than the AENTR, potentially creating a bottleneck situation causing double counts during fast scans. I'd suggest matching the RPIs or even trying a lower RPI on the card. Additionally, verify your encoders' setup matches the specified pulse counts and check for any sort of electrical noise that may interfere with the signals.
It sounds like you’re really digging into this issue! Double counts can be tricky, especially with different encoder types and those RPI settings. One possibility to consider is whether there’s any electrical noise or signal interference between the encoders and the VHSC cards since that can cause erratic behavior. Have you tried isolating the encoders’ power sources or using shielded cables? Also, if it’s feasible, checking the physical connection and making sure they are all secure might help rule out any loose contacts. Just a thought, but sometimes the simplest solutions can lead you in the right direction!
It sounds like you're dealing with quite a tricky situation there! The consistent double count at regular intervals is definitely puzzling, especially since it seems tied to the RPI and routine periods. Have you considered checking the wiring and potential interference between the signals from both encoders? Sometimes, issues like crosstalk or grounding problems can introduce unwanted noise. Also, since the encoders are from different manufacturers, it might be worth diving into their specs to ensure they are compatible with your VHSC cards, as differences in signal timing or electrical characteristics could lead to those spikes you’re seeing. Good luck troubleshooting!
✅ Work Order Management
✅ Asset Tracking
✅ Preventive Maintenance
✅ Inspection Report
We have received your information. We will share Schedule Demo details on your Mail Id.
Answer: Answer: The double count issue could be a result of mismatched RPI and routine periods, leading to erratic behavior and double counts at random intervals.
Answer: Answer: Experiment with different filter settings on the cards, ensure the RPI and routine periods are matching, and check for any inconsistencies in the system configuration.
Answer: Answer: No, the double count issue is not a common occurrence and usually indicates a specific configuration or synchronization problem within the system setup.
Answer: Answer: The use of different encoder types, such as the Beta LaserMike laser encoder and Dynapar rotary encoder, could contribute to the double count problem if their pulses per revolution (PPR) settings or wheel diameters are not properly synchronized.
Join hundreds of satisfied customers who have transformed their maintenance processes.
Sign up today and start optimizing your workflow.