Ken Roach

MrPLC Member
  • Content count

    2776
  • Joined

  • Last visited

Community Reputation

194 Excellent

About Ken Roach

  • Rank
    Propeller Head

Recent Profile Visitors

20142 profile views
  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. Allen Bradley/Rockwell Automation questions:

    • What is the difference between Common Industrial Protocol (CIP) and Ethernet/IP?
    • What are CIP class 0, 1, and 3 connections (and the differences between them)? Are they are other class numbers I'm missing (2, 4, 5, etc)?
    • What are unicast and multicast connections (and the difference between them)?
  7. 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".  
  8. 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 ?  
  9. 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....
  10. 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.
  11. 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.
  12. 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.
  13. 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 !
  14. 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.
  15. 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.