Automation Technology Query - Page 1
Forum section: electronics / projects

author: Probb
author_rank: Contributor
timestamp: March 16, 2016, 04:03:58 pm
content: Hey Guys!I'm currently part of a small team that's designing a new and improved automation product intended to be used by anyone in a rapid development environment or manufacturing industry.We're currently looking for a lot of general feedback regarding peoples experience with automation technology. If you're interested and have 5 minutes to spare in your day, it would be greatly appreciated if you could fill out our survey (linked below):https://fluidsurveys.usask.ca/s/Automation_Technolgy_User_Information/Posting stories on this forum about your experiences (good and bad) with a variety of automation technology would also be very much appreciated.I'll be uploading a link to our website once it's up and running, which will have all our product information for all of you to critique at will!Really big thanks for your time and consideration!

author: _Wim_
author_rank: Super Contributor
timestamp: March 18, 2016, 06:44:23 pm
content: Hi,Just filled in your survey. I work mainly with Siemens S7 (THE standard in Europe), although Siemens user friendliness is very bad, and I would personally opt for a different brand as a programmer. (I have worked in the past with Allen-Bradley, Festo and Mitsubishi also, and all of them I liked much better then Siemens user friendliness wise)The main reason Siemens is preferred by many of our customers, is that Siemens support their product for an extremely long time, and spares are very easy to find even if the product can no longer be provided by Siemens itself. They also have an extremely big catalogue, which means they have a solution for almost anything (if you do not care about the $$$...)But they software is really outdated and slow, plc’s have very small memory, and their product are definitely not plug and play (in my opinion getting a Siemens product to do anything is 80% of the work, programming the rest of the program is the easy part)

author: Probb
author_rank: Contributor
timestamp: March 18, 2016, 09:30:06 pm
content: _Wim_,Great feedback! I've heard similar complaints about user-friendliness regarding Siemens products.In my current job, I do a lot of work with Schneider products, specifically Zelio PLC's. They're relatively straight forward to use if you understand PLC's; the trouble is that I work with a lot of mechanical engineers that don't necessarily understand PLC's, but need to use them on a regular basis.The product my team is currently developing will create a "plug-and-play" option for those who don't want to delve too deep into the programming aspect of logic control and also don't want to spend a lot of time cutting and stripping wire. The hardware will be accompanied by an easy to use application for monitoring and controlling the assembled automation system remotely.You mentioned that "getting a Siemens product to do anything is 80% of the work"; could you clarify what exactly you mean by this "work"? Are you referring to actually interfacing the PLC with a physical system, such as creating addresses for inputs and outputs to switches and actuators, etc.?

