Colin Carpenter

I remember having having similar fun setting up a FX2N CCLink master to talk to a FX0N CC link slave and then onto a Q2AS CC Link card. Seemed to take forever. It was written in MEDOC, so I've printed the code to text files, the relevant bits of which are now attached. One thing I did remember when I dug them out again was that I needed a programme to cause writing to the EEprom of the master CC Link module. I downloaded this into the FX2N, then turned on a bit (M100 I think) to cause the parameters to be stored. Best of luck, I know it wasn't that easy .... CC_Link_Data_Chart.pdf MASTER.TXT CCMREAD.Txt SLAVFXON.txt CCMDEBUG.txt

Wondering if I could ask the AB experts on the forum for some advice regarding a job that I'm currently looking at? I'm currently evaluating a job that involves reading in about 6 analogue inputs, doing some fairly intensive floating point calculations and equation solving to arrive at some set points that 4 or 5 PID loops need to work to. The existing plant is fairly complicated and is being run by an SLC505 which was programmed by others and runs pretty much 24/7, with occasional stoppages for maintenance. Although I'm fairly confident with the equations, parameters and constants that my programme has to perform, there will inevitably be a learning process prior to commissioning and numerous tweaks that will have to be made before the job is signed off.To avoid the fear factor of having to continuously go online to make changes on the main plant SLC (someone else's programme), I'd like to install a small "black box" PLC that can either read in the analogues through its own analogue inputs, or that could receive the analogues by network comms from the main SLC if the SLC has the IO capacity available. This enables me to play with the software to my hearts content without fear of messing up the running process. The calculated setpoints would be transferred back to the main SLC by the same network comms, so effectively the "black box" PLC would just do all the number crunching and none of the process control. Coming from the Mitsubishi world, I'd choose an FX3U - small, fast, economical, large memory, but this will almost certainly create data transfer and comms issues, so please could you advise me if there's an AB equivalent that would be a good fit for this particular application. Thanks, Colin

Thanks for the advice, and I really like the look of that Micrologix 1400, which seems to fit the bill perfectly. I also like to simulate the process as much as possible, but the SLC in question is 200 miles away and it would things a lot better for me to have a PLC in my office to initially write the programme and simulate the process control in a calm collected environment. I'm old enough to have developed a healthy fear of strange things happening whenever I go on line to make changes. I once managed to delete the ethernet comms rung from a system running three SLCs communicating via ethernet .... it wasn't really my fault ... somebody had deleted the line previousy and left it as a "pending edit". A few weeks ago I managed to make a Mitsubishi Q series completely go into fault mode purely by the action of attempting to go into online change mode. Only a key reset would cure it, which meant that the plant (which was on full production at the time) had to be stopped, manually emptied, cleaned and re-started again. I suspect the comm port ethernet re-direction software I was using, but it's worked fine before and since (after a PC reboot). I just put it down to quantum fluctuations .... but they do happen, and normally at the worst times

So where you have D51 and D52 connected just by a line, what does that translate to in the programme? I would assume that it means move the value of D51 into D52, but don't have a way to test it at the moment. Interesting .....

Does rung 2 of your code compile OK? There are a few things in rung 2 that made me think "I didn't know you could do that" ...

"an unusable com port has been selected!". Have you checked to make sure that no other software is grabbing the com port first without your knowledge and approval? That phrase will be used when something else has grabbed the serial port and won't let the Mitsubishi software access it. If you have Allen Bradley's RS Linx on your PC, then there's a very high chance that it's loading itself at startup and grabbing every port on the PC for it's own use .... after all, why would anyone want to use anything other than AB's software I had to load up various Allen Bradley software packages for a customer a while ago, and it got so bad at grabbing everything, that I decided to do it all using Microsoft Virtual PC 2007 (which is now free and works in XP) to set up a virtual system where all the AB products are installed. This means that my laptop's host operating system stays lean and mean for the Mitsubishi software and RS Linx only operates in it's own virtual drive. It causes lots of problems that software ........ bit naughty really.

