16
Technical support / Re:RF Noise
« on: January 08, 2014, 01:15:10 PM »
Thanks for the response Gary.
This may be worth a go and I'll be sure to post the results.
This may be worth a go and I'll be sure to post the results.
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
17
Technical support / Re:RF Noise
« on: January 07, 2014, 08:00:54 PM »
An update on this issue....the aerial cable screening wasn't as effective as thought. Further testing provided interesting information. When the PLC is powered from a separate source, like a battery, the interference goes away. This would say to me that the noise is not airborne from the plc directly and is rather being radiated down the power supply cables.
Does this info generate any other solutions? Using a separate supply isn't really an option due to space constraints and backup requirements.
Does this info generate any other solutions? Using a separate supply isn't really an option due to space constraints and backup requirements.
18
Technical support / Re:RF Noise
« on: May 03, 2013, 05:08:08 PM »
Thanks for the answer. It isn't that easy to screen the PLC in the way you mentioned (especially considering there are 20 units that need this modification). Our tests show it is just as effective to add an additional sleeved screen over the radio aerial cable within the cabinet and we will be doing this instead.
FYI, we believe that the reason this has only shown up now after four years of acceptable operation is that some other external interference has raised the noise floor which means we have lost some of our signal strength margin and that has pushed the reception tolerance to the limit.
FYI, we believe that the reason this has only shown up now after four years of acceptable operation is that some other external interference has raised the noise floor which means we have lost some of our signal strength margin and that has pushed the reception tolerance to the limit.
19
Technical support / RF Noise
« on: April 29, 2013, 12:03:02 AM »
Hello,
We have a number of T100MD888+ installed in remote sites that communicate over a VHF radio network. We have always noticed at some sites that there has been some interference to the radio that we have always considered as being from an external source. Recently this level of interference has become problematic and we have employed RF consultants to investigate the issue. The result is that the interference is coming from the T100MD888+ PLC and more accurately their "RF sniffer" identified the noise emanating from the CPU.
Our radios work in the VHF spectrum at around 150MHz. I was originally skeptical to the PLC being the issue but based on their analysis, I tend to agree (i.e., removing power from PLC stops the source of interference).
Are you aware of this product generating RF interference? Do you have any recommendations as to how we could reduce this interference? It is unusual that it would seem that things have degraded over time (although that could be explained by other influences) but is there anything within the PLC that may degrade and cause RF noise?
Any help, as always, is greatly appreciated.
We have a number of T100MD888+ installed in remote sites that communicate over a VHF radio network. We have always noticed at some sites that there has been some interference to the radio that we have always considered as being from an external source. Recently this level of interference has become problematic and we have employed RF consultants to investigate the issue. The result is that the interference is coming from the T100MD888+ PLC and more accurately their "RF sniffer" identified the noise emanating from the CPU.
Our radios work in the VHF spectrum at around 150MHz. I was originally skeptical to the PLC being the issue but based on their analysis, I tend to agree (i.e., removing power from PLC stops the source of interference).
Are you aware of this product generating RF interference? Do you have any recommendations as to how we could reduce this interference? It is unusual that it would seem that things have degraded over time (although that could be explained by other influences) but is there anything within the PLC that may degrade and cause RF noise?
Any help, as always, is greatly appreciated.
20
Technical support / Re:RAM Failure
« on: November 12, 2012, 08:55:36 PM »
The 12 Vdc PLC power supply is fed from a 24-12V DC-DC converter which has it's 24 Vdc side connected to a battery bank which is charged by the mains via a 24Vdc battery charging power supply.
So the PLC is well protected behind two DC power supplies and a battery bank in the middle to provide some surge tolerance.
There is very little chance of lightning strike in this area and we have multiple other units that don't display this same failure mode.
In the end a PLC reset seemed to fix the problem, if it was power supply damage, would this have corrected the fault?
So the PLC is well protected behind two DC power supplies and a battery bank in the middle to provide some surge tolerance.
There is very little chance of lightning strike in this area and we have multiple other units that don't display this same failure mode.
In the end a PLC reset seemed to fix the problem, if it was power supply damage, would this have corrected the fault?
21
Technical support / Re:RAM Failure
« on: November 06, 2012, 12:11:52 AM »
To continue with this thread and the fault reported in the January posting, I have had the PLC fail again in the same way. There is also another unit on the same network which is almost as problematic with the same failure mode.
The only relationship between these two units is that they both experience high levels of noise on the RF radio network as they are located close to boating marinas with a lot of UHF and VHF radio use.
I have found out that the radios we use can confuse noise with a transmission and will raise pin 1 of the com port high while the noise is there. Is there any chance that this could cause the failures we are seeing? What about false signals on any other of the com pins that aren't used? Only pins 2,3 and 5 are needed to communicate between PLC and Radio but all of the other pins are connected straight through.
The only relationship between these two units is that they both experience high levels of noise on the RF radio network as they are located close to boating marinas with a lot of UHF and VHF radio use.
I have found out that the radios we use can confuse noise with a transmission and will raise pin 1 of the com port high while the noise is there. Is there any chance that this could cause the failures we are seeing? What about false signals on any other of the com pins that aren't used? Only pins 2,3 and 5 are needed to communicate between PLC and Radio but all of the other pins are connected straight through.
22
Technical support / Re:Fmd88 outputs toggle at power on
« on: July 02, 2012, 03:09:22 PM »
If I understand correctly, the CPU needs to be running to keep the output off. This makes me wonder what failure modes there may be that could make an output turn on when not wanted. I.e., if the CPU were to fail, would outputs 7 and 8 turn on? What about outputs 1-6?
Are there any other failure modes that could cause an output to turn on?
Are there any other failure modes that could cause an output to turn on?
23
Technical support / Re:Modbus delay
« on: July 02, 2012, 12:35:41 PM »
Thanks support, this is definitely good to know. Just to confirm, if I want to increase the delay on comm1 to 30ms, I would write:
SETSYSTEM 3, 00000011
SETSYSTEM 3, 00000011
24
Technical support / Modbus delay
« on: July 01, 2012, 11:41:40 PM »
I am having an issue with a radio network that is echoing the scada master modbus rtu read command and is confusing the scada which interprets the echo as a failed modbus transmission. To get around this we may need to delay the master to look for a response afer a longer delay.
What is the delay time in the fmd88 plc between receiving a modbus read request and responding? Is this delay configurable at all?
Do you have any other ideas of how this issue may be resolved?
What is the delay time in the fmd88 plc between receiving a modbus read request and responding? Is this delay configurable at all?
Do you have any other ideas of how this issue may be resolved?
25
Technical support / Re:Fmd88 outputs toggle at power on
« on: June 23, 2012, 01:58:50 PM »
Yes, the heater relay and PLC are connected to the same 12V source.
When I noticed the problem I had 22 PLC's that were being commissioned in our product. While I can't conclusively say that this was happening to all PLC's it definitely wasn't unique to just one and would have applied to most.
The relay used is an OMRON G2RV-SL700 DC12.
When I noticed the problem I had 22 PLC's that were being commissioned in our product. While I can't conclusively say that this was happening to all PLC's it definitely wasn't unique to just one and would have applied to most.
The relay used is an OMRON G2RV-SL700 DC12.
26
Technical support / Re:Fmd88 outputs toggle at power on
« on: June 14, 2012, 05:27:54 PM »
My heater is swiched by a 12v omron relay, this relay momentarily switches on startup. It was this relay switching that drew my attention to the brief on/off of outputs 7 and 8. So it would seem that there is enough transient voltage to switch a relay.
27
Technical support / Fmd88 outputs toggle at power on
« on: June 13, 2012, 06:08:47 PM »
I have noticed with the fmd88 that outputs 7 and 8 briefly turn on when the plc is powered up. For my application this briefly toggles a heater relay so no harm done but for other applications this could be a significant hazard.
Is this a known issue?
Is this a known issue?
28
Technical support / Re:Output State on Power Off
« on: May 11, 2012, 08:30:02 PM »
Support, can you please tell me which chip is connected to which outputs?
29
Technical support / Logical Comparison Limit
« on: April 30, 2012, 11:43:51 PM »
Is there a limit to the number of logical comparisons that can be used in an IF statement?
E.g.,
IF A=1 OR B=1 OR .........Z=1 THEN
E.g.,
IF A=1 OR B=1 OR .........Z=1 THEN
30
Technical support / Re:FMD88 Analogue Inputs
« on: April 22, 2012, 03:23:07 PM »
I like the idea of leaving the avg const at 3 but it doesn't work when I need to do my one off reading from the sample and hold system I have set up.
Can I trick the PLC by reading the ADC channel 3 times to essentially give me a one off reading? Do I have to use the REFRESH command after each read?
E.g.,
REFRESH
DM[103] = ADC(3)
REFRESH
DM[103] = ADC(3)
REFRESH
DM[103] = ADC(3)
Can I trick the PLC by reading the ADC channel 3 times to essentially give me a one off reading? Do I have to use the REFRESH command after each read?
E.g.,
REFRESH
DM[103] = ADC(3)
REFRESH
DM[103] = ADC(3)
REFRESH
DM[103] = ADC(3)