andybr

In SE VBA can only run on a client and not on a server and is attached to a specific display object. We handle this by running a "hidden" display behind the main background on one of our clients. Each VBA sub is triggered by an object on this display. For instance the object could be a numerical display with the VBA triggered on any change or an expression can be entered causing the VBA to be triggered at a specific time interval. It is clunky but it works OK and is reliable. We did this to accommodate quite a lot of old VBA code when we migrated from RSView32 to Factory Talk View SE.

I am not in the USA and not governed by NEC requirements but I do not like to see anything including (and especially) drawings/manuals stored in panels. This is because most of the major modes of failure that occur in panels are quite capable of destroying the items stored inside them which you might well need to repair the damage. In my experience these modes of failure tend to be:- i) Water ingress - self explanatory. ii) Arcing which can coat stored parts in carbon and sputtered copper. iii) Fire, again self explanatory. My point is that it may or may not be against code but you should think about the wisdom of doing it anyway.

One other consideration would be that in some circumstances it is desirable/necessary to open both valves at the same time. This will have the effect of locking the cylinder in more or less its current position. This is sometimes safer than dumping the air in the event of a problem.

Unfortunately our security software does not like GX Developer projects so I cannot attach an example in that format but I have copied the relevant code from an old Medoc print file and this might help if you read it in conjunction with the manual.   Mits_A_DeviceNet_Code.docx

I have not used a DeviceNet module with a Q Series PLC but for an A Series system you could set up the module entirely within the PLC code so there was no need for EDS files etc. The Mitsubishi DeviceNet modules were made by Hilscher and their configuration software was subject to an annual licence renewal so using the PLC programme was a common way to set these modules up. It was a bit lengthy but straightforward enough and I still have systems working with it after 15+ years which have never been any trouble. The required code was detailed in the DeviceNet module manual.

If you are using the standard ascii instructions you can just set an appended character on the user protocol tab of the controller properties dialogue. '$r' is the entry for carriage return. This is very common when setting up comm's with simple devices.

An X Ray system is normally used to detect high density foreign bodies in low density materials like foodstuffs. If your mirror is made from glass then its density will be much higher than that of the rubber so I doubt that you will be able to reliably detect the rubber part. Okie's suggestion is good though and a supplier of this type of machinery should be able to give you a quick answer as to the suitability for your application. You should also understand, however, that these machines are not like a normal camera and will include substantial shielding to protect the operators. It is also necessary in the UK to have a suitably trained and certified person on site to be responsible for radiology equipment so using this type of system is not something to take lightly.

Endress and Hauser have recently been pushing a hybrid Guided Radar/Capacitive solution for interface measurement but I think this is aimed primarily at oil/water interfaces. Still it may be worth talking to them. One thing to be wary of, however, is that you are not really looking at a solid in water. In your case you are trying to measure the level of salt in saturated brine which may not work well with many instruments. The actual interface may also be difficult to pin down as the salinity will probably cause stratification in the liquid above the salt.

Microcomputer programmes for Mitsubishi A Series PLC's were sub programmes written in 8086 Assembler and were generally used for calculations/tasks which were not possible using the PLC instruction set (these plc's did not support floating point maths, PID and many other functions which are now commonplace). These programmes were created using something like the DOS Debug command and called from the ladder programme using the SUB instruction. The constant in the SUB instruction is the allocated memory address for the start of the Assembled programme and the preceding MOV instruction loads the required data. The data in your application looks as if it contains ASCII which could be used to construct a message for transmission via the AD71 card. Unfortunately I do not know of any way to convert the compiled programmes in the PLC back into assembler. I would suggest that you look at the actual machine/system and try to work out what is missing from the ladder logic so you can recreate it in your new system.

Carplet. Special functions for the F Series included all arithmetic instructions, high speed counter instructions and data movement instructions. They were entered by turning on a series of "coils" for addresses F670 upwards each of which had a constant attached to determine its precise use. This system would seem bizarre nowadays but was quite powerful at the time. The Fx series had a "proper" instruction set so there was no trace of the old system left. I am not sure what Medoc would do if asked to convert the old instructions into FX instructions and unfortunately I have no way of trying to find out at the moment

Crossbow. You just prompted me to ask whether it is possible to convert an F1/F2 programme to FX if it contains any special function instructions. I have never tried this but it doesn't seem likely.

I am not sure about this since I have not seen the F2-232GF before but it looks like this is for a direct RS232 connection to the PC and you therefore do not need the SC02N (which is a 232-422 converter). If you use the cable pinout in the manual you posted and make sure that Medoc is configured correctly the system should work though you may need to change the Medoc settings if you are not using the SC02N.

