Ken Roach

Welcome to the MrPLC forum community ! As I wrote a decade ago, the "DeviceFailureRegister" is for the whole of the network, and is part of the DeviceNet Scanner's data table. It has one bit for each node. If your E3 Plus is Node 05, then the associated bit for the DeviceFailure status if Bit 05 of the Device Failure Register.

Was the greater part of Proficy in the power generation business, and the ordinary factory automation side was just a ride-along ? I'm not super enthusiastic about what most venture capital owners do to their acquisitions: when a business was built up out of parts, selling it off for parts is easy too.

Welcome to the MrPLC forum community ! Pulse test is good for detection of short-circuit or cross-circuit faults, of course. How are those other inputs set up ? What sort of safety devices are they wired to (or will be wired to) ? One common configuration is 2-channel parallel or 2-channel complementary. You can cause a fault for the function by transitioning only one of the channels.

Welcome to the MrPLC forum community ! When you say "holding registers" and preface them with a "4" that suggests Modbus. Do you have a Modbus interface module or gateway of some kind connected to the controller, or are you using the Modbus TCP add-on instruction ? In general when you use the COP or CPS instruction to copy a DINT into two INT[x] elements of an array tag, you set the Length value for the instruction = 2 (the number of destination elements).

Rockwell decided to append the label "5000" to some well established brand names to indicate that they're compatible only with the 5380 family of ControlLogix (1756-L8x) and the 5069 series of CompactLogix. Those are the only controllers that support 5069 "Compact 5000" I/O, and 5094 "FLEX 5000" I/O. Today I learned that 5032 is "ArmorBlock 5000", and is also in that category. The 1732 and 1734 products are based on the now 15+ year old POINT platform, so they have a lot more backwards and legacy network and controller capability. Similarly there is 1769 "Compact I/O" and 1794 "FLEX I/O" (a namplate that I started using in 1994). Ask me how I feel about the things that Ford calls a "Mustang".

FactoryTalk Optix has a very expansive online Help file, a whole GitHub community, and very strong participation in the RA "Engage" forums. Which it needs, because it's very complex and very new and very different from anything Rockwell has offered before. While this MrPLC forum is useful, you should definitely start with some of the existing resources. The YouTube channel and the examples hosted on GitHub are really good. https://www.rockwellautomation.com/en-us/products/software/factorytalk/optix.html https://engage.rockwellautomation.com/home https://github.com/FactoryTalk-Optix https://www.rockwellautomation.com/en-us/docs/factorytalk-optix/1-2-0/contents-ditamap.html

Alarming is a big topic in automation generally, and various Rockwell platforms have different methods, which users deploy to different degrees of sophistication. It's a lot less formal and pre-canned than a typical distributed control system. Even FactoryTalk Alarms and Events can be done a little differently in different platforms. A PanelView Plus typically polls tags in the controller, which have associated messages in the alarming system. A PanelView 5000, by contrast, connects using ALMA and ALMD instructions in the ControlLogix program. Do you have a big FactoryTalk View SE system with different PC-based clients in different places, or are some or all of your HMI's PanelView Plus terminals ? One of the things I see often overlooked is the simple configuration for filtering which alarm triggers are shown in a given Alarm Banner object on a PanelView Plus. But let's start by figuring out which flavor of Rockwell HMI you're running.

Welcome to MrPLC forum community ! Your program looks like it has about 20 relay outputs, most of them wired to solenoids of some kind. You say that "multiple" of them turned on simultaneously, and presumably they aren't supposed to. There is no logic that acts on the whole Slot 8 or Slot 9 output word, so if logic was the source of the malfunction you're going to find it in the code. Can you explain what you mean by 'the alarm bits lighting all the indicators" ? Do you mean alarms that are indicated on an HMI ? Your data file B11 is lengthy and describes Bit 0 of each 16-bit word as an "LED", some of which are labeled in a way that suggests an alarm indicator and are addressed in logic in your LAD6 -ALARMS routine. When you say there were no "stored faults", do you mean that the CPU was faulted when you found it ? Or that it wasn't faulted at all ? Was your injection molding machine running in automatic mode and processing material when the incident happened, or sitting in Manual mode ? It's not technically impossible for a 1746-OW16 module to malfunction all at once and close all of is relays. But it's not what the devices are designed to do, there's no configuration in software that you can make to cause it, and I've never witnessed it. Relays generally either "stick on", or they fail OFF.

I very strongly recommend that you post specifically where you live now, and what passport you hold. I'm not confident that you understand the electrical standards in Germany if you live in Samoa.

