CapinWinky

Just to pop in and clarify that if you install v13 on a computer, uninstall it, and install v12, it will have this same issue where .mer files made on said computer will not be compatible with computers with v12 that have never had v13 installed on them. It is deeper than just SQL version; Rockwell ran into hard obselense of various Microsoft components and lost the legal ability to release new software that used those components. They had to rush release View Studio 13 in a broken state just so it could be grandfathered in, which is why you must also install a recent patch roll-up or it won't work at all. ActiveX is actually one of the bigger pieces of this puzzle with View Studio v13 probably being the very last to support ActiveX and probably meaning there will never be v13 firmware for the panels themselves. What will be interesting is what happens with v14. It will have to be a fairly large departure from v13 and one would assume it will not support ActiveX at all.

Ha, the solution is it doesn't work. Awesome.

I was just about to search for B&R posts and offer any help I could and despite a very recent post containing 'B&R' in the title, no results were returned. B&R is the number 5 or 6 controls company by controls revenue and has been for almost a decade, so it's a bit weird they're in the 'Other' category anyway, but they're fairly small outside of Europe, so I get it. When it's impossible to search for their company name, that's a whole other level of exclusion. It's a high-tech platform and used for primarily complex and high-end machines, so people are going to need from the community.

Really, most things are covered in the help under Motion -> Reference Manuals -> ACP10SDC. A few details that you can easily miss are closing the loop on axes that usually don't have encoders (VFDs) and how to tune a stepper axis with an encoder so it doesn't just stall all the time. When you add an inverter, like a P74 as an SDC axis, it will make an entry in the axis parameter table for PCTRL_S_ACT_PARID (230) = PTCRL_S_SET, which makes it open loop. Just remove that line and setup the SDC encoder stuff and it will use the encoder position and close the loop. I do this with X67 encoder modules to better maintain set speed for intermittently loaded conveyors. For stepper tuning, you have to get into the axis tuning and set p_max to a real value that prevents stalling instead of 1e30 (no limit). With map axis control, p_max must be set from code after the map initialization until they fix the initialization step always writing down the default values for parameters not in the map config, which p_max isn't because you never use it unless you are doing a closed loop SDC stepper axis. You will also want to set t_predict/t_total to some multiple of your cycle time to give time for the encoder feedback to reach NC Manager. I usually use 8xEPL cycle and this is recommended in the help. Just try different values to find the one that minimizes lag error spikes up or down on a high accel move, which is the same tuning procedure as a servo (the difference being that the value you find for a servo will be 1x or 2xEPL_cycle, not 8x).

The torque loop doesn't need to be tuned, just the speed, position, and possibly feed forward if you are using it. If the motor isn't even trying to move, you may have an issue with a cable. You can check the cable by doing a phasing command.

There actually is a Mapp User function that will handle logging in, but in the past you had to write your own login code. Once you have a login level, you use the locking datapoint to lock or unlock page change buttons. You can also use the page change variable to programatically change to the secure section automatically when they login.