author: _Wim_
author_rank: Super Contributor
timestamp: March 19, 2016, 06:45:18 am
content: What I mean with that is that setting configuring and initializing many product is more difficult that writing functionality for it. A few examples I personally came accros:- The older Siemens Masterdrive Servo system: when it is the first time you use these, you probably spent almost a week before you can make the motor to some basic movements like a home run and a constant speed movement. Once you figured out how to do that, the rest of the software is "easy". Around the same period (+-10 years ago), I also had a project with the Allen-Bradley kinetics drive system (with a controllogix controller). This was alot easier to confiure everything and do basic movement.- To read in a loadcell, you need a Siemens Siwarex card. Normally, you expect something like this to be as easy as define this card in the hardware configuration, enter the properties of the loadcell used, and you can read-out the actual weight. With a Siwarex card you probably spent at least 3 days trying to understand how to configure this.- Setting up communication between to Siemens plc is supposed to be as easy as defining the connection between them and using the standard SFBs to communicate. But the number of times I struggled to make the communication is I cannot even count anymore. This fact is for sure not helped by the generic error you get when trying this (eg. "communication does not work" instead of "connect find IP-address on subnet"As I work mainly in the process industry, I have normally do not use the smaller plc types like the Zelio of S7-200 series.But, to be honest, at least here in Europe, there are already to many "small" plc-brands as it is. Most of them are quite user friendly and cheap, but have the following main disadvantages for bigger companies:- small catalogue of products, which means that there is a risks that future upgrades of the process will not be possible this the existing hardware- because it cannot be used as the "universal" automation platform for the company (small catalogue), it means they need to train their maintenance staff in multiple automation platforms, and this is expensive. It already very expensive to get a well trained staff in 1 platform and to maintain their knowledge.- long-time support (>20 years) for the hardware is uncertain (I know of several smaller brand were the lifecycle of the product is less than 5 years, with an additional 5 years of support only but not recommended for new designs)- no proven track record for reliability. If you take into account the enormous cost of a forced shutdown due to a breakdown of an automation system, this can be a very big issue- services: for example Siemens provides the service “Spare parts pooling”, were you provide Siemens with a list of ALL siemens components used within the company, and they guarantee that you will have a spare on site within the next 2 hours of exactly the same time (to be exchanged for the broken component)Because the above is impossible to provide by a small start-up, smaller companies all seem to target the smaller systems markets like the Zelio. Problem with this market is that it is mainly drives by price and nothing else, features and services are much less important. In short, unless you work for a very big company with big funding, I would think it will be very difficult to convince people to buy a “new” automation product…

author: Probb
author_rank: Contributor
timestamp: March 21, 2016, 05:46:44 am
content: So, if the initialization and configuration requirements of many existing PLC systems was mitigated, you'd be more inclined to use the product?Also, what are your thoughts on a web based application to control and monitor automation systems. I understand their are issues with security when it comes to large plant processes , which typically incorporate desktop applications; however, a web based application with secure sign-in options may allow for simpler connectivity between systems or nodes by utilizing a wifi or ethernet network to connect between automation systems and communicate back to an end user..

author: _Wim_
author_rank: Super Contributor
timestamp: March 21, 2016, 07:55:51 am
content: I think it does not really matter what you as a programmer think, you have to look at the big pictures, which is support and reliability for the next 20 years. Initial programming of a plc is only a small fraction of the total cost of an installation, so the focus is much more on the maintainability. And this is where Siemens in Europe (and I suspect Allen-Bradley in the US and Canada) are very good in by having proven reliability, ensure availability of spare long after initial purchase, and having plenty of trained people around for emergency fixes. So to target the process industries, you cannot be a small player on the market, you need to be one of the biggest. User-friendliness does not really matter so much in the end.For machine constructors this is slightly different (because initial programming is a substantial cost for them), but they have the disadvantage that many customers specify the automation platform to be used. Therefore investing in an “unknown” brand which you can only use for customers who do not have specific automation requirements is possible, but still not the preferred route by many.As to webbased applications, I do not see a big future in them. The plants that I have worked for do indeed struggle with communication issues (mainly DCOM security of windows), but once up and running, they have proven more reliable than web-based. A good indicator for this is the different OPC communication standards. OPC-DA-XML has been specified at least already 10 years, but almost everybody still uses OPC DA 2.0. Wifi in industrial environment should be avoided, certainly for critical monitoring. Every now and then I do come across portable wireless panels, but mainly for maintenance purposes, not for monitoring.In essence, I think everything that is “needed” has already been available on the market for quite a while, with the only new trend I can speak of being virtualisation. This is mainly performed to replace dying hardware, but has also some big advantages for remote service and reliability.

author: ChristopherN
author_rank: Unknown
timestamp: March 21, 2016, 08:51:00 am
content: Hi Probb,we're working as consultants on automation and IT technology and also offer some specialty sensor products. We do a lot of design work for small run (5-10) or one off machinery but have also had some bigger projects with 5k machines / automation systems being used.For low volume, high cost machinery:The price of the PLC system does not matter much, as _Wim_ put it, things like reliability and long term support are far more appreciated. A day or two of downtime will cost you most likely more than the the whole PLC system. There are many components that are much more expensive as well in a whole machine, like vision systems or robotics.Web based UI systems are a thing right know, but only for new equipment that does not need to integrate with older systems. Many web interfaces of PLC systems are beyond unusable. Security is a real challenge, note that most PLC systems lack basic things needed for real security, such as a precision time source. Another challenge is that people that build systems for machinery are not the end users and, in many cases, don't know the end users or have any contact with them.Network access can be a real pain depending on the target operation environment. WIFI is not really an option, for one due to customer regulations (you will have to support full remote configuration, Enterprise WPA, secure certificate storage and so on and might still have a problem at certain plants due to local RF regulation), the other being general reliability concerns that are based on prior systems.For high volume:IMO the route for high volume systems is more like building a customer product. If you have a few hundred of something, you want to be able to manage the whole system remotely (if you are offering some kind of service or guarantee). There are several ways this is done in real world applications:1) A PLC with GSM / DSL uplink and maybe custom code or even linux (Weidmüller has a system like that).2) A (maybe cheap) PLC with a separate linux ipc.3) A ipc with some IO's or IO cards.A web interface could be helpful for setup and service operations, but in most projects we work on everything has to be configured remotely. Nobody want's to send out a tech cause a machine that is worth a few k€ broke down. You want to figure out what's wrong and send replacements. You have to supply your own internet uplink in most cases, this leads to internal GSM with appropriate contracts. The backend system managing this whole mess of stuff in the field is where it gets interestingAnother thing to consider besides all the technical an logistical issues is what actual RfPs state. Most customers insist on a specific brand or even product line for the PLC system. This is due to internal staff training, on site replacements and service contracts.Fell free to contact me if you you need more information or have specific questions.Christopher

