Continue to Site

Eng-Tips is the largest engineering community on the Internet

Intelligent Work Forums for Engineering Professionals

  • Congratulations KootK on being selected by the Eng-Tips community for having the most helpful posts in the forums last week. Way to Go!

Capture Large RS-232 Data Stream 1

Status
Not open for further replies.

rmaier9

Automotive
Aug 13, 2018
4
Hello,

I am relatively new to PLC. I'm well versed in electronics, just not so much PLCs. I was hoping you all could provide me with some direction.

We are trying to capture a long data stream via RS-232. We send a request for data byte. Then come up to 200 bytes of data (length is known ahead of time). We are using the Automation Direct Productivity 2000 Series PLC. The challenge is that it only has a 128 byte data buffer. We are able to capture some data, but a lot of times we miss a data frame due to some missed data points. Our speed then suffers. Maybe 3 data frames per second.

So, from an experienced PLC programmer's experience, should this be something that can easily be done with ladder logic? Or, is there some sort of intermediary device that will buffer the data for us?

Asynchronous communication seems to be the easiest to implement. I'm guessing the best way is through a converter module. If so, any recommendations on a decent device for this?

One more thing, using Serial TTL 0-5 vs the RS-232 +/-15V would also make my life easier.
 
Replies continue below

Recommended for you

A little more info please.

What are you talking to that barfs out 200 bytes a request?

What is the data rate?

Is there no provision for communications handshaking? No RTS line? No XOFF/XON function available?

===========

0-5V serial is good for 3 to 5 feet inside the same enclosure surrounded by the same grounding.

Keith Cress
kcress -
 
Hello Keith,

Thanks for your response. We are communicating with an electronic controller. The PLC is intended for an End of Assembly test. It simulates the application and constantly monitors feedback from the data stream. It's a proprietary system.

There is no handshaking. No RTS, etc. It's basic UART. Data rate is 38.4k.

The 0-5V length is limited to a specific installation, but we have that under control. That is simply how things are typically done with low cost microcontrollers. The addl. hardware cost for real RS-232 are not justified.

We were able to wrangle the PLC to get data. And it is almost acceptable, but I prefer an easier solution for future applications if possible. For example, when our Windows-based software communicates with the boards, we use an FTDI cable/IC. It has USB to serial converter (TTL) on it. The key is that it has a buffer of at least 1kB for the Rx side. That way, we can take in the serial data onto the PC "whenever we are ready for it".

Is there a device that would do the same? Some send byte request via ethernet or similar... and then some receieve request command via ethernet? It should have capability to clear the buffer as well.
 
Baud rate converter

These things need buffering to handle rate conversions. You use the same rates but use the handshaking available to control the data coming into the PLC to a speed or data block size that's usable. This handles the crude (stupid) handshakeless instrument output you have to contend with.

ANother flavor

Keith Cress
kcress -
 
Great. Thanks for the tips. Serial buffer was what I was looking for, but I couldn't quite articulate it.
 
Yep. it's one of those hard things to find on google. Put in 'serial buffer' and you get a million pages of software stuff or ICs that buffer the electrical aspect not the data aspect.

Google searches have decayed over the years into something akin to searching for a snake while looking thru a straw.

Keith Cress
kcress -
 
itsmoked - it's less a problem that the view is too narrow as there is so much overlap. I recall reading that a certain college decided to add it's considerable language database as a source for spell checking, not realizing that almost every combination of letters shows up in some language as a legitimate word.

After a while it seems like it is asking a Genie for a magic wish and not being sufficiently specific, ending with an undesired result. I have had occasion to play this search game for a while before hitting on the correct combination of search terms. This is where metadata searches could help = for example, asking for answers to be drawn from "network integration" areas. Unfortunately, getting people to correctly apply metadata is nearly impossible.

Edit to add - using negative terms can also help. Such as "-circuit" to eliminate serial buffer circuit designs.
 
I hope you realize that most laptops do not come with RS232 ports anymore. So your have to find a USB to RS232 interface for capturing data.

Then get familiar with the program Putty (hyper terminal old days windows 2000 or before) or similar serial data display programs. Maybe lab view has this RS232 interface for capturing data? Most interfaces anymore are ethernet, so don't let any vendor sell you an antiquated RS232 system as an interface. Or just specify the interface you need.
 
There is always Arduino. Coding is straightforward and you get exactly what you want. Shields are available for proper levels.

Gunnar Englund
--------------------------------------
Half full - Half empty? I don't mind. It's what in it that counts.
 
We actually design the electronics and manufacture them. UART is king for the cheap stuff. I have written drivers to interface with USB to RS-232. Pain in the ass... Until you figure it out.

With micro controllers, at least for us, everything is still UART (~RS-232) or CANbus. Sometimes K-Line. A CANbus chip is like $0.30. UART is essentially free! So for a low cost device, UART is the way to go. Mostly for engineering use or factory diagnostics.

In the past, I've created test stations using custom PCBs and Windows I/O modules. The problem is extensibility. Add an extra function, and you need a new PCB. So, we started venturing into PLCS. Since everyone and their mom uses PLCs, we thought it's time to go that way. At this point, I'm not sure it's really any easier in the end, just different...

So, there's a bit of a learning curve here. I appreciate the advice so far.
 
is the best thing I've ever found for diagnosis of serial communications.

To me, the description sounds like not using the correct PLC, rather than a problem with PLCs overall. There's quite a few PLCs that handle serial communications, normally they're a lot more expensive than the Automation Direct ones. I've seen instances of using ladder logic and specific instruction sets to manage the buffer, but a lot of the time its not worth the development effort to get the lower specification PLC to do the job compared to buying a higher specification unit.

This might well be a good example for an Arduino application.

EDMS Australia
 
But here is the deal about PLCs. If your bringing in vender/OEM equipment. You as a customer need to have very specific rules that need to be followed in there control panel creation. What I mean you specify a particular brand of PLC and this goes for any component that you commonly use. So if your going down the route of Automation direct PLCs then stick with Automation direct PLCs for your plant. Otherwise you get into the situation where you have like 5-10 brands of plcs in your plant and it turns into a maintenance and spare parts nightmare.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor