Ken Roach

I forgot completely about this thread until I revisited it today, 4 years later, when I was having trouble figuring out some serial port commands on a DataStation Plus.   Neat !

I'm not a GE expert, but I've seen those ICRXICTL000 controllers;  they're basically a PC platform running GE's Machine Edition control platform. If this has to be a super-fast interface, you can use ProfiNet and a PN/EIP bridge device to connect to the ControlLogix.   I would use the HMS Anybus X-Gateway as a ProfiNet slave on one side and an EtherNet/IP Adapter on the other. But that's relatively expensive and inflexible. I would reach for a Red Lion DataStation Plus to connect to the controller through its general purpose Ethernet port.   You can get the Protocol Gateway-only model for under $700 (DSPLE) and it will happily read and write from the ControlLogix and the GE controller simultaneously, exchanging data in configurable blocks.     Crimson 3.0 software takes a little learning, but it's a very versatile device to have in your multi-platform arsenal. Find out from your GE-equipped customer programmers what protocols they support.   The DataStation Plus will happily talk Modbus/TCP or GE's older SRTP protocol, which the RX3i almost certainly supports for backward compatibility with 90-30 and 90-70 series controllers.

The Terminal 3/4 pulse output is probably isolated from the MicroMotion transmitter power.    Because your PLC and the MicroMotion are using the same main 24V power supply, the easiest thing to do would be to connect Terminal 4 to DC Common, thus tying the MicroMotion output to the same DC level as all the other devices.    Terminal 3 would then just connect to In0, In1, In2, In3, In4, or In5.     The POINT I/O's field power bus DC Common would also be tied to the same DC common as the MicroMotion and the POINT I/O adapter. If you need to isolate that circuit, you can do so by using 1734-FPD field power distributor blocks.    In that case you would connect the MicroMotion Terminal 4 to DC Common on the field power bus, and connect Terminal 3 to an Input point.   The matter of pulse speed is probably more important.     POINT I/O is generally scanned by a CompactLogix or a 1734-AENT adapter, and those Requested Packet Interval (RPI) values can be relatively long compared to a pulse train. What's the range of pulse outputs that the MicroMotion will be sending ?       My guess is that 1734-IK  (the 24V Counter module) is probably the best choice for a flowmeter input.  

That ribbon cable only carries the low-level signals for the data transfer, so you can happily have a 24V DC module next to a 120V AC module. Once you add the 1762-IQ16 to your I/O configuration and download the new program, it will work.    No sweat.

I'd bet you a shiny metal donut that the Visibility of the button is tied to a user access level or other security-related value.     When I do that, I put a little icon or text underneath the button reminding the operator to log in for access to that feature.

The corrupted LEN value is very suspicious, though it shouldn't cause the STOR instruction to not work. Look at the logic that moves data into that String, and figure out why the Length is not 5.   I've got a feeling you have something over-writing the BCN_Q tag. 1360867896 (decimal ) is  51 1D 32 38  (hex), which is Q [GS] 2 8  in ASCII (0x1D is a Group Separator control code).     The presence of the letter Q and the separator byte 0x1D in the tag name, in the "extra" data, and in the corrupted Length is suspicious. I've got a feeling you will find logic that uses a COP to put data into the base BCN_Q tag (which will start with the 4 byte Length element) instead of starting in string data section (BCN_Q.Data[0] ).    

This is a Module-Defined Data Type, so it's similar to a User-Defined Data Type. I'm not totally sure what you're asking.   You can create a new Tag of the same datatype and copy 1:1 into that, or you could use an ordinary SINT[11] array and just copy starting at the .Data[0] sub-element.  

Don't do it. If you have an I/O system for which there is no alternative vendor and it is only available with Profinet RT, choose a Siemens controller or another one that natively supports Profinet RT. Mixing a low-end A-B controller with a gateway device and a Profibus configuration tool and a third party I/O platform will make you want a time machine to go back and change your mind. If you MUST use a gateway, I would use the Prosoft.     HMS and Hilscher are both very good, but their US-resident support staffs can be counted on one hand while holding a coffee cup.

