Ken Roach

Thanks for the screenshots ! Those appear to show that your PLC-5 code used a data block starting at N9:84 that was 44 Words long to configure the 1771-VHSC.    The screenshots of N84 show that all the values in that data block are zero, which suggests that the VHSC was configured for all defaults, which you've assessed to mean Counter Mode, No Store, Rollover = 0, Preset = 0, and Scaler  = 0. What kind of pulse signal does your flowmeter generate ?   What's the voltage, what's the pulse rate, and how long (in ms) are the pulses ?   I'd have to look up the default filters on the 1771 and 1756 modules to see if they're similar. How do you evaluate your flow;   do you count up a number of seconds then capture the Accumulated Count, then calculate the flow ? Could the logic that triggers that calculation be different between the two systems ? Is the ControlLogix sending this flowmeter data back to the PLC-5 for you to do that calculation (I see that there's some copying of the 32-bit value into ControlLogix tags that are equivalent to N8:70-71 and N8:72-73)  ? Is the deviation of the volume flow consistently above the old measurements, or consistently below, or is it always different ?  

You will have to do it in blocks. Most ASCII devices like label printers use a delimiter (usually Carriage Return and/or Line Feed) instead of a timeout.   You will have to split up your string into multiple sections and use a sequencer to send them one at a time, with the delimiter on the last one.

I did a lot of searching for a hardware interface or method to talk via Ethernet to a Fanuc 30i family controller and did not find one. I used the FOCAS OPC Server product directly from Fanuc Support North America.   Relatively inexpensive, but the jury is still out on the reliability;   I had some trouble understanding the update mechanism and some "stale data" issues.

Thanks for the clarifications and follow-up ! A MicroLogix or SLC-500 does not service communications during the program execution (with the exception of explicit SVC instruction interrupts), so there is no risk of having your loop or COP instruction be in between the instructions that assemble your data into the Integer data table when the data is read by the external program. There is definitely that risk in ControlLogix. CPW was added to the instruction set for the MicroLogix 1500, and then moved forward into the 1100 and 1400 controllers.    It was built to accept operands of differing data types, in part because of the addition of Modbus RTU to those controllers and the need to pack 32-bit Floating Point data into Modbus Holding Registers.   As you have found, it's also useful for manipulation of Long Integer data tables.    

The MicroLogix and SLC-500 operating systems are functionally single-threaded, so they service communication requests based on the data table values in between execution cycles of the control program.    There's no way that I am aware of for an element of a data table to change during the reading of an array of elements, even if it is changed by a Routine that is executed by a Periodic or Event interrupt. Strictly speaking the data tables are "atomic" down to the Element level;   if you read N20:0 through N20:3, that's four elements, not one. This is different in the ControlLogix family, which has a task scheduler and communications services in the background.   You can encounter (and I have) circumstances where data in an array changed during a communication operation.  I use the Copy Synchronous (CPS) instruction in ControlLogix to lock the source and destination tags when I need to assure integrity of an array of data.

I'm posting this Red Lion Crimson 3 application here as a reminder and repository for sample code. This Forum seems to be a favored place to put sample code and sample applications. I think Red Lion should undertake a Forum of their own, especially because of the relatively steep learning curve for their C-like Program language, but for now this will have to do. I have an application where I am manually creating descriptive text strings for events that are being monitored by a Data Station Plus. I want to have a tidy String that contains the Year, Month, Day, Hour, Minute and Second to go into those descriptive strings. While this is easy to do with display objects because there is a Time and Date Primitive, this method works for making strings that will be used with the file I/O commands. This program is configured to execute "On Tick", so it runs every 1 second. The result is a text string in the format "02/01/2003 08:53:46" This was written for and tested on a Data Station Plus DSPSX000, using Crimson 3 version 579.003. Timestamp_String.zip

You can "fake out" the older controller by entering the L33ER as though it was an old 1769-L35E.    There is no version dependency that I am aware of that prevents any ControlLogix or CompactLogix from exchanging Produced/Consumed Tags with any other ControlLogix or CompactLogix that supports the same networks.  

