Version 15 FP2 and Rockwell

We are looking at replacing the VFDs in part of our process to Rockwell from another vendor.  We are currently using version 14 LTS but we are going to move to 15 in the not too distant future.  Our current VFDs go through a PLC concentrator to a VIM2.  For a variety of reasons that I can't go into here, we are considering replacing the SX controller / VIM2 with a PK controller and going directly from the VFDs to the PK.  I see that version 15 FP 2 has expanded the address ranges and it sounds like this would make connecting to the VFDs simpler.  Am I understanding this correctly?  Aside from the cost of the new controller, are there pros and cons to this approach?  Would Feature Pack 2 be recommended for this?

Kent

• 4 Mar 2025 8:48 PM
• Cancel

4 Replies

• Matt Forbis

  

  • 4 Mar 2025 9:09 PM

  Rockwell VFD's can easily be interfaced via Ethernet/IP and a PK controller. They have been able to be done since the EIOC came out in v13.3.1, but also with the PK. There are some pros and cons to each approach and I'll try to lay it out the best I can.
  
  1. With either an EIOC, or a PK, there is a limit on the number of physical devices on the port. On the EIOC, this is 256 and on the pk this was dependent on model (16, 32, 64, or 128 depending on size). This effectively limits how many motor overload relays and vfd's on the port.
  
  2. With an EIOC, while it has more physical device capability, it is limited to 26 PID blocks. If you create manual loaders that use a PID for the speed control, this makes it more difficult if you have more than 26 VFD's.
  
  3. Right now, your DeltaV to the VIM appears as Modbus. But when going through your PLC, it doesn't have to be natively, depending what firmware is in the VIM. Secondly, your legacy VFD's could talk Modbus, Ethernet/IP (easy as mentioned above) or something else entirely. No matter what type of protocol any VFD is speaking, it likely is not making use of the extended modbus registers that 15 FP2 is giving you (though I can't say for sure without more information). So, it might make it easier to connect if your VIM is talking to the PLC through extended PLC registers and you want to remove just the VIM, but likely it doesn't have much impact on if you talk directly to VFD's.
  
  So, depending on the layout of VFD's and your plant, hopefully some of the above will help you choose the right solution. I think almost any version of DeltaV (that's recent) would work for what you need.

  • Cancel
• Kent

  

  • 4 Mar 2025 9:17 PM

  In reply to Matt Forbis:

  Thank you for the quick response.

  • Cancel
• Andre Dicaire

  

  • 5 Mar 2025 12:42 AM

  In reply to Matt Forbis:

  Depending on number of devices (> 64) you would looking at a PK1500. That’s a lot of coin to especially compared to an EIOC.
  
  If you consider the EIOC as your data concentrator and removed the PLc, you would simplify the architecture and gain performance. Note that the EIOC and PK design is around direct device integration with performance tested on 256 physical devices. The PLC funnels all comms as one device which impacts the polling rate due to number of LDTs that one device has to service. Modbus TCP in the VIM polls round robin with minimal pause while Ethernet IP has 20 ms pause between LDTs. Eliminating the PLC lets the EIOC get all devices more quickly and easy additions without need to update PLC data array tags.
  
  The other impact is the change in IO references. VIM present data as Dataset/register (DS-001/R0001). The LDT signal structure is a signal per register which coil look similar( DS-001_R0001). Point is, you have to update am module references for this change in IO datatructure.
  
  I don’t like the limit on PID blocks in EIOC but we have to consider if this impact the path forward.
  
  EIOC and PK offer two subnets A and B bus. With PRP, you can expand number of groupings of devices to improve availability, mitigate imapct is a switch failure.
  
  Lots to explore here.

  Andre Dicaire

  • Cancel
• Kent

  

  • 5 Mar 2025 1:57 PM

  In reply to Andre Dicaire:

  Thank you to everyone for your input. It looks like I have a lot to talk to our Impact Partner about.

  • Cancel