Not strictly a PLC problem, but related. I have an FX2N that is CC Linked to a Q2AS which is then linked to a SCADA system. All works well. In the FX2N, the operator has the ability to set up around 80 operations, and can set numerous operations going at the same time, depending on the interlocks in the programme. I'd like the SCADA system to store the operations that are happening at any one time, so I've used the MOV K4M700 D100 command to move the status of 16 bits starting at M700 into the 16 bit data register D100 which is then accessed by the SCADA system as a decimal number. There are 5 of these data registers used, so the status of the 80 bits will be carried to the SCADA system as 5 decimal numbers. The SCADA system has no ability to convert the decimal number back into binary and then access the individual bits, so I'm looking for a long hand way of being able to convert the 5 numbers back into binary and show what operations where happening at any time. A spreadsheet is the obvious answer ..... just type in the 5 numbers and it will show you what bits were on at any one time, and I thought I'd cracked it when I found the DEC2BIN function in Excel, but it only appears to work for binary numbers with 10 digits, which leaves me about 6 short of what I need. So the question is, does anyone know a neat way of converting a decimal number into a 16 bit binary number in Excel? Thanks, Colin

That works a treat ... many thanks, I'd never have thought of dividing by 256 and then working with the remainder, it seems far too easy, but it works well. Panic Mode - The SCADA system is called Prodigy and works very well. I've checked and there's no way of stripping out binary bits from a decimal number that they know of at the the moment. I could read each bit as individual tag, but it would use 20% of the site's "bought" tags. This way, it's 5 tags used instead of 80, which they're much happier with. Thanks

For what it's worth, this is what I've learnt this week. I had to tune a system that used a high spec pneumatic control valve to close againts a water flow generated by a centrifugal pump. The flow rate was monitored by a water meter giving a 4-20 ma output. This was the Process Variable. The Set Point was an operator specified flow rate. The valve took 10 secs to fully close (from 100% open), when working against the water flow pressure. The same valve took 5 secs to fully open (from fully closed) when working with the water flow pressure. Disabled the Derivative Constant and tried to set up the Proportional and Integral values from guesswork ..... no joy ..... just a wildly unstable system. Read the manual and tried the Autotune function ..... no joy, in fact I have't a clue how that's supposed to work, as it seems to hold the MV value constant. Anyone know? Spoke to a Guru, who said ... a) Set Proportion Constant to 100% b) Set Integral Value to 60% - 80% of the system response time (in other words how long it takes the valve to move from fully open to fully closed and vice versa) c) Disable the Derivative Constant. The Integral Value was then set to 6 secs (60 x 100 ms) and immediately the system got better. 100% on the Proportional was too much and resulted in much bigger changes than I needed .... ended up at 10% which gave me a slow, steady landing on the setpoint. Calibrated the flow rates against valve position bits, and use that value as the manual PID mv. After a few seconds, witch to auto and PID works like a charm. Fow what it's worth ......

Please can anyone point me to a document that explains in detail the methods that can be used and the way they work regarding going online with a Logix 5000 controller. I'm doing a job at the moment which involves modifying the code of an existing Logix5000 programme, written by someone else. I'm modifying the code offline, and am quite happy with the ladder logic modifications etc. The problem I have is actually getting the code into the controller, and not being entirely familiar with the way things work in online mode, especially relating to data tables etc. The .ACD file that I've created offline obviously holds the data tables from the last time the programme was saved, which was several weeks ago. Obviously things will have changed on the plant (set points, statuses etc) , so I don't want to download historic data tables into the controller. Although I doubt it, it is possible that the controller may have had it's code changed since the time I was given the saved .ACD file, so there may be a later version of the .ACD .... I doubt it, but there might be. Due to the "interwoven" design of the site controllers, the customer is keen not to stop the PLCs, and would prefer it to all be done online, including setting up produced and consumed tags and remote ethernet IO etc. It would be nice to be able to bench test all this, but the cost of two controllers, two ethernet cards and racks is prohibitive to say the least. Coming from the MItsubishi world, I know exactly what I'd do. Firstly, verify that the programme in the CPU matches exactly the version that I believe is in there. If not, find out what changes have been done by others and incorporate them in the new software. Negotiate a 5 minute shutdown fo the PLC, download the software, parameters and tags and then start the PLC again, knowing that the data tables are never uploaded or downloaded so that won't be an issue. If the customer absolutely refuses a 5 minute shutdown, then I'd do all the mods offline, then select the "Online Programme Change" option which would enable large chunks of code to be shuffled around in the CPU while still running the programme. It's fairly simplistic, but it works and lets me know exactly what's going on. Is there a way to be this simplistic with the Logix5000 controllers? Thanks.

There's more ..... The more I thought about this, the more awkward it seems. After all, all I want to do is download the programme from my laptop so that only the parameters and programme are changed in the controller, while the controller maintains the data that it currently has in it's data files. Another option would be that the software would give me the option to upload the current data files in the controller to my laptop, then when I download the programme I know that the data files being sent would be the values that were only a couple of minutes old. Another option would be that it just plainly gives me the choice of doing nothing with the data files, and only operates with the code and parameters. And it turns out (I think) that you can actually do that now, with a tool called DATA PRESERVE which is available as a download from Rockwell at the following URL http://www.software.rockwell.com/support/d...ail.cfm?ID=3709 This installs an extra tool in the TOOLS menu of Logix5000, called RSLogix 5000 Data Preserved Tool. I can't try it out yet, as I'm not online, but the text file that accompanies it reads the following. (It's dated September 2008, so is fairly recent) It looks good to me Readme for RSLogix5000 Data Preserved Download Tool version 1.2 - September 4, 2008 The RSLogix5000DataPreservedDownloadTool.exe application is a utility that runs in an integrated mode, launched from within RSLogix5000. There must be a project (ACD) file open within RSLogix5000 before launching the tool. The project file must contain a valid CIP path to the controller, and the controller type in the project file must match the type of the controller. The tool performs the following tasks: 1. Checks the tags defined in the open ACD file, and reads all corresponding tags currently in the controller that is pointed to in the open ACD file. All tags, including controller scope and program scope are read, except tags with one of the excluded types. The following tag types are excluded: MOTION_GROUP,COORDINATE_SYSTEM, AXIS_CONSUMED, AXIS_GENERIC, AXIS_GENERIC_DRIVE AXIS_SERVO, AXIS_SERVO_DRIVE, AXIS_VIRTUAL, ALARM_ANALOG, ALARM_DIGITAL, MESSAGE 2. Saves the tag structure and values from the controller in a text file (Taginfo.csv) in the current RSLogix5000 Data Preserved Download Tool directory 3. Downloads the open ACD file to the controller 4. Writes saved tag values from the Taginfo.csv text file into the corresponding tags in the controller If there is no tag in the controller corresponding to a tag in the open ACD file when reading tags then that entry in Taginfo.csv is skipped / left blank. Tags with excluded types are not written into the csv file at all. If there is no entry, or a blank in Taginfo.csv for a tag in the controller after the new ACD file is downloaded, then the tag write is skipped and the value loaded with the ACD file will remain in the tag. The tool can be operated in one of two operating modes: 1. Download with Data Preservation with Prompt - you are prompted to do the download with or without data preservation. Download without data preservation is the same as doing an ACD file download from within RSLogix5000. 2. Download with Data Preservation without Prompt - the download with data preservation will be done automatically. By default the tool is installed in mode 1 (prompting is enabled). After the tool has been run menu options become enabled in the tool window. The edit\configuration menu allows the operating mode to be toggled for subsequent runs. Note for Softlogix users: Softlogix users can not use the Virtual Backplane driver of RSLinx to download to Softlogix Controllers. You must configure a standard network driver in RSLinx other then the virtual backplane to talk to your Softlogix controller in RSLogix 5000 and save this path in your project in order for the tool to properly connect Limitations: Bridging/multi-hops are not supported This product uses the log4net library which is licensed under the Apache Version 2 license (http://www.apache.org/licenses/LICENSE-2.0).

That's right .... here's the screenshot. From memory, the manuals have always seemed a bit vague about the positioning of the RET command. Probably better to just enter in the instruction editor and see where it gets put in the ladder editor?

Thanks for all the advice. It seems that there's a general "sense of the unknown" regarding what can and can't be done "online". The site is being very good about this, and we've agreed a brief shut down period for the two PLCs this weekend, and we've also agreed that the original guy who wrote all the code (who has since left the company) can be in attendance briefly during the initial upload of the code, as he will have far more knowledge of the things that are happening in the background than I will. The laptop used will be the site's own laptop which I know is running the same version of Logix5000 as mine, so that should be OK. Regarding testing of the Logix5000, I actually have access to an old, redundant 1756- L1/A Control Logix CPU and rack, but the later versions of Logix5000 don't seem to acknowledge that that CPU exists, and at around £3,000 for a modern CPU and rack, there's no chance of getting one of those just to sit on the bench. I believe that there's an emulator package that can be run on a PC, but whether or not it would truly emulate the online / offline behaviour of a controller I have no idea ..... but the pessimist in me doubts that it would.

Thanks for the advice, it's really appreciated. I found the comparison tool on the DVD and installed that and it really is useful, as it shows the differences between the two versions. I know I should know the answer to this, but with Logix5000, what actually happens when you attempt to go online with a programme that has been modified relative to the running code in the CPU and which contains different data tables to those in the CPU? Is there an option to do anything (eg upload the data tables from the CPU), or does the software just notice that everything's different and refuse to do anything. Thanks.

