speakerman

MrPLC Member
 View profile  See their activity

  • Content count

    88

  • Joined

  • Last visited

Posts posted by speakerman

  1. Posted

    Hey Glee; I am using a HandyGOT 940 right now - just finished programming it for the main functions. Here's a way of doing alarm screens that worked well. Forgive me if it's redundant, and you've already thought of it: You've probalby read that you can configure the screen display registers with an overlay screen as well as the base screen. I use D20 for the main screen, and D21 for the first overlay. (there are two possible overlays, but I haven't really found a need for that yet.) That way I can write all my alarm status bits so that correcting the problem resets them. Once the alarm status bit goes low, the overlay window will simply shut off, and whatever screen was active will be revealed beneath, without having to do any fancy tricks to get back to it. This way you aren't actually changing the main screen number being displayed, just calling up an overlay screen whenever a fault or other condition occurs that you want to notify the operator of. It gives great flexibility. I also have a button so the overlay window can be cleared by hitting "OK" on them to acknowledge the alarm. Operators like this way of being able to tell what screen is active below the pop-up, and it's easy to add overlays and base screens in the future without getting more complicated. The overlay screen is created as just another base screen, but you need to make a solid colour box as its background, because it's translucent to the screen below. I just left a little margin exposed around the edges so the operator can tell it's a pop-up window. I can forward an example if you like. We ended up using screens 1 through 22 for the operator's main operations, and the overlay screens start at 30. When there is no fault condition, I have the PLC run monitor bit drive an instruction to move K0 into D21 so the overlay screens are inactive. I hope this is of use. Perhaps it is more complicated than you need in this case, but could be handy some time in the future. Feel free to ask more questions if this concept interests you. There are really a lot of possibilities with these little GOTs! Cheers, Speakerman.

  2. Posted

    Hi Bradner; Welcome to the forum. I'm up in Prince George, BC myself! Hopefully you'll find herein some insights to your dilemma, and your opportunity. I have recently quit my job in the pulp industry, as a production worker on the floor level of a pulp mill packaging department, and now work full time as a consultant designing equipment and PLC control strategies for several industries. As yet I have no degrees, courses, or formal training. This was not an easy process to work through, or an easy decision in some ways to move to full time programming/design work. I have been running my company part time, on days off and holidays for 8 years now, and it took that long to build the reputation and customer base to quit the 70,000/year day job. I find this website and its reasources invaluable, as my lack of formal training and ignorance in some of the basic areas does crop up at times, and this forum has helped with that greatly. What I have found is that my operational foundation and love of code writing makes some of the more difficult aspects of this profession easier, so it more than balances out. Do take Alaric's suggestion and peruse this site's many resources for learning PLC programming. There are plenty of very knowledgeable people here. I have seen great comments and wisdom from BobLFoot, and Crossbow as well, just to name a couple more. Code writing itself is an extension of understanding the process, and then translating that into the boolean flow. If you understand the process really well, learning to program is just learning another language, another syntax for describing that sequence of operation. There are critical elements in the application of that description to do with safety and interface, but I'll talk more about that below. One of the factors that determines if programming is a good career for you is if you love the challenge so much that it doesn't feel like work. I can write code for many hours straight, and the creative process energizes me for more. The satisfaction of seeing a complex program going live, watching a machine cycling, changing, reacting and producing in harmony with the strategy you have designed makes it all worth it. Seeing an operator smiling and nodding, and the surprise on their face when the system does something sophisticated and intelligent that they did not expect - that's a real treat. I bet you know as well as I how hard it is to impress an operator... Another factor is whether or not the industry you intend to work in at first has programming needs that aren't being met. That includes whether or not the current companies or people that are available to them are able to deliver the kind of programming expertise and performance they need. I typically find that PLC systems and control strategies are not being used nearly to potential. (It's amazing what operators can learn to live with!) Once you have a reputation within your industry and command of programming interface, you may find work in others, but that would most likely be years down the road. It would be beneficial to begin with the one you know so well, because that will make many aspects of the programming process easier at first. The trend in production is always toward automation, so the need for skilled programmers will increase in all industries, especially with HMI and other forms of advanced control becoming so inexpensive lately. As an example, I recently converted a forty year old Russian steel milling machine to PLC control from its original relays and amplidyne, a job that cost about a third of what it would have ten years ago. This sort of opprotunity will crop up more and more, as companies want to improve a machine that represents a large capital value of infrastructure, but has antiquated control systems that limit its productivity. With PLC systems and drive control products dropping in price so dramatically, these sorts of projects become economically viable. There is another critical aspect of prpogramming to do with operator interface, which is why I refer to writing code for a PLC as a control strategy. I'm not sure how similar it is in the food production industry, but everything in the heavy industrial plants I work in is big horsepower and high pressure, usually more than capable of tearing itself, its surroundings, and any person caught in its path to bits, in a instant. There are plenty of machines that, in an area safety tour, the guides refer to simply as "instant death". The work environments and hazards to employees play a huge role in my code design, as people are always in close contact with the heavy products being produced and the machines that manipulate them. In this area, 20 odd years of operational experience is a huge plus, and I would guess that for yourself that would be true as well. That said, you still MUST have a great love for programming, and solid grasp of the concepts, strengths and limitations of a PLC system, and all its sensors. When a machine goes awry, and people need to correct it, your operational knowledge should help to design a strategy for interface to make that job safer and easier. With the extra complexity of HMI thrown in, and all its plusses and minuses, you really do need a solid foundation of what's important to the operator. I have seen so many poorly wrought interfaces that obfuscate the process and confuse operators with needless data and tiny, redundant controls. Always remember that in a manual workplace, mistakes in code writing can have utimate consequences. As an operator, and being harshly realistic about the process you see, ask yourself if there are areas for significant improvement around you? And are they likely to exist throughout your industry, or are they isolated? What scale of project or change would it take to correct them? For you to make a living at this, you need to have enough market to service - and that market has to be profitable enough to support you. Everything that is worked on is either a maintenance job to keep equipment up to snuff, or a capital improvement, which must be justified by a return on the investment to achieve it. You need to know what it will cost to make specific improvements, and what the real economic recovery from those improvements will be. The pulp industry expects repayment in production cost savings on their investment within 6 to 12 months. Again, since you work directly in your industry, you have some easy avenues to filter through the dramatic soapbox speeches and find the real answers to those questions. These are the biggest hurdles to success for an independant contractor, working without a large company, and their muscle, behind you. It is more critical than your individual programming ability, or how smart a businessman you become. In terms of selling yourself, one of the first things I learned was that no one will write a purchase order for an idea, no matter how great it sounds. If they don't believe strongly in the results it can produce, and your ability to deliver them, they will not likely take a chance with their career by taking a chance on you. Gaining and holding the trust of the people you want to work with is vital. They must learn that you will be a positive, consistent deliverer of solutions, and those solutions must be to problems they perceive they have. It is very difficult to walk into a plant and tell someone you have no history with that part of their process doesn't work right. Believe me, I did that very thing - foolishly - for a while, and got no results. Strange, but not everyone seemed to share my enthusiasm for criticizing their workplace... imagine that? It's a delicate balance sometimes, to convey that something is an opportunity for improvement when there are people in the plant, possibly in room, or even the very person you are speaking to, who are emotionally invested in the process you are undressing. If you find yourself in that position proceed with caution, and focus on the end results, not making the most of the problems you see. I hope that gives you a smattering of the idea as experienced by your's truly. The short answer to "can I quit my job at 40 and start a PLC company" is yes, done carefully and with a good idea of the goals and markets available. I'm 42, and recently unemployed myself! Feels good too! Speakerman

  4. Posted

    Hey there to all the people who understand the magic of the MSB... I am relatively new to the Mitsubishi platform and am having some difficulty working through the mass of information in the manuals to find a specific instruction. Hopefully someone out there can pass on an easy fix to this problem: I have data registers for sending the speed control frequency to several VFD remote devices on a CC-Link. The interface for setting the speed registers and ramping in an accelerated way for graduated adjustments works well, and the operators like the way that performs. My only remaining wrinkle is that I need to be able to convert that number to an rpm for speed display, and the trouble is that the frequency register resolution is from 33 to 7833 in single integer increments. This represents frequency in hertz x 100, where 60.00 Hz is stored in the register and read by the drive as 6000 for a speed of 1800 rpm. I need the resolution to remain this accurate, as this is a steel milling machine and the rpm is critical during larger cut cycles. I tried dividing the frequency by 3.33 for an accurate conversion to rpm, but I'm not allowed to use decimals unless I delve into the world of floating point. Next I tried multiplying it by 100, then dividing it by 333, which would give the same result. This seemed to work, as the destination register stored the higher value after the multiplication, using two consecutive registers to store the number as the value exceeded the capacity of a single 16 bit unit. The problem occurred when I tried to reference those registers to divide them by 333. It kept showing negative numbers, as it wouldn't reference both of the destination registers holding the result of the earlier multiplication. It appears that the follow-up DIV function was only reading the first register, which usually had a 1 in its MSB location, making the answer negative. I have read through the massive manual for any information on how I can make the DIV function reference both registers for a 32 bit value, and divide that by 333 getting a result that would of course fit into my display register, but although there are many references to double registers, I cannot find any instruction as to how I reference them in a math function. The data is there properly in the multiplication rung, showing the value, (example - frequency of 2000 multiplied by 100, correctly displayed in the destination register as 200000) and on the very next line, that same register is referenced in the DIV function, and shows a value of -XXXX. Is there a way to make the DIV function to read the value of both registers for the calculation? Or is there another function I have to use to achieve this? Note that this is a display issue for feedback to the operator, and the system does perform well. I'd really like to be able to give them a readout that correctly reflects the speed their motor is about to run when they turn it on. So far they are happy with the system overall and just compensate for the "drift" they see between the setpoint and the actual output. I hope someone out there has either seen the problem or can point me in the direction of a page or section in the programming manual that actually describes how to reference a double register, with a typed example of how it would look in a rung. Or a simple way to use 3.33 without too much complexity... Thanks in advance for any help that you can give, and for providing this great resource. B. Woodley, Innotech http://www.innotechglobal.com

  5. Posted

    I second that point hugely. It applies to all parts that communicate to the PLC as well. Here's an example... We were installing a Jag Extreme scale control unit. During the same shutdown, another company was installing the exact same unit for a different application in the same department. We took the time to write a config program that ran when power was cycled to reset everything, lock out all unneccesary keys and functions, and set reasonable limits for inputing setpoints to prevent keypad errors. An extra hour of programming, and when startup came, the difference was phenominal. Our interface was slick and intuitive, and when utility power to the area bumped, the other controller lost everything. It had a four-step mystery procedure to get it working again, which only a few people knew of. The contrast was dramatic. Take the time.

  6. Posted

    Hey, this is a great thread! I am so familiar, and in total agreement, with this one. Please spare a thought for what happens to the safety of the area operators when people start hacking code up because they believe it is the problem. I've seen essential parts of code related to safety backchecks 'removed' because it seemed to 'fix' the intermittent problem, setting the operators up for a future disaster. I'll add my own thought to the mix. I haven't read all 82 posts, but I hope this one is original: PLC Law # XXX01: Consider what will happen sequentially when each sensor on the input system fails. Will the code stop appropriately? Will it be safe? Will it cause nuisance interruptions when a sensor starts to flicker, (they rarely fail outright), or will it pause and continue? Remember, every part of the control system is constantly degrading, and eventually, every part will fail. Production facilities aren't known to replace PLC parts on a PVM schedule. ADMINISTRATORS NOTE : THE ABOVE IS NOW LAW 50 IN THE 2008 EDITION. PLC LAW # 50 - CONSIDER WHAT WILL HAPPEN SEQUENTIALLY WHEN EACH PART OF THE AUTOMATED SYSTEM FAILS. PLC LAW # 50.1 - THE CODE MUST STOP APPROPRIATELY WHEN FAILURES OCCUR? PLC LAW # 50.2 - THE CODE MUST BE SAFE WHEN FAILURES OCCUR. PLC LAW # 50.3 - THE CODE MUST NOT CAUSE NUISANCE INTERRUPTIONS WHEN A SENSOR STARTS TO FLICKER. PLC LAW # 50.4 - REMEMBER, EVERY PART OF THE CONTROL SYSTEM IS CONSTANTLY DEGRADING, AND EVENTUALLY, EVERY PART WILL FAIL. PLC LAW # 50.5 - PRODUCTION FACILITIES AREN'T KNOWN TO REPLACE PLC PARTS ON A PREDICTIVE, PREVENTATIVE OR PROACTIVE SCHEDULE. And here's my central control strategy item. Think Asimov's three laws of robotics, as they are the inspiration. PLC Law # XXX02: All code that causes machinery, hazmat, or heavy product of any kind to interact with operators in any way should be written to protect people first, equipment second, and production last. ADMINISTRATORS NOTE : THE ABOVE IS NOW LAW 51 IN THE 2008 EDITION. PLC LAW #51 - ALL CODE THAT CAUSES MACHINERY, HAZMAT, OR HEAVY PRODUCT OF ANY KIND TO INTERACT WITH OPERATORS IN ANY WAY SHOULD BE WRITTEN TO PROTECT PEOPLE FIRST, ENVIRONMENT SECOND, EQUIPMENT THIRD, AND PRODUCTION LAST.
    1 person likes this

  9. Posted

    Thanks Crossbow, and everyone else, for your input. Looks like I'll go with the Mitsubishi unit after all, an F940 hand-held with a protective cover, integrated E-stop and a handy keyed selector switch. I've modified the interface to accomodate the four natural buttons, and will have an additional small box that it will hang on containing 4 3-way selector switches to handle to common tasks, so the screen will not be beaten to an early death. Let you know how that goes. I've also changed from the old standard of an analogue pot for speed control to a digital selector switch input, with some programming to make it user friendly. A scalable input sensitivity will allow the digital input for raising or lowering the speed to adjust from tiny changes at a single flick of the switch, to ramping of 200 rpm per second when held continuously. Preliminary tests are good. Think iPod scroll wheel... that was my inspiration. This frees up the PLC from having an analogue card for only one input. The mits processor seems pretty user friendly so far. We'll see when the commissioning starts I guess! Thanks again guys. Happy programming.

  10. Posted

    Hi Mike; I'm glad you found someone to write your program. Came upon your request a little late, as I'm a new member, but I'd be happy to help with something in the future if you have questions regarding the IDEC suite. I've found it reliable and quite user friendly. Still have the programming software somewhere. I'll keep my eye out for any more requests for assistance with IDEC. Take care, speakerman

  11. Posted

    Hey Paul Ked, Thanks for the post! You have a good idea. I am trying to replace an existing dangling pendant control box with something smaller and more flexible, and your suggestion is my fall back if there is no slick design available. I have seen other machines with very well featured pendants that have a small screen and about a dozen configurable buttons. They are light enough to hold comfortably, with have a flexible cable that can dangle loosely from an arm above. I am hoping that such an animal exists for the Mitsubishi processor, as their own pendants appear to be limited in their button count. If I find anything appropriate, I'll post it here in case anyone else has a similar need. Good programming! B.

  12. Posted

    You have it exactly, panic mode. This is a metal milling machine, and it is immersed in metal filings, welding gases, and oil, continuously as are the people who use it. Touch screens don't fare well in this shop. To give the functionality of the touch screen as a status indicator and some basic function and troubleshooting controls is as far as I'd go. The pendant you mention is a Mitsubishi product? I missed that one. I'll look into that in more detail. Thanks for the reply... B.

  13. Posted

    Hi Everyone; I am new to this forum, so forgive any redundancies. My most recent job uses a Mitsubishi PLC, the FN series, and this is my first enconter with same. (I have worked with Allen Bradley, GE, Modicon, Siemens, and IDEC.) The programing interface is okay, and I'm sure there will not be a problem designing code to achieve the desired result. I am having some trouble locating a pendant style HMI with about 20 buttons, and at least a 5" screen to provide the machine operator with some feedback as to machine status. I would like to find one that is connected via data cable and not I/O structure to cut down on wiring requirements. We cannot use a panel mounted HMI, as the operator has to lean out over the unit while working. It would be best to be able to pull the controls near on a suspended cable so he can see what he's doing during fine manipulations. Has anyone out there used a pendant with the Mitsubishi PLC and had a good, bad, or indifferent experience with it? When I try a look up on the internet I end up going in circles. Once, about two months ago, I found a pendant that was featured right and compatible, but ironically my saved web address doesn't work anymore. I appreciate any help that can be given on this topic. Thanks, B.