Welcome to the MrPLC forum community ! The first thing to do when you're dealing with intermittent DeviceNet problems is to check for proper termination resistors (about 60 ohms between blue and white wires, with power off), as well as any obvious loose connectors or an overloaded power supply. After that, when you're dealing with alarms or errors, pay close attention to the scrolling display on the 1756-DNB.   All that data is also available in the status tags for the module, but a quick look at the scrolling display is a faster way to figure out things like Error 91 (Bus Off) or 92 (No Power). When plugging in one devices takes down the whole network, then the device is probably a duplicate node to the Scanner, or the Data Rate is set to the wrong value.   DeviceNet can run at 125, 250, or 500 kb/s.     Most slave devices auto-detect the traffic on the network and adjust themselves, but some can be hard-set for a specific data rate. Imagine you're having a rap battle and Celine Dion shows up singing "My Heart Will Go On".    It's the same thing with a mis-matched data rate;  the transmissions are at the wrong speed so that they interfere with shorter or longer transmissions and can't use the built-in CAN network anti-collision mechanisms. MTS has built DeviceNet-equipped position sensors for a long time.   Some of the older ones had the data rate set by DIP switches, and even the modern -R series can be ordered with a pre-set data rate from the factory.     So a mis-set data rate is my best guess at the problem you were having.     This incident is probably a good prompt for taking a look at the "alarm reset" logic and how it works on your specific system.    Most DeviceNet status or alarm conditions are self-resetting;   when power is restored the Error 92 goes away, and when a slave is reconnected, Error 72 goes away.

Welcome to the MrPLC Forum ! What is the exact part number of the PanelView 1000 terminal ?     Is it a 2711 PanelView Standard (black bezel) or a 2711P PanelView Plus (gray bezel) ? In general you need the programming software and a network or serial cable, or a flash memory card and access to the configuration menus. All of the Allen-Bradley user manuals are available online at literature.rockwellautomation.com  

Download and read the 1794 FLEX I/O Selection Guide.    It will show you the basics of which terminal modules go with which I/O modules, and how power is calculated and provided. http://literature.rockwellautomation.com/idc/groups/literature/documents/sg/1794-sg002_-en-p.pdf

It's just a matter of which protocols are championed by the market leaders in their area.     Profibus has deep ties to Siemens, and the risks of integrating Profibus directly into their controllers outweighs the technical and market penetration benefits. Even though Profibus is in theory an independent technology not controlled by Siemens, they still control the source of good interface chips.  What if they restricted Rockwell from buying them ?   What if they asserted a patent, even without good grounds to do so ?  It's happened before (the Solaia/Schneider affair). And at the product level, Rockwell's never going to have easy, smooth, simple integration with Profibus like Siemens does.   So offering Profibus integrated into their controllers pretty much would start out with "Siemens does this better than we do". There's also a matter of competitive differentiation.    Rockwell had ControlNet and DeviceNet and EtherNet/IP, and promotes those in competition with Profibus and ProfiNet.    To adopt Profibus wholeheartedly would give up a major competitive differentiator in which they'd invested many years and many dollars. I have a Hilscher NT100 bridge on my desk between EtherNet/IP and Profibus DP.    I'm not sure that a built-in Profibus DP scanner in the ControlLogix would be a lot easier to use, if it existed.

If your microcontroller-based device used SPI or another low-level interface like a shift-register or parallel discrete interface, then the HMS brick or module implementation of their CompactCom NP40 chip would be ideal: https://www.anybus.com/products/embedded-index/anybus-compactcom-modules/m40-details/anybus-compactcom-m40-module---ethernet-ip Hilscher is also a leader in embedded board levels stuff.   I'm working with their relatively-bigger NT100 units this month, but they also make board-level products https://www.hilscher.com/products/product-groups/embedded-modules/communication-module/comx-51ca-reeis/

Where are you seeing information about "switching from one to the other" ? In general, FactoryTalk View ME allows you to run only one "Data Log Model".     It polls and stores all the data that will be used for Trends and for Data Logs in the project. It is one of the weakest features of FactoryTalk View ME.