This screenshot from dear old DOS Medoc might give you a clue .... not sure how GX Developer handles the RET command, but MEDOC shows the ladder as this when it's entered as instruction code.

Hi Bob, Will try and answer as clearly as possible. 1. You are modifying an existing production system which contains multiple Logix 5000 Controllers. That's right. There are two in particular, both 1756 L55 controllers, each fitted with a 1756-ENBT/A ethernet card. 2. You are adding new ethernet I/O to one of the processors. Not physically, but in the course of adding consumed tags to a controller, I have to add the remote 1756-ENBT, the rack info and remote controller into the IO configuration of the local 1756-ENBT so that the consumed tags can be pointed at the contoller that they will be consuming data from (if you see what I mean) 3. You are adding produced and consumed tags to multiple processors to share data from the new I/O Units. Not really, the consumed and produced tags are being installed on these two controllers only, so that they can share data between themselves. This will form the basis of an ongoing project to update the comms around the site and use ethernet more and more, thus taking data transfer away from the severely overloaded and very slow DH+ network. 4. You are adding new control code to one of the processors to service the new ethernet I/O you added. Kind of. A small amount of code will be written to enable the use of the data that arrrives via the produced / consumed tags. 5. You have an offline copy of what you want the program to look like when done. That's right. 6. The customer cannot tolerate any shutdown of the process. He might have to, but would strongly prefer not to. 7. You do not want to overwrite any exisitng data files in the processors. That's right. The existing data files in the controllers need to remain as they are and not be overwritten with the aged values that are currently in the offline version that I'm working on. 8. Mitsi not AB is your native platform so you're in a learn curve mode to boot. That sums it up pretty well. I've done a few SLC 500 and one Control Logix projects, but in all cases they were "new build, stand alone" projects. There's also numerous ladder routine rung modifications which have been done in the offline file and would be very tedious to do on a rung by rung online basis. Thanks

Thanks for that, Ken, that's a great help. I wonder if you might know whether or not it's possible to set up a "produced and consumed tags" system on two Logix controllers with the ethernet cards already installed and configured whilst in "online mode". I've done online ladder changes before, but this would mean adding tags and adding the remote ethernet card, chassis and controller (in the IO section on the left hand side), all while the two controllers are running. Thanks, Colin

Hi, Back to programming Control Logix after a few years lay off. Wonder if someone could confirm that what I'm trying to do is OK. Two Control Logix Controller (both 1756-L55 v15.02), each fitted with a 1756-ENBT Ethernet Card I propose to set up 100 Produced and 100 Consumed tags in each controller and use them for ethernet comms between the controllers. The remote controller will received some INT words via DH+ that I need to copy onto the Produced tags (which are DINT tags by definition) Once the tags have transferred across the ethernet, I need to copy the DINT words back onto INT words. In summary, using the MOV command, the process will be INT->DINT->ethernet->DINT->INT The question is, will the bits of the last INT be the same as (and in the same order as) the bits of the original INT. I'm pretty sure it will be fine, but I can't test it until I get to site, and things can get a bit fractious then. Thanks

After a bit more research, I found that the bit in the manual about data conversion, and it appears that as long as you steer clear of signed integers (SINT), then the lower 16 bits of a DINT will convert faithfully to the 16 bits of an INT, so that all appears to be OK. Thanks.

>>On the Consuming end, use the CPS instruction also to copy the DINT array into an INT array.<< I checked out the CPS command in the programming instruction manual, and it states: Important: the Source and Destination operands should be the same data type, or unexpected results may occur. And this is the bit that still worries me a little. Coming from the Mitsubishi world (shock, horror ), their software is very specific on not mixing INT and DINT values in functions. For example their MOV command for INTs becomes DMOV for DINTs, and putting both an INT and a DINT value into a function block will result in an error when the programme compiles. To overcome this, they have two functions that help, named DINT to INT and the reverse INT to DINT. I imagine that these functions take the bottom 16 bits of each value and transfer them exactly. It means that a large DINT decimal number cannot be transferred to an INT, but that is something that you learn to make sure will never happen. The Allen Bradley software seems to allow mixing of DINT and INT variables in the same function, but warns that unexpected results may occur, which makes sense if a DINT has a larger decimal number that cannot be stored in a 16 bit INT. If that truncating of the number is the "unexpected result" that they warn about, then I can happily live with that, but I would be happier being able to find a DINT to INT instruction that I know will remove all doubt about the integrity of the operation. Am reading the manual now and may find the answer, but if anyone has come across this, I would be grateful for a pointer. Thanks, Colin PS. Thinking about it a bit more, as the original word is a 16 bit INT word, presumably only the lower 16 bits of the DINT produced and consumed tangs would ever be use, so when it then pops back out as an INT there shouldn't be a problem .... it's just the uncertainty that worries me a little, and I can't test it until getting to site when time is very limited.