author: Probb
author_rank: Contributor
timestamp: March 21, 2016, 04:25:48 pm
content: _Wim_ & Christopher,This is fantastic feedback! You guys both clearly have a lot of experience in the industry and it's great to get your opinions.I can understand the issues with security, especially when it comes to any type of wireless communication within heavy industry critical process monitoring and control, and I know Wifi is definitely a "no-go" when it comes to those systems. In one of my previous engineering experiences, it was nearly impossible to get process operators and managers within a plant I was working at to transition their systems from RS-232/485 to Fibre, so making the leap from any type of hardwired comm. to wireless would inevitably be an intimidating challenge.But, what I think I'm getting from both of you is the fact that back-end service is more important than the automation product itself (as long as the product is very reliable and meets the specific system requirements). I also understand that big industry organizations have their preferred vendors and would likely never stray from the reliable big industry suppliers, such as Siemens or Allen-Bradley, etc; However, _Wim_, you mentioned "machine constructors" being somewhat of an outlier in this circumstance, considering their services or products aren't necessarily stagnant, and may in fact always be changing based on customer needs. I feel this is the group my team should be designing for - companies that require ever changing automation systems to meet ever changing customer needs in a short term. Would you agree?Christopher, your comments on back-end services, specifically with regards to a GSM/DSL uplink for servicing purposes, are very helpful. The system my team and I are currently developing will utilize multiple web applications for users; however, the plan is to develop a (mirrored) desktop application to improve overall security for system monitoring and control. I'm realizing now that we can actually use our web based application more as a servicing tool. For example, if a user is having issues with a particular system, their system can be easily "mirrored" (with a network connection) within our web application (since it's Java based and can seamlessly transition between desktop and the web), and our team can then service the system remotely through the web-app, troubleshooting, checking for bugs, and determining faulty parts faster with the user present on their end. What's your opinion on this approach?

author: tonyarkles
author_rank: Regular Contributor
timestamp: March 21, 2016, 05:00:06 pm
content: To the OP:This is one of those weird Internet coincidences... If you want to grab a coffee and chat about GSM/UTMS/LTE uplink security, I'm in Saskatoon and have been working on things like this (not for industrial control, but for some other embedded devices)

author: Probb
author_rank: Contributor
timestamp: March 21, 2016, 05:25:12 pm
content: tony,Refer to the General Chat post.

author: _Wim_
author_rank: Super Contributor
timestamp: March 21, 2016, 07:56:55 pm
content: Quote from: Probb on March 21, 2016, 04:25:48 pmIf it was me, I would chose even a specific type of machine constructors and add-in specific features for their market segment. I remember in the beginning of my career that all over sudden Beckhoff became the "standard" platform for the automotive industry (I have no idea if this is still the case today). I have been told that they had really specific instruction for that kind of automation, and that this was one of the reasons for their rapid rise (I cannot confirm if this is actually true, as I have never done a project in automotive)So look for machine constructors that would benefit greatly from highly specialized plc instructions you develop specifically for them , and try to convince them to develop the product together with you. Once you are a valued supplier in one specific market niche, look to further evolve to a more general market. Off course, I am a technical guy, so please take commercial advice at least with a grain of salt ?

author: ChristopherN
author_rank: Unknown
timestamp: March 21, 2016, 10:06:53 pm
content: Hi Probb,glad I can help.Could you go into a bit more detail about the system you are planning?Java and multiple applications sounds like a complicated system that would be very hard to manage. Don't get me wrong, but most PLC systems are used cause they can do the same thing, in the same amount of time each and every time. Are you planning on using separate cores for the tasks? Whats your testing strategy?I guess certification would be very hard if you don't separate those functions. Trying to blend all components into one system seems like a very complicated approach.The management functionality for remote service and updates needs to be easy to use and a many to one concept. This implies having a system management software of some sort, not just separate systems that an operator can log in to (thats possible today). I would suggest looking at software that is used to do system management for large server farms. The challenges are similar in many aspects.I would go with _Wim_ on this and focus on a very specific industry and a very specific task. The first thing to do prior to anything else is to talk to your customers. Many machine builders (called Sondermaschinenbau here in Germany) are already serving very niche markets. They know what their customers need and what are the most pressing problems for them.A main challenge for all of them is digital transformation. I guess products and services that assist in the upcoming challenges could sell very well.

author: ChristopherN
author_rank: Unknown
timestamp: March 21, 2016, 10:17:56 pm
content: Here is a link to the Wago Linux PLC:http://www.wago.us/products/components-for-automation/modular-io-system-series-750-753/programmable-fieldbus-controller/linux/index.jspI used that one (the 750) in a project a few years ago, it is a very capable platform but not really intuitive.

author: Probb
author_rank: Contributor
timestamp: March 21, 2016, 11:44:13 pm
content: Our product itself tries to replace the front-end physical work required around building automation systems. By "front-end" I mean the actual cutting and stripping of wire, connections of outputs and inputs, and overall addressing of components. Generally, we're following the traditional concept of PLCs, which utilize cards and backplanes; however, our cards are actually blocks (imagine 45mm x 45mm cubes made of CPVC) that can easily plug into our own version of a backplane. Each block can be "programmed" to perform a simple task, such as timing, counting, PWM control, and each block can have up to 3 inputs and 1 output, 3 outputs and one input, or any combination in between. There are also blocks that are dedicated simply to be input and output connections to auxiliary components such as actuators and sensors. The automation system will run according to how you assemble each block on the backplane - interconnecting each blocks input/output with another blocks input/output. The physical interconnection of each block is meant to loosely mimic ladder logic programming. I realize this isn't the greatest verbal description of our product and may be a bit difficult to picture, but once our website is up and running I'll make sure to link it here so you guys can get a better idea as to what I'm talking about.The main reason we're using Java for our application development is because the language itself can (relatively) easily transition between desktop based apps and web apps. Do you guys have other suggestions? Python perhaps? Ruby?Out of the three applications we're developing, 2 are web based and free to use, and the third is a downloadable application meant for desktop/offline use.The first web application is only used by the user to customize the overall look of each blockbeforemaking a product purchase. It's simply used for product aesthetics and essentially has a direct link to our company's laser cutter, which will cut the designs into the block before final assembly and packaging/shipping.The second web application is meant to be used when the user has physically built their automation system using the blocks. They can then connect the system to the web through their backplane via serial-USB network connection, Wifi, Ethernet, or Bluetooth, and the web application will automatically build their system on the screen based on how they've interconnected each block (Note: I'm leaving out a lot of detail regarding membership requirements, sign-ins, etc. to avoid muddying things up). At this point, the user is free to program each block as needed - for example: timer blocks can be set to cycle on/off, delay on/off, etc.; servo block parameters can be set for positioning, speed, home run, etc.; counters can be set for range, pulse definition, etc.Once programmed, the user can run, stop, and monitor the whole system, but has no other control otherwise.The third offline-based application has the same functionality as the second, but gives the user the ability to control each individual block while the system is running or stopped. There will be other integrated features with improved security settings and further system customization incorporated within this application as well.Thoughts?