The "remote" 1756-ENxT, the chassis that contains it, and the "Producing" 1756-L73 controller must all be in the I/O tree. The 1756-L73 is definitely supported by Studio 5000 v30.

Take a look at what's in the contents of those "DVD images";   for better or for worse it's every support file in every language. When I download a Rockwell software product, I put the .RAR or .ISO or .ZIP files onto our big file server once I'm done with my installation;  no reason to keep them on my relatively small SSD.

Yes.    The very oldest Series A chassis had some MOV's under the processor slot that were notorious for getting bent and damaged, and Series B improved that design. 1746 chassis of any Series are 100% compatible with all controllers, modules, and power supplies.

OK, that's a different set of conditions and devices. Is your communications over serial, or over TCP/IP ? What revision of firmware is the CompactLogix 1769-L32E running ?  What protocol are you using;  DF1 full duplex, or half-duplex, or half-duplex Radio-Modem ? Telemetry can be hard to troubleshoot, and the tools and techniques aren't as commonplace as ordinary automation electronics.  I used to make my living hooking up protocol analyzers and hunting for the correlation between communication failures and weather/temperature/vibration/traffic/time.

What is your master controller ?   When you say "some of the messages do get through", do you mean that of the three to that site two of them always get through, or some of each of the three sometimes get through ?    Does your system do any statistical collection on error rates or counts ? Have any changes been made to the system lately ?   Do your radios have any independent diagnostics ? In general, Error code 0x37 really does mean "timeout";   the local controller sent a query to the remote controller, and never got a reply. This is different from the sort of error that you would get if the data table was unavailable, or there was a corrupted value like a CRC error.   With a MicroLogix 1000, the data tables are fixed in size and type, so the risk of mis-addressing is mostly limited to typos at the master side.  

Yes, that is definitely possible.    FactoryTalk View's diagnostic log will generally indicate the data table addresses it cannot read or write.

There is no difference between the 16K and 32K controllers in their ability to communicate via the serial port. So your problem could be in the configuration of the serial port, or with physical damage to the serial port, or with differences in the data table addresses that you are attempting to read and write.   But it's not a firmware problem.

I don't like to directly address Inputs or Outputs;   FactoryTalk View has had some SNAFUs with the drivers, and in general I just don't like to risk the possibility that the HMI will write to something that the PLC is also trying to write to. Is your multi-state indicator configured for 2-state (which could address a Bit) or Integer state (which would have to address a whole word) ?

Video Graphics Adapter (VGA) connectors are about the same size and shape but have different pins (15).    The MicroLogix 1400 has an ordinary 9-pin "DB9" RS-232 connector, which you can see is a Male (pin) connector.    The pinout is for a "Data Terminal Equipment" type port, on which Pin 2 is Receive (Rx) and Pin 3 is Transmite (Tx). This is the same pinout and style of port that you would find on a typical personal computer. The Delta HMI you posted a picture of appears to be a DOP-B07S411.    It has at least two communication ports on the back, which can be configured for RS-232 as well as for other interfaces like RS-485. The DOP Connection Guide manual I was able to find for the Delta HMI suggests that the DB9 Male plug is also a DTE style plug, where Pin 2 is Rx and Pin 3 is Tx. That means that your serial cable must be a "null modem" type that swaps Pin 2 and Pin 3.    Or, you can add a "null modem adapter" that internally swaps pins 2 and 3. There is no way to tell from a picture what type of wiring is inside an RS-232 cable.   You must either have its specification sheet or measure continuity with a meter from end-to-end.    

In general, modern Ethernet systems should be allowed to use "Auto-Negotiate" to set speed and duplex.    If you have configured only the VFD to use 10 Mb/s, then the managed switch may still be set to "Auto-Negotiate". "Auto-Negotiate" is not "auto-detect".    There is a low level protocol for testing the link at 10 or 100 mb/s and at full or half duplex.    In general that's done each time the link is broken (unplugged) and re-connected. But some switches when they have an Auto-Negotiate failure (because the connected device is hard-set to 10 MB/s) will periodically attempt to re-negotiate so they can establish 100 Mb/Full Duplex. This causes drops of connections on that port, when the switch decides to do a new link negotiation cycle. So unless you have a very good reason to set the VFD to 10 Mb/s on the Ethernet port, I strongly suggest setting both the switch and the VFD to "Auto-Negotiate". A sophisticated switch like the Stratix should have some logs for you to examine, but I'm not enough of a Cisco IOS expert to tell you how.