Block Transfer instructions are executed in the PLC-5 controller based on the pre-conditions on the ladder logic rung. Many PanelView systems use multiple BTR and BTW instructions, which the PanelView application differentiates by their size. If the BTR or BTW instructions "don't work", they will typically have an error code associated with them. You need to examine the logic for all of the BTR and BTW instructions configured for that PanelView and figure out which ones are completing with a /DN bit, and which ones are failing. Wiring that has been in place for decades can often look good visually but be corroded or loose or damaged. You may need to schedule some downtime to remove each off the RIO network cable terminations and make sure they are clean and tight.

Welcome to the MrPLC forum community. The PLC-5 and PanelView 1400e are at least 25 years old, so it is unlikely that the firmware has changed. Can you post screenshots or other information about the block transfer (both BTW and BTR) instruction logic ? Have you recently added or modified anything in the system, including adding additional block transfers to other devices ?

I have not done that with the 5069 platform, only with the 1756-OB16IEFS, and it's been a while. I think that the technique was to change the O.ScheduleMask to zeroes so that the outputs weren't part of the scheduled effect of the MAOC. Then we could have ordinary discrete logic control over them, and when we ran the MAOC again, it applied the schedule mask according to the Input DINT in the MAOC instruction. I could definitely be incorrect... it's been at least five years since I touched those machines.

I have not used that Zebra unit before, but at first blush this sounds like an RPI timing issue or just a mistake at designating the length. Does the Zebra provide some kind of "new data present" or handshake to let the PLC know that there's a new symbol decode string in the Input data table ? Do you execute that CPS instruction every single scan ? The Scanner.Data[x] SINT array is the Input tag itself, correct ? Do you know what the Zebra is set to do in the event of a bad decode ? I would take a step back and look at how the Input data changes when there's a new decode. You could also maybe troubleshoot by putting a "if .LEN >0" condition on the CPS instruction. Because the source is a simple SINT[x] array input tag, and the destination is an ordinary STRING, there shouldn't be any of the v36+ question about the length of data depending on the size of a UDT that's involved.

Welcome to the MrPLC forum community ! In that case in 2018, there was no "BCData.LEN" element because BCDData was a SINT[8]. So that's not really a question i can answer. Ideally, create a new thread and provide some details about your application. Because some modern ControlLogix firmware has changed the way that COP instructions handle dissimilar-typed sources and destinations, please post your firmware revisions too. When using barcode readers, the function that indicates that new data is present is important. Sometimes it's a handshake, sometimes an incrementing identfier, etc.

In the ten years since the last thread, the InView product line production and support has been taken over by Spectrum Controls. https://www.spectrumcontrols.com/product-category/inview-displays/

The "Home to Torque" feature does all of those steps automatically. Are you using that option, or rolling your own ?

Any time you're diagnosing software problems, think like a physician and do a patient history: What versions, what hardware, how long has the system been running, and what else changed recently ? Do you have a standalone SE system where the Client and Server will always be on the same computer ? Or do you have distributed clients that have to connect using various FT services to the server ? Apparent performance is certainly one way to diagnose problems, but also FactoryTalk and Windows have monitoring tools that can tell you the state of a service or an application. Do any error messages appear when you try to open a Client again ? What shows up in the FactoryTalk Diagnostics Viewer (often the lower pane in FTView Studio) ? Have you been working with RA Technical Support on the problem ?

The easiest way to figure out what Series of hardware you have is to look at the front of the controller. If there is white text reading "10/100" over the top of the Ethernet jack, it's a Series C daughtercard. The sticker on the side of the controller will also show the Series letter for the hardware and the firmware. I just pulled one out of my test rack that has Series C hardware and Series C FRN9 firmware, manufactured in May 2005.

Do you know the firmware revision of the controller ? Series C hardware and firmware after Series C FRN5 had an "enhanced" web server that allowed access to data tables and user-configured web pages, but the prior revisions had only very general status pages accessible via HTTP. I think the older versions could not be disabled. The Series letter and firmware revision numbers were very confusing with the SLC-5/05 when RA upgraded the Ethernet daughtercard and called the controller "Series C", and instead of calling it a new operating system (OS502 would have made a lot of sense) they called it OS501 Series C... which could also be loaded onto older Series A and Series B hardware.

There is not. You're describing much of the functionality of Studio 5000 Logix Designer. Why do you need to "extract" the program ? The text formatted versions of the logic diagrams and project configuration (*.L5K and *.L5X) will be a great deal easier for third party tools and libraries to process.