author: _Wim_
author_rank: Super Contributor
timestamp: March 22, 2016, 08:06:36 pm
content: Quote from: Probb on March 21, 2016, 11:44:13 pmI see a few problems with this approach:- as ChristopherN pointed out, do not use actual programming languages like java, Ruby, etc. The only good reason to use these is to allow the user to create "user defined functions" that can be used as a typical graphical plc programming block afterwards- configuration of many individual blocks is just the opposite what an automation engineer wants. Preferably all settings, configs and code are stored in one location for ease of maintainability ("master", typically a single plc CPU). When some hardware module is replaced, it should receive its settings/code/config again automatically from this "master". This way hardware modules can be replaced by maintenance technicians without the need to have actual knowledge of the automation platform. Ideally hardware modules are hot swappable- always provide the standard IEC 61131 programming languages as a minimum. More languages can be added to extend the functionality, but do provide the basic languages that have been in use for >20 years. All of these languages have advantages and disadvantages, and a skilled plc programmer uses many of them in a single solution depending on the application- from your description, it seems flexibility is rather limited (were the hardware dictates the possible functions). In general hardware should support as many functions as possible, so changes during the lifetime of the machine/process are possible without the need for any hardware modificationTo be honest, I think your team needs a couple of seasoned automation engineers who can specify "real" needs and to stop your team going overboard in architecture. Also talk to your end customers, and them for actual use cases and check if your solution allows to implement them. If this forum is providing good information, then you clearly need much more in depth field research before starting a very expensive project like devopping a new automation platform.

