writing speed commands to powerflex 4m

Hello everyone, I have my ML 1400 and panel view working together now. I would like to be able to write the speed commands to the drive from the HMI currently looking at possibly purchasing an analog expansion module 1762-IF2OF2. I see where I can supply 24v to channels 5 & 6 on the drive to set the preset frequency but would like to be able to ramp the motor up and down. Was wondering if this is the module I need to make this work. Thanks in advance guys.

Processor= ML1400 BXB

VDF= Powerflex 4m

Yes that would work you could also go with a 1762-OF4 since the 4m doesn't seem to have an analog output for speed indication the 2 AIN channels aren't really needed unless you had planned to use them for something else

Thank you for your quick reply, I was just looking at this particular module because it has both inputs and outputs. Would RTDs work on the input side of this module? I have some of them laying around not really wanting to shell out the money for an RTD module.

Without a transmitter RTD will not work.

In theory you could probably make it work but it's not worth the effort and would not be as reliable as having an RTD module or Transmitter

you would want a temperature transmitter to convert the RTD to a 4-20mA.

Ok thanks for all ya help and suggestions.

Another option would be to use Modbus polling to read and write commands to the VFD using the 1763-NC01 module to break out the RS485 pins of the ML1400. It can be more time consuming to set up the logic, but you get much more than just speed and control commands, the hardware costs less, and you can daisy chain multiple drives without having to add more I/O.

I have done this with several different makes of drives, but not a Powerflex so I am ASSuming the PF supports Modbus. There are times and places where good old fashioned hardwired analog control is a better choice.

Would the 1763-NC01 be considered DF1 communication? I plan on setting up the drive for Ethernet with a 22-COMM- E a 22-XCOMM-DC base, and see if I could get it working with drive explorer. Could find much information on using the 1763-NC 01, but your talking about seething up logic threw the serial port has me interested in know more about it. Can you point me to some data sheets and examples of its implementation.

The NC01 allows you to set up the serial port (electrically) for RS485 configuration for use with a protocol that supports multiple drops. Straight DF1 is a point to point protocol, so it would not require RS485...not sure if have ever seen DF1 protocol with RS485.

Modbus is a protocol that supports multiple devices or drops and is very often used with RS485 wiring. The ML1400 plays well with Modbus protocol and has a RS485 port on the little round connector. The 1763-NC01 is a very convenient way to break out those pins so you can land a cable on them.

I don't know enough about the PF40 comms protocols it supports or the serial port configurations it can support, but I am pretty sure Modbus and RS485 are included and that is the direction I would take if I were to try to do this.

It will mean the little round 8 pin connector gets configured as "No Handshaking" which enables that port to use the RS485 pins instead of the RS232 pins and the protocol set to Modbus RTU Master. This means that you won't be using that port for programming or anything else.

The next part is to get into the books on the VFD and find out what Modbus addresses you need to read and write in order to poll it to suit your needs. With the VFDs I have dealt with, it usually takes no more than two messages to read all the stuff you could ever want and one message to write the command word and speed reference. This is true AFTER you set the node number and other settings that allow the VFD to be controlled in such a manner (and in some drives set up the data values so they are nicely packed for.)

So the drawbacks are:
-Give up the little round port for Modbus only.
-Deal with the fact that it can take up to a second or two to get data between controller and VFD.
-Deal with the fact that it can take a few seconds to detect a failure of communication when something goes wrong.

The benefits:
-Control several drives with a piece of wire and a $50 breakout board.
-Be able to read speed, amps, dc bus voltage, fault codes, and whatever else is in the book.

I could give examples for Modbus with LSIS drives or with Yaskawa but the messaging logic is pretty similar, just the Modbus addresses vary from one maker to the other.

Thanks OkiePC for the information I may try the Modbus direction with the drive and use the ethernet/ip on one of the other drives. This is just stuff I have around to play with.

I forgot to elaborate on my experiences with the 22-COMM-E and the PF4 series drives. I worked on a system done by others that had a SLC 5/05 as the PLC talking to 7 drives using messaging to attempt to control the VFDs.

It was pretty cruddy. We could make it reliable with 4 or less drives. I am sure it works great with a PLC capable of mastering Ethernet/IP I/O such as CompactLogix or Controllogix, but the SLC (at least at that time with older firmware) couldn't really do a proper job of it.

It is my understanding that the newer firmware available does allow for some new instructions to perform new types of Ethernet/IP messages. I don't know if that means the SLC/Micrologix controllers are now capable of reliably controlling those drive using the COMM-E modules or not. Search for posts that include responses from Ken Roach on this topic.

On the system I inherited, we had hard wired start and stop commands and only used the COMM-E modules for speed reference and status information and it was still problematic with more than 4 drives in the message polling loop.