Did something change in the configuration for those two PowerFlex drives ? Were the drives replaced, or the 20-COMM-D modules replaced ? Could the node numbers have been swapped ? Error code 73 on any Allen-Bradley DeviceNet scanner indicates that there is a mis-match between the scanner's Scanlist records for the Identity object of the adapter drive (the AC drives) and the actual Identity object. Electronic Keying is implemented to ensure that the wrong device doesn't get controlled by the PLC just because it's been set for the wrong DeviceNet node address. If you are confident that the node numbers are correct and the PLC will control the correct drives, then you can fix this problem by disabling Electronic Keying in the 1756-DNB Scanlist, or by updating the electronic keying information in the scanlist to be sure it matches on the Scanner and the PowerFlex sides. That's done with RSNetworx for DeviceNet software.

Yup. Stick with Universal Coordinated Time (aka Zulu Time or Greenwich Mean Time) for the controller clock and any timestamps you record. Apply local offsets for reports or time displays. It's worth reviewing that the WallClockTime's 64 bit CurrentValue is UCT/Zulu. The WallClock Time 7-DINT object is also in UCT/Zulu... it's the LocalWallClockTime that's in local time format. I'm not totally sure what the CST object gives... is that always the time since boot ? I have recently been working on a project where I'm using both the PanelView 5000's built-in FTA&E alarm history log and a Raspberry Pi running Node-Red and a pylogix script. At first I was very annoyed to learn that the PanelView 5000 expresses all of the exported timestamps in UCT/Zulu, but then realized that means they're going to align with the Wall Clock Time CurrentValue timestamps I am capturing and uploading in bulk. Correlating the actual time that one of the events I'm analyzing occurred is straghtforward. I only have to convert the first and last timestamps into Local Time for my report. Meanwhile, across the factory, is a system that has ten Stratix 5700's doing NAT, and I'm trying hard to make the switch be the time master for the controllers (which also have 8x Kinetix each) and have the switches in turn get their time from a Windows 2012 Server instance that has NTP Server enabled. So far no dice; the switches apparently get their device time properly, but the 1756-EN3T and the 1756-L72S are trucking along pretending it's 1969.

I think that the DST check box affects only the UTC offset in the time that you are poking into the controller with the [Change Date and Time] button. It does not enable automatic Spring-forward/ Fall-Back changes of the controller's WallClockTIme at the appropriate US dates and times. Or, checking or unchecking the checkbox it is like changing the hour in the Date and Time field and clicking that same button; it makes the change in the controller only if you're online. As far as I know, none of the A-B controller families that have clocks will automatically advance or reverse for Daylight Saving. You would have to change the WallClockTime object by 60,000,000 microseconds in your program at the appropriate early Sunday morning. Today I've been working with a bunch of different timestamps from machines in France and Washington, and frankly I'm so tired of wondering what the offsets are supposed to be that I'm ready to use Zulu time for everything.

FCS and Checksum errors on a network module are virtually always related to noise induced on the network cabling, or damage to that cabling. They are not due to timeslice or CPU utilization considerations. Increments of one or two a day is normal. Thousands per hour is interference, especially if they're causing connection failures. The fact that the error counts are reduced when you reduce the frequency of packet exchange is just because there are fewer total packets being exchanged. If you're getting checksum errors on the ControlBus 1756 backplane, that's could indicate noise on the ground plane or generalized electrical noise around the system, rather than in the Ethernet or ControlNet networks. I had a little experience with ControlLogix in a detention center environment. The vendor wanted me to prove that the ControlNet wouldn't cause the I/O devices to fail ON if someone put 277 volts onto the cable, and was not convinced by the user manuals or industry certifications. So we did: 480v 3-phase, one leg connected to the ControlNet trunk conductor. It smoked the 1756-CNB immediately, but the CPU and the local I/O were well protected by the backplane isolation and kept on running.

Is it too late to say "don't do it" ? Cyclic I/O runs data back and forth regardless of the change of status or payload, and fixed-site cellular data plans can get expensive in a hurry. Makers of RTUs and other telemetry equipment have been trying to economize on data via report-by-exception and other protocols for decades. It's entirely possible that your cellular connection doesn't support UDP, even unicast UDP. Check to be sure that both TCP and UDP ports 2222 and 44818 are open and available. In Windows, PING isn't enough because it only tests ICMP. Instead, I like to use the Windows PowerShell "test net-connection" (tnc) command, which lets you specify the TCP Port number to test.