ratcliffe_ic

That code is straight out of the A-B manual for the card. As you say, the 1st BTW sets up the card config, the other handles the transfer of data to it when running.

If the developer included a go to config mode button, you could create a new .mer file with a different name, then send that to the terminal. Select not to run application when it downloads so as not to make it the default application. You can then shutdown your application, load and run the new apllication and give that a test run and check your passwords are ok, you could do this before you make any mods to check that your 3.2 application from v5.0 software will be OK. You can then easily return to your original app. if problems are encountered.

You can import your zinc.pvc file directly into RS View ME, open a new application, give it a name ZINC and then choose the import option, you can then select PV1400e type and browse for your zinc.pvc file. There is some options to set up to do with the new screen size, you may have to have a few goes at this to get it right, I know I did when I converted one a while back. Also if your source application is not particularly good with respect to being aligned to the grid when you are moving to a larger screen e.g. a 1500+ this becomes magnified greatly and takes some remedial work to get it looking OK again. The tags all get imported into ME, your application is on RIO and this is where my experience runs out. You will have to set this up in RSLinx Enterprise within ME, maybe someone else will chip in with some pointers. I've attached a pdf of your tags and rio setup from PB1400e. Good luck. Zinc_info.zip

If you view your user accounts, you will have your 10 users in rsview 3.x accounts. If you click-on set-up on the top menu, you have an option Migrate 3.x user accounts. This will transfer all the accounts into V4 format.

I think you will need for example a Prosoft Modbus TCP card to do this, e.g, an MVI69-MNET as you need to be talking the modbus protocol to send data to the Eurotherm. There may be other interface converters which will acheive this as well.

On for example a production machine with a repeating cycle, it is very easy to have the necessary diagnostics within your program to provide timeouts and give maintenance personnel the necessary prompts via operator interfaces to reduce fault finding time. My application is a back-up generator which is used rarely, and definitely falls into the "failure on demand" scenario. The generator will be run once per week to test so there is an opportunity to pick-up any faults but if something fails between times and the generator is required its no use having two processors when an output has failed. Yes it would be great to write a simulator and fully test code but sometimes when the pressure is on, you know what can happen.

I've just been involved in writing the software for a redundant CLX system, I wasn't involved in the hardware design, anyone setting out on one of these projects must get the A-B technotes and follow the guidelines, these basically consist of ensuring all intelligent cards are flashed at the same firmware level, selecting controlnet addresses correctly to ensure there is always a keeper and positionning of cards in remote racks. While the system has redundant processors and a redundant controlnet network and it all sounds great to the people buying the equipment, I still only have one input looking at a sensor and only one output driving an actuator. In my experience this is where the faults happen that stop a system, I can't remember any occasion where I have had a processor fail (apart from out of the box). So unless you have 2 sets of inputs and outputs and 2 sets of sensors and actuators how can I have improved the situation. One thing which may be of use to those performing online edits on a critical system is the ability to decide what to do with test edits on a switch over. So if you select to cancel edits on a switch over, when you crash the running running program through some bad code, the other processor takes over with the unedited code. Which if you've done that on a live critical system you will know it could be a good thing! So my thoughts are a bit mixed, I can see benefits for me in that I can avoid the risk of crashing a system but the system we have installed does not truely address all the issues which can occur with a control system. The cynic in me says its basically a way of getting more money in.

Anyone got any good suggestions for controlling raise and lower outputs to move a control valve using the PID instruction in an SLC. I have an existing control valve which is opened or closed by relay contacts on a temperature controller, there is no feedback from the valve. The temp controller is now obsolete and I'm exploring the possibility of performing the control in the existing PLC system. I can't really see a way at the moment without some valve feedback to the PLC. I could replace the controller but I have at least 15 of these units over a number of SLC equipped systems which may make it worthwhile developing a solution. Any ideas much appreciated.

This is a standard bit of code downloaded from the A-B knowledgebase, the values that are in the program are how it was set when I packed in for the day. Whilst testing I have had all kinds of numbers in it, including much slower updates as you suggest. When you play with the values the timer value gets adjusted by the maths to give a pulse of longer or shorter duration. This part seems to be working as I would expect, there is another document with it that I now attach which gives a bit more info about the code. I am now wondering if I started off with the proportional gains too high in the 1st instance, I'm going to have another mess about tomorrow morning and see what I get. Thanks for your modified code, all that you say makes sense, I'll check it out and give it a try. Ian SLC500_SRTPO.doc

Well it took a bit longer to get in the machine, but i've spent today trying to get it to work with limited success. The code is from the A-B knowledge base and what I am basically seeing is that the process value is fluctuating around the setpoint by approx +/- 30 degrees and no matter what I do with the PID terms I can't seem to get better than this. I created a trend so I could watch what was happening and one thing I noticed is that the heating output should be turning off much more quickly as it approaches the setpoint. The control valve obviously takes time to open and close, I was just wondering how this can be taken into account if you have a slow or fast operating valve. Also in the PID setup screen the feed forward bias is greyed out, is this not available? I've attached my code, any pointers from some PID gurus much appreciated. TEMP_TEST_PROG.RSS

