Sign in to follow this  
Followers 0
KIKO

ODBC

10 posts in this topic

hello I just want to know how does the ODBC in windows work?and how it should be related to the database and the HMI software. Thanks

Share this post


Link to post
Share on other sites
My understanding of ODBC is schetchy and rough at best, but from the couple of times I've seen it used it functions as follows: You author an HMI program which uses a database and instead of referencing a specific file like C:\mydata.mdb. you reference the ODBC file name of Mydata.mdb. Windows is then set up thru ODBC to redirect all requests for mydata,mdb to C:\mydata.mdb or to Z:\Mydata.mdb where Z: is a networked drive. This allows the customer to change the database location for your program without needing the source or having to "look under the hood" of your program. Hope this oversimplification helps some.

Share this post


Link to post
Share on other sites
ODBC is Open Database Connectivity. It's just a protocol to talk to your database. For example, once an ODBC is setup in Windows and established between your database and HMI software, you can use SQL statements like SELECT, INSERT, UPDATE, etc. to retrieve, insert or update data into the database. Each HMI software package has its own quirks of SQL statements but basically they should be similiar to accomplish the same task.

Share this post


Link to post
Share on other sites
Thanks alot, I understood your explanation but I just want to know something it may look stupid:) but it will help me for more undrestanding. my question is; why does the Hmi program use the database?...when I opened the database of my application I found many tables with some tick mark on some cells of the table..but I don't know what does that mean? Regards Edited by KIKO

Share this post


Link to post
Share on other sites
Some software programs, HMI programs alike, use databases to store information such as I/O mappings, etc. If that is what you are playing with its best not to touch it or you may lose some information.

Share this post


Link to post
Share on other sites
many thanks... I'm still can't get the role of the database on the coomunication between PLC and the HMI application...I will tell you some points which may help for more explanation: *There is always a database file on the computer of the HMI application.That file sometimes can be an access file or sybase.I just know that is the database file for the HMI application. I thought that i should find all the analog and digital signal from the plc on that database,but that was not true I just found a static tables... I want to understand what's the function of that tables and what's the infra structure of the HMI application,and how is these tables (or database) are linked to the HMI application . Also I'm wondering what's the best way to backup that database? Any help & discussion is appreciated...Many thanks again for all the previous replies.

Share this post


Link to post
Share on other sites
I've divided your question into parts because each is involved in and of itself and will vary greatly depending on the HMI application {Wonderware, CItech, RSView, etc} that you are using. My answers for now will be in general terms and if you can provide specifics then others can provide more detail. 1. Function of the table and HMI Infrastructure. - The tables can contian any thing from object definitions and locations to communication protocol settings and passwords. 2. How these tables are linked to the application. Again this depends on the HMI. But many use SQL statements and jet engine drivers. 3. The best way to back up the database. I would say as a generality use your HMI creation software and backup the program and all its databases. Failing that a simple dos/windows copy of the files could prove usefull or disastrous depending on your HMI application. Hope this helps some.

Share this post


Link to post
Share on other sites
Thanks BobLfoot I'm using an HMI application which called Picos.net it's an industry specific one.and the PlC is AB control logix the hmi is showing the process details and alarms and ofcourse many analog and digital value etc. I'm using the Sybase database. I have the address's on the plc for the words which will be read and write to the HMI software, also I have that addresses on the HMI software...so it's clear for me how the HMI and the PLC are communicating with each other...BUT what about the database role?

Share this post


Link to post
Share on other sites
It could be storing historic data, alarms etc. I've used databases before to store batching results or delivered material data, to enable reports to be generated. Edited by Groo

Share this post


Link to post
Share on other sites
ODBC connections are really simple. They just define a database connection with the parameters you'd expect: database type, database name, address, port, username, password, etc. They're also easy to set up. You go to "Data Sources (ODBC)" in the Control Panel->Administrative tools. "User DSNs" refer to connections that are stored under that windows login name. "System DSNs" refer to connections that any user can access. The role between database and HMI is changing. Fundamentally, every HMI system needs some kind of "database". This is where it stores variables, paths to the PLC, update rates, caches PLC values locally (so it doesn't have to slam the device all the time), and most importantly, logs historical data. In the early days of HMIs it was standard practice for authors to write their own database. The sole advantage is that it can be kept hidden from the user - for simplicity. Early packages chose to use a myraid of bad ideas, typically consisting of some sort of text or binary files or their own concoction. These tended to be: difficult to back up or maintain, prone to file damage, would slow way down over time, did not do well with queries or later analysis, were not efficient in terms of file size (compression, file structure, etc). It quickly became obvious that developed SQL databases had already tackled these problems. Thay have the additional benefit of being supported by IT departments. Now, every major vendor supports SQL databases to some extent. Most have chosen to use Microsoft SQL server or a variation of it (Wonderware sells InSQL server, which is their own custom version of SQL server). They typically employ this for the "historian" (datalogging) portion of it and for: recipes, transactions, and the likes. Most of these companies still use their own local scheme for their database and communication between nodes, but use the SQL database for the larger sections of data. ie Wonderware uses Archestra, Rockwell FactoryTalk, etc. They've expanded this notion to include communication between their computers (client and server) and also PLC communication. At Inductive Automation we've chosen to use an SQL database centric model. All of our communication between HMI and PLC go through an SQL database. The advantage is simplification in setup and maintenance, and that any product that can talk to an SQL database fits right in. Many other vendors only want their own software to be compatible (they will go further and obfuscate their SQL tables, this is not necessary for performace). Our theoretical disadvantage is that there is more traffic (overhead) since everything goes through the SQL database. We've found this to be negligible since SQL databases are very fast and tend to be able to handle orders of magnitudes of data more traffic than PLCs. Hope this helps - the real answer is that the role between database and HMI is changing. To what extent depends on who you ask. Edited by Nathan

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0