Ken. I can only speak for their UK operation but I have always found IDC to be good for this type of training. It goes without saying that the student must have the required basic skills to start the course. In my experience trying to train people without the basic mathematical skills in PID is a waste of time. This course seems to be available in the US. http://www.idc-online.com/training_courses/instrumentation/?code=PL%20%20%20%20&country=United+Kingdom

Have you considered using a MicroLogix (1400?) at each remote site rather than the Flex. This needs less connections and allows you to have "Local" control in the event of comms failures.

The .tge files are tag groups which are edited using the Tag Group Editor (logically). This can be opened from the "Apps" menu in Draw.

GX Developer up to V7 (at least) did not support the Melsecnet B network properly. This might have been fixed for later versions but I do not know if this is the case. Our solution to this problem has been to keep a copy of the programme in Medoc format and use Medoc if we need to edit the Network parameters. GX Developer can still be used for the actual PLC programme. If you have downloaded the Network Parameters using GX Developer then these parameters will be corrupted but you should be able to upload them into Medoc, correct them and then load the corrected parameters into the PLC. Andybr

Steve. If you have the L5K Function Block option then the Totalizer instruction will perform much better. Your proposed method will not take any account of flow variation between the individual samples and there always seem to be timing issues with "roll your own" systems which do not happen with the dedicated instruction.

D Registers set to latch as suggested above can still be cleared using the key on the front of the processor. If you want to prevent this then you should use file registers which are designated as Rxxx. You will need to set these up in the PLC parameters before you can use them but this is simply a matter of entering the number of R registers you wish to have.

Peter. Without getting too involved in the detail I would say that your system works in a similar way to software packages such as Expertune and these packages generally work well. My take on the OP's question was that he is looking for the kind of thing built into many single loop controllers and I have never found one of these which works on the type of loop used as an example in your paper. The main issue with these controllers is that they cannot /will not wait for 40 minutes while a step returns to steady state. The amount of data which would need to be stored would probably preclude this for most controllers. Since your example is typical of the process heating loops I am familiar with this renders most built in autotune systems unusable. Oddly enough I have always assumed, probably incorrectly, that autotune would be easier for motion where responses are much faster and easier to identify.

Andy. As you are in the UK I would suggest you speak to Lambda who are based in Ilfracombe. I am sure that they will be able to do something off the shelf which meets your requirements.

PID Control was possible with an A1s PLC but it was not easy. In fact by modern standards it would be considered ridiculously difficult. The An and Ans processors did not have a PID instruction which could be used within a ladder or instruction list programme. PID control could only be performed using what Mitsubishi called a Microcomputer programme. This had to be written in 8086 assembler, using Debug in DOS or something similar, and called as a subroutine from the main PLC programme. I have looked for an example or some documentation but I am afraid I no longer have anything. Mitsubishi used to sell Micro's for specific applications and I believe that one of these was for PID but I do not know whether you would be able to get hold of a copy now. If you could get it I suspect you will need an older software package than GX developer to download it to the PLC. In any case I would not recommend following this path. Using Micro's was never easy and I doubt that you will be able to find much help with it nowadays.

If the power line is only 70cm away I assume that it is an insulated cable (or group of single cables) and it is either contained within a duct or buried. In terms of interference with the PLC high voltage cables are generally less of a problem than low voltage because the currents are so much smaller and the cables are screened as a matter of course (for safety rather than EMC reasons). It is not unusual to have PLC's mounted within HV switchboards (or MV in US terminology) where they are mounted much closer than 70cm to enclosed busbars. The level of electromagnetic interference is a factor of current rather than voltage.

Since 1 atmosphere is 34 feet of water the difference between your two readings is less than 0.5% of full scale if the transmitter reads vacuum only or less if it reads positive pressures as well. This seems a pretty good level of accuracy to me. I would try swapping the transmitters over to see if the difference moves with the instruments.

The latest product notifications form Rockwell contain a link to a Knowledgebase article (Answer ID 33121) which deals with this error. http://rockwellautomation.custhelp.com/cgi...ated=1127966400 This might help. Andybr

panic mode. I work for a large multinational company. Standardisation is not up for discussion, we just have to live with it. Software changes can be surprisingly involved when going from A to Q if there is extensive use of special devices. The real issue, however, is that large volumes of data (thousands of points per machine) need to be manually re-entered into file registers which are handled differently in the Q processors we have (Q3A). Since the installed software is poorly documented and written by a long since defunct OEM there are benefits to be had by re-writing from scratch.