AB Basic Module Serial Output to FTP Ethernet

I am daunted with a new task at our facility that utilizes the Allen Bradley SLC Basic card, programmed with PBASE. Our application prints data from the basic card to a serial ASCII printer, used for auditing purposes.

We want to use the second serial port on the SLC basic card to somehow drive this information through a serial to ethernet converter, and send the data to a file storage PC, via the plant's network. This PC will run whatever software is required in order to receive data. This PC will be dedicated for information only.

Has anyone ever come across this in their past applications?

In most cases, the platform is SLC 5/04's. Would it be more beneficial to somehow use 5/05's, and get the data through the M-G files and send them through ethernet?

I would much rather send the actual data that is printed, due to the fact that I won't have to modify the program or hardware, tremendously. (Through the serial port)

Is there any examples of how the data would be sent to a file folder in explorer on a route drive C for example?....or is this even possible with my hardware?

Thanks for any information that you may bring to my attention,

What you described is doable. The hard part, at least for me, would be the coverting the Ethernet signal back and log it properly in a database. Unless you are a seasoned PC programmer, this would “suck”. What format will the PC log the info into, Access, SQL?



A few options:



* If the PC is dedicated to log info for this process, then why not just put the PC next to the SLC and run the serial cable from the BASIC module right into the PC? This would simplify thing quite a bit.



* If you go with a 5/05 then you can use RSLinx (not lite version) to DDE or OPC the data. You still need a small VB program to log the info.



* Or if you got the budget, use 5/05, RSLinx, RSSQL, then it’s all drag and drop and you are done. No programming.



Btw. You do not need to use the PBASE software. Hyperterminal works fine.

Also, do you have ANY AB Ethernet processor currently in the plant? I got another idea but it would require you to have a AB Ethernet processor elsewhere.

Thanks for the reply harryting.

The plan is to use the PC with about 15 application PLC's. Actually, DAQ stations. They will connect directly to the industrial ethernet system in the plant and connect to the PC through a hub.

We have many ethernet PLCs on site. Many are networked, but not all.

The largest problem that I can see is that the application in the Basic Module prints a pre-formatted document, as per the program within it. I don't think that I can get the same information from the PLC backplane in the same format. That is why I wanted to use the serial port to ethernet option.

Price does not seem to be an issue here, so I like your drag and drop ethernet idea. Could you elaborate?

I realize that I can grab data from the PLC, but I need to format it somehow if this is the method. Is this possible?

Thanks for your help, let me know if you need any additional information,

Cheers,

What you need is one of the many serial - ethernet - serial adaptors available and a program like Software Wedge which will read serial ASCII data and send it to a spreadsheet or text file. To the PC the ehternet link appears as a virtual serial com port.

http://www.bb-elec.com/tech_articles/merging_ethernet_serial_technology.asp

I have also written a program in Delphi that collects serial data in ASCII format from measuring instruments and stores it in an Access database. The serial activeX controls I used were Async Pro.

http://sourceforge.net/projects/tpapro/

I'd go about this in an entirely different fashion KCarlen. If the PLC's aren't ethernet capable (SLC 5/05), you would need to add NET-ENI adapters, but still..

User RSLinx and RSSQL (one copy each) on your server, and let them handle the actual communications. If you aren't going to a 'standard' data-format, you can still use RSLinx (Professional) and DDE/OPC to a VB program you write to handle stuffing your data-tables.

It's much more flexible this way, adding nodes doesn't require more BASIC modules, and the communications interface is done and reliable.