RSSQL, MicrosoftSQL, Micrologix 1200 possible?

[Eddi1984]

Hi FYI, I am new here ;o),

first an explenation: I have a Micrologix 1200 PLC, a serial to Ethernet adapter (from AB), a Endress + Hauser Ultrasonic controller, Keypad (with microcontroller sending code over rs485).

The setup: Ultrasonic is monitoring a diesel tank. this info is transmitted via 4-20mA loop to the micrologix analog card. alarm is than sound, if tank level to low.
A employee wants to fill up his forklift and has to punch in his code. The code is sent to the PLC, the PLC checks the MicrosoftSQL database via RSSQL (Ethernet), and if valid, the PLC startes the pump.

Q: Is it possible to set it up this way? I don't know what exactly I need to make it possible. How the code should look. Can I read with my plc from the SQL database? Can somebody help me on this?

Thanks,

Eddi

 

[Eddi1984]

Hi,

can somebody help me on my question, or is here nobody experienced enough?

Thanks,

Eddi

 

[SNK]

It is all possible Eddi.
The only thing that I don't have experience with is the RSSQL part, although I have heard it is good.
Do you really need to use the database? How many users are there?
You can add a lot of users to the data tables supported in the 1200 stand alone.
It is ALL possible though.
You probably would have been better off with a 1100 in place though.
(Native Ethernet, but check on type for SQL required)

 

[surferb]

Not bad with FactorySQL - also possible with RSSQL. We can get into implementation details if you'd like. Your requirements are pretty broad stroked - with lots of coverage.

 

[Eddi1984]

Thanks for your replies. Appreciate that, and cleared a few question marks.



I was planning to use the database, because I have to create a web page, where users can login and enter access codes. If I can get around not using the database, it probably would make my life easier. But I need room for approx. 300 access codes (that includes: Name, Access code, expiry date, how often the code can be entered, and because it is a diesel tank, I need to keep track of how many liters the user used in total, and I have to be able to set a total) I don't know how much space that will take up in the plc.



Any ideas?



Thanks,



Eddi

 

[harryting]

Anything to do with string type will fill up a PLC in no time, unless you are dealing with Contrologix processor.

You could also use a HMI and store the data in memory tags and use it for the operator interface as well.

 

[surferb]

You are correct on wanting to use a database in your application for several reasons:
1. 300 codes including several fields (date, strings, etc)
2. Web page access - server side scripting pages (ASP, PHP, Cold Fusion, etc, etc) are all designed to work with SQL Databases easily and NOT PLCs.
3. Keeping track of long term totals in the database is better than the PLC to protect from power loss and provides a greater granularity of querying.

Thanks for your replies. Appreciate that, and cleared a few question marks.



I was planning to use the database, because I have to create a web page, where users can login and enter access codes. If I can get around not using the database, it probably would make my life easier. But I need room for approx. 300 access codes (that includes: Name, Access code, expiry date, how often the code can be entered, and because it is a diesel tank, I need to keep track of how many liters the user used in total, and I have to be able to set a total) I don't know how much space that will take up in the plc.



Any ideas?



Thanks,



Eddi

 

[SLC_Integrator]

I've done a few RSSQL applications and they are pretty straightforward as long as you keep it relatively simple.


What data are you looking to transfer between the PLC and SQL ?

 

[Eddi1984]

The communication and data transfer should be as follows:

Somebody enters a user into the database (Microsoft SQL 2005 Express) via a web interface. The operator enters: name, 5 digit code, times the code can be used (like 5 times than it expires), expiry date, how many liters the person is allowed to fill up, and total filled up to date.



Now the Trucker comes, entrees his code. The code is entered into a keypad. The keypad is connected via RS-485. The keypad sends the code to the PLC. The PLC receives the code, and forwards the code via RSSQL to the database. The database should start a query, and check if the code is existing. If it is existing or not existing, the database sends a string or whatever, back to the PLC. If the code was valid (the code is entered into the database and not expired) than the trucker can fill up.



In an event, that the code was valid, the PLC receives the total liters, the allowed liters and the usage number (how often the code can be used), and is adding/subtracting this info. After the trucker is done, the PLC sends the updated info back to the database, to be updated.



That is the brief communication process.



I was reading the RSSQL manual, and as far as I understood the manual, I can run queries, or call queries with RSSQL!???



Thanks,



Eddi