One thing to do is if you have rungs with [GET][=] instructions in, i.e 400.....200.....................................010 [GET]-[=]-------------------------------( ) ............0........................................00 400.....201.....................................010 [GET]-[=]-------------------------------( ) ............1........................................01 This is the equivalent of an EQU instruction in later processors, and is checking the value in store 400 with store 200 (decimal 0) and if the same it enables the output. Once you [GET] 400 though you do not need to GET it again in the next rung, so it can look like this: 400.....200.....................................010 [GET]-[=]-------------------------------( ) ............0........................................00 .201..............................................010 [=]--------------------------------------( ) ....1...............................................01 I once saved a whole load of memory this way in a PLC2.

Let's say you have a bitmap called "nin_cals.bmp" just use this name in the bat file. Then you need to put both files onto your memory stick (nin_cals.bmp and autorun.bat). When you insert your memory stick the terminal changes to the windows CE environment and replaces the existing image with nin_cals.bmp. The document I attached explains how to revert to the original AB bitmap near the end of the document.

See the attached technote for the information. PV__screen_saver.doc

System CLX L61 with flashcard slot. I need to write some data (2 words - engine hours) to a flash card to ensure the data is conserved in the event of a processor problem (e.g. battery goes dead). I know there is an example of read / write to a flash card available from A-B and I've got a copy of it. What I can't believe is how big the program is for it. Has anyone had a go at this and come up with something simple, I've had a quick trawl through the code and there seems to be a MSG instruction involved but also a lot of error checking (which I know is important). As usual time is running out on the project and this is a last minute request with no time to do any testing/development. Any suggestions / help much appreciated, thanks.

Great bit of code, thanks I've got it on my test rig and looks to be doing the business, I'll have it on a machine by Friday and we'll see what happens.

The other day when I saw this I thought I can do that, get out the old laptop, couple of minutes all done. Old laptop was dead...... 2nd backup very old laptop also dead......oh christ how will I support those old systems Anyway out of dispair I've managed to create myself a virtual pc using an image of the hard drive which is how I've created your .txt, I'm now just wondering how far I can go with this and whether I need to get another old laptop off ebay to sit in the cupboard and then find it has died when I need it! 903205.TXT

The ICOM PLC2 software has a facility to do something with 1774 PLC programs, I can't remember what exactly, it's 10 years since I last used it. Under F5 utilities you can monitor a PLC/PLC2 over DH. You can also upload from a tapedeck or cartridge to the software. I've a feeling we used to save the program to a tapedeck, then upload the tapedeck to the computer, then merge with comments and produce a printout for the maintenance guys. The ICOM software is not cheap though.

Spoke with tech support and its not a problem that I am set to UDP, I can set to TCP if I need to but need to do more set-up in GX developer on the QJE71 module for this to work. I've got enough to get working, so I'll leave as is and might have another look if I've got time.

I was setting up a Q series system yesterday, Q02 processor, QJE71 ethernet card and E1101 and I struggled a bit with the HMI until I read the help file in E designer which said set to UDP. I did this and its all up and communicating nicely. But I'm just wondering why it would not work with TCP selected, can anyone explain?

I have worked on many systems which have come from this French company and generally they do seem to overcomplicate the ways in which they acheive things. Having said that the solutions generally work well and it will be a matter of sitting down and fully understanding what is going on with the parameter files. The first thing to do will be to track down how the parameter file is loaded, this will be when a go to screen button is pressed, look for say a recipe screen then track back to the button that is pressed to go to that screen then have a look at the buttons properties. This will display in the GENERAL tab the parameter file that is used with the target screen. Have you checked if there is a "standard" available for the PV+ that you can get a copy of. Good luck

If you wish to use bit 3 of a word you have set up, use the following syntax in the connections tab for the Tag / expression: {WORD123} & 8 for bit 0 it would be & 1, bit 1 it would be & 2 and so on (binary style)

I'm looking at an upgrade project where I have 11 existing machines controlled by SLC5/04 processors and a new supply system which feeds these machines which will be CLX based. Hard-wired I/O signals between the the SLC and the CLX would give me all the required dialogue to control everything, but this will result in lots of I/O in the CLX and lots of multi-cores to run in (long runs as well) So I'm looking for something smarter.... So far I've thought of a 1746-DCM module in each SLC, which will allow me to look at the I/O in the rack it is placed in, I can then use a DH+/RIO scanner in the CLX and I've got the info I require. or Some Flex I/O in each SLC machine wired to the required signals and again on RIO to the CLX. Has anyone else any bright ideas?

I didn't know the 1747-SCNR existed, it looks just the job. My SLC machines have 3 off 7 slot racks, can it reside in a spare slot in rack 3? The examples in the user manual only have it placed in the same rack as the SLC. Is there a knowledgebase example of setting a 1747-SCNR and a 1756-CNB?

It is for hardwired signals for interlocking of sequences, some of the signals would be for items that could collide with the CLX systems hardware, therefore I would not be happy with a MSG instruction providing that information. The DH+ network is already utilised for a SCADA system.

I've found the email info from my CLX losing program problem: "I've spoken to rockwell tecnical support who have told me the following: The major fault is something processor related and not caused by software problem (e.g. indirect address looking at data table that is not created etc) They have recommended upgrading the firmware to version 16.20 (latest version) I will send you the file tomorrow. (you are on 16.07) Unfortunately this seems to be the Rockwell stock answer, have you got latest software / fimware? If you answer no, they recommend updating straight away. Looking at the manual, when a major fault code 60 occurs you should examine the status of the OK and RS232 LED's and make a note, this info will assist in diagnosing the problem with tech support." As I said earlier this has not occurred again after the upgrade which is now 5 months ago.