Ken Roach

MrPLC Member
  • Content count

    2776
  • Joined

  • Last visited

Everything posted by Ken Roach

  1. 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.
  2. 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.  
  3. Allen Bradley CRC Errors

    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.
  4. 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.  
  5. Buy a stack of new MicroLogix 1400's and plan to keep the processes running indefinitely. If your processes are critical and cannot have downtime, and your client won't even pay for network cabling, leave the control system alone.
  6. If you have an SLC-5/04 (not an SLC-5/03) controller with a free serial port that's still set up for good old DF1 Full Duplex, it is relatively straightforward to enable DF1/DH+ Passthrough and perform upload/download to PanelView Standard terminals on DH+ via a physical connection to the RS-232 Channel 0 serial port. The only two important steps are enabling DH+ Passthrough in the Status file of the SLC-5/04 (S:34/0 and S:34/5 = 1), and changing the Device Type in the RSLinx DF1 Full Duplex driver from point-to-point to "KF2/KE".  
  7. The bad news is that rejected configuration parameters involving Rockwell's own module profiles are hard to troubleshoot.  Third party module profiles, doubly so ! With no extended error code, that suggests to me that there's maybe an identity or compatibility issue. Let's double-triple-quadruple check to be sure that the module profile matches the actual device.   You described it as a ProMag 400, and the module profile shows that it's configured for Firmware version 4.001. You posted a serial  number, " T711F49000".   The fifth screenshot shows a serial number "001AEA4A".   What does the web interface or a right-click in RSLinx Classic / Device Properties tell you about the firmware and serial number ? The IO connection fault is occurring when the controller sends the Configuration data block to the device, the Flow_MS_HSEast:C tag.    That configuration data assembly gets filled in when you configure devices offline and save the project.   I assume you've saved the Studio 5000 project then re-downloaded the program and cycled power to the ProMag. Do you have access to a network tap or mirrored switch port and Wireshark, to try to intercept exactly which parameter or object is being downloaded when the ProMag refuses the parameter setting message from the CompactLogix ?  
  8. This probably is not possible with the EX600 and SLC-5/05.    The SLC (and the Ethernet-equipped MicroLogix 1100 and 1400) do not support I/O connections on EtherNet/IP like the ControlLogix/CompactLogix family controllers do. If the EX600 has a mechanism to kludge a timeout or send explicit messages, you will also need an SLC-5/05 that is new enough to support Ethernet Explicit Messaging (EEM). I'm wonder if I've got any EX600 stuff in the thrift shop shelves....
  9. There is an "Add On Graphic" example in the RA Knowledgebase for the  PanelView 5000 platform: https://rockwellautomation.custhelp.com/app/answers/answer_view/a_id/1093164/loc/en_US#__highlight The document ID is QA58715, and you do need a TechConnect contract to see it and download the example code.
  10. ACD TO PDF

    Welcome to the MrPLC forum community ! That *.ACD file is for a 1769-L33ER controller with v32 firmware.   That happens to be a version I don't have installed, so I just let Studio 5000 open it and convert it to the newer version before generating a PDF report. My guess is that this is a controller for a Char Technologies (Toronto) reverse osmosis water purification system.  It's a very well-organized and structured program. The maximum attachment size on this forum is 3.91 MB and even zipped the PDF is 14+ MB.   Send me your e-mail address via the Messages feature and I'll e-mail or DropBox/Google Drive it for you.
  11. Thank you very much for those photos.    While the wiring is slipshod at best, at least it shows the pinouts !    The 1746-BAS has a 1980's vintage Intel 8051 microcontroller running a BASIC interpreter.  It has three serial ports and a bunch of custom routines for accessing DH485 networks and the backplane data interface for the SLC-500. One very popular use of that module is what you see here:  it is almost certainly polling a multidrop RS-485 wired network on PRT2.  The installers obviously used the same Belden cable for the RS485 network as they had on hand for DH+.   And that's fine:  it's ordinary shielded twisted pair, and low-speed RS485 is very forgiving.  When the jumpers are set for RS-485 mode, Pin 1 is Data(-), Pin 9 is Data(+), and Pin 5 is Data Common, and that's what pins are connected in the plug on PRT2. The most popular protocol for this purpose is good old Modbus RTU.    Prosoft sold a version of the 1746-BAS with their own firmware in it, and I wouldn't be surprised if you found a Prosoft chip stuck in an A-B labeled module. Honeywell, of course, has made hundreds of different models of controller that fit in a DIN cutout like that.   The odds are good that it does run Modbus RTU, but of course you'll have to identify it to be sure. There are dozens of ways to poll a Modbus RTU network with a ControlLogix.   The easiest-to-use are probably Real Time Automation's gateway, or the Spectrum Controls Universal Gateway.   If you told me "I don't know what protocol it will be on RS485 but you need to order the parts today" I would buy a Red Lion DataStation, because of their very broad range of serial drivers. To connect to upload this program, you'll need an ordinary serial terminal and an RS-232 cable.   Good old Hyperterminal or RealTerm will work.   You're literally going to send a Control-C to interrupt the program, LIST to make it print the BASIC program to the console (where you will copy/paste it to a document), then RUN to put it back in operation.
  12. ENBt and EN2T fw compatability

    I would need more details about the type of "interlocking" and the nature or symptoms of the communication failures to guess. Most features that the 1756-ENBT version 4.x firmware supported are also supported by 1756-ENBT version 6 firmware.    Certainly ordinary MSG instruction and Produced/Consumed Tags would be supported.   I might expect some issues if one of the systems is ControlLogix Redundancy. You can read up on the details in the Release Notes: https://literature.rockwellautomation.com/idc/groups/literature/documents/rn/1756-rn591_-en-p.pdf Sometimes I have found that when you configure two devices and make a configuration mistake, you can mis-attribute it to the firmware revision, not to the mistake or difference in the configuration.    Or there's really a bug !
  13. The only Studio 5000 family controllers that support real "Redundancy" are the 1756 ControlLogix, when equipped, configured, and programmed properly with the appropriate firmware, network modules, network architecture, and Redundancy Manager modules. There have been some attempts over the years to implement "hot backup" with ControlLogix and CompactLogix.   I am aware of a Application Technique document for High Availability CompactLogix that was last updated as version 4.0 about five years ago that used 1769-L30ER and 1794-AENTR products and architectures. The document and the accompanying "hot backup tool" code generation software is not publicly available.   You can only get it from a Rockwell Automation sales office, and only if you are approved by them and their country manager and/or Commercial Engineering at RA. Support for those systems is only available through the local field sales office that approved you to use it.    You are correct to be looking at the Fault Action configuration for the 1794 FLEX Output modules;   they should be able to be set for Hold Last State during a Fault condition.   Remember that Program Mode and Fault Mode are separate settings for FLEX I/O. Testing it is simple: set up a single-controller system with FLEX outputs configured to hold last state during a Fault, set some of them = ON, and unplug the CompactLogix.    If they work correctly and stay on when their connection is faulted, then the problem must be when they go back into RUN mode. Also remember that you must use a direct Module connection to each Input and Output module;  "Rack Optimized" connections to the FLEX adapter are not supported. You probably cannot easily solve the PanelView problem.    PanelView Plus terminals are specifically not supported in this kind of system because they cannot switch between IP address targets.   I've built systems like this using RSLinx Classic OPC Alias Topics with PC-based FactoryTalk View HMI stations. Again, this is something that your local RA sales and support office should be involved in.
  14. Absolute Encoder Scaling

    Hi James ! The good news is that your wire-draw encoder is a really good device compared to how most wire-draw encoders work, with simple voltage divider and potentiometer. Yours has one of SICK's EtherNet/IP absolute encoders bolted to it.   That looks nearly identical to the Allen-Bradley 842E because it is. To scale your actual mechanical stroke as installed, Panic Mode is exactly right:  you need to capture the encoder counts at zero inches of your mechanism, and at 150 inches of your mechanism, and do a straight linear equation. You can get some insight into the encoder by converting those counts into hex: 1073741824 = 0x4000_0000 = half of the maximum value of a 32-bit signed integer 262144 = 0x4_0000 = 1/4096 of 0x4000_0000, so it supports up to 4096 turns.   The important specification that I got from the SICK website is that while the total wire draw is 5.2 meters for that model, the wire draw *per encoder revolution* is 385 mm. 150 inches is 3810 mm exactly. 3810 / 385 x 262144 = 2594204.26 counts for the full 0-150 inch stroke, or about 17294.7 counts per inch.    
  15. Turning on all the segments of an LED display is a normal part of low level self-diagnostics for any embedded system with that type of a display, so the main control board probably isn't getting past the power-on self-test stage.   It likely won't communicate with anything or even flash lights for diagnostic codes. It can't hurt to try to flash the firmware with a 22-SCM or 1203-USB, in case it's only the display subsection that has failed.   But I think this is just a glowing brick at this point.
  16. Panel View 800

    I have never seen that exact sort of display behavior on a PanelView 800, but it's surely a self-test process for the display driver section.   It won't hurt to power down the terminal, disassemble it, and look for a damaged cable or debris causing a malfunction. But otherwise, it probably cannot recover and needs to be replaced.
  17. Because the indicators are on the POINTBus, it means a problem with the module itself or the POINTBus configuration. Is the module newly installed, or has it been running for a while ?    If it failed after running for some time, and simple re-seating it or cycling power does not recover it, then the module must be replaced. If it is newly installed, maybe the problem is in its slot number configuration.
  18. In general, a motorized roll up door isn't going to be an acceptable means of emergency egress, because it can't be opened during a power outage. In my facility, every roll-up door also has an ordinary personnel door that opens outward with a crash bar and is accessible only with a key-card from the outside.   Access hours and authorization is handled through our central alarm and security system, not through any PLC-based equipment. As noted, any PLC that's going to be used to perform time-of-day work needs a Real Time Clock feature, and comparison instructions are generally how you program features for time window limits. The more challenging part is how you get a PLC to accurately keep time for its location, through power losses or battery failures or time drift.   Even the common method most computers use of getting the time of day from a Network Time Protocol (NTP) server on the enterprise LAN or the Internet is not built into many PLCs.  
  19. Control Logix GSV request

    The length of the string might differ by device;  mine was 20 bytes, not 33.   I agree that it might be simpler to get the Device Code from that identity object, and use its value against a table of known CPUs you can update. That list is on Page 194 of the 1756-RM003 reference manual: https://literature.rockwellautomation.com/idc/groups/literature/documents/rm/1756-rm003_-en-p.pdf Here's the results from my testbench:
  20. See if FactoryTalk View ME's application manager utility will let you decompress the *.MER and create a Runtime from it.   That's the easiest way to reconfigure the RSLinx Enterprise drivers that are pointing to the RN6 now, and need to point either to an Ethernet/DH485 gateway or directly over Ethernet to the two new CompactLogix in the future. It might be possible to carefully reconfigure the RSLinx Enterprise configuration on those terminals separately from the FTView ME Runtime, but you want to be very sure you have appropriate backup files before you go messing with it.
  21. PannelView 800 to logix 5555.

    Welcome to the Mr. PLC forum community ! Do you have the PanelBuilder32 file ?    Was the PanelView 550 connected over RS-232 to the Logix 5555 ? Examine the Tag database closely and see if it uses any data types other than N, B, and F. Those are the three kinds of data files that a ControlLogix can emulate perfectly, using the PLC/SLC Data Table Mapping tool. If it uses other data types, you will have to adapt the PanelView application and possibly the ControlLogix application.
  22. The RJ-45 network plug on an SLC-500 "brick", or the 5/01 or 5/02 or 5/03 controller is always DH-485, both electrically and protocol. It wasn't until the SLC-5/03 and 5/04 (and later the 5/05) came along with added multifunctional RS-232 ports (Channel 0 in the SLC operating systsem) that we started calling the proprietary network port Channel 1. The 1747-AICs are logically transparent;  they don't have node numbers.   The 1747-UIC of course needs a node number that's unique on the network. While DH-485 can be set for 9600 baud, I've seen that maybe twice in 20 years.  It's virtually always 19200, the default. There's also a "maximum node number" you can set to save time with token passing but on most systems it's left at 31.
  23. Thanks for those clarifications ! I think that to connect your HMI and the 1747-UIC to the SLC-5/03's DH485 network port simultaneously, you will need two 1747-AIC isolators. While you could physically connect the trunkline connector of one 1747-AIC to the RJ45 jack on the 1747-UIC, I don't think it would function correctly. But if you can get your hands on two 1747-AIC devices and the proper 1747-C11 and 1747-C13 cables, you can connect it up as shown in the screenshot below. 1747-C13 is pretty easy to make yourself (do not use an Ethernet cable !) but 1747-C11 you'll need to buy.
  24. Which exact model of Automation Direct HMI ?    Do you have a specification or pinout for the cable ? Do you have a USB/DH485 interface, the 1747-UIC or equivalent ? You might be able to do this with a single 1761-NET-AIC, or a single 1747-AIC, but I'd have to see exactly how the Automation Direct HMI is wired up.   The Installation Instructions are likely the best thing to have for wiring up the 1747-AIC. https://literature.rockwellautomation.com/idc/groups/literature/documents/in/1747-in062_-mu-p.pdf
  25. Powerflex 700s data

    If the CompactFlash card has the image of a DriveLogix program loaded on it AND it that image is configured to automatically load into a defaulted controller, then you can load that image without the RSLogix 5000 editing software. If the image was not configured to load automatically, you need the software. The parameters of the PowerFlex 700S drive itself need to be loaded separately, using Drive Executive software. Repair or recovery of your system might require working with the OEM or an integrator who has Rockwell Automation experience.