PS: what commands, or how can I get the PLC to send info (Strings, integer etc.) to RSSQL????

 

[surferb]

Eddi,
You can definately do that with FactorySQL. RSSQL should be possible too. I don't think you can do read instructions from the PLC. You typically set up PLC trigger conditions that cause reads or writes. RSSQL is big on using SQL Server stored procedures.

A few points:

1. Your web interface will be responsible for validating the PIN - easy.
2. PLCs aren't good with datetime data formats, you'll need to write in values that the PLC understands - not a huge issue.
3. You'll want to consider your requirements to come up with an SQL database schema that makes sense for your process in terms of what you want to track. For example, is a PIN necessarily tied to a user at the web end upon generation? Much of this can be done at the web end, seamlessly wrt the PLC/process.

Edit - forgot to mention, sounds kind of funny that you're using RSSQL and SQL Server with a Micro. Have you checked out the pricing for what you're looking for? Maybe there's a small, low tag version...

The communication and data transfer should be as follows:

Somebody enters a user into the database (Microsoft SQL 2005 Express) via a web interface. The operator enters: name, 5 digit code, times the code can be used (like 5 times than it expires), expiry date, how many liters the person is allowed to fill up, and total filled up to date.



Now the Trucker comes, entrees his code. The code is entered into a keypad. The keypad is connected via RS-485. The keypad sends the code to the PLC. The PLC receives the code, and forwards the code via RSSQL to the database. The database should start a query, and check if the code is existing. If it is existing or not existing, the database sends a string or whatever, back to the PLC. If the code was valid (the code is entered into the database and not expired) than the trucker can fill up.



In an event, that the code was valid, the PLC receives the total liters, the allowed liters and the usage number (how often the code can be used), and is adding/subtracting this info. After the trucker is done, the PLC sends the updated info back to the database, to be updated.



That is the brief communication process.



I was reading the RSSQL manual, and as far as I understood the manual, I can run queries, or call queries with RSSQL!???



Thanks,



Eddi



PS: what commands, or how can I get the PLC to send info (Strings, integer etc.) to RSSQL????

 

[Eddi1984]

HI,

Thanks for the replies. I got the Micro1200+Ethernet module for approx $600 CAD. That is not to expensive.



For the SQL table, I will only use one table with all info in it. I do not have a ton of info to store.



Well, thanks for all of you for your input. I guess I have too sit down now, and do my homework, and read up a few manuals etc.



If I have further questions, I will post them.



Thanks a lot.



Eddi

 

[surferb]

Lol - I know Micros are cheap. I was referring to RSSQL - might want to get a quote and play with the software first. I'm not sure what it runs; I think it's going to be quite a bit steeper than your Micro. You'll probably need some version of Linx to go with it.

Thanks for the replies. I got the Micro1200+Ethernet module for approx $600 CAD. That is not to expensive.

 

[ghettofreeryder]

Our company has moved away from RSSQL and are currently using FactorySQL from Inductive Automation. Couldnt be easier, and the tech support is by far the best i have seen, which can not be said for Rockwell

 

[Eddi1984]

I got a RSSQL to test the communication setup and I have to get everything working, than we have to buy the licenses for the software. If I can't get it going, oh well, than the project is canceled. So I hope that that will not happen.

Eddi

PS: I had a look at FactorySQL and it looks promessing, BUT I do not think, that I could get a demo or something, too test and try the setup. The application I am planing to use it in, and because I do not have the expirience, I can not justify a purchase of FactorySQL. To bad.

 

[surferb]

FactorySQL has a fully functional (2 hour runtime) trial that can be downloaded from here. In my experience, which is a few years dated, FactorySQL is much simpler to configure than RSSQL. However, your setup will necessarily involve a little SQL database layout and being able to thing with the triggering/transactions/etc. This is true of either package, and both will be simpler than coding it - your requirements are custom. Not bad, but not as simple as drag and drop datalogging, etc.

Out of curiosity, did you get a RSSQL quote?

I got a RSSQL to test the communication setup and I have to get everything working, than we have to buy the licenses for the software. If I can't get it going, oh well, than the project is canceled. So I hope that that will not happen.

Eddi

PS: I had a look at FactorySQL and it looks promessing, BUT I do not think, that I could get a demo or something, too test and try the setup. The application I am planing to use it in, and because I do not have the expirience, I can not justify a purchase of FactorySQL. To bad.