Guys,
I work for a manufacturing company that manufactures building materials and home improvement products (treated lumber, steel siding, concrete products, etc). We are looking right now to find or create a standard for our HMI's. Currently all older HMI's that interact with our business system are written in Visual Basic 5 or Visual Basic 6 and communicate with the line through an Opto 22 G4 card. All of the newer lines use Visual Basic .Net (2005) and communicate through Ethernet. Below is some information and things we have been considering. I was hoping to get some opinions or other ideas. We are also debating between Visual Studio (C# & VB) or Java. Sorry to post this in the VB and Java section, but i wanted to make sure i get both opinions.
Description of Problem: We have a few problems we are looking to resolve...
1) Phased Deployments - We want to have a phased deployment so we can find problems before they become a issue on all the lines. For example, we would switch one line over at one site, then the next week
two at each site, then the rest.
2) Easy Roll Back - If we run into an issue we need to be able to easily roll back to the last version.
3) Component Re-use and Simple Updates - We want to be able to update some thing in one place and have it changed everywhere. For example, we use the same FTP class in all our VB applications . If we want to add a check to see if the server is on, we don't want to have to add this check in every program that uses this class or open every project and add the new class.
4) Easier Deployment of New PC's - We have a lot of issues with every computer tech setting up the line PC's differently. This may end up being more of a training issue, but I was hoping whatever method we use to deploy new updates could also make registry edits and file changes. This would eliminate 90% of the problems we get on program deployments.
5) Added Data Tracking - We currently only track the metrics that directly relate to production (What was produced, when, how long, etc). We would like to go much more in depth.
6) Better Data Retention Procedures - Right now we keep all data for a year and manually run a purge scrip every 3 or 4 weeks. We would like to automate this process and also put different limits on different items.
7) Faster Development for New Applications - We are always getting more and more requests (new apps and changes) the faster we can turn these around the more time we have to work on growing (new plants, new products, etc).
8) Developer Support Time - We spend a lot of time trying to figure out other peoples code. I realize this will always be a issue, but right now we look at some of the programs we have outsourced and we can not tell what code is used. There is also issues with no comments or documentation in some programs.
What we have looked into (Option 1): We looked into the idea of going with a web based HMI for a while but decided against it for a one reason: initial infrastructure investment. In a typical web infrastructure you have at least three servers. A Dev, Stage, and production. If you have a large number of users you may also have load balancing (3 production servers). If applications are spread across multiple sites you may need production servers for each site, especially if you do not have reliable communication between sites. This put the server count for my company at 10, at a total cost of about $80,000. This does not include software to run on the servers.
What we have looked into (Option 2): We looked into the idea of going with a desktop application where all the main logic would be done through web services. This would run into some of the same issues as the above. We would need 7 servers, but they would be much cheaper servers. at a total cost of $40,000. This would also not include additional software.
What we have looked into (Option 3): We would create a Windows Forms application that acts as a sort of shell. This shell would handle all of the behavior and functionality that is used in all the plants (such as production tracking, uploading stats, user management, etc…). The behaviors that would be specific to each plant or line would be implemented as separate components and interface with this shell through the use of plug-ins or Remoting. Updates would be handled through Microsoft’s Click Once technology. One of the downsides to this approach is that phased deployment and roll-back would be difficult. Despite this, we currently see this as our best option.
Back Ground Info: Our company is made up of 10 different divisions currently in 6 sites (currently around 22 plants). Over the next two years we are thinking about acquiring some companies, adding more divisions to each site, and adding more new sites. In all, we could be adding up to 4 additional sites and 14 plants over the next two years.
Until about a year ago all human machine interfaces that interact with the line and our business were done through relay i/o boards (Opto 22 G4) and Visual Basic 6 programs.
For the most part, our PLCs are mainly Koyo 05, 205, & 405's in all of our slower process plants and Allen Bradley in our more "high tech" plants. We have acquired a few companies and bought some equipment from OEM's that are not compatible with either the Koyo or Allen Bradley PLCs. Some of theses are Idec FA-2J, Idec OpenNet, Mitsubishi, and Seimins. On the operator interface side there is mainly Cutler Hammer (the one that runs Windows XP) and Panel Views.
Technical Info / Standards:
PLC: Depending on the application, it will be either a Koyo 05 or 205 if it is a low end application. If it is any thing other then a basic process it will be a Allen Bradley Compact Logix or Control Logix. We are using the MicroLogix in our newer lower end lines where using VB would be unnecessary. We have been putting Ethernet cards in all new PLCs, even when unneeded. However, about 75% of the plc's currently do not have Ethernet.
PC Programming: We are in the process of switching all of our applications over to Visual Basic .Net. We are using the Visual Studio .Net 2005 with the .Net 3.0 framework.
PLC to Visual Studio Interface: We use an INGEAR driver to connect to the Allen Bradley plc's via Ethernet. We have created our own Ethernet plug-ins to connect to the Koyo and Idec plc's.
Business System: Our back end business system is in Progress with some 3rd party add-ons. Some of these include Webspeed and Mapix. All old applications transfer and receive data to and from Progress via FTP. All new applications send and receive data through a web service using Progress and Web Speed.
Data Storage: We store all of our production stats and orders in a mySQL database. We are unable to easily directly interact with the Progress database. This is due to a limitation of the version of Progress we are using, we are looking at upgrading to resolve this issue. For any line specific data, like configuration settings, or temp data, we use XML files.
Thank you,
Brandon
I work for a manufacturing company that manufactures building materials and home improvement products (treated lumber, steel siding, concrete products, etc). We are looking right now to find or create a standard for our HMI's. Currently all older HMI's that interact with our business system are written in Visual Basic 5 or Visual Basic 6 and communicate with the line through an Opto 22 G4 card. All of the newer lines use Visual Basic .Net (2005) and communicate through Ethernet. Below is some information and things we have been considering. I was hoping to get some opinions or other ideas. We are also debating between Visual Studio (C# & VB) or Java. Sorry to post this in the VB and Java section, but i wanted to make sure i get both opinions.
Description of Problem: We have a few problems we are looking to resolve...
1) Phased Deployments - We want to have a phased deployment so we can find problems before they become a issue on all the lines. For example, we would switch one line over at one site, then the next week
two at each site, then the rest.
2) Easy Roll Back - If we run into an issue we need to be able to easily roll back to the last version.
3) Component Re-use and Simple Updates - We want to be able to update some thing in one place and have it changed everywhere. For example, we use the same FTP class in all our VB applications . If we want to add a check to see if the server is on, we don't want to have to add this check in every program that uses this class or open every project and add the new class.
4) Easier Deployment of New PC's - We have a lot of issues with every computer tech setting up the line PC's differently. This may end up being more of a training issue, but I was hoping whatever method we use to deploy new updates could also make registry edits and file changes. This would eliminate 90% of the problems we get on program deployments.
5) Added Data Tracking - We currently only track the metrics that directly relate to production (What was produced, when, how long, etc). We would like to go much more in depth.
6) Better Data Retention Procedures - Right now we keep all data for a year and manually run a purge scrip every 3 or 4 weeks. We would like to automate this process and also put different limits on different items.
7) Faster Development for New Applications - We are always getting more and more requests (new apps and changes) the faster we can turn these around the more time we have to work on growing (new plants, new products, etc).
8) Developer Support Time - We spend a lot of time trying to figure out other peoples code. I realize this will always be a issue, but right now we look at some of the programs we have outsourced and we can not tell what code is used. There is also issues with no comments or documentation in some programs.
What we have looked into (Option 1): We looked into the idea of going with a web based HMI for a while but decided against it for a one reason: initial infrastructure investment. In a typical web infrastructure you have at least three servers. A Dev, Stage, and production. If you have a large number of users you may also have load balancing (3 production servers). If applications are spread across multiple sites you may need production servers for each site, especially if you do not have reliable communication between sites. This put the server count for my company at 10, at a total cost of about $80,000. This does not include software to run on the servers.
What we have looked into (Option 2): We looked into the idea of going with a desktop application where all the main logic would be done through web services. This would run into some of the same issues as the above. We would need 7 servers, but they would be much cheaper servers. at a total cost of $40,000. This would also not include additional software.
What we have looked into (Option 3): We would create a Windows Forms application that acts as a sort of shell. This shell would handle all of the behavior and functionality that is used in all the plants (such as production tracking, uploading stats, user management, etc…). The behaviors that would be specific to each plant or line would be implemented as separate components and interface with this shell through the use of plug-ins or Remoting. Updates would be handled through Microsoft’s Click Once technology. One of the downsides to this approach is that phased deployment and roll-back would be difficult. Despite this, we currently see this as our best option.
Back Ground Info: Our company is made up of 10 different divisions currently in 6 sites (currently around 22 plants). Over the next two years we are thinking about acquiring some companies, adding more divisions to each site, and adding more new sites. In all, we could be adding up to 4 additional sites and 14 plants over the next two years.
Until about a year ago all human machine interfaces that interact with the line and our business were done through relay i/o boards (Opto 22 G4) and Visual Basic 6 programs.
For the most part, our PLCs are mainly Koyo 05, 205, & 405's in all of our slower process plants and Allen Bradley in our more "high tech" plants. We have acquired a few companies and bought some equipment from OEM's that are not compatible with either the Koyo or Allen Bradley PLCs. Some of theses are Idec FA-2J, Idec OpenNet, Mitsubishi, and Seimins. On the operator interface side there is mainly Cutler Hammer (the one that runs Windows XP) and Panel Views.
Technical Info / Standards:
PLC: Depending on the application, it will be either a Koyo 05 or 205 if it is a low end application. If it is any thing other then a basic process it will be a Allen Bradley Compact Logix or Control Logix. We are using the MicroLogix in our newer lower end lines where using VB would be unnecessary. We have been putting Ethernet cards in all new PLCs, even when unneeded. However, about 75% of the plc's currently do not have Ethernet.
PC Programming: We are in the process of switching all of our applications over to Visual Basic .Net. We are using the Visual Studio .Net 2005 with the .Net 3.0 framework.
PLC to Visual Studio Interface: We use an INGEAR driver to connect to the Allen Bradley plc's via Ethernet. We have created our own Ethernet plug-ins to connect to the Koyo and Idec plc's.
Business System: Our back end business system is in Progress with some 3rd party add-ons. Some of these include Webspeed and Mapix. All old applications transfer and receive data to and from Progress via FTP. All new applications send and receive data through a web service using Progress and Web Speed.
Data Storage: We store all of our production stats and orders in a mySQL database. We are unable to easily directly interact with the Progress database. This is due to a limitation of the version of Progress we are using, we are looking at upgrading to resolve this issue. For any line specific data, like configuration settings, or temp data, we use XML files.
Thank you,
Brandon
