Colin Carpenter

Thanks, that's a good point. I'll have a check in the Scada settings and see if I can improve things by slowing it down. Thanks

Which part of the system is causing those error messages do you think? I'm starting to think that it's not the HMIs as the other PLC doesn't show so many, so presumably it must be the Scada system. This was upgraded recently and runs on a "virtual PC" on the main site server rather than on the standalone PC that it ran on for many years. My knowledge of servers and management networks could be written on a postage stamp with a paint brush ..... 🙂

Thanks for the reply, but what I don't understand is that all the errors seem to relate to completely undefined port numbers and I have no idea what an IP address of 0.0.0.0 actually means. What sort of ethernet command would attempt to send nothing to "nowhere in particular" from "nowhere in particular". The scan time on that PLC will be high .... probably in the region of 80 ms or thereabouts, but the problem with replacing is that it's tied into 4 other PLCs that all use Melsecnet B to communicate and effectively run the processing plant. We always install Q plcs now on any new plant, and these use the Melsecnet 10 coaxial connections, but we still have to have one Q2AS which can talk to both Melsecnet systems and translate from one to the other and back again. The "twisted pair" Melsecnet B is ultra reliable, but a real headache when upgrading the PLC.

I wonder if anyone can help with this problem. The PLC is an old Q2AS-S1 with an ethernet module in the rack and this PLC is communicating with three Beijers screens - two E1100s and one of the newer X2 screens plus a SCADA sytem. 8 UDP ports are set up in the code using Beijers function blocks. The screens do have a lot of alarms and data points to display - perhaps 100 or so screens and 200 alarms. The communication all works, but the screens are slow to update - perhaps 8 seconds or so for a screen to load and display values. It's possible that it's "just the way it is" - too much data, too many screens, too old equipment etc, etc. However, when using the IEC ethernet diagnosis tool and looking at the errors page, you see as shown on the attached image - lots of "meaningless" C047 errors which can be cleared but immediately come back again. We have another similar PLC with similar setup and it does show the C047 error, but only the one and seems much faster. Googling C047 shows that "An error packet ICMP was received" where ICMP means "Internet Control Message Protocol" - which seems to be related to a PING command in some ways. I'm wondering if this is what is hogging the comms, but have no way of knowing what's causing these errors - possibly the SCADA connection ???? Any advice greatly appreciated ...

Thanks for the information and your obvious knowledge and experience. I also have installed probably hundreds of analogue 4-20 ma sensors and outputs and have never come across an issue like this one. In general, we use multi core cable to go from the PLC to remote junction blocks and then split out from those to the individual local items. The multi cores can have up to 50 cores and are generally 0.5 mm squared cores to give good cable strength. The multi cores will only ever carry the 24 VDC Io signals and there will never be any AC voltage used in the cores. We've never had a problem before and this particular output had been running happily for more than ten years. The individual two core cable from the junction block to the valve was changed at the time but the failures kept happening. The multi core cable was still used, and once the isolator was installed the failures stopped. For extra security, the valve has now been wired all the way back to the PLC in a dedicated two core, but the isolator had solved the problem already. The only issue I've ever had on analogues before, was a PRT probe that had the 4-20 converter head installed remotely to the resistance head, and that was very susceptible to interference when inverters started up. Changing to a probe with the ma converter on the probe cured the problem.

So, in the freewheeling state where it's showing 44 amps at 3 kw, assuming that the "root 3 IV cos phi" equation still holds, this would equate to a power factor (cos phi) of around 0.1 to produce a stated power of around 3 kw? I suppose what I'm really try to do is determine how much it actually costs to run the plant, in other words, how many kWh will the electricity supply company charge to run that freewheeling motor for one hour? Presumably 3 kWh?

Not strictly Mitsubishi based, but I thought I'd ask here as there are some good people who view this forum. It's a general question regarding calculation of electrical power. All my career, I've worked on a couple of simple formulae to calculate electrical power, namely I x V for DC circuits and single phase AC circuits and 1.732 x I x V x cos phi for 3 phase AC circuits. However, as inverter control becomes much more common and energy becomes much more expensive, we have now started looking at the energy information available from modern inverters ..... and I'm now very puzzled. The motor in question is a 75 kW three phase motor running a dairy homogeniser, effectively a piston pump that can have a lot of restrictive back pressure enabled to smash the fat globules to smithereens. Effectively, the machine has two modes. It can run on water with no back pressure while cleaning and it can run on dairy product with high back pressure when homogenising. In other words, the pistons can be freewheeling or working hard. The ABB inverter works fine and it's output frequency is controlled by a 4-20 signal from the q plc and it all works fine. However, the output power and amps that the inverter is showing don't make sense to me. In the freewheeling state, the inverter shows 368 volts output voltage, 44 amps and 3.08 kw of power. In the full production, high back pressure state, the inverter shows the same voltage, but 52 amps and 16.36 kw. Which makes me think that my career long use of those equations now needs a complete rethink if those inverter amps values are correct...... Can anyone enlighten me please.

