Eddie Willers

The MVI69-MCM is a Modbus Communication Module built by Prosoft, Inc that provides two serial ports that can be configured as Modbus Master or Modbus Slave devices. If you're going to send it data, your computer/device/application needs to be a Modbus Master and the MVI69-MCM needs to be set up as a Modbus Slave. Your description makes it sound like you are just sending ASCII data to the serial port of the MVI69-MCM. Since you say you enabled the card using the Configuration data block, you probably saw that there's a sample program that Prosoft provides to give you the basic ladder logic to make the module work. Is the data you are sending actually in Modbus RTU master format ?

I recommend contacting RA Tech Support directly if you are experiencing a controller major fault that you cannot diagnose. Is the "OK" LED flashing red, or solid red ? Flashing red means a recoverable major fault, solid red is a nonrecoverable fault. If you can clear the fault with the keyswitch, it sounds like a recoverable major fault. That sort of thing can be caused by a programming error, but should not clear the user program. That's what is really happening; the controller isn't forgetting or losing the program, it is intentionally clearing it because it cannot run in its current state because it is corrupted or the program execution cannot logically continue. If the operating system has actually crashed, you can get a "dump file" via the serial port. RA Tech support provides the fault dump reading tool. Do you have a fault routine configured in the controller ?

I use the same "last value" comparison method to determine changing values for watchdog purposes, but when the value is from an analog card or is a Floating Point value the small changes "at rest" require some changes to the approach. Try sampling the position value at a definite time period instead of every scan, and using that to compute the speed at which it is moving. Displacement / Time = Velocity Then you can use a positive or negative velocity threshold to determine direction using the same GRT and LES instructions. The Periodic Task or Event Task with an analog input module real-time-sample trigger would be a good way to do this.

When you're going from a built-in RS-232 serial port through a signal converter, you use the "1747-PIC/AIC+" driver for the DH485 protocol. Each step uses the DH485 protocol: it's only the signalling method that changes. This driver only works with a built-in RS-232 serial port. It will not work with a USB/RS232 converter, nor will it work with a PCMCIA or ExpressCard or Ethernet/RS232 interface. You may not have success with your ABB RS232/485 converter. The two Allen-Bradley devices, the 1747-PIC (ancient) and 1761-NET-AIC (maybe 12 years old) have specific RS-232 handshaking control of the transmit/receive circuits on RS485 which your ABB converter may not do the same. A-B doesn't publish or describe the timing because they are part of the DH485 protocol. The third option is to use the USB/DH485 interface, the 1747-UIC. It runs a DF1 Full Duplex driver on a USB serial port, and does the DH485 link and protocol layer work onboard. If you will be maintaining SLC-500 and MicroLogix gear that uses DH-485, you'll want one of these for the future.

The local IT guy's demonstration of a local PC's ability to connect with the controller via HTTP is encouraging but not determinant. Can you access the controller via HTTP if Port 80 is (very temporarily) forwarded to the controller ? I don't use the Remote Devices Via Linx Gateway (though I know some people do), but rather the ordinary RSLinx Ethernet Devices driver. Sometimes it can be something simple like the -ENBT module lacking the proper Default Gateway address so that it knows how to respond to a packet that comes from outside the local subnet (unlike that HTTP request the local guy showed you). I very strongly prefer VPN over Port Forwarding for a permanent installation. When RSLinx Classic is browsing an "Ethernet Devices" device for the first time, it tries first to connect on Port 2222 (the old CSPv4 protocol). After it gets three "Port Closed" responses, it switches to Port 44818 (EtherNet/IP). In RSLinx Classic's Ethernet Devices driver, you can append ":EIP" to the hostname/IP address to make RSLinx skip the attempt to connect using Port 2222. Some firewalls consider that to be a "port scan" and will block the second and third "port closed" responses that RSLinx needs to see. If you're feeling hacker-y, download NMAP and try using that to probe the router.

You don't translate a *.RSS file directly. Instead, you export a logic file and a description file from RSLogix 500 and translate those. If you do not have RSLogix 500, I'm sure someone on the Forum would be happy to perform these exports for you. These steps are described in the Translation Tool Help File and in the User Manual for translation between PLC/SLC and ControlLogix: http://literature.rockwellautomation.com/i...rm085_-en-p.pdf

The MicroLogix 1400 is newer than both the RSLinx and RSLogix 500 software that you have. It has a new operating system, new instructions, and new features that are included in the updates to RSLinx and RSLogix 500. While you can upgrade RSLinx Lite without a TechConnect contract, you cannot upgrade RSLogix 500 without a TechConnect contract. The RSLogix 500 Micro Starter Free Edition works only with MicroLogix 1000 and 1100 controllers. If I were in your shoes, I would explain myself to your A-B distributor and he'd likely update your RSLogix 500 software for you. He'd probably explain the benefits you'd get from a TechConnect contract, too.