The top few are currently: Rockwell Siemens Mitsubishi Schneider-Electric B&R Omron Beckhoff Rockwell and Siemens are clearly the top two and account for 50% combined though who is bigger at any one point in time is up for debate and the numbers are fuzzy because they sometimes include crap that is outside of core PLC products, like buttons and terminal blocks. They mostly trade market share with each other since they are similar ideology. Mitsubishi used to have Asia wrapped up, but is in rapid decline as Asia branches out to foreign platforms and Mitsubishi fails to penetrate other markets. They are also the more traditional paradigm, like Rockwell/Siemens. Schneider-Electric keeps buying other brands and then running them into the ground, so they're constantly losing market share only to buy more of it. The core of that problem is that they carry wildly different PLC lines but upper management doesn't seem to realize that lines like Modicon and ELAU (now PacDrive) are completely different paradigms. You can't sell these two completely different controls to the same customer and set them up with the expectation that they are in any way similar or you will end up with a frustrated customer looking for a new platform. B&R, Omron and Beckhoff are all scrapping it out for 5th place with similar numbers. B&R and Beckhoff are eternal rivals with very similar offerings; both growing rapidly as they win over customers looking for a more advanced platform. B&R was clearly winning this fight until Beckhoff managed to win over a lot more 3rd party support for their EtherCAT fieldbus than B&R has secured for their Ethernet Powerlink fieldbus. However, a chip from TI that supports both of these and more and is priced to corner the component market will likely mean 3rd party support for both fieldbuses and nudge B&R ahead again. Omron is the most interesting case. It seems like they are trying to transition from a Rockwell-like platform to a B&R-like platform, but are doing it in a much smarter way than Schneider-Electric; they seem to fully realize the magnitude of the change they are making and doing damage control with existing customers, managing expectations of new customers, and training their existing sales force. I'm not sure if their middle ground tech offering is going to cut it though; engineers comfortable enough to go that far would be comfortable enough to go the whole 9 yards to a B&R or Beckhoff. I have no idea if they are growing, but I know they aren't growing as fast as B&R and Beckhoff both have long since passed the 2006 Omron numbers (the last publicly available numbers on global market share).   There are tons of other platforms of almost the same size as B&R/Omron/Beckhoff, many with larger total company sales, but smaller PLC sales. Here is a full list of anyone with noticeable market share: ABB, Altus, B&R Industrial Automation, Beckhoff, Bosch Rexroth, Delta Electronics, Eaton, Festo, Fuji Electric, GE Intelligent Platforms, Hitachi, HollySys, IDEC, Koyo Electronics Industries, Lenze, LS Industrial Systems, Mitsubishi Electric, OMRON, Panasonic, Phoenix Contact, Rockwell Automation, Saia-Burgess Controls/Honeywell, Schneider Electric, Sharp, Siemens, Sigmatek, Toshiba, VIPA/Yaskawa, Yokogawa I know of a few that don't make that list because their current market share is tiny, but are worth noting anyway, but right now, only Keba comes to mind. They tightly combine PLC and Robotics through traditional robot controller commands rather than CNC style commands (like B&R) or function blocks (like Elau/PacDrive/Schneider-Electric).

That's a fairly old processor (the System 2003 line came out in the mid 90's, despite the name implying it came out in 2003), but it might support OPC, which would work with basically any HMI. If it doesn't support OPC, you could do a .NET HMI and use B&R's free API to talk to it.  I assume you have the original PLC program (B&R HMI program is part of the PLC program) and a copy of Automation Studio so you know what all the variable names are and whatnot. I'm curious why you would go through the time and expense to replace the B&R HMI on such an old PLC line. If the HMI broke, you can just slap on a new one and it will upload the HMI from the PLC.