What sort of devices are the ASCII devices ?    Do they have any sort of handshaking (Xon/Xoff, or RTS/CTS) that could prevent them from transmitting at the same time ? In some applications a "code activated switch" would be appropriate.    B&B Electronics (now owned by Advantech) makes a neat device they call a "buffered smart switch" that allows you to add a prefix or even do some polling, so you could tell each port's data apart. http://www.bb-elec.com/Learning-Center/All-White-Papers/Serial/Automatic-Serial-Data-Collection.aspx  

Do you mean an Allen-Bradley MicroLogix 1200 controller ? In general, a flashing red Fault LED indicates a recoverable fault, often created by the user program with a math overflow or array pointer overflow, or by the diagnostic subsystem with an expansion I/O fault. Diagnostic and Troubleshooting information can be found in the MicroLogix 1200 User Manual: https://literature.rockwellautomation.com/idc/groups/literature/documents/um/1762-um001_-en-p.pdf

The Net-ENI can handle up to six incoming TCP connections.    It's possible that if you are connecting to it with too many computers, you have overloaded it. I don't think the Web interface allows you to see the number of TCP connections;  I don't have a Net-ENI Series D to test on.    I do know that you can connect via Telnet to the device and send some commands to get some status data. Here's a Rockwell Knowlegebase article about how to do that (TechConnect required):  KB 27418. One common issue is that an RSLinx Classic station with an RSWho browse open will create and maintain a connection to a Net-ENI, so it's possible that in a large enterprise network that you have computers that are just running RSLinx in a background window that are taking up resources on the Net-ENI.

If you're using a DF1/Ethernet interface like the 1761-NET-ENI, it's possible that there is a configuration problem with it (like the Subnet Mask or Default Gateway) or that you have exceeded its capacity to accept incoming connections. In general, both FactoryTalk Linx/RSLinx Enterprise (for FactoryTalk View) and the RSLinx Classic drivers (for RSView32) can simultaneously connect to any controller;  the memory size of the controller is not a factor. But the connection capacity or configuration of the network interface device might be an issue.

The MVI46-ADMNET is one of the most broadly programmable modules that ProSoft makes;  it's basically a DOS system-on-a-chip with a backplane access toolkit and an Ethernet network stack. https://www.prosoft-technology.com/Products/Rockwell-Automation-In-chassis/Platform/SLC/C-Programmable-Application-Development-Module-with-Ethernet-for-SLC The ADMNet Dev Guide includes instructions on how to interrupt the user program and get access to the filesystem via the console serial port.

Comtrol looks like they've got a straightforward Web browser based configuration.    You tell it the name of tags you want it to transmit serial data into, and it does it based on the delimiter (like a CR/LF) or a timeout. DeviceMaster isn't a product I have direct personal experience with, unfortunately.

The "5370" family CompactLogix controllers support "raw socket" services, but the older CompactLogix family, including the 1769-L35E, do not. The MSG instruction on the 1769-L18ER controller points to the controller's Ethernet interface object (the 1,0 path) because that object is what handles socket creation and transmission.   If you had a ControlLogix with a 1756-EN2T or 1756-EWEB, the path would point to the 1756-EN2T module. You cannot make this connection with the 1769-L35E.    There may be another way to do it with a protocol gateway device (I would use a Red Lion DataStation) but not natively with the Ethernet port.

That CIP Path looks OK for a message originating in a 1756-L71 ControlLogix or GuardLogix with a 1756-EN2T or other Ethernet module in Slot 1. "1,1" is "backplane, Slot 1" "2, 192.168.105.245"    is "Network port, IP address" "1,0" is the default hop to the backplane and then the CompactLogix L43 CPU If the originating controller's Ethernet module is not in Slot 1, the CIP path should be adjusted.