author: Probb
author_rank: Contributor
timestamp: March 22, 2016, 09:56:43 pm
content: The programming languages I've mentioned, specifically Java, are only for theback-endaspects of our applications. They are not seen or used by the end user. The applications we're currently developing are thefront endaspects the user actually sees and uses. These applications will be very easy to use - simple drag and drop functionality. The purpose is to mitigate the need for users to have previous automation programming experience in order to use our product. The applications and the physical interconnection of the blocks make automation system development and analysis very intuitive from an outsiders point of view.I totally agree with your opinion regarding automation engineers wanting the "all-in-one" package, and it's something we're simultaneously developing as a "customizable" block option, for those wanting a more compact and application specific product.I suppose I should iterate that right now our target market is focused on those working in a rapid product development industry, specifically test engineers, who often need to build and re-build automation systems to test their own products under certain conditions continuously. These are the guys that don't have the time to sit down and carefully develop automation systems using traditional PLC/ladder logic methods. They need a product that incorporates plug-and-play tangibility and minimal programming, as well as the ability to control and monitor their systems remotely.We're also trying to target small independent production companies, such as craft breweries and distilleries - in North America, this is a fast growing market. Their teams often run lean, and like every start-up, they tend to have a small budget to play with. Our product gives these small teams the ability to build relatively powerful automation systems on their own, regardless of their automation developing experience.When it comes to creating a product intended to be used in heavy industry, I understand the need to follow many standards and plant regulations (based on my experience working with Imperial Oil, Suncor, Shell, and Nova Chemicals). However, both you (_Wim_) and ChristopherN have mentioned that it's nearly impossible to jump into those industries when they already rely entirely on products made by the much bigger names like Siemens, and I am in 100% agreement.My team and I are looking to develop a very user friendly and affordable product. We're trying to take what we already know about the automation and production industry and develop a leaner, easier to use system. It's great to get feedback from everyone with varying automation experiences (from heavy industry engineering to small local farming) because it helps us pin-point the key product attributes everyone is looking for.So far, the comments both you and Christopher have made with regards to customer support and remote product maintenance have been a great help.Also, _Wim_, it was very sad to read the news today about the bombing in Brussels. I hope you and your family are safe and well.

author: _Wim_
author_rank: Super Contributor
timestamp: March 23, 2016, 08:41:35 pm
content: Quote from: Probb on March 22, 2016, 09:56:43 pmYes, it is indeed very sad what is happening. Luckily my family and I were not affected, but unfortunately many were.