I don't think there are any IP67 machine mount blocks with relay outputs. Those IO blocks are usually completely filled with epoxy and solid state relays that could do the job are a bit big to fit into that form factor. You're better off putting the relays with the lights and supplying normal IP67 outputs to them (unless you're telling me you have IP67 lighting). EDIT: B&R has an IP67 Modbus bus controller that acts as a ModbusTCP server (slave) to control any of their IO. It should work with any Modbus TCP master; the only annoying thing is you can't control which registers it uses, those are automatically generated based on how you connect up the IO hardware.

Thanks a lot for that Sparky, it was super useful. I did notice it was missing the MPC parameter to select if you are using Cos Phi or Rated Power (the embedded webpage is also missing it). I'm guessing is 16#91/16#01/16#0F or similar and may do some experimenting to find out, but for now I'm just hoping I don't need to use it.

Schneider doesn't have the Sercos 3 interface out for the Altivar 32, and I'm going to use the Ethernet/IP interface until they do (not my choice). I found documentation on the CIP basic and CIP advanced control, and honestly, I will probably use one of those two, but I'm curious about the "Native" control, which seems sparsely documented. SoMachine Motion doesn't label any of the input/output words and it looks like you're supposed to custom select parameters that will be read/written using the drive's web server. Just wondering if anyone has an app note, bonus if it's explicitly for PacDrive3. Related, I'm a little fuzzy on explicit messaging with Ethernet/IP, but it seems that's what I'll need to do to setup the motor parameters and possibly to configure the "Native" control words. Any examples of that on PacDrive3 would be nice. I have a manual with the file name: ATV32_Modbus_TCP_EtherNet_IP_Manual_S1A28701_02.pdf that has been really helpful and may even answer all my questions, but it looses me in a few spots, such as how a parameter is addressed with explicit messaging.

Just the other day I was saying I didn't know why anyone would by a B&R PLC from Schneider instead of B&R. How did you end up with an M258?

EtherCat, ProfiNet, and Powerlink (and to a lesser extent Sercos III) are real-time, deterministic, ethernet protocols. They all have a cycle time and they refresh at that cycle time, every time, or they shut down with a major fault. Just because your PLC program isn't running as fast as them, doesn't mean that the EtherCat interface in the PLC isn't or that the drives you're connected to don't need to share position data faster than the PLC. I come from the B&R world where the drives do their own set point generation and function largely without interference from the PLC. It is very common to run electronic camming on Powerlink at 400microsecond cycle times so the master can send the slave it's position with a high resolution and fastest task on the PLC to be much slower at a few milliseconds cycle time.

There are a few higher tech PLCs like B&R and Beckhoff that offer ANSI C programming standard. I know B&R also offers C++, but that is an add-on more geared for automatically generating code from MatLab/Simulink. ANSI C actually lends itself very well to PLC work, but C++ and C# start getting very object oriented which starts to veer away from the point of hard real time processing that PLCs normally do. That's why you don't typically see newer, high level, PC languages in industrial automation, they are geared around PC type operation with interrupts and events. PLC programs run all the way through, over and over, a completely different type of programming.

When talking about the IO cards, sourcing means they send out 24V and sinking means they are expecting 24V in. Sensors are generally not referred to as sinking or sourcing and instead referred to as PNP or NPN. PNP = Sinking inputs (you put in 24V to turn an input on) and Sourcing outputs (24V comes out of them when you turn them on).NPN = Sourcing inputs (24V comes out of the input and connecting that 24V to common turns the input on) and Sinking outputs (when turned on, the output connects to common).Generally, you always use PNP, Sinking inputs, sourcing outputs. The reason NPN stuff exists is because low powered microchips with inputs and outputs built right in can't provide any power themselves, so they are always sinking no matter if they are outputs or inputs. That explains sinking outputs, I forget the very legitimate reason sourcing inputs exist, but there is one. I am of the opinion that if you are not in the very rare case of actually needing NPN for a legitimate electrical reason, you should always use PNP. It makes a lot more intuitive sense (put voltage into inputs take voltage out of outputs) and there is a much wider selection of sensors available. The next thing to think of is Normally Open or Normally Closed (NO or NC). NC sensors always give you 24V until they see the thing they are supposed to sense. That way, if the sensor is broken or the wire is cut, it will behave as if it is sensing the thing (in your case, everything will be an over height truck, which is better than missing an over height truck). NO are the opposite, only giving 24V when sensing the thing/event. These are better for when a you are waiting for a thing to happen rather than making sure a thing isn't happening. For example, you're looking for a cylinder to extend would use NO, but making sure a cylinder is not extended would use NC.

I've been working with B&R for several years and have nothing but good things to say about them. I recently changed jobs and now work mostly with Rockwell and Elau/Schneider PacDrive3 and frankly, I miss B&R because their platform is so much more capable than Rockwell and has a better programming environment than Schneider. Automation Studio (I'll shorten to AS) 3.X is a HUGE step up from AS2.X and AS 4.0 has introduced more improvements. I actually copy and past ST code from RSLogix/Studio 5000 and EPAS/SoMotion into an evaluation copy of AS to work on them and then past them back into where I need it because the AS editors are so much better. If you worked with B&R before 2008, you should check them out again.AS covers programming everything, no need for separate HMI, drive, commissioning, or simulation software and the AS does the entire product line, (so much better than Rockwell's dozens of separate programs/license). Programming the SafePLC does use a 3rd party editor (I'm sure for liability reasons), but it is integrated into AS. Unlike most, AS works easily with standard version control (Subversion, Git, etc) and allows multiple people to download different parts of a project to the same PLC. It really is the best) IDE of any PLC platform by a very wide margin.They are #4 or #5 world wide for PLC sales (behind Rockwell, Siemens, and Mitsubishi) and most likely past Mitsubishi for servo control sales, maybe even past Siemens. World wide, they passed Omron in total sales a few years back. You don't see the B&R name on a lot of equipment because they make it very easy to re-brand to the OEM's company name. In the US market, they frequently end up on systems with a do-nothing MicroLogix thrown in to make end users feel better since so many places spec AB because AB programmers are a dime a dozen in the US.They're an advanced platform; that makes the learning curve steeper, but there is nothing they can't do. You don't tend to see B&R on really simple machines, even though they can be cost competitive at the low end; I think the reason is OEMs making simple machines don't want to spend money on training and Automation Direct or ProFace is more geared toward the low end, no-training-needed market.Their advanced camming and servo control in general is just flat out amazing. Their only weakness has been robot control, though they've been able to do it for many years, they kept it all pretty much in house. Now they are starting to make standard robot geometries available (a lot like Elau) for easier, wide spread use (probably because they snagged so many Elau guys when Schneider bought them).I haven't done anything with their CNC capabilities, but I hear they just overhauled that and it is very capable.Their Visual Component HMI editor (built into AS) is really good in some respects, but bad in others. They had plans to move to web based HMI, which would be a huge step up and a big advantage over the competition. However, I fear that will make their learning curve even steeper.Honestly, I no longer have any connection to B&R and don't even use their products anymore, but I want them to succeed because they are, hands down, the best product on the market at a really great price point and a good company filled with good people The better they do, the more likely I am to get to work with them in the future. What's extra frustrating is I'm using the PacDrive3 platform because my company is locked in with Schneider, and all the IO is made by B&R but programmed in Schneider's inferior software package! There are already comments about ladder; I think B&R's early mindset was that ladder was dying out as new engineers (already familiar with text based programming) entered the workforce and machines got complicated enough that you didn't want just anyone poking around in the code. This has been largely true at advanced OEMs, but B&R quickly realized that the US automation industry is slow to change and low-end OEMs buy a lot of PLCs. B&R's first cracks at a ladder editor were barely usable because they just didn't expect people to really use them that much. Now, their ladder editor is very good, comparable with other big brands, but their ST editor is world class and should be the model that all other brands steal from. I could talk all day about how bad ladder is for the industry and the terrible ST implementation of Rockwell is the biggest blockage the death of ladder, but I'll save that for another post.

