 |
|
| home products how to buy support & downloads literature search |
Pages
Search by Date
Search by Keyword
Search by Title
- Inspiring the Production Line
- InteractX Performance: Tag Update Rates (Part 4)
- InteractX Performance: Panel Caching (Part 3)
- Fun with Booleans
- InteractX Performance: Rapid Data Updates (Part 2)
- InteractX Performance: Introduction (Part 1)
- Toy Story: Steve Jobs and Design
- Solid State Storage
- Information Anywhere!
- Text Etiquette in IEC61131
- Newest Brammo Race Bike
- Frameless Motors
- Circular Arguments
- Function Blocks: Program Once, Reuse Often
- Gearhead Sealing
- Other controllers just follow...
- Xpress...Create ACR controller tags in seconds
- Factors Affecting Velocity and Current Ripple
- Gearheads Reduce Inertial Mismatches
- What's the Frequency Kenneth? Linear Positioning Settling time and Natural Frequency
- Backlash and Lost Motion
- Regenerative Power Dissipation
- Race Day
- HMI and SCADA Security
- Calculating Winding Temperature
- Compax3 EPL
- Motor Feedback Options
- Solving problems one blog post at a time.
- Have you ever broken a belt?
- The robustness of roller wheels
- Life. It's Important
- PFD and Line Efficiency
- Cache and forward buffering in InteractX
- Welcome to the Parker EMN Blog!
Inspiring the Production Line
Most people want to do a good job
The main character in the classic novel One Day in the Life of Ivan Denisovich endures an unjust sentence in a Soviet Labor camp. The book describes a typical day in the camp, where Ivan, a former naval officer, struggles against starvation while being forced to work as a bricklayer.
At one point, the guards determine that his day's labor is done and they force him to stop before he completes a piece of wall that he has been working on. This bothers him so much that he risks punishment to sneak back and finish his work. Even when I first read this story in High School, I understood where Ivan was coming from. Though I couldn't explain it, I knew there was something in the human condition that made people want to do a good job. Since then, I've seen this play out in real life. Through the recent economic downturn, workers at countless companies have pulled together, working long hours amidst pay cuts to deliver quality products. It's one of the reasons productivity in the U.S. has soared in recent years. Even before the downturn, I heard of similar stories. When a programmer I knew found out he was about to get laid off from a consulting firm, he raced to check in his changes before he got locked out of the system. It doesn't always work like that, of course. Sometimes, employees goof off. Sometimes they call in sick when they're feeling fine or they take an extra long lunch or leave early. More often, employees simply check out. They endure their day and put in their time, but fail to give their best. So why the difference? Many things drive people to do a good job, and quite a few books have been written on the subject. However, two things relate directly to visualization: cooperation and competition. Cooperation is a terrific motivator which happens naturally when people belong to a group with a shared purpose. This leads to a sense of duty to that group. The programmer I mentioned who raced to check in his code had been working long hours as a member of a tight knit group. They were a team. They had shared purpose, and he couldn't bear letting them down by losing his recent changes. Competition can also be a great motivator when handled properly. It's tricky, though, because it can lead to abuses, cheating, shortcuts, and even sabotage. So what's the secret to healthy competition? It must be friendly. To be friendly, competition must be fair, grounded in a shared overall purpose, and relatively low stakes. In other words, it would probably cause problems if you gave everyone working the most efficient production line a free trip to Vegas and canned everyone working the least efficient. Friendly competition isn't about making people feel unappreciated. It's about inspiring them to do better while having fun doing it. So how can visualization help inspire cooperation and friendly competition? Through our visualization products, we've discovered that just showing performance metrics can vastly increase production line efficiency (see PFD and Line Efficiency). This usually isn't a small increase, it's huge.
The reason is that showing productivity metrics inspires both cooperation and friendly competition. Think about it. Would you really want to be the reason your production line is less efficient than others? At the same time, the competition remains friendly because the metrics (if chosen properly) are immediate and unbiased while the reward is simple bragging rights. What's more, competition can be kept in check by showing overall metrics and trends, inspiring plant-wide loyalty. And that's not the best part. Cooperation and friendly competition are fun. Your mom was right when she told you to make a game out of cleaning your room to make the time go faster. When done right, showing production metrics improves morale right along with productivity because it turns work into a game. Now that's cool. Brent MerandaMixed real-world results
What motivates people?
How visualization helps
Your Mom was right
InteractX Performance: Tag Update Rates (Part 4)
Tag Groups
InteractX uses OPC Data Access Tag groups to manage data updates. Since the update rate of different groups can be set independently, InteractX assigns a different group to every panel and then manipulates the rates of individual groups to improve overall system performance.
The group rates are then set to one of three values: Cached Disabled You can set the Active and Cached group rates on the Runtime settings TAB of the Application Just remember that the maximum possible rate is 1/10mS. Also, this is the maximum rate. The server may deliver updates slower than what you specify.
Tags that are exposed to VBA are always sampled at the Active Group rate. When they are read in a script, the most recent (cached) value is returned. This makes sure the reads happen right away. MyValue = Tags.MyTag.Value ' cached read However, you can read tag values that are not exposed to VBA by referencing them dynamically by name. If a tag referenced dynamically is not exposed to VBA (or otherwise referenced in the globally active group), InteractX will not know its value when the read is performed. As a result, it will execute a synchronous device read. This means it will ask the server for the current value and then wait for the response. This could cause severe performance problems, especially if it is done frequently or in a loop. Brent Meranda
This is the fastest update rate (1/10mS by default). It is used for tags referenced by visible panels as well as tags which need to be active all the time, such as those exposed to VBA (see below) and those used in alarms.
This is a slowed down rate (1/2.5 seconds by default) for tags used by near panels. Near panels are those that are not visible, but are referenced by navigation buttons on visible panels. In other words, this rate is used by panels that the operator might navigate to directly. This helps insure that data on these panels are relatively fresh when they are brought up.
Tags that are not currently active or cached are disabled. This can greatly improve overall system performance. User Definable Update Rates
Properties window. (Select Properties under the Edit menu, and then click on the Runtime Settings TAB.)VBA Tag Reads
InteractX Performance: Panel Caching (Part 3)
As I mentioned in Part 1 of this series, there are three main measures of HMI performance: Initial startup time, Panel switching time, and Real-time update rates.
It turns out that each of these areas can be slowed down significantly by the need to load panel definitions from the hard drive (or Compact Flash Card).
Initial startup time
Before an HMI can start, it needs to at least load the first panel. It might also want to load other panels before startup to speed future panel switches, but doing so will delay the initial start.
Panel switching time
Panel switch time is primarily determined by how fast the destination panel can be loaded into memory (unless it is already loaded) and how quickly its parts can be drawn.
Fortunately, under Windows 7 with the proper drivers and graphics chips, the drawing time is hardware accelerated. This means that the panel switch times are almost entirely dependent on how long it takes to load and create the panel. And, if the panels have already been loaded, the switches are very fast.
***Windows 7 will be supported in InteractX 4.0, so keep an eye out for blazing fast panel switch times.
Panel updates can be affected by panel loading in two ways: Fortunately, InteractX provides a Panel Cache setting that allows you to make performance tradeoffs. To set the Panel Caching option, select Properties under the Edit menu. Then click on the Runtime Settings TAB. Available options include:
No panel will be unloaded from memory once it is loaded. Panels will also be loaded in the background when there are spare CPU cycles. This is good for applications that are small enough to fit into memory and you don't mind slower panel switches the first time panels are viewed. All panels will be loaded into memory on startup before the first panel is shown, and will never be unloaded. Assuming you have enough physical memory, this option gives the best runtime performance. However, depending on the number of panels and the system performance, it could take a while to initially load all the panels. Near panels (panels referenced by navigation buttons from the currently visible panels) are loaded in the background and kept in memory. This helps insure that panels are loaded before the user navigates to them. Only visible panels are kept in memory, and all others are unloaded. This option should really only be used in cases where you might run out of memory. Brent MerandaReal-time update rates
Thrashing happens when a process uses more memory than will fit into the available RAM. When this happens, the OS will swap memory out to a file on the hard disk, and this can be very slow. Panel Caching Options
All
Before Start
Navigate To
None
Fun with Booleans
Let's Play a Game
Imagine you're getting ready to work on an electrical outlet at my home. Because of your recent safety training at work, you pause before starting to ask, "The power's off, right?"
Then I answer, "Minus one."
Obviously, that isn't an answer you'd expect. You didn't ask me a math question, you asked for the state of the power switch. You wanted a simple "yes" or "no" or perhaps a "true" or "false". In other words, you wanted a Boolean instead of a numeric answer.
What does it mean to show a Boolean on a Numeric Display?
In the same way, you shouldn't treat Booleans as numbers in your HMI application.
What does it mean to add or divide Booleans? Unless you're using Boolean algebra and Boolean operators, it means nothing; and, you might not get the results you expect if you try it.
In the same way, you might not get the results you expect if you tie a Boolean value to a numeric display. Most people would expect to see a 1 to represent true, but that's a little like expecting the answer "1" when you ask someone if the power is off.
In fact, if a Boolean value is passed through an OPC (OLE for Process Control) interface and then standard OS calls are used to convert the value to an integer, the display may very well show -1 instead of 1 to indicate true. (I think the reasons for this are interesting, but I'm a little geeky that way so I'll spare you the details.)
How Parker HMIs Convert Booleans to Numbers
With that being said, Interact, InteractX, and Xpress all force the value of true to 1 whenever it's converted to a number.
However, that doesn't mean that's how the value is stored in the underlying hardware. Therefore, if the register used to store the Boolean contains more than one bit, you shouldn't assume that the first bit is on and the other bits are off when you see the number 1 displayed.
Brent Meranda
InteractX Performance: Rapid Data Updates (Part 2)
As I (Brent Meranda) mentioned in Part 1 of this series, one of the biggest challenges for an HMI is handling data updates. While we always want to display and write data as quickly as possible, too much data with too many updates can overwhelm the HMI making it unresponsive.
What Happens When Data Updates come in too Fast?
In fact, if data changes are delivered faster than an HMI can process them, then the values presented to the user can start to fall behind the actual current values. Eventually, the data will be so far behind that they will become useless. In addition, the HMI could run out of memory and crash, or start thrashing the hard drive swapping out virtual memory and causing even worse responsiveness.
So how does InteractX handle this?
Analog (Numeric) Values
If InteractX can't keep up with data changes, it will keep only the latest Analog values, throwing away older ones. The idea is that the operator is mainly concerned with the most current reading. The exception to this is when data are logged. However, even when logging data, InteractX logs the most recent value at the time of the logging trigger.
Booleans
Booleans are different than analog values because they are sometimes used to drive state machines (such as a latch button). If InteractX simply reported the latest value, it might miss an important transition such as the release of a latch. This is shown in Figure 1.
At the same time, if InteractX reported all values even when it is falling behind, the operator would see progressively older data as described above.
InteractX handles this by only keeping the initial, final (most current), and transition value(s) as shown in Figure 2 and 3.
Specifically, Figure 2 shows the case where the current value is the same as the initial value (before InteractX started falling behind and throwing away data). In this case, InteractX will process three values: the initial state, the transition state, and the final state.
Figure 3 shows the case where the most recent value is the opposite of the initial state. In this case, InteractX will process four values: the initial state, the transition to the oppoosite value, the transition back to the original value, and the final state.
Of course, InteractX only uses these strategies if it cannot keep up with the updates. Normally, this should not happen. If your application is consistently falling behind, you may want to consider using a faster machine or reducing your data update rate (which I hope to discuss in a future post).
Brent Meranda
InteractX Performance: Introduction (Part 1)
Key HMI Challenges
HMI's must provide reliable and responsive operator interfaces that are sturdy enough for industrial applications. To do so, they must perform several functions simultaneously without locking out the operator (or simply locking up).
First, an HMI must take operator input and pass it to the machine controller as quickly as possible. In other words, when an operator hits a "Stop" button, the machine needs to stop. The HMI can't just sit there because it's busy doing other things it thinks are more important.
Secondly, an HMI needs to update the display with data from the machine as quickly as possible. The faster it can update, the better the user experience. In addition, log data needs to be logged. Alarms need to alarm. Panels need to switch. Recipes need to be downloaded, scripts need to be run, and reports need to be generated.
Three Primary Measures of HMI speed:
While there are a lot of things going on in an HMI, there are essentially three main measures of performance:
-
Initial Startup Time
This is how long it takes an operator to power on an HMI and start "interfacing" with a machine. It includes the time it takes to boot the Operating System, start the HMI, load and display the first panel(s), and connect to the machine(s) and get initial data. -
Panel Switching Time
This is the time it takes to bring up a new panel once the system is already running. - Real-Time Update Rate
This is a measure of how quickly the HMI reads and writes data.
While performance can usually be improved through hardware upgrades (like adding a faster CPU, more memory, and/or a faster hard drive), it's always possible to overload an HMI with more work than it can handle at one particular moment.
Good HMI's try to handle this in the smartest way possible.
Why the CPU Meter Often Reads 100%
While this is less of an issue with multi-core CPU's, people are often confused when InteractX shows a single core processor maxing out at 100% of available cycles. This isn't necessarily a problem as long as the interface is still responsive to user input.
The reason is that InteractX tries to use all available CPU time while still remaining responsive to the operator. In other words, rather than just spinning cycles waiting on user input, InteractX will perform background tasks or speed up the graphic updates whenever it makes sense.
On the other hand, when the HMI becomes overloaded, InteractX will slow down the screen redraw rates. Otherwise, it could easily spend all of its time redrawing the screen instead of responding to the operator.
Future Posts
In future posts, I plan to offer some tips on tweaking performance by discussing how InteractX handles data updates and explaining the panel caching options.
Brent Meranda
Toy Story: Steve Jobs and Design
I need to confess something: my office is filled with toys.
I have a miniature fire truck on my windowsill, a remote controlled car in my desk drawer, and, after Christmas, I hope to have a bag of LEGOs sitting around just in case I get the urge to build something tactile, immediate, and fun.
Sometimes, I worry about how my toys affect my image. After all, the workplace is supposed to be professional, efficient, and serious.
Then, I remember Steve Jobs. There's no doubt that he was a remarkable business leader, probably best known for founding and later saving Apple. He transformed it from a dying company into one of the most valuable brands in the world. He was a serious businessman.
But that's not what inspires me the most about him. What inspires me the most was his passion for creating cool products that people actually wanted to use. He's credited for giving the world the iPod, the iPhone, the iPad, and the movie Toy Story. You might not think of a movie as an engineering product, but I do. In fact, Toy Story illustrates real engineering genius.
Like almost all of the products Jobs created, Toy Story was a technological marvel--the first purely digital 3D animated film in history. It was also a joy to watch. The technology didn't define the movie. Rather, it was a tool that served the story. Jobs understood that, first and foremost, a movie needs to tell a compelling story that human beings enjoy watching. In a movie, that means realistic and interesting characters, a solid plot, and a realization that movies are made by and for people instead of machines.
The same can be said for manufactured products. Whether it's a computer, an MP3 player, or a servo drive, they're all made by and for people. That means they need to be made with people in mind. Configuring a motor or accessing an HMI (Human Machine Interface) should be easy instead of intimidating. And, while it might not be as fun as a box of LEGOs, I daresay it should be a joy--if even just a little. That's the idea behind our Xpress brand.
I don't always get there in the products I help design, but I always try. It's what keeps me coming to work in the morning with a kick in my step and a spark in my eye. And that's why I loved Steve Jobs: he showed that engineering can be cool, as long as engineers design for people first.
My name is Brent Meranda and I am the Software Engineering Manager at EMN. I hope you find my future blog posts useful--as a human being and an engineer.
Solid State Storage
Total system reliability:
It's the Holy Grail that we all strive for in our industrial automation designs. Of course, there are many challenges along the way: mechanical components that wear over time, systems that require periodic maintenance and the dreaded unexpected failure. With all of this to worry about on the mechanical side of the design it is particularly troubling when an "electronic" component like an HMI or Industrial PC fails.
This is why Parker-EMN is always working on ways to make all of our products more reliable and robust. We are currently in the middle of an effort to increase the reliability of our HMI and Industrial Computer systems. Not unsurprisingly, the electromechanical components in these products tend to be amongst the highest points of failure: This includes cooling fans and rotating media hard disk drives.
Parker has been making an active transition away from these components wherever possible using several enabling technologies to upgrade our HMI and Industrial computer reliability and consequently your total system reliability where these products are deployed.
Enabling Technologies:
Removing cooling fans from our designs is more complicated than it first appears, but surprisingly it often goes hand and hand with removing the rotating media storage from the design. The first step to removing the cooling fans in a design usually involves redesigning the board with a CPU and chipset that have a low power draw that will allow a convection cooled design using only passive heat sinks. A switch to Solid State drive technology replaces what is typically the second largest heat dissipating component in the system: the hard drive. At present the following product families are passively cooled: PA2, P13 and XPR. Shortly we will be introducing the EPX2 and XPR2 families with the same convection cooling technologies.
CompactFlash Solid State storage:
SanDisk introduced the CompactFlash card standard in 1994 and very shortly after introduction Parker deployed the first CompactFlash cards ever used in Industrial Automation products. A lot has changed over the years in CompactFlash cards: Moore's Law has been at work here: Capacities have increased, performance has increased and cost has gone way down! Today's CompactFlash cards are built on NAND flash technology and offer access times and latencies that are significantly faster than rotating media hard drives while offering data transfer rates that are approaching 30% to 50% of a typical rotating media hard drive. In practice this means that CompactFlash performance is now very similar to a rotating media drive in typical HMI applications. One last item to consider with CompactFlash is the P/E cycles: again today's CompactFlash has improved dramatically over years past with P/E (Program / Erase) cycle ratings as high as 1,000,000 cycles: But the net result is the same, the Flash memory, just like the magnetic media in a hard drive will eventually fail when subjected to repeated reads and writes.
CompactFlash Controllers:
CompactFlash cards include an integrated controller that is responsible for the following:
-
Interfacing the memory to the ATA bus like a hard drive.
-
ECC or Error Checking and Control.
-
Wear Leveling.
These techniques allow the cards to be easily interfaced in a design and take care of the 'maintenance' required on a CompactFlash card. The ECC manages any soft read errors that may occur from the media during normal operation, by identifying data that has been read incorrectly and either recreating or re-requesting this information from the memory. Wear leveling is an algorithm that is designed to use the memory cells in the CompactFlash card evenly: the most sophisticated wear leveling utilities even move data that is static in order to ensure that the cells are used over the life of the card. These utilities are transparent to the user: but ensure that the CompactFlash card lifespan is both long and reliable.
A final thought on CompactFlash that applies equally to Solid State Drives: You may have become accustomed to performing a 'Defrag' on your rotating media hard drive on a regular basis in order to improve read and write performance by ensuring that files are stored contiguously on the hard drive media. Not only is a 'Defrag' unnecessary on Solid State media like CompactFlash and SSD's but it will reduce the lifetime of these storage products. The reason we like data in contiguous blocks on rotating media hard drives is because it takes time to position the read/write heads over the location of the data on the drive: so the more contiguous your data: the less moving of the heads, which results in faster overall transfer rates. With solid state memory any memory block is accessible in the same amount of time as any other: so having the data contiguous provides no benefit and running a 'Defrag' simply moves the data many times in order to put it into a contiguous segment: using up the P/E cycles with no benefit. Net Result: Don't 'Defrag' your solid state media.
CompactFlash is the standard storage media in our P13, PA2 and XPR family PowerStations and is coming soon in the XPR2 and EPX2 family PowerStations. Not unsurprisingly all of these models are also fan less, passively cooled units.
Solid State Drives:
Solid State drives offer the best of both worlds: Performance that meets or exceeds rotating media in every important criteria and the mechanical reliability of solid state media. Like CompactFlash, SSDs are produced using NAND flash memory. What makes them different than CompactFlash is form factor and the parallel internal architecture of the NAND flash memory. Most SSDs are designed to physically resemble traditional 2.5" and 3.5" hard drives: specifically so that they can be used in hard drive replacement applications. These form factors make them easy to incorporate into existing or new designs that would ordinarily use rotating media drives. The parallel internal architecture of the typical SSD is what provides the enhanced performance over CompactFlash. While the typical CompactFlash card contains a single NAND flash chip, the typical SSD contains several NAND flash chips operating in parallel providing significantly enhanced data transfer rates.
Much of the information from the CompactFlash card section also applies to SSD drives, given the same core technology (NAND Flash memory). While the controllers used in our CompactFlash cards provide an interface using the ATA bus the SSD's that Parker uses in our systems are interfaced via the faster SATA interface standard, which provides the bandwidth to support the enhanced transfer rates that the parallel NAND chips in the SSD offer.
SSDs are the standard storage media on our IPX PowerStation line and they are optional on our IPC Industrial PC product line.
The net result: these newer storage technologies provide key benefits to increasing overall system reliability by providing a media that is much more resistant to physical shock and vibration than traditional rotating media. It is important to understand the limitations that the P/E (Program / Erase) cycle puts on the life of the media in your application. Whether selecting a rotating media drive or solid state storage, if you are deploying in a high write environment (ie: database logging in the ms time domain) it is important that you understand the anticipated life of the media and schedule a replacement ahead of a failure.
AB
Information Anywhere!
One of the primary reasons that any Visualization products are deployed is Information:
Machine Level HMI's offer the following:
- Delivering information about the machine status, alarms and setup to the operator.
- Delivering information about production volumes, yields and operational efficiency to the shift supervisor.
SCADA Systems:
Go beyond this 'shop floor' level of information to deliver aggregate KPI's to management as required. Information from multiple cells or production lines can be aggregated, pareto'd, reported and sorted to provide management a window into the overall efficiency of their operation.
Plant Floor Displays;
Deliver real time information on the production process that allows operators and supervisors on the floor to correct issues as they occur, leading to increased throughput and efficiency. This information can also contribute to the overall KPI delivery of the SCADA system.
Parker's Information Anywhere product family includes products in each category: Interact Xpress is our machine level HMI, InteractX is our SCADA system and the Parker Factory Display is our Plant floor display product. Three key features seperate the Parker Information Anywhere products from our competiton:
- Ease of development - each of the products in the Information Anywhere family have been designed to allow our customers to get their projects up and running faster. After all, the best project is one that is running delivering real returns to your organization.
- Scalable integration - Parker's Information Anywhere products play well with others. A transition to Parker's family of products does not require huge investments in redundant servers or 'all or nothing' implementations. Projects can be scaled from a single display to a complete plant floor one unit at a time.
- Superior information flow - Our point of collection products (Xpress and PFD) support award winning Web publishing technology that let you move information form the plant floor anywhere it is needed with just a simple web browser. These same tools allow you to leverage that information up and down the chain: Our SCADA automatically imports the web published screens and tag data from the plant floor level tools, so you only have to create it once!
All of this information is useful not only in realtime at the point of collection (Xpress and PFD) but probably even more so when logged historically over the course of time for further analysis (InteractX). The point of this blog post is to point you to newly posted tutorials on moving Information Anywhere with the combination of our Xpress, PFD and InteractX products.
On the InteractX product page: http://www.parkermotion.com/products/Windows_HMI__5934__30_32_80_567_29.html
under the Section: 'Download-Sample Files' you will find posted a new series of tutorials that will walk you through using InteractX's database features and connecting Xpress and PFD to the information in the databases. These tutorials demonstrate not only the ease of information flow between these products but how to store and retrieve information from common database formats.
Text Etiquette in IEC61131
If you thought this was yet another blog telling you if it's appropriate to text while driving (never!) , during meetings (with caution) or sending personal photos (with extreme caution!), then you're in the wrong place. No, today I'm here to talk about my favorite of the IEC61131 programming languages, Structured Text. As someone who started off with BASIC and Pascal, then moved to Visual Basic before sampling a variety of Basic-like motion languages, Structured Text (ST) is certainly in my comfort zone.
ST includes many familiar commands like WHILE loops, IF-THEN-ELSE blocks, FOR loops and the very useful CASE statement. In most IEC61131 platforms like the ACR9600 series, you will also find a full set of built-in functions for math operations (SIN, SQRT), string manipulation (LEN,LEFT) and data type conversions. When it comes to writing code with complex evaluations, ST is easier and more efficient than the graphical languages like ladder.
But now for the important thing to remember: ST acts like a PLC! What I mean is that you need to consider that the code will scan and run over and over, without stopping and without the need for looping. A common practice in many motion text languages is to dwell or wait for an event to happen before moving to the next line of code. You won't find the dwell or wait statements in ST and please do not try to create them! A PLC program should be designed so that it completes in a finite and fairly short and consistent time. Resist the urge to create a WHILE loop that spins in place until a condition is met, such as an input being pressed by an operator. That could take seconds or even minutes. If the ST code is "waiting" for that input, the task will not complete. In many cases, other tasks will not run and background services required for communications will be stalled. Instead of waiting for that event, let the task run freely and evaluate that input condition each scan with, say, an IF statement. Once the condition evaluates true, the code can take the next step in the machine operation.
For examples of Structured Text code, visit our samplespage. And remember to keep both your text messages and PLC programs short and clean. You don't want the machine to slow down or lose your seat in Congress.
Newest Brammo Race Bike
Friday - May 7th was an exciting day for both the Brammo Race Team and Parker Hannifin. It was the last day for performance validation and testing before the TTXGP Race ( part of the West Coast Moto Jam event) on Sunday, May 15 at Infineon Raceway - a high performance electric motorcycle race.
The Brammo bike, Empulse, was charging when I arrived at the track. The team did some slight mechanical adjustments to the bike before taking it out on the first trial of the day. The refinements that were made to the bike were going to be under the spotlight in a matter of minutes as the Empulse sped around the track.
The MPP traction motor was being studied closely on this day. We were benchmarking the performance of the Brammo bike with performances from last years event. The motor/inverter and mechanical drive ratios were tuned for the Infineon track. Testing planned to reveal key performance indicators like peak torque, RPM, battery usage, current draw, coolant temperatures, power output and perhaps the most imporatnt indicator: lap time. The data recorded will be excellent indicators for next Sunday's race because the track was filled with dozens of other non-electric (gas-powered) race bikes.
The MPP-powered Brammo's Empulse around the track dozens of time during the day. Data recorded showed positive results from the all the refinements the Brammo-Parker Engineering team implemented not only on the Parker traction motor, but on the bike as a whole.
The TTXGP race exemplifies a high performance sport that pushes green technology to the edge of performance - and then demands even more. From track results this past Friday, it looks as though this bike will be a top performer at next week's race and has given all at Brammo and Parker a reason to be excited about the effectiveness of collaboration on such a stage as the TTXGP.
You can learn more about the event at http://www.infineonraceway.com/tickets/west_coast_moto_jam/
By Jay Schultz, Product Manager - Motors
Frameless Motors
Frameless Motors
A frameless motor consists of a stator assembly and rotor assembly with permanent magnets. Hall effects may be offered as an option to provide feedback if an encoder is not selected for the application. The frameless motor does not include shaft, bearings, or endbells. The intent is that the motor will be directly integrated into the mechanical structure of the machine (the rotor is connected directly to the machines rotating shaft) leading to an optimized design, reduced footprint, and lighter machine weight.
The performance advantage of a frameless motor is in the increased rigidity (stiffness) that it will offer when designed into a machine. Since there are no mechanical elements between the motor and load (couplings, belts, pulleys, etc...) dynamic performance is improved. Inertia matching is not as critical as the motor and load are now one inertial mass. In addition, as there are no mechanical parts to wear, the lifetime of the entire system is increased and maintenance costs will be reduced.
Sizing a frameless motor is the same as a housed motor. You need to calculate speed and torque based on load inertia, acceleration, friction, etc... . There seems to be more questions regarding what winding to choose from as many options may exist. From experience I advise that you look at your speed requirement and available voltage to the motor to approximate your motors required voltage constant (Ke/Vkrpm). The following is an example of how you can approximate your Ke;
Given
- Required speed - 3,000 rpm
- Voltage - 120 VAC (168 VDC from the drive)
Approximate Ke = Voltage/Speed (V/Krpm) = 168/3 = 56 V/Krpm
Typically I would add in a 10% safety factor for any voltage drops, so I would make sure that after I selected an appropriate frame size that met my torque requirement, I would look for a winding that had a Ke that was no greater than 50 V/Krpm. Total voltage requirement needs to be addressed also and would take into account the required current (amps) for the application, the motors resistance, and the back electromotive force (BEMF) of the motor. The following is a continuation of the aforementioned example;
Given
- Required speed - 3,000 rpm
- Required torque - 250 oz-in
- Voltage - 168 VDC
- Motor Ke - 50 V/Krpm
- Motor torque constant (Kt) - 60 oz-in/amp
- Motor resistance - 2 ohms
Total Voltage Requirement = IR+BEMF = (250/60 x 2) + 50 x 3 = 158 volts to meet your rpm requirement. Available voltage is 168 volts, so your selection thus far seems to be correct.
This example is meant to show a method to shorten the selection of available windings when sizing your frameless motor. Other factors do need to be taken into account such as thermal calculations involving dissipation and motor core losses. Review of the motors speed/torque curve should answer any concerns at this point in your motor selection.
In conclusion, frameless motors are an ideal solution for applications such as machine tool, centrifuges, mixers, winders, or any other application where mechanical elements represent additional maintenance costs and important loss of space. Parker offers frame sizes ranging from 32 to 254mm in diameter providing torque from 6.3 to 13,000 oz-in, and speeds up to 50,000 rpm. A variety of windings are available which will allow you to optimize your motor based on your power supply and application requirements.
For questions, or additional information, contact Parker Application Engineering at 1-800-358-9068.
Jeff Nazzaro - Parker Product Manager
Circular Arguments
Linear and circular interpolation have been standard features in motion controllers for many years. As PLCs have incorporated more motion functionality, some higher end PLCs and Programmable Automation Controllers offer multi-axis interpolation. For many of these controllers, however, these features often require add-on hardware or firmware modules or special NC kernels.
The ACR9600 Programmable Automation Controller is built on a core motion engine, capable of performing multi-axis interpolation on up to 16 axes. Additionally, the controller can be virtually divided into up 8 different axis groups, each able to execute motion in its own coordinate system. IEC61131 Function blocks are provided to give users unlimited flexibility in combining linear and circular interpolation with as many axes as needed. These function blocks and the associated motion functionality are standard features: no extra hardware or software to purchase or install. 
Whenever arcs or circles are involved, for me it's time to dust of the trigonometry and break out the graph paper. Start point, center point, end point, sine and cosine; how nice would they look inside a function block! Here'smy version of a circle , you only need to supply the radius and the angle.
Stay tuned for the next FBOTW. Jim
Function Blocks: Program Once, Reuse Often
The heart of IEC61131-3 programming is the function block, the basic building blocks of a control system. A function block is programming unit, or chunk of code that represents a specialized control function containing an algorithm and data memory. Function blocks can and should be used over and over within a project and across multiple projects, making them a great investment. Spend the time once to code and test and then use it again with confidence on the next application. Creating programs from smaller, more manageable blocks of code encourages well structured software design and ultimately speeds application development.
The Xpress PAC 9600 controller is delivered with over 60 built-in, firmware function blocks for machine and motion control. Some are the basic blocks for any PLC such as Timers and Counters. For motion control, Parker implemented a number of blocks defined by PLCopen, a vendor-independent organization devoted to creating standards for motion within IEC61131-3. The PLCopen function blocks will be familiar to users of Parker’s Compax3 drive controllers as well as several other vendor products. These motion modules have recognizable names and consistent behavior and were a logical choice for generating single axis motion with the 9600.
In a recent training class, one of the first lessons covered the basic blocks needed for motion and stressed that MC_Power and MC_Reset must be included with every axis. Along with these, ReadStatus and ReadAxisErrors are commonly used. It wasn't long before one of the students remarked "it would be nice to have a single function block that included all of these". Great idea!
Download this function block and watch a video of how to import into a project.
This is just one example of pulling multiple blocks together. I'll be back soon with another example, hopefully prompted by a user suggestion.
Jim
Gearhead Sealing
Sealing
The International Protection Rating (IP Code) classifies the degree of protection a product has against the intrusion of foreign matter. The first numeral designates the degree of protection the product has with respect to the ingress of solid objects. The second numeral designates the degree of protection the product has with respect to the ingress of water.
Parker's helical planetary and bevel gearhead product lines (PS/PX/RS/RX/RB/RD/RT) are sealed to IP65 for complete protection against dust (dust tight) and washdown conditions (projection of water jets at a pressure of 30 kN/m^2 at a distance of 3 meters). Our PV gearheads are sealed to IP64 for complete protection against dust (dust tight) and splashing water. The spur NE product line is sealed to IP54 where ingress of dust is not totally prevented but will be fine on a machine where the ingress of dust will not be in sufficient quantity to interfere with the satisfactory operation of the machine. As with the PV product line, it is also protected against splashing water.
These ratings must be considered when selecting a Parker gearhead for your application. Please make sure to contact us if you are unsure of your requirements, or if special requirements need to be taken into account.
Other controllers just follow...
Xpress...Create ACR controller tags in seconds
Xpress.. more that just a brand name
The main idea behind the Xpress brand is the desire to solve automation puzzles faster. Well designed products that are easy to use is the most basic implementation. Step two is getting multiple products to work well together and thus save the user time. To see this concept in action, give ACR-View 6.1 a try.
A typical application that includes an HMI and controller requires the user to create tags in the HMI that represent data in the controller. This can be tedious work, creating names and assigning the correct controller address. Often names for these variables already exist or were developed in the controller project, so having to re-do this again in the HMI is double work.
A new feature with ACRView 6.1 is a Tag Export utility, which eliminates that redundant effort. With just a few clicks, ACR-View will construct a text file that properly formats the tags and associated addresses for import into a Xpress HMI project. A set of standard tags are created based on the project and controller configuration. For example, the jog flags and actual position parameters for each axis are tagged, using the axis names in the project. Additionally any user variables in the DEFINE editor will also get tagged. This feature can be used with any ACR9000, 9600 or even Aries controller.
Now, when you develop the HMI screens in Xpress Manager, you can import this list and have a full list of ready-made tags. Say it normally takes thirty seconds to enter a tag manually. Importing 300 automatically generated tags for 4 axis application could save two and a half hours of programming time. Thats why we call it ..Xpress.
Download a video of this Xpress solution.
Factors Affecting Velocity and Current Ripple
For any motion control system operating in Velocity Control mode, any amount of deviation between the commanded steady-state velocity and the actual velocity at any given point in time is known as velocity ripple. Similarly, in a motion control system operating in Torque Control mode, the fluctuation between commanded and actual measured torque is called torque ripple. Both velocity and torque ripple values are usually defined as a percentage (%) of deviation from the ideal commanded value.
When it comes to determining the velocity or torque ripple in a stepper or servo motor system at some arbitrary motor speed or motor load is not always a simple task, because any combination of a large number of factors can influence how much ripple will exist in any given application system. The following list gives an example of many, but not all, of the factors that affect velocity and torque ripple:
- Load-to-Rotor inertia ratio
- Motor Pole count (higher pole count = less ripple)
- Encoder resolution
- The commanded velocity (is the commanded speed at a harmonic of the motor?)
- The system bandwidth (different between an analog and a digital drive)
- Commutation type (Sinusoidal vs. Trapezoidal commutation)
- The system trajectory update rate (when using a digital drive)
- The natural (harmonic) frequencies of the system as a whole
- Mechanical resonance of individual components, such as:
- Couplers
-
The motor
-
The load
-
Gearboxes
-
Drivetrain assemblies, such as lead screws, pulleys, transmissions, etc.
- Mechanical friction in the system
- Physical alignment of mechanical components
- Inherent performance variances between two like components
- Load damping
- The consistency of the AC supply voltage to the drive (i.e., power supply integrity)
- Sampling rate / resolution of the tachometer (or velocity-measuring device)
What makes a "concrete" ripple number difficult to nail down is that rarely can any two motion control applications be replicated exactly. Because it is nearly impossible to accurately simulate every constraint from one system to another, the amount of ripple is completely dependent on the individual system from which the ripple measurements are taken. So, while "Ripple Value X at speed Y" may be measured in one test, taking every component from that first test to another location and performing the same test may yield a completely different value, even if outwardly it seems that all factors are kept equal.
Many companies offer an "across the board" ripple specification for their products. Because so many factors contribute to - and influence - the actual fluctuation in velocity or torque that a motion control application will experience, specifying an "absolute" percentage of velocity or torque ripple at a given motor speed (or for a given load) is not only highly misleading but often times unrealistic.
It is important to remember that the actual ripple is not the critical question to be asked. The frequency at which any velocity or torque ripple/fluctuation takes place compared to the frequency at which you are actually collecting your velocity or torque data
Beware of those companies who boast of being able to provide "specific and repeatable" values for torque or velocity ripple as a function of motor velocity. This is because these ripple values can only apply to a system whose operating conditions closely approximate those conditions present in the factory's laboratory test at the time that this stated "ripple" value was measured. Most of the time, the quoted velocity (or torque) ripple data by a company is unsubstantiated altogether - "pulled out of the air", so to speak.
So, when any motion control company makes claims to have repeatable velocity or torque ripple values, be sure to ask the company about the conditions under which that data was obtained. Granted, some companies will be able to back up their claims with sound data and empirical evidence. But, if any company publishing fixed performance claims for velocity or torque ripple for their products cannot - or will not - provide this data, be leery of the validity and accuracy of their claims.
- Motor Pole count (higher pole count = less ripple)
Gearheads Reduce Inertial Mismatches
Servo motors are putting out more torque, relative to frame size, than in the past with their use of lightweight materials, dense copper windings, and high energy magnets. Because of this, greater inertial mismatches can be present between these motors and the loads that they are trying to control.
Inertia is defined as a measure of an objects resistance to a change in velocity given the objects shape and mass. The larger an objects inertia, the greater the amount of torque that will be required to accelerate or decelerate it. In rapid start and stop applications you can significantly improve system performance by having the correct ratio of load inertia to motor inertia. If the load inertia is too great compared to the motors an application may experience overshoot and/or increased settling times which will greatly decrease a production lines throughput. In contrast, a motor too large for an application will have to use more power to accelerate its own inertia resulting in increased operating costs, in addition to the higher cost of the motor itself.
A gearhead will help to match the inertia of the motor and the load that it has to control. The reflected inertia experienced by the motor will be equal to the load inertia divided by the square of the gearhead ratio. So as an example, if you were using a Parker MPP0921B with a rotor inertia of .00039 lb-in-sec^2, and your load inertia is 1 lb-in-sec^2, your inertial mismatch is 2564:1. Using a 10:1 gearhead ratio then with a Parker PS90-010 will now create an inertial mismatch of only 25:1, a PS90-020 will get you down to 6:1 inertial mismatch between motor and load.
How you look at solving an inertial mismatch is dependent on the application requirements, and the components being used in the application. Gearheads are just one of the ways to design an efficient and productive system that will perform reliably for many years to come.
What's the Frequency Kenneth? Linear Positioning Settling time and Natural Frequency
There are a lot of things that affect positional accuracy which include: ambient temperature changes, system dynamics, travel lengths, load orientation, structural stiffness, location of center of gravity, feedback type, and more. The thing I want to focus on today is settling time. If positional accuracy is a concern for the application, then settling time must also be understood as it relates to the throughput of the process in particular when the process requires small repetitive moves at high acceleration. You may never get "there" on time if you don't allow yourself time to settle long enough.
- Know your required settling time and ensure your throughput allows for that time
- Work to understand your system moving weight, stiffness and natural frequency you can then expect that the position bandwidth of the servo is about 1/3 of the natural frequency
- Recognize the effect of the environment and minimize external disturbances such as ground vibrations, cable rattling, rough rolling surfaces to assure that their effect on the dynamics of the system is minimized (thereby not resonating the system natural frequency)
- Optimize the selected motion parameters including maximum jerk, max. acceleration, and max velocity to maximize throughput at the required dynamic precision.
- Machinists Handbook for Accuracy
- Japanese Industrial Standard JIS B6201. This Japanese Industrial Standard specifies the common fundamental matters and essentials relating to test methods in the case where the tests of the running performances, rigidities, mechanical accuracies and machining accuracies of machine tools are carried out.
- Parker Engineering Corner – linear mechanics accuracy
- Fundamentals of Servo Control - Parker Engineering Corner
- ISO Standard on Accuracy (Buy ISO 230-2 Online). ISO 230-2-2:2006 specifies methods for testing and evaluating the accuracy and repeatability of the positioning of numerically controlled machine tool axes by direct measurement of individual axes on the machine.
Showing 1 to 20 of 34 Post