In the analogue input card are things called buffer memories. The buffer memories store information such as the set up data for the various channels, the current values of the channels etc. The CPU communicates with these buffer memories to extract the information that you need, eg the value of the analogue inputs. The TO command writes information from the programme to the buffer memories and the FROM command reads information from the buffer memories into the programme. Sometimes you will see the TOP command which is the same as a TO command, but the P indicates that it is a "pulsed" TO command, meaning that it only happens for one cycle scan when the rung conditions are true. I haven't used the Q series CPUs yet, so it may be different, but I posted an example of a QnA analogue input card in the thread below, which is pretty self explanatory http://forums.mrplc.com/index.php?showtopic=7677 The key thing is that the CPU needs to know what address to read the data from, and this is determined by the BASE Address of the analogue input card and the buffer memory of the analogue input card. Note that the Base Address of a card is the first two digits of the Hex address. Therefore a card with the Hex address 160 is entered as 16 on the FROM and TO commands. The example posted is from IEC Developer, but the same rules apply with GX Developer

Thanks Ken, the CPS instruction is the thing that I wasn't sure of, and I'll look it up and use it. Incidentally, this job of full of co-incidences. CPS is also the initials of the company I'm working for on this, and the plant is controlling a CIP set (stands for "clean in place" in dairy terminology), and to cap it all, CRC are my initials. Spooky

As Goody says, the S elements are known as State Elements and are used in the FX series of PLCs for Stepladder Programming (STL). If you're not using one of the FX series, then I would strongly advise not using them as you may well find that you're getting weird errors .... stick to M elements. If you are using one of the FX series PLCs and you've read up on what Stepladder programming is and you really want to use Stepladder programming, then fine, else stick to M elements. The RET command that you talk about is the command that you would use at the end of a Stepladder routine to tell the PLC to return to normal programme operation. Stepladder is very useful for sequential events that rely on something happening before moving on to the next step. I often wish you could use it in the larger breed of PLCs, but you can't.

I'd never heard of the method for putting an E in front of the instruction, so looked it up and it seems that it can be used on the Q range of PLCs only (including the QnA series). I've used floating point numbers on FX2Ns, but have used a different method - see attached graphic. The theory is that I tend to keep the variables in integer or double integer form for use elsewhere in the programme and on the HMI, but need to do accurate floating point calculations to work out what those variables are. I also tend to use a lot of multiplication and division by factors of 10 to get the accuracy that I need in the engineering value. For example, if calculating a fat % on the product, then 2 dp is required (eg 48.19) as this is the accuracy that the customer can measure to, so the integer variable in the PLC will always be 100 times larger than the actual value (eg 4819). This scaling means that it's very easy to produce numbers greater than decimal 32,767 (the max for integer numbers), so I tend to always use double integers unless I'm sure that it's not possible for the number to exceed 32,767. I think the attached graphic shows one of the major plus points of IEC Developer when compared to GX Developer. In the equation shown, only the input variables and the output variables need to be defined in Global Variables, and all the variables that would normally be needed to store the results of the individual function blocks of the equation are automatically created as system variables when the code is compiled. IEC is very good at letting you easily programme this type of complex equation.

I don't think it's a case of Medoc supporting transparent mode. From Medoc's point of view, it will send serial data to the PC's designated com port and will expect to see data coming back that fits with what it's expecting to see. The Mitsubishi programming lead contains an RS232/RS422 converter which enables comms to be established with the RS422 CPU port. In transparent mode, the Mac terminal does the same thing,.... it has an RS232 port connected to the PC and an RS422 port connected to the CPU port, so it's effectively emulating a programming lead. The clever part is that it can do it while still running as a terminal, meaning that operators can carry on using it while you monitor / do online changes etc. For almost every job now I use IEC Developer, but still have a lot of old PLCs running Dos Medoc software. I love IEC, but still prefer Dos Medoc to GX Developer. I've heard that the later versions of GX Developer are much better than the early version that I tried, so I'm probably out of touch on that one, but I can't imagine using GX in preference to IEC, so I stick with the tried and trusted Dos Medoc on the old stuff. There's something very comforting about Dos software that just works .... and I just love the screen colours .... and the nostalgia