I know this is a year old, but I'm 99% sure you can't program the M258 line with USB. The M258s are part of an agreement with B&R and are re-branded X20 PLCs, none of which can be programmed by USB. Schneider did the same thing when they bought Elau, put USB programming ports on them when they changed the name to PacDrive3 and then never added the ability to use the programming port. Schneider software tends to not use the IP address by default and there should be a setting in SoMachine to use the IP address, which can eliminate many connection issues. Sometimes Windows Firewall gets a little picky when it comes to SNMP, which is how most auto discover stuff works; you may want to check those settings as well in your VM.

Just an FYI, you posted this in the "Other PLC" section instead of the Rockwell/Allen-Bradley section where most people that could help you would be located. You might also want to try PLCtalk.net, which is 99% Rockwell.

1-2) As long as the original program was done in Automation Studio, there is an automatic upgrade path to the current version of Automation Studio; otherwise, you will need to manually duplicate the code into Automation Studio. There is a big difference between AS 2.5.X and earlier and 2.6-2.7 and a massive difference between 2.X and 3.X (the jump from 3.X to 4.X is much smaller). Because of this, they recommend you first upgrade to 2.7, then to 3.X, then to the latest version. If you have a license for a new version, that also allows you to install 2.7 and 3.X to complete the upgrade of very old projects. 3) You will need the source project, B&R only puts compiled code on the PLC by default, so unless you luck out and it is archived on the CF card with the compiled code, you will need to hunt this down (it's actually a little rare to find the source archived on the PLC, even now that there is a simple check box to do this). In older versions of AS, you had to transfer the source quasi-manually, usually to the User partition (F:\), which would require FTP to the PLC to access since CF card readers generally don't support multiple partitions. On newer versions of AS, the source is saved in a single archive with the rest of the system binaries and is pulled up using Automation Studio. 4) If there is an ethernet port, a standard ethernet cable, otherwise you need a serial cable with a null modem and a gender changer. You can also find null modem serial cables that already have the female end on both sides. 5) I'm not sure if you can pull off the upgrade with just the maintenance license, so you may need a full license of Automation Studio, which is not cheap. If the project was not originally done in Automation Studio, you will need to get that software (they'll give it to you for free if you have an AS license) and do a manual conversion of the code. 6) B&R's website is hands down the best of any Automation company, you can find detailed information on each IO slice there. The things to pay attention to are: Multi-funtion modules that can only do one or the other function (like high speed counter OR encoder input).Module power consumption, both IO and internal. You will need to use PS2100 modules to boost the output power supply if you have a lot of outputs. If you have a very large number of modules, there is a PS3300 module that will also boost the logic power supply (most modules use 0.7W of logic, there is an excel sheet in the help that will guide you)Potential groups. There are BM11 modules with IO power conductors on both side and BM01 modules with power conductors only on the right side. You use these to isolate output cards into groups of IO power with a module that supplies IO power (BR, BT, and PS modules). You can then cut the 24V going to the supply module during E-Stop to ensure the outputs can't energize.Node numbers for optional IO. Don't use a ZF module to reserve a spot, use BM05 or BM15, which allow you to skip node numbers.If you have IO on a powerlink controller and motion, you may want to split the IO racks up, especially if you are using safety. X2X is actually slower than powerlink, so you may have to increase your EPL cycle time because your X2X bus controller can't run that fast. Splitting the offending rack into two bus controllers will let the X2X keep up and let you run EPL faster.If you are using SDC (B&R's way to make steppers and VFDs act like servo motors), you will have to slow down your EPL network to match the SDC cycle on the PLC. You can't have super high speed servo motion and SDC on the same machine unless you are running a really beefy PLC (likely one of their faster APC offerings).Those are the big considerations that are often overlooked by my old sales guys. The usual non-vendor specific stuff applies as well, like making sure you aren't overloading outputs, sinking/sourcing-PNP/NPN, and 10V/20mA. 7) There are some things that can get you if you are upgrading a very old project. It sounds like you are doing a non-motion application since you didn't mention drives. If you have motion, B&R has vastly improved/changed the way you create and run an axis. In addition, older projects may have regional librarie, NCX in the US, PosLibs (I think) in Europe, that do not upgrade well.The way variable linking is stored in their visual components HMI editor (part of Automation Studio) changed a lot between versions. Occasionally, you can run into a situation where it will lose all the linking when upgrading from 2.X to 3.X. I don't know how that happens (opening the HMI before compiling, or the opposite are likely suspects). Always backup first just in case.Install Automation Studio to C:\BrAutomation, not the Program Files folder. Probably best to stay away from Windows 8 as well.

As mentioned, Rockwell doesn't support the 64bit LREAL from the IEC standard and the 32 bit REAL uses 23 bits for the whole number and 9 bits for the exponent (NOTICE: I may be wrong on this, these are the details for B&R and apparently it isn't set in stone in the IEC standard). That means that if you erase the decimal point and the leading/trailing zeros, you number can only go up to 8,388,608. In other words, 0.1234567 you can do and 0.12345678 is beyond the resolution of a REAL. It's the same thing with DINT only being able to do +/- 2,147,483,648. That also means that if you try to add 0.00000001 to 1.0, the answer will be 1.0. I've seen this loss of resolution cause major headaches for people that didn't know such a thing was a problem.

