database

[snowmaxx 0]

I have a CS1G-CPU44 and I was wondering if there was an easy way to put my microsoft access database on the plc or if there is an easy way to access the database from the plc. Any thoughts?

[scottmurphy 1]

Not sure exactly what you are wanting to do, but is your database for your tag development? If so, if you can copy the tags directly into the symbol table. You just need to have the column format correct. I, and probably others here, use excel to generate tags, then copy in.

[snowmaxx 0]

Well I have an Indusoft front end that I am using to create and edit the database. The information that I am putting in the database consists of card numbers, employee ID numbers and other things pertaining to a access management system. Using the database was what I thought would be the easiest way to manage the information. I have my protocol reading the access cards and storing them in the D memory area. The reason I was using the Access database was that I am under the impression that doing queries and making changes to the database is easier than excel. Now this is the part I am confuesed about at the moment, do I put the database on the plc so it can interigate the database, or do I leave it on the computer and have the plc communicate via the peripheral and interigate the database. Now I am fiarly new to PLC's in general and I don't really know how hard either way would be, or even if both opetions are viable. I was kinda thinking that putting the database on the PLC and doing the interigation from there was the easiest.

[TERdON 9]

So, if I understand you correctly, you'd like to use a database during actual production use of the system to store all data about access rights etc? No, PLCs don't run databases. Did you even check the system requirements for the database? You normally need a full operating system, like Windows or Linux to run them. Also you'll need permanent storage, like hard drives. Your PLC has neither (except a miniscule amount of flash, probably less than on a diskette) You could possibly build some kind of custom SQL client on the PLC and use a Ethernet Card (ETN*) to interface an external database directly, but in my opinion it wouldn't be very easy and would take a lot of time. The approach I'd take would be to build a simple computer application which acts as "glue logic" for the database, which can use a less advanced protocol than SQL in communication with the PLC. It could even act as a communication master, constantly checking possible new "queries" in a special DM. For communication between computer and PLC you'd either use Host Link (serial) or FINS (Ethernet). Edited 30 Nov 2006 by TERdON

[snowmaxx 0]

We have a box with Win XP pro sitting that will be running our applications. Both indusoft and the database need XP to run, so that part is covered. The rest of it is what I was trying to figure out. If I need to create some sort of way for the PLC to communicate with the database, do you think that the VBScript that you can do in indusoft would be a good interface. Remember that anytime a card is read I need to access the database asap an unlock the door if access is granted. The other thing that I was thinking about doing was writing all the information directly out of indusoft and storing it on the PLC. But I wasn't sure how to manage all that information on the PLC. Oh yeah, we are using the OMETH drivers that come with InduSoft to communicate directly with the PLC already. If that makes any difference at all.

[Berti Baker 7]

So here's a few ideas for the 'glue logic' 1. If Indusoft is an OPC Client, then use Omron's OPC Server (called CX-Server OPC) to connect Indusoft to the Omron PLC. Just define a block of memory areas for storing this data and write the values to these addresses. or 2. If you have good Visual Basic knowledge, Omron's "CX-Server Lite" is the perfect tool for all Omron device communication from Visual Basic. Of course VB itself has good database access built in, and 'Lite' gives you an easy ActiveX control to handle all communciations worries. or 3. If database programming or VB script is not your forte, or you might need some graphical front end too then consider CX-Supervisor. It has really easy 'programmless' db access and of course all PLC communications too. I'm not going to write you application for you but will give you some more pointers if you explain which you think you need.

[snowmaxx 0]

OK, I kinda made some decisions after looking at more of InduSofts capabilities, and visiting the facility that the system will be going into today. In Indusofts built in language, they have the functions that allow for the easy creation of the database. The computers that will be running the Indusoft front end are constatnly in commnication with the plc, and what makes it even easier for me is that Indusoft has built in drivers that are easier to use than Fins. So I can easily use Indusoft as the interface between the database and the plc. Also today I got a copy of thier most current plc and InduSoft programs. Now the main decision is to either use the built in language, or take care of everything using the VBScript that InduSoft provides. I am kinda leaning towards the built in language, so I don't have to learn as much VBScript at this time. Only for time reasons though. New question since I have an easy way to communicate between the database and the PLC, which type of database should I use? Really I can use various versions of SQL, Access, Excel and a couple others I can't think of right now. I think Access is slower than SQL, but is it worth the extra time to learn it to gain the speed out of SQL. And how much slower is Access?

[TERdON 9]

1. Excel is NOT a database application, it's a spreadsheet application. Bad idea to use it, as it's not really built to be used as a database. (Even though I know that people who don't really know what a database it do use it as one...) 2. Unless you have huge amount of database accesses (tens or hundreds in a second) I don't really see that performance would be an issue, regardless of which database application you choose. Remember that in this case you'd have a primary key (card #) which would make for very efficient lookup in the databse. I'd pick the cheapest and easiest to use.

[Berti Baker 7]

I second that opinion... Don't touch Excel with a barge pole and I've always found Access fast enough for all but the most extreme applications so would be easiest to try first. Remember, you should be able to refactor (i.e. to SQL) with minimal Indusoft changes if you really need to.

[snowmaxx 0]

Sounds like a plan. I have already started with Access, and it soudns like it should be fast enough. I am not doing logging with it, so I shouldn't need tons of speed. Thanks for the help guys!!

[moosty 0]

Hi, Use Access database if you - Have only one computer - your database has less than 1 000 000 records (If you are using Access 2003, if you use older versions, Access is not working efficiently after it's size exceeds ~ 100 MB , also your computers RAM memory is important for retrieving results from an Access database) Use Oracle or SQL Server if you - Need multiple user connections for your database - Your database needs to handle millions of records If you are making this project for only controlling a locked door, your database should be so small and can be controlled by an Access file I think. And for the Database - PLC connection, I generally prefer: RS232 Serial communications with host link commands if: - Only one computer is needed - Data amount is relatively small, such as a few data words - PC is close to PLC (Max. 20 meters distance, if this distance is more than 20 meters, I use two RS232 / RS485 converters) Ethernet communications with FINS commands if: - PC is far from PLC - Data amount is more than 100 words - An already made ethernet infrastructure I think, serial communications may be enough for your project, because serial communications is very simple and easy to debug in case of an error. I do not prefer to use CX-Server Lite because it sometimes freeze and sends non-fresh data, and you can not be aware if your connection to PLC has been lost. For both serial and ethernet communications, I always use my own routines developed in Visual Basic 6.0 If you tell me more, I can help you to develop some softwares for your project. Best regards,

[snowmaxx 0]

Thanks for the additionial help, but it looks like the boards we were using for the doors are no loinger going to work, and my company doesn't want to invest in different boards right now, so this project is on hold. If we start it up again, I may be asking for your help. Thanks again.

[Nathan 7]

If the project does start again, check out FactorySQL. It's a program that runs as a "communication layer" to coordinate/synchronize data between SQL databases and PLCs. I would highly recommend using the free, MySQL database over Access, but FSQL can work with Access. Edited 11 Dec 2006 by Nathan