PulsePeriod/PulseFrequency Fx PLC

[garysdickinson]

I have coded myself into a corner and need some expert advice.

I am using the Fx1616-BA PLC firmware revision 91.1

My client's application uses 3 flow sensors with pulse outputs.  They are connected to PLC inputs 1,3 and 5.  I am using the the High Speed counters 1,2, and 3 to capture the total pulse count for each flow sensor.  Additionally I am using the pulse measurement system to measure either the PulsePeriod on the same 3 inputs.

The incoming pulse frequencies of interest are between 10 and 300 Hz.

For test I am driving the PLC inputs from the PLC's PWM outputs.  This allows me to simulate the behavior of the flow sensors without having to have a 15 HP pump and 460 volt 3 phase electrical service at my home.

I am having a problem with PulseFrequency(1) and PulsePeriod(1).  With a constant input signal at 50 Hz, if I call Pulse Frequency(1) every 100 ms the returned value will not always be 50 Hz, but periodically a value close to 30 Hz is returned.  The 30 Hz measurement shows up about every 20 or 30 measurements and the erroneous measurment lasts for a single call to PulseFrequency(1).

Now what makes this more interesting, is that the PulseFrequency(3) and PulseFrequency(5) measurements are always correct.  I can connect all of the pulse inputs to the same frequency source (remember I am using the PLC's PWM outputs) and only the PulseFrequency(1) values are randomly wrong.

The HSC mechanism calls an interrupt routine when the HSC reaches a programmed limit.  I have instrumented the interrupt routine and have found that with a constant frequency input, that the time between calls to the interrupt routine  is not consistent. This tracks the behaviors of PusleFrequency(1) and PulsePeriod(1).  HSC[2] and HSC[3] do not show these behaviors.

I have tried to duplicate the problem with a minimal PLC program, but have not been able to get a simple program to exhibit the failure.  

Let me tell you what else is going on with this PLC that may have some bearing on the issue and why I can't get a simple program to fail:
1. I am using one of the RS-485 ports to communicate with an external Modbus RTU device.  The Modbus traffic is fairly light.  I am sending out 3 Modbus queries every second, maximum.  Only a single registers is accessed for each query.

2. The RS-232 port is running the most traffic. It is connected to Weintek HMI panel.  The HMI is using the RS-232 link to access the PLC internals.

3. I have turned on the "High Speed Timer" mechanism for 1 TIMER.  I needed a timeout of less than 100 ms.

4. There are no DELAY statements or polling loops in the custom functions. Everything is written to execute as quickly as possible and to execute as seldom as possible.

Do you have any ideas as to what I did in some other life to get into this mess?

I am concerned that there might some sort of issue in your firmware with regards to the handling of the pulse measurement / HSC[1].  I worry about interrupts getting shut off for too long and edge events being missed. I am not having problems with HSC[2] and HSC[3] and that is both "good news" and oddly interesting.

Any suggestions on what to look for or to test for would be greatly appreciated.  If I could get this problem down to a simple PLC program, It would be in the mail.

As always, I am happy to work with you to figure this out,

Gary D*icknson

[garysdickinson]

I have kept working to try and isolate the problem that I am having with the Pulse measurement / HSC system.

I've attached a PDF file to this post to give you an idea of how big an issue I am having.

I am driving INPUTS 1 and 5 with a PWM OUPUT that is at 77 Hz 50% duty cycle.  I have verified that this frequency is present and at the correct frequency and is completely stable.

The PDF file shows over 300 samples made 0.100 second apart.  The numbers in the columns are the values returned by PulseFrequency(1) and PulseFrequency(5) and are multiplied by 60 to get the number of pulses in one minute.

The values from PulseFrequency(5) no not change from sample to sample.  The values from PulseFrequency(1) have randomly switch back and forth between the correct answer of 4260 and 3060.  I can't come up with a rational explanation for the 3060 value.

The reason I was collecting this data was to see if I could filter out the "wrong" values.  I working on a median filter to treat the wrong values as impulse noise.  My first cut at the filter did get rid of about 75% of the wrong values but due to the frequency of occurrence 25% of the wrong values still got through.  It will take a much more complex algorithm to "fix" the PLC behavior.

Best regards,

Gary D*ickinson

[garysdickinson]

I've tested out the median filter idea to discard the noisy values received from PulsePeriod(1) and PulseFrequency(1), but this approach will not mask the problems with the measurement system.  The frequency of the invalid measuremnt values returned by PulsePeriod(1) and the pattern of these values can not be filtered out.

I took another approach.  Rather than using the HSC[1] and PulsePeriod(1) to both count edges and measure the period, I am using interrupts.

In my initialization code I define an interrupt handler for interrupt #1:


INTRDEF 1, PrdctIntr, 1
[/font][/color]

The interrupt routine looks like this:

' PrdctIntr - interrupt handler from Product flowmeter
'
ScratchVariable = Status(21)
PrdctPulseWidth = ABS(ScratchVariable - SavedCPUTime)
SavedCPUTime = ScratchVariable
[/font][/color]

The variables ScratchVariable, PrdctPulseWidth and SavedCPUTime are in DM32[].  I am a big fan of the #define mechanism. This code will be extended to replace the counting (totalization) function that I was getting from the HSC[1].

The bottom line is that the Interrupt handler approach works as a replacement for PulsePeriod(1).  I an drving INPUT 5 with the exact same signal as INPUT 1 and getting 100% agreement with PulsePeriod(5).

I have made no other changes to the code other than not using the HSC[1] and pulse measurement system on INPUT 1.

Best regards,

Gary D*ickinson

[support]

Thank you for your report. This is the first report we have received of this nature and we will send the report for internal testing to try to replicate the issues of PULSEFREQUENCY as per your report. If found to be a firmware bug we will release a fix so that you can upgrade the firmware that will address the reported issue.

[support]

Hi Gary, we have not been able to reproduce your observation in our internal tests, but by analyzing your data, we deduce that a missing edge capture interrupt processing on the pulse measurement input probably could explain what you have encountered.

The pulse measurement inputs 1 to 4 are each driven from its own 10MHz free running counter. Input capture technique is used to capture the counter value of the rising and falling edges of incoming pulses and the differences are used to compute the period, width and frequency

One question - when you feed pulses to input #1, what signal is being applied to input #2?  Is it held at OFF or the same signal is also applied to input #2?

A 50Hz square way signal applied to the input will mean that period of the ON half and OFF half are each = 10000000/50/2 = 100000. If one of the input capture interrupt is missed and not processed, that means either a ON or OFF cycle would become 200000. The frequency measured therefore = 10000000/(100000+200000) = 33Hz which may be what you have observed.

Likewise a 77Hz square way signal applied to the input will mean that period of the ON half and OFF half are each = 10000000/77/2 = 100000. If one of the input capture interrupt edge is missed and not processed, that means either an ON or a OFF cycle would become 200000. The frequency measured therefore = 10000000/(100000+200000) = 64935 counts. A missing edge capture interrupt will cause one of half cycle to be doubled. Therefore the measured frequency = 10000000/(64395+64395*2) = 52 Hz. This  corresponds pretty closely with your observed frequency of about 51Hz.

As you mentioned, this does not usually happen in most of our users application (that is why this is the first time we receive this report).  Although we have not been able to reproduce it in our test but we are looking what we could do to reduce such possibility from happening. If you would like to continue testing we can send you beta firmware to try when ready.

[garysdickinson]

In the actual customer's application, the pulse frequencies sent to INPUTs 1,3 and 5 are not related to each other in any way.  The pulses originate from 3 pulse flow sensors.  To make it more interesting the pulses tend to be "jittery" and from one pulse to the next both the duty cycle and frequency may change by as much as 10%!

I have been simulating the customer's pulse sources using the PLC PWM and a set of equations that model the relationship between the flow rate and pump speed measured in Hz (VFDCurrenHz).  Just to give you an idea of the complexity of the simulation, this is a snippet of the actual Fx code that I am using to generate the simulated project flows and then simulate them with the PWM system:

      ' The equations to covert VFD Hz to flows are based on a "science project" performed
      '   at Tomar on 1/13/2016 on a 15 hp "POOL" system.  These are the "best fit"
      '   equations to relate Pump speed (Hz) to flow rates in GPM
      '
      SimProductGPM = 0.0072 * VFDCurrentHz * VFDCurrentHz + 0.0644 * VFDCurrentHz + 8.6493
      SetPWM 1, 5000, SimProductGPM / 60.0 * ProductPPG
      SimBrineGPM   = 0.0009 * VFDCurrentHz * VFDCurrentHz + 0.033 * VFDCurrentHz + 3.8351
      SetPWM 2, 5000, SimBrineGPM / 60.0 * BrinePPG
      SimRecircGPM  = 0.4988 * VFDCurrentHz - 0.951
      SetPWM 3, 5000, SimRecircGPM / 60.0 * RecircPPG
[/font][/color]

I know that the simulation is an approximation to the nearest Hz for the SetPWM commands.  In some cases I have summed in a bit of random noise to make the simulated pulses "look" more like what I see from the actual flow sensors. However, even with the customers real system, the values returned by the PulsePeriod(1) function and the HSC[1] can be in error by significanly more that the the jitter that I can "see" with test equipment.

I'd be happy to test stuff.  At present I am using an interrupt routine to measure the pulse period on INPUT #1 but am using the high speed counter mechanism and PulsePeriod() for INPUTs 3 and 5.  I don't see a pattern of wrong measurements on INPUTs 3 and 5 and the interrupt routine that I am using is working without a problem.

What I started to do, was to write the simplest code that could demo the problem. However, it was too simple and the problem did not show up.  As soon as I can get a break from my client's issues, I'll go back and see if I can a demo program that you can use to "see" the issues.

I have another issue with the PLC firmware and I see it on both the Fx and the FMD/Nano PLCs.  I have problems with error rates over the the RS485 ports. As an example, I get measurable error rates with Modbus RTU and the native host commands over serial cables that are less than a foot in length.  I would expect an error rate of 0.  What I am seeing is both missing data bytes and corrupted data bytes.  The error rate correlates directly with BAUD rate, but even at 4800 BAUD I can still  find a measurable error rate.  I have, also, written by own Modbus RTU routines in TBASIC so that I could better observe what was the nature of the data corruption.  Once we get the HSC/Pulse measurements system figured out, I'll attack this issue, next.

Best regards,

Gary D*ickinson

[support]

We have examined the .PC7 program you sent to us, and  we have discovered that it was the STATUS(21) command executed just before the PULSEPERIOD(1) command that affected PULSEPERIOD(1) execution.

This is because when STATUS(21) was run it also enables the same free running timer that PULSEPERIOD(1) depends on to capture the transition edge. Unfortunately when an already running timer was en-enabled it also resets the input capture event, which led to the pulse monitoring missing one rising or falling edge event and that led to the error.

The simplest solution is to remove the STATUS(21) command from the program if it is not needed for the application. (STATUS(21) is typically used for measuring the execution time of a section of codes during debugging phase and is not normally used in the final application program).

We have also rewritten the code of STATUS(21) to prevent it from affecting the next pulse catpure event. The new firmware version F91.2 for Fx CPU and r84G for Nano-10 & FMD will be released very soon which contain the above-mentioned fixes.

[support]

New firmware version r84G and F91.2 have just been released for Super PLC users to self-upgrade. Users who like to upgrade the PLC firmware but do not yet have the instruction please email to support@triplc.com and includes a PLC purchase record such as a scanned or a PDF copy of the invoice from TRi or a distributor and you will receive the downloading instructions.

Note: only PLCs with firmware >= r83 or >= F90.0 are user-upgradable.