DH+ and Allen-Bradley Universal Remote I/O run on the same kind of wire, but are different protocols for different purposes. 1794-ASB is a Remote I/O adapter. You cannot connect it to a DH+ network. I presume your controller is a ControlLogix-family controller. PLC-5E and SLC-5/05 do not support I/O scanning on Ethernet. I'd choose the Ethernet adapter for the speed, the flexibility, the diagnostic features, and the ease of support for specialty and analog I/O.

If you're talking about the DCOM 108 bug, aka "RPC_E_Disconnected", then it affects all OPC products, not just RSLinx. And it doesn't affect Windows XP. And it would exist in any version of RSLinx. So that might be the problem. It might not. Bob, any more information you can post to narrow down this rumor ? I'm sure I wouldn't be happy if I was a Rockwell support engineer who got the call saying "some guy on an Internet forum says there's a bug in RSLinx 2.54 and I have to roll back to 2.51 with some kind of patch. What do you have to say about that ?"

Well, that's just weird. I never had any problems connecting RSView SE 4.0 to PLC-5E or SLC-5/05 controllers. I had an problem with MicroLogix 1100 because it wouldn't browse the data tables, but directly typing in the addresses worked. It sounds like any PLC-5 tag that runs through the HMI tag database is not working correctly, not just animations but also numeric displays and alarm tags. Do Memory tags in the HMI database work correctly ? I assume they do, but I'm asking. Are there any diagnostics in the FactoryTalk logs that refer to communication failures ? Is there any chance you have an RSLinx Classic OPC Topic with the same name as an RSLinx Enterprise Shortcut that might be confusing the HMI Tag Database ?

Can you share which OPC Client was in use, whether it was local or remote OPC, which type of controllers, what networks, what operating systems, and what symptoms the IT group calls "locking up" ? I want to take a lot of IT guys and forcefeed them freshman philosophy books so they understand the basics of epistemology and stop treating "issues" like myth.

The status of the logical Connection between the controller and the I/O device in the network can be read using the Get System Variable (GSV) instruction to access the EntryStatus value for each I/O adapter. The EntryStatus value is encoded in bits 12-15, so you can bit-shift, divide, or mask to interpret them. I recommend just running these GSVs on a repeating timer or in a periodic task, since they do require a bit of system resource to execute.

It's a minor issue. Send Data Acknowledge (SDA in DH+ shorthand) is just an internal part of the DH+ protocol. If the buffer that handles SDA's is full, a message might error out as being "not acknowledged" but it will be retried. If the value isn't increasing fast, it's probably just a symptom of a busy network.

Aha... you are using the 1203-EN1 EtherNet/IP to SCANport module. These are not very common because most older SCANport drives are pretty successful with their existing network interfaces to RIO, DNet, CNet, etc. The 1203-EN1 should support the "PCCC Object", in which it emulates a PLC/SLC when you send requests to specific emulated integer files. According to the 1203-EN1 user manual, data elements N30:1-9999 should emulate the drive's parameters. Try creating an OPC Topic that points to the 1203-EN1 and set it for PLC-5E or SLC-5/05 device type. Then try manually creating an OPC item with one of those N30:xxx addresses.

All that being said, let's take a look at that DF1 frame: 10 02 01 00 STS TNS A2 01 89 00 00 80 CRC 10 03 There are several incorrect things about this frame. 1. The STS, TNS, and CRC values are missing. 2. The CMD field is missing. 3. The CRC field should be the last two bytes, after the End of Transmission (10 03). 4. Remember that DF1 is a binary protocol, not an ASCII protocol. The "10" is one byte, equal in value to 0x10 (hex) = 16 (decimal) = 00010000 (binary). The command payload is incorrect. The File Number is missing, and the "80" at the end does not belong there. The command you posted is most similar to a Read of "N7:0". A few tips that I find helpful when dealing with DF1 protocol: The Status (STS) field is always 00 for the command frame. It can have a Status value for a response frame. The Transaction Sequnce Word (TNS) is two bytes, with the least-significant byte first. Start at 1 and increment by 1 for each request. Many controllers will ignore frames with duplicate TNS fields. Calculate the CRC with all the fields except the Start of Transmission (10 02) and End of Transmission (10 03). Also exclude any extra 0x10 values that are included to designate data bytes equal to 0x10. This is called "DLE Escaping".

