hitachi L300P inverter

[LV_Pro]

Well, as shown by my increase in question posts (vs my answering other posts), I'm getting down to the wire trying to get a new system up and running. I am trying to control a Hitachi L300P inverter (motor controller), via its RS485 link. I have, at the computer end, a usb-to-RS485 adapter, and the run to the L300P is made by a twisted pair, fairly short (60 foot max) run (the controller is setup for "Half duplex, two wire"). When I send a message to the unit I get no response, neither the desired result, nor an ACK or NAK message. I have tested my port by hooking up a second and "talking to myself", have run the L300P's self loop back, which involves disconnecting the external connection and doing some manual stuff through its front programming panel and have, while the cable was disconnected tested its continuity. This morning I'm planning on running a second long twisted pair from the computer's location to the controllers and doing an end to end test to confirm that I can talk down the wires. I'm pretty sure that my command string is correct, but think that the unit is supposed send a ACK or NAK if it "sees" something come in.

If there is anyone that has had any experience with these drives, either through LabVIEW or not, I would appreciate hearing from them. Also any other paths to troubleshoot this are appreciated. I am growing fatigued, mentally and physically, and another set of "eyes" looking at the problem will probably help.

[Wayne.C]

Putnam,

No experience with this drive in particular, but lots of experience with similar devices.

Most drives ship with configuration software.  One trick I've used in the past is to use NI-SPY to monitor serial com while I send a command via the factory config software.  I then compare what the software sent vs what the manual said to send.

Can you post an example of the command string you are currently using?

[RavensFan]

I'm going to state a few things to check, although some should be obvious.

1.  Check baud rate, parity, and stop bits.

2.  Check that it is wired properly, such as not crossing the + lead of the pair with the - lead.

3.  Check that you are calling the drive by the correct slave address. 

4.  See if the drive has different modes of communication and whether your commands match that mode.  For example, Modbus vs. an ANSI serial protocol.

5.  Go through all the parameters you can access by way of the front panel of the drive to see if there are any settings that may affect, #1, #3, #4.

Along with #3, try a different slave address.  I came across a situation where I was not able to communicate with a particular brand of drive when it was its default address of 01, but could when I made it 11.  Actually, the communication worked, but it was only one way.  When it was address 01, it would accept the commands, but not respond back with an ACK or NAK like the manual said it should.  Only by changing the address could I get the acknowledgement messages.

Could the environment be electrically noisy?  Is the bridge in the drive active while you are trying to communicate.  In my case, I had an RS-485 isolator in the same cabinet as the drive.  As soon as I enabled the drive which turns on the SCR bridge, the cabinet got electrically noisy and the communication failed.  Disable the drive and it came back.  I solved the problem by moving the isolator out of the cabinet.

[LV_Pro]

I'm definitely going to try the changed node address, have only used "01" so far. I did get an ACK message, but only once, after doing the "loopback" test, where I connected another usb-485 adapter, with about 150' of cable, to the vable leading to the VFD. It worked fine, leading me to believe that the signal path was ok. I am constructing a message according to the manual. For example, for a command "00" which signals a Reverse, Forward or Stop the manual  Appendix B6,describes the command protocol as"

 <STX>,  0x02

Node#,  2 bytes

Command, 2 bytes

Data, 1 byte

BCC,    XOR of Node, Command and Data

<CR>  0x0D

With the example for "forward": (STX) | 01 | 00 | 1 |BCC|(CR)  ------> 02 | 30 31 | 30 30 | 31 | 33 30 |0D  which is what my program is constructing and sending...

As to it being a noisy signal environment, well that may be an issue that I have to deal with, but I haven't gotten the inverter to run from a remote program yet, so no noise!!

[LV_Pro · Accepted solution]

Well, to help anyone with similar problems I will tell what I found. As mentioned in the earlier posts I had run 150' of cable out to the drive end and connected it to the far end of the existing comm cable to the drive, the near end to another USB-RS485 adapter (Easysync ES-U-3001-M). When this worked I thought that it proved that the problem wasn't hardware but either my software (doubtful, the string being sent matched the example in the manual) or a drive configuration problem. WHile I was talking to "Sam" at Hitachi, I noted that one time that I sent the command message I actually got a returned "ACK" message. Hmmm!!?? Well the USB adapter I have, designed to be used as RE232, 422 or 485, has a number of configuration jumpers inside, which allow adding 120 ohm termination resistors and 750 ohm pullups and pulldowns to certain signals. I enabled them and "Bam!" the drive starts seeing, and replying to my messages. Apparently the adapters have a more sensitive front end than that at the drive, or at least are matched (reasonable) allowing them to successfully communicate over ~300 feet of twisted pair in their out of the box configuration, but the drive needed the configuration changes. Still have a big headache (real one), and now have to talk to another Hitachi drive, which uses Modbus rather than the simple protocol of this drive.

Thanks again for the support, it can feel pretty lonely out here with out you folks!

[Wayne.C]

Putnam,

Thanks for posting that.  Your mention of biasing resistors jogged my memory about an app note I found the other day on RS485 networks.  Includes sections on termination and biasing of 485 networks.  http://www.bb-elec.com/bb-elec/literature/tech/485appnote.pdf

Adding as file attachment as well.

Message Edited by Wayne.C on 09-29-2009 10:23 AM

[RavensFan]

That's good to hear.  Out of curiosity, what is your baud rate?  I wasn't thinking of termination resistors because 150' doesn't seem that long for RS-485 considering it is supposed to go to 4000'.  Usually longer runs or higher baud rates take you from the realm of not needing termination resistors to requiring them. 

Modbus really isn't that hard.  I would recommend looking at the documents at http://www.modbus.org/specs.php to get an overview of what is in a modbus message.  Also, use the modbus libraries that are available for download at NI.  I use the 1.1 version of this library.  It was recently updated to version 1.2, making the VI's polymorphic.  I would assume they work as well as the older version.

[LV_Pro]

I was not thinking that termination resistors were necessary either. I did try different baud rates in my search, but am back at the inverter default of 9600. The next unit that I am going to struggle with, a "Lighthouse Solair1100" particle counter defaults to 19200, but the run is only about 10 feet. I think that what made the difference were the pull up pull down resistors, which pull the TX+ to VCC , TX- to gnd, RX+ and RX- using 750 ohm resistors.