Click PLC communications

My apologies if this is answered somewhere else, but I'm not getting any results with my search keywords. I am an experienced software developer, but I'm new to PLCs. It's possible that I don't yet have the relevant vocabulary to search effectively.

I work for a manufacturer who would like to get real time data about the quantity of product coming off the mills. There is an existing installation in one of our plants that uses proximity sensors fed into a Durant(Eaton) Ambassador 57601-400 counter, and there is a Java app that periodically queries it for information to put into a database.

The counters are older technology (and unitasking at that), and they are priced like they don't want to sell them anymore.

What I'd like to do is use a Click PLC instead of the counter. Unfortunately, I haven't seen anything that specifically says it can communicate with the Java app in a similar manner to the counter. I'm pretty certain that the data is retrievable in some manner because we set one up with a pushbutton and an app to count the button presses, and I can see the data increment onscreen during testing.

I'd like to know if what I am trying to do is even possible, and if anyone out there has tried this before. Any known-good links would be appreciated as well.

Thanks in advance...

It is possible, we have had a few customers that have managed it.

The Click PLC uses MODBUS RTU for communications. You can find all of the relevant standards at the MODBUS Organization website. MODBUS is a very well supported protocol and there are tons of third party communication applications that might interface to your system.

Modbus in the Click is pretty easy to set up, keep in mind that it only supports Modbus RTU (not Modbus ASCII).

Which would be great if this thing spoke Modbus. It doesn't.

Go to: http://downloads.eatoncanada.ca/dow...601400, 57602400 and 5760X450 User Manual.pdf

to get the manual, skip to page 18. You will see that they kind of went off of the reservation when it can to communications. (at least it's RS485).

All is not necessarily lost, I implemented a subset of Modbus ASCII in the Click for a job in California, so it can be done. If you like, I'll see if I can dredge up my old code and mod it a bit for your purposes.

Rootboy -

I think we may be operating under mismatched ideas. Just to clarify...I'm not looking to use this WITH the Durant unit.

I'm looking to replace the Durant with the Click PLC.

Our existing setup at the other plant talks to the Durant appliances all the time through the command language you noted on page 18. That's not a problem, and, in fact, it will be our default practice for new mills unless I can figure out how to get information out of the Click appliance.

It just seems to me that if I can switch from buying over a dozen of these $450.00 counters for two $69.00 PLCs, then, basically, everyone wins.

I keep getting the impression from my investigations that comparing the Durant and the Click PLC is like comparing apples to oranges...one can't supplant the other.

It comes down to how the Java app is communicating and how many different ways it CAN communicate. Is it set up to ONLY communicate with the Durant? If it has other communication protol options and if Modbus is an option then it's all ok. Otherwise you may have some work to do.

The Java app has a component specifically engineered to query a Durant appliance over the serial port connection, and I was always figuring that it would have to be "tweaked" (at minimum) to work with the Click PLC.

The thing is...I need to find enough information about it to learn the programming model before I can even consider diving in.

I learn best by understanding the model, so even links to remedial tutorials would probably help a lot.

jeffreystacks said:

The Java app has a component specifically engineered to query a Durant appliance over the serial port connection, and I was always figuring that it would have to be "tweaked" (at minimum) to work with the Click PLC.

The thing is...I need to find enough information about it to learn the programming model before I can even consider diving in.

I learn best by understanding the model, so even links to remedial tutorials would probably help a lot.

Click to expand...

Yup. The Click isn't going to get you there all by itself. It speaks Modbus RTU, and your Durant (and by extension, your Java app), does not.

I've been there with the Click, "Tweaked" isn't the word that immediately comes to mind.

The Click will work, but you will have to create your own driver. The other (much more sane) option is to replace the Java app with a Modbus RTU Master driver. This makes more sense since you will not be locked into a dead communication protocol.

The only "native" option for Modbus on the Click is Modbus RTU. And it's more complicated than Modbus ASCII.

Modbus ASCII has defined start and stop characters while Modbus RTU uses a 3 1/2 character (minimum) dead span to denote the end of the last message and the beginning of the next.

So if you have the java source, which I assume that you do, rip out the comm section and install a Java lib instead Such as: http://jamod.sourceforge.net/)

jeffreystacks said:

I learn best by understanding the model, so even links to remedial tutorials would probably help a lot.

Click to expand...

http://langhofer.at/fileadmin/downloads/sineaxcam/Modbus_Basics.pdf

http://www.chipkin.com/files/liz/MODBUS_2010Nov12.pdf

(from the Chipkin manual) Truer words were never spoken.

"Because it is so commonly used, because it is so limited, because some
vendors went to a lot of trouble and because some vendors hired bad
programmers, Modbus, as simple as it seems, can offer lots of complications."

Chipkin also has their "useful tools" page:

http://www.chipkin.com/useful-tools-and-applications-for-modbus/


You will need to get yourself a Modbus monitor program. To try to work with Modbus any other way is insane. Chipkin has this page as well:

http://www.chipkin.com/products/software/modbus-software/

And a Modbus video (pay close attention to the RS485/RS232 discussion).

http://www.youtube.com/watch?v=OvRD2UvrHjE


Enjoy!

Yep, RootBoy..."tweak" was the polite word...

I think we're on the same page. I'll be reading up on those links over the weekend, but thank you for coming through with them for me. I appreciate that very much.