The Rockwell Automation PLC platforms have never supported that sort of functionality.  I's something that Siemens is very proud of, but of course you need to very carefully designate and monitor that data area. A popular workaround is to use a Rockwell utility to upload specific data registers, then perform your program download, then restore the values of those registers. There's one called the "Data Preserve Download Tool" that's for ControlLogix family controllers (v13 and up), and another general purpose data upload/download tool called the "Tag Upload Download Tool" that works with MicroLogix, and PLC/SLC controllers.   https://rockwellautomation.custhelp.com/app/answers/detail/a_id/32503/page/1   The Tag Upload/Download Tool does use the OPC Automation Interface, so you need an OPC-capable license (anything but Lite) for RSLinx Classic to use it.

You've identified that the basic problem is that RSLinx Enterprise doesn't recognize the newest controllers, so you can't create a Shortcut from the normal browsing method. The first thing I'd try is to manually enter an old 1756-L6x controller into the RSLinx Enterprise schema, as though it was in Slot 0 of a 1756 chassis. If that doesn't work, I agree that an upgraded copy of FTView Studio is probably appropriate, with a *.MER compiled to run on v5.x firmware.

I've done it a handful of times.   I usually don't use the UDT that they use as an example, and forget to make my target data array big enough, but it definitely works. If you want to copy your code into a simplified application and post it, I've got a 1756-L71 and a 1756-EN2T I can test it on.

You can send a CIP Generic message to the TCP/IP Object in the 1756-EN2T itself to get the IP configuration. It's documented in the RA Knowledgebase;   Article ID #26779 (TechConnect required).

It's not particularly easy, but it's possible. What you need are the files associated with the Alarm History, as well as the files that describe the Alarm Configuration, and you run those both through a FactoryTalk log file viewer utility. Whenever I do this, I get out and pay close attention to the directions in this Knowledgebase article: https://rockwellautomation.custhelp.com/app/answers/detail/a_id/823751/page/2 And then I say nasty things about the parents of the FactoryTalk View developers, and go back to using Indusoft where my alarms are logged into an SQL database.

I don't think so.   The PanelView 800 is the lowest-end product in the A-B HMI range and I've never seen an ActiveX or a Browser object for it. I know there's limited support for Cognex camera objects, and the Browser object will allow some webcams to work, with the PanelView Plus 6 and Plus 7 Performance model HMIs.

Are we talking about a Kinetix 350, or a Kinetix 300 ? The 300 has the browser/java configuration interface and is a standalone or treated-as-an-IO-adapter device with ControlLogix. The 350 works as a CIP Motion axis, and is configured entirely within Studio 5000 Logix Designer.   That's the one you would use a Motion Servo On (MSO) instruction on. I installed four Kinetix 350's on a project where I had no hardwired overtravels, and had to use CIP MSG instructions to turn off the Overtravel feature (it's stored in NVRAM so it's permanent unless you load new firmware).   I just made those MSG instructions something we toggled once when setting up the machine. https://rockwellautomation.custhelp.com/app/answers/detail/a_id/467773  

Not to mention the cold junction offset values !    That is meant to be used as a substitute for the CJC devices themselves;  you're supposed to put the estimated temperature at the module in there, and un-check the CJC box.    Your temperature isn't off by 10 degrees;  it's off by 40. You need proper thermocouple extension cable if this system is going to get anywhere near accurate measurements.

The Web interface should give you options of "Ignore", "Disable and Coast" or "Ramp and Disable".    I assume that "Alarm Only" means the same as "Ignore" since the drive isn't going to stop when it sees the overtravel signals. https://rockwellautomation.custhelp.com/app/answers/detail/a_id/69994/page/1

In general, the motion controllers and the motion subsystem of the Logix operating system take care of interrupts and motion planning by themselves.  As a programmer, I just try to keep my other program tasks from taking up too much processor bandwidth. I usually use a relatively fast cyclic task (5-10 ms) to hold my motion control routines, because I want to be able to react quickly to motion-related events, like the completion of a move or a change in gearing or dynamics.

I'm a little confused by your description, so let's take a bit of a step back and review. Is the 1756-DHRIO in the same chassis with your ControlLogix CPU, or is it located in a chassis that is connected to the ControlLogix CPU via Ethernet and a 1756-EN2TR module ? You *can* put DHRIO and DNB modules in remote chassis.    The amount of data that gets moved across the network is substantial, but it works. The Unicast option won't be for the 1794-ASB entry in the I/O tree, but for the 1756-DHRIO entry itself.