You may be underestimating the cost and overestimating the benefit of formal AB training. I just went through 4 weeks of it on the company's dime; cost including classes, travel, and other expenses aproach $10k USD and that doesn't include a month's pay. Even the advanced classes were geared toward people that couldn't even spell PLC, it was a total waste of money. If you've managed to get an engineering degree and have ever programmed anything in any programming language, you're better off learning the PLCs on your own and saving the money. AB is in a unique position in that industry will buy their products at virtually any price, and there are a million guys out there that know how to program AB PLCs (because it is stupid easy). The market for AB programmers is saturated and VERY expensive to enter. You would have an easier time finding a job working with one of the smaller, more advanced automation platforms (where training is far less expensive or free and way more comprehensive) and avoid the commodity market that is AB programmers until you can pad your resume. I suggest B&R or Beckhoff as both hire and train newly hired engineers and both are expanding rapidly in the western hemisphere.

I'm constantly amazed at the OEMs that no longer have a controls engineer. They had one guy when the company was founded that wrote a decent PLC program and they've had interns and service guys hacking and patching at it ever since. They can't ever change the machine or the controls platform and continue to make exactly the same machine with the same controls for decades until they are put out of business by a more innovative competitor or they can't buy the PLC anymore. Also shocking to me is that a lot of companies don't use proper version control. I mean, it's free to slap a Git repository on BitBucket and track your changes and every non-PLC programmer uses it for everything, but in the PLC world, no body knows the who, when, why, or where to find the last change in the PLC code. And then there's ladder logic... Let's just use a cumbersome system of hieroglyphics that are different from platform to platform as the industry standard. Why? Because it's easy for the shop guys to understand? Maybe if they're illiterate.

Each PLC platform is different and the training almost always is expensive and only available from the company directly or, more rarely, from distributors of that platform. Getting training yourself would be expensive, but you might be able to get your employer to send you to training. In general though, the best thing to do is try to get the data sheet for whatever component is causing your problem. Short of getting into the program, most controls stuff and sensors have LEDs that will give you a good idea of what is going on if you have the data sheet to tell you what they mean when they are blinking in that particular way.

PLCs are expensive. If you're just doing this for school, can you use a Raspberry Pi ($35) or arduino? If you're talking about running a servo and doing a PC based HMI, you're talking about hundreds of dollars for a super low end PLC and Drive and really, it may be more than a thousand dollars. The cheapest thing that comes to mind to me would be either Galil or maybe a B&R drive with an AC140 in it. Automation Direct might have some cheaper setup.

I will say this for Rockwell, lead times are very good (probably their biggest selling point) and their support isn't terrible (not good, but not bad either).