Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Exponential vs Tracking filter
#1
Using an Acc-65-ETH I want to filter ADC1 as follows:
(Modbus config shown at bottom)
I8008=$D10781 ;ECT Entry 8 Y:$003509 = $D10781 ;begin exponential filter on ADC1 located at X$:010781
I8009=$000005 ;ECT Entry 9 Y:$00350A = $000005
I8010=$00068E ;ECT Entry A Y:$00350B = $00068E


Bit 19 = 0 should give Exponential filter, but I get a tracking filter instead. I think this may be because my source address extends into byte 5 (bit 16=1). I know this is not supposed to happen; that the filter selection is supposed to be limited to bit 19 only, but it seems to be sensitive to any value in the entire byte. (0=Exp, otherwise=Tracking)

I know the filter algorithms have worked correctly for many years, and indeed I have used the Exponential successfully in other applications - where the source address was limited to 4 bytes. I am curious regarding the mode selection behavior for the $D filter method.

As a workaround I code the filter in PLC0 (thereby confirming expected source location as well). This is not a current issue anymore, but am still curious if I am doing something wrong.

Hardware is an 8 axis GEO Brick


Code:
;DEFINE UBUFFER 1024     ;define 48 bit address space $010400-$0107FF inclusive for user

;I67=$010700              ;Beginning of ModBus Buffer
;
; Modbus Global socket configuration...
;
WL:$10700,$100000000000    ;X=Socket0 Mode1, Server TCP PMAC ascii  IP=0.0.0.0            
WL:$10701,$000000000000    ;IP=0.0.0.0
;WL:$10702  RESERVED
WL:$10703,$200000000000    ;X=Socket1 Mode2, Server TCP PMAC interrupt ascii IP add=0.0.0.0    
WL:$10704,$000000000000 ;IP=0.0.0.0
;WL:$10705  RESERVED
WL:$10706,$400000000002    ;X=Socket2 Mode4, ClientModbus/TCP-IP IP add=Server            
WL:$10707,$0000C0065E32 ;IP=192.006.094.050
;WL:$10708  RESERVED
WL:$10709,$000000000202    ;X=Socket3 Mode0, not active                    
WL:$1070A,$000000000000 ;IP=0.0.0.0
;WL:$1070B  RESERVED
;
; Global Timers...
WL:$1070C,$000001010101    ;All socket timers = 1*5ms
;
; socket 2 commands
WL:$10710,$170000040000 ;X=timer0 Func=$17 ModBusRef=$0    Y count=4 PMACref=0 [READ Inputs]
; Func$17=23d  ReadWrite multiple registers x 120 words [REQUIRES 2 ENTRIES]
WL:$10711,$000004040004 ;X=timer0 Func=$0  ModBusRef=$4    Y count=4 PMACref=4  [WRITE Outputs]
;each count = X or Y 16bit
;$10780 - Digital Inputs X:0-15  Y:0-7(16-23)
;$10781 - Analog Inputs  X:0-11 #1   Y:0-11 #2
;$10782 - Digital Outputs X:0-15  Y:0-7(16-23)
;$10783 - Analog Outputs X:0-11 #1  Y:0-11 #2

M1900->X:$010781,0,12          ;ADC#1  raw
M1901->Y:$010781,0,12          ;ADC#2 raw
M1902->X:$00350B,0,12        ;Filtered ADC#1 see ECT for exp filter definition
#2
I'm puzzled as to how this could be the case. A tracking filter (which is simply an exponential filter plus an integral gain term) is a 5-line entry in the table, so if it were a tracking filter, the result would be at the address matching I8012, not I8010. And the integral gain term, which has to be greater than zero for the filter to act as a tracking filter, would be in I8012.

What happens if you use one ECT entry to process the analog input into an intermediate result in the table, then execute the exponential filter on this intermediate value? This is how the filter is usually used.
#3
(08-23-2011, 02:11 PM)curtwilson Wrote: I'm puzzled as to how this could be the case. A tracking filter (which is simply an exponential filter plus an integral gain term) is a 5-line entry in the table, so if it were a tracking filter, the result would be at the address matching I8012, not I8010. And the integral gain term, which has to be greater than zero for the filter to act as a tracking filter, would be in I8012.

What happens if you use one ECT entry to process the analog input into an intermediate result in the table, then execute the exponential filter on this intermediate value? This is how the filter is usually used.

Yes, I agree - the result does not seem to be where I would expect.
With I8008/bit19=0 the X value at I8010 should be a filtered result from the exponential, but is instead a highly varying value that makes no sense in the context of the raw data (potentiometer) going into the filter. My thought is that where I expect to see result data I am instead seeing intermediate data from the tracking algorithm(??)

That is why I am wondering if the address extending beyond 4 bytes is inadvertantly triggering the tracking filter by placing a (non-zero) value in byte5(bit16). Bit19 alone should be the switch but maybe it is sensitive to a non-zero value anywhere in byte5 bit16-19 (?)

Your second comment may be the answer though; unfortunately I'll have to wait until I have access to a machine to try this.
I might have checked this initially but it's been a while back & I'm not sure - The ECT entry references all 24 bits at X:$10781 but the ADC data is only in the lower 12. Modbus protocol transfers 16bits, which leaves the upper 8 bits of the source data unknown. I am assuming it to be zeros but that may be the problem.
Whatever it is, I wouldn't expect it to be dynamic so I still am wondering. Filter coefficients are very slow & the result data I see varys so wildly I don't see how it could be comming out of the Exp filter, even if the higher order bits are random.

Per your suggestion I could ensure using only the valid 16 bits in the X word transferred by Modbus with the following ECT entry:
I8008 = $690781 ;X/Y data at $010781 is not fractional
I8009 = $010018 ;data is 16 bits wide starting at bit24 (bit0 of X)
I8010 = $D0350A ;start Exponential
I8011 = $000005
I8012 = $00068E

I'll give this a try in the comming weeks when I have access.

Thank You

#4
I've had a chance to check this here on a Turbo PMAC. The exponential filter works fine when bit 16 of the source address is 1.

I'm worried about the possibility of "random data" in the high 8 bits of your source register. This may be the real source of the crazy results you are getting.


Forum Jump:


Users browsing this thread: 1 Guest(s)