PLC to Excel communications

I am working on the following test system:
Barcode reader connected to PLC reads label.
The PLC search for this number in Column A of an Excel file (Up to 2000 rows in Excel file)
PLC reads about 10 cells in the row with the matching number to set up system.
Test is performed.
PLC writes number read from label and one measured value to the next row in another Excel file.

I am planning on using either an AB Micrologix 1200 or Siemens S7-226 PLC. How difficult is it to do as mentioned above? Can a Excel VBA macro handle most of it or is extensive PLC logic required?

Thanks,

Adrian

I have often seen this type of thread on this forum and would say that it is perfectly feasible to do what you want using VBA (the ML1200 might be a problem as you would need to connect the BCR and the Excel PC to a single serial port). I would, however, question why so many people feel that they need to use Excel as a database in this kind of application. For a single stand alone system SQL Server is available as a free download (desktop edition) and provides a far more powerful and efficient means of storing data. I would use a DDE server (ie Linx) to get the data from the PLC and ADO to write it into the database. Excel could then be used as a simple front end for viewing the data. I would normally pass the data to the DB via a stored procedure which would query the list of codes and append the resulting data to the log. SQL Server seems to frighten many people but it is not really so difficult to get to grips with.

The ML1200 I am planning on using is a 1762-L40BXBR which supposedly has two communication ports. The reason I am planning on using Excel is that the customer already uses it to store all the information. Their current file has 1641 partnumbers and the file has over 70 columns

While I have absolutely no problem with the idea of using Excel directly as your storage medium, I do think Andybr's system is a little better, even for this application, if for only one reason.

By writing directly to the spreadsheet that the customer opens and uses, you run the very real risk of an accidental spreadsheet modification that would render your system inoperable. A hands-off system for storage would be much better. This way, the communications and data gathering would occur regardless of the end-user and the customer is only faced with retrieving the data from the SQL database.

Just my 2-cents.

Steve