PMCR

MrPLC Admin
  • Content count

    701
  • Joined

  • Last visited

Posts posted by PMCR


  1. Managed Switches on EtherNet/IP provide several benefits, but are not necessary in most systems. The most useful function of a managed switch is something called IGMP Snooping, which stands for Internet Group Multicast Protocol Snooping. This function is used when a device is set to Multicast data, which is similar in concept to a broadcast. When using Multicasting on an Unmanaged Switch, all devices attached to the switch recieve all multicast packets, which increases the network traffic on each node. When using Multicasting on an Managed Swtich with IGMP Snooping, the switch has a subscriber table for each physical port on the switch, and which Multicast packets each device subscribes to. So, only the devices that request specific multicast data will recieve it. In most applications, multicasting is not necessary, so unmanaged switches will work just fine, as long as you remember to configure each connection as 'Point to Point', not multicast. The feature that I use most often on managed switches is Port Mirroring. Port Mirroring allows Wireshark running on my PC to monitor all traffic between a PLC and another device (IO Block for example). The Managed Swtich is configured to mirror all the traffic on one particular port (the PLC port for example) out another port to which my laptop is attached. The other key to understanding EtherNet/IP communications is the concept of RPI, which is Requested Packet Interval. Each connection to a device is made at a specified RPI, which the user can set. The RPI is set in ms, and is the interval that the data should be transmitted from the device. So, a Congnex camera can be set to transmit data every 50ms, which is a relatively low network load. IO blocks, which may need faster response, can be set to a 10 ms RPI for faster response. By setting the RPI for each connection at an appropriate value, it is easy to control the amount of network traffic on EtherNet/IP, and setup a very viable network, using an unmanaged switch.
    1 person likes this

  2. Something else that I ran into while testing this. If you have a 'lab' PLC that you have used for other things in the past, clear out the DM area that configures the module. For you, that is D30,100 - D30,199. Set them all to 0000. Then download the configuration of the module through the IO table. I had some 'stale' data' in the DMs from something else I had done before, and it was causing me some problems.

  3. Ricardo It sounds like you should be almost there! Trying the 2nd bar code reader on the 1st system was a very good idea! Did you also try the cable that you have for the second system? If you can trigger the reader, but are getting no data, it could be something as simple as the cable. Like Bob indicated, check the port settings. I do this in CX Programmer. Check each and every setting to make certain that the 2nd systems settings are the same as the first. If you are not seeing any response in the Trace function, then the data is not getting back to the card. Is the 'Protocol Macro Transmission Method' set for Half Duplex or Full Duplex? It should be Full Duplex, as this is RS232.

  4. The other issue that I have seen is that the CP1W-CIF41 does not handle all of the other network traffic (Rapid Tree Spanning, Tree Spanning, etc) very well. Isolating the PLC removes all of the other 'IT' traffic from the PLC, and lets the CIF41 focus on what it was designed for: FINS communciations.

  5. Interesting thought. I have run the Web Server for long periods of time (I have one running all the time in my office), but not with logging. It will be interesting to see if rob5029 is using either one of those features in his application.

  6. I agree with Mendon Systems idea, but I wonder why it needs resetting. I have used NS terminals for many years, and never run into a situation where this was required. Can you provide some details about the overall system?

  7. denise01 If the port on the SCU card is not configured correctly, nothing will work. Configure the SCU card through the IO Table tool. There are 2 places to create the IO table for the PLC: CX Programmer and CX Protocol. Create the IO table in CX Programmer. Here are the steps. 1. Go Online with CX Programmer. 2. Put the PLC in Program mode. 3. Double Click on the IO table (from the tree view). 4. Click Options / Create. 5. In the Dialog Box that asks 'Are you sure you want to create the IO table', click 'Yes' 6. In the Dialog Box that asks 'Initialize CPU Bus Settings', click 'Yes'. 7. In the Dialog Box that asks what to transfer, leave both boxes checked and click 'Transfer'. 8. Once the IO Table has been transferred, click OK. 9. Click the '+' sign next to Main Rack. 10. Double Click on the SCU31 card. 11. Make the settings as shown in the manual for the Modbus Master program. This is also shown below. 12. Click "Transfer PC to Unit'. 13. In the dialog box that asks 'Are you sure you want to continue', click 'Yes'. 14. When the transfer is finished click 'Close'. 15. In the dialog box that asks if you wish to restart the module click 'Yes'.

  8. When you convert from a larger screen to a smaller screen, the objects are not automatically resized. So, most likely the objects that are 'missing' are simply off the screen. Change the Zoom to 100% (or smaller if needed) to see all the objects that are off the screen. You will need to open each screen and resize the objects. You can select all the objects, and then grab the corner of one and resize all the objects at once.

  9. I just took a look at the port configuration for the SCU module. The first setting for Port 1 is Port Settings. If you leave this at 'Defaults', it ignores all the other settings that you make. It appears as though this is the case for your project. Set Port Settings to 'User Settings'. Also set "Maximum Number of bytes in Protocol' to 1000 to allow the maximum receive buffer size (this is not the problem). Look in the manual for the Modbus Solution (page 6) for the setup of the port. Set the port exactly as shown, and download the settings.

  10. Lost Control appears to be on the correct path! The addresses in the ATV31 document appear to be in decimal, but Modbus need them in HEX. The other thing you may try doing is subtracting 1 from the Modbus address. Some manufacturers document the address, but the Modbus mapping is really 1 less. The other thing you could do would be to use CX Protocol and do a trace of the serial port. This would show us exactly what is being sent and returned from the drive (if there is a response). The .pdf below shows the steps. Save the Protocol Macro file, and then post when you are done. The data that you trace is saved as part of the file. CX Protocol Data Trace.pdf

  11. The problem that you are having is that you are trying to mix protocols. EtherNet/IP is a CIP protocol. Controller Link is a FINS protocol. To connect across Ethernet to Controller Link requires using FINS Ethernet (either UDP or TCP). You can't connect to a PLC via EtherNet/IP, and then route across Controller Link with FINS. In any CX application, setup the CJ2, and then click the 'show all' checkbox under the Network Type dialog box. Then choose Ethernet as the comms method. This is why all CJ1 / CJ2 / CS1 / NJ EtherNet/IP modules also support FINS simultaneously. Make certain that the Ethernet card is in the FINS routing table.

  12. Great discussion! I have seen a distributor come and go with B&R. The commends from the engineers centered aound the ease of use, or lack there of. I have not used the product, but from the users that I have seen who have used it, the sentiment is 'once you have it working, it works well', but 'good luck getting there'.

  13. Given the correct Modbus RTU addressing, the E5CN is Modbus RTU capable. You do need to set the COMMS in the E5CN to Modbus. CompoWay/F (Omron protocol) is the default.

  14. Vijaya Welcome to the world of Omron! What Omron PLC are you using? This will help us to provide more specific answer. In CP1L, CP1H, CJ1, CS1 PLCs, there are 2 different ways you can use timers and counters: BCD and Binary (HEX) ranges. BCD Timers / Counters have a range of #0000 to #9999, and Binary Timers/ Counters have a range of #0000 - #FFFF (&0 - &65535). If you are using a CJ2M or CJ2H PLC, you do not need to select between using BCD or Binary Timers/ Counters. You can use both types of timers / counters in a program. For CP1L, CP1H, CJ1, and CS1, you make a choice of using BCD (default) Timers / Counters or Binary Timers / Counter by right clicking on the PLC in the tree view in CX Programmer, and selecting Properties. You can put a check mark in Execute Timer/ Counter as Binary to select the Binary timers / counters (TIMX, TIMHX, and TMHHX, instuctions). There is also a 'long' version of the 100 ms resolution timer (TIML (BCD) or TIMLX(Binary)) Unfortunately, the Totalizing Timer that you are using is not available in a long version, so the range is limited to &0 - &65535 (0 - 6553.5 seconds) The other way that I tackle this type of timing is simply use some of the P_xxx system bits such as P_0_1s to increment a UDINT value, as shown below.

  15. ICase Yes, this can be done! It takes a little doing, and some understanding of FINS Routing in an Omron PLC. If you can provide the exact configuration, I can walk you through the setup. What I need is: 1. Model(2) of CP1L (specifically 1 or 2 plug in slots on the front). 2. Which socket the CIF41 is plugged into on the CP1Ls. 3. IP Addresses (or at least the last octets of the CJ1M and CP1Ls). 4. FINS Network number (if any) that was assigned to the CJ1M and / or CP1L for Ethernet. 5. Which serial port (Port A or Port B) on the NS is connected to the CJ1M.

  16. That's great! I agree FBs are very useful. It begs the question: can you share your function block? I have created one that takes the output of PID and time proportions it for a digital output. You can pass the output of the PID function, the output resolution of the PID instruction, and the time base (control period) of the digital output into the FB, and you get a digital signal and a MV for monitoring.

  17. The 'Socket Services' function of the ETN21 is just the Omron way of saying 'user defined protocol', as opposed to FINS. I have used it for bar code readers, torque wrenches, and numerous other non Omron protocol devices. It works with UDP and TCP, and you can have up to 8 sockets open at a time.

  18. ptrksr First of all, great diagnostic information! Screen shots are the best way to get help quickly! In your CIF41 setup, you show 10.50.2.32 as the IP address, with 32 as the node number. Proper standard FINS node address based on the last octet of the IP address. In the Color Coded FINS Messaging Tool, you have 54 as the Node Number (which I hard coded as the default). Do you still get the same response if you change the node number to 32? I have tried to replicate this with a CIF41, and as long as I have the destination node number set correctly, I cannot cause the error.
    1 person likes this