Thanks for that. So, it sounds like it could be an issue with the circuitry within the positioner that is causing unusual voltages to potentially cause problems in the internal circuitry of the analogue output?

A few weeks ago, I was called out to have a look at at a steam valve fitted with a Samson positioner ... the sort that has an LCD screen that is powered up by the milliamps of the analogue output and displays various things about the valve position etc. The PLC is a Q04-UDE with several 8 way current analogue output cards fitted and this has been in operation for around eight years with no problems. The Samson screen was blank and it rapidly became clear that the analogue output must have failed as zero milliamps were coming out. It was during the recent heatwave and I assumed that it was probably a combination of heat and age, so reprogrammed the valve to work using a spare analogue output, changed the wires and all was good again .... for about a week, before that output failed after a few days / week or so, and after having to use at least two more outputs that both failed after varying times, the time had come to do something about it. So, new 8 way analogue output card, new valve positioner head, new twin core screened cable from the output to the positioner and a milliamp to milliamp isolator has it all running again and it's been fine for the last few days ....... My question is ..... what could have caused those 4 channels to fail in such a short space of time? I'm used to the odd one failing, but this was a pattern and all related to the one positioner. All other outputs on the PLC that use the same power supply have been fine, and as far as I'm aware, the channels are short circuit protected and if the resistance of the positioner is high, it will cause an issue but is unlikely to actually destroy the inner works of the channel. Any ideas please?

Ah, sorted it. Put a line of code in at the start to "first run pulse write" the value of -32000 into V7 to ensure that it didn't get to 100 before I could start monitoring. Toggled off M2701 by hand and sure enough, it didn't come back on until V7 got to be 100, indicating that Rung 3 was now operational as expected. Phew ....

I read up on the CJ command a bit more and rearranged the rungs as shown in this graphic and also changed the CJP command for a CJ command. According to the manual, it should skip Rung 3 when V7 is less than 100 (which it is in the top graphic as confirmed by M2702 being ON), and yet Rung 3 still seems to be operational as M2701 is still ON. Really confused now .....

For the first time in my career, I find that I'm looking to write "For Next" loops using index registers to solve a problem, but am struggling to make sense of the way these things work. As shown on the attached graphic, I have an old FX2N hooked up and the entire ( 4 rung) programme is shown as two screen shots. Rung 1 - Meaningless code just to have something there Rung 2 - Labelled START_1 and purely adds 1 to V7 (an index register) as long as V7 is less than 100 Rung 3 - If V7 is less than 100, then it should jump to Rung 2 (START_1) Rung 4 - Purely there so that I can see if Rung 4 is being run as part of the programme. (M2701 should be on when it is) I start the routine with V7 set to a large negative number (-32,000) to give me time to monitor the programme. The top of the graphic shows that scenario and I would have thought that the programme would go through Rung 1 and Rung 2 and then when it gets to Rung 3 it would loop back to Rung 2 and carry on looping until V7 gets to 100. If that is correct, then Rung 4 would not be run during that time and M2701 would be OFF - and yet it is ON, showing that Rung 4 is clearly operational. I'm obviously missing something and wonder if someone could advise what that is please. Thanks

Thanks, I tried check my output window after a "Build" and even a "Rebuild All", but it shows nothing other than a few warnings. Do I have to enable something to get it to show me bits and words that have been used in the compile, as happens in the IEC Developer compile?

Thanks for that Dave, I had a look at that and it seems like GX Works 2 allocates System Variable M Coils starting at the top address of the range and then working backwards. In my case the range from M8191 to M6613 is currently used, meaning that I now have 1,663 spare addresses (as I set the start point for system variables at M5000) before having to look at re-allocating ranges. I'm constantly finding that GX Works 2, while better in some respects, has just lost a few of the more useful, simple functions that IEC has had for many years. Cheers

Please could someone tell if it's possible using GX Works 2 to find out how many System Variables (M bits and D registers) have been used when I compile my programme, so that I can get a feel for the number left for any future expansion. IEC Developer would always display the values after a "Build", but I just can't find the information in GX Works. I must be missing something obvious, but just can't seem to find it. Thanks