AB ControlLogix to PowerFlex4 on Modbus

I have an application where I am trying to communicate to an AB PowerFlex4 drive from a ControlLogix processor through a ProSoft MV156-MCMR Modbus module. We can communicate successfully using Modbus from the card to another Modbus device (a Eurotherm heater controller) but not to the PowerFlex. We get back a string of what looks like random byte values from the drive the first time we send a query after a power-up. After that the drive won't respond at all until the next power cycle.
We have taken this same drive and connected it to a MicroLogix 1500 and have communucated to it successfully using the MSG statement. So we know the drive comm port is good.
We have tried just abouot every variation of wire positions and resistor values and positions you can imagine.
As near as we can guess the Modbus implementation on the PowerFlex is not a pure Modbus RTU implementation. Has anyone talked to a PowerFlex on Modbus with something not in the AB stable? Any help would be greatly appreciated.

Thanks,
KEith

Let's get a good look at those bytes. Can you use the Diagnostic port on the Prosoft module to capture the first Master/Slave exchange with the PowerFlex ?

I've used the 22-SCM-232 for this function, as well as the MicroLogix 1500 serial port and the 1769-DSI module. I worked in the past with the MVI56-MCM but not with the PowerFlex 4.

Let's get geeky on the Modbus data !

When I get in tomorrow I'll get a copy of this. We have been using the diagnostic port on the Prosoft module to get the info we have so far so a quick copy and paste should get it on here.

We are trying to read the software version of the drive as our test query, although we have tried some other parameters also. The response doesn't seem to vary deterministically with the query. The response isn't completely randon. It always seems to be between 14 and 16 bytes long. The first byte is always a [00]. The last four or so bytes are always [00]. The second or third byte is often [20]h.

Thanks for the response and I'll try to post the info tomorrow.

Keith

This is an example of the initial query from the MV156-MCMR:

<R+><01><03><00><10><00><01><85><CF><R->[00][00][90][90][80]
[90][00][00][FC][00]<R+><01><03><00><10><00><01><85><CF><R->_TT__TT__TT__TT__TT__TT__TT__TT__TT__TT__TT__TT__TT__TT__TT__
TT__TT__TT__TT__TT_<R+><01><03><00><10><00><01><85><CF>_TT_<R->

This was pulled off the datalogger from the diagnostic tools on the MCMR.
For those of you not familiar with the MCMR the the values between the <> symbols are bytes going out the com port and the values inside the [] are bytes coming in. The _TT_ values are timer ticks the data logger puts in when no data is received just to give the user some feel for elapsed time. There was no response from the drive to the second data request you see at the end of the string.

My last post isn't accurate, as you can see. The return byte count in this example was 10, not the 14-16 I listed last night.

In this test we are trying to read the firmware version from the drive at node 1.

Thanks,
Keith

I'm an idiot...

Well, we got it to work. We must have messed the wiring up somehow.

We connected the PF4 on the Modbus link with the heater controller we had working. The heater controller has diagnostic LEDs on it to aid in the RS-485 wiring. We used this to get the wiring straight. After that we were good to go using standard Modbus protocol.

In our searching for answers we came across a document (not sure of the source at this point) that stated the PF4 will write any changes to parameters that come in over the Modbus link into its on-board NVRAM as soon as the write completes. The document warned about this because a polled style update scheme would cause you to go over the write lifecycle of the NVRAM chips pretty quickly.
Is this point true? If it is true is it true of all parameters or just selected parameters?

Tnaks for the info.
Keith

I can see how that would be miswiring; the 00 and 90 bytes are what I tend to see as "junk" when I have a bad connection on a serial line.

I dunno about the NVRAM issue.... I'll have to do some digging.