As a matter of industry practice, most HMI applications do not write directly to an Output file in a controller. Most often, the controller remains in control of the output points via its user program, and the HMI contributes its data which the controller program can use to decide to turn on the output if the HMI takes over control. HMI programs generally write and read to Allen-Bradley PLC/SLC/Micrologix "N" or "B" or "F" data files. Also as a matter of industry practice, the wholesale upload and download of program files is left to the vendor's software. I won't say that it is "dangerous" to write directly to an Output file, since you can make plenty of mistakes in other coding of a controller. Be aware that if you write to an Output bit that is under the control of the controller program, the controller will write over your command the very next scan. If you write to an Output bit that is not under the control of the controller program, it will remain on or off until you write to it again; the controller cannot turn it on or off because it is not referenced in the program. For the above reason, I have never experimented with writing to an Output file element in DF1.

As I understand it, they simplified RSLogix 500 Starter and Professional to be MicroLogix-only. No SLC-5/00,1,2,3,4,5 support, FactoryTalk Activation only, and a simplified RSLinx Classic installation. The prices I saw were the "RSLogix 500 Micro Starter" for $129 and "Micro RSLogix 500 Developer" for $499. RSLogix 500 Emulate is also getting a refresh this fall, with support for the new MicroLogix and new SLC operating systems.

You're going to need a current version of RSNetworx for DeviceNet to configure the 1769-SDN. RA is shipping version 8.0, which has the same Demo Mode without activation as all the older versions. Make friends with your local RA sales office and get a copy. The minor revision of a device seldom makes a difference with regard to the EDS file.

A fine point. I found another list of the same statistical counters in the DF1 protocol command reference (1770-6.5.16, I think) and in the RSLinx online help file. But a lot of the DH+ diagnostic counters have to do with the token-passing mechanism of DH+, and that's the part that is proprietary to A-B, and they don't describe or publish.

I think your problems are not coming from the messaging application running inside the SLC-5/04, but rather from another node on the network, maybe one of those computers. Two diagnostic counters in Node 52 stand out: Queue Errors: 40552 Buffer Not Armed: 40552 This indicates that incoming messages to this SLC-5/04 were not able to be serviced because the incoming message buffer was full. You can increase the ability of an SLC-5/04 to service incoming messages by clearing the Comms Service Bit or adding SVC instructions inside the ladder program. The best thing to do is to figure out which one of those PC's is hammering the SLC-5/04. There may also be some media or noise issues on this system that are indicated by the token passing error counters.

...when you bought it ? Caveat, emptor. If you're on any kind of good terms with your local A-B office or distributor you could carry that in the door and get it unlocked in about ten minutes.

Read the Knowledgebase article closely; SLC and MicroLogix passwords are always numeric. The clear-memory function password is "MLCLRMEM" translated to the corresponding numbers on a telephone keypad, which is "65257636".

Another attempt you could make is to designate the RS232 port on the Digi One IAP as the Modbus RTU serial port, and attach a serial sniffer to that port. Even Hyperterminal will tell you if the Digi One IAP is even attempting to send a Modbus command when you hit it with the SLC Typed Read request from the SLC-5/05. If you have a managed Ethernet switch that supports Port Mirroring, you could try to intercept the data going from the SLC to the DOIAP with a utility like Wireshark. With all the data you've provided, those are the only two steps I can really think of short of walking through the Digi One IAP setup myself.

The Digi One terminology is confusing me a little bit. Within the realm of the Digi One IAP itself, the message sources are called "masters" and the message destinations are called "slaves". But I remain very skeptical of the configuration of the Serial port on the Digi One IAP. The telnet host described in the User Manual I finally found (publication 90000263_b.pdf) does show the serial port configured as a "Modbus Slave" even when I think it should say Master. This document also includes proofreading notes to from the editor to the author, which makes me not totally trust its contents. Make sure you cycle power to the DOIAP whenever you change its configuration ! A slightly-related note on your MSG instructions: You don't need to "seal in" a MSG instruction with the /EN bit. Once the preconditions on the rung go from false to true, the MSG is enabled until it is through executing. This can happen because it's Done (/DN=1), because it has Errored (/ER = 1), or because you have manually timed it out (you set /TO =1, it sets /ER =1). When I write message instructions that run on a periodic basis, I condition my MSG block with the /DN bit of my periodic timer in series with an XIO instruction addressed to the /EN bit of the MSG command word. That way the MSG doesn't get re-enabled (and thus stuck into the queue) before it's completed the previous execution.

You described the Digi One IAP as working correctly when you set it up for use with a Modbus/TCP master and as a passthrough device, which makes me assume that you have the serial port on it configured correctly, but I don't trust my assumption. The above configuration for the serial port on the DOIAP with type=slave concerns me. We want the serial port on the DOIAP to be a Modbus RTU Master, as the Altivar 31 drives are Modbus RTU Slaves. The Digi website has a lot of good stuff (not to mention Lynn Linse's multiple personal sites) but I have not found a really substantial User Manual for the Digi One IAP. There are a lot of step-by-step guides for specific features but nothing that I'd call a reference manual.