BRX -> analog input module -> consistent measuring interval required

[Zero Magnitude]

I've got a BX-DM1-18ED2-D and BX-08AD-2B. I'm using an accelerometer to measure both shock amplitude and to estimate position. 

First, the accelerometer is a little jittery and has a small offset.  It's a 5V device, with a separate grounded supply, putting out a 2.5V nominal at rest with deflection responding linearly to encountered acceleration to +/- 20G.  I've got that compensated, but if there's a built-in function to redo my hand-rolled function, groovy.  From what I can tell, I'm getting the right acceleration out via the RX1 conversion and setting the range to +/- 20 via System Configuration.

The major issue I'm having right now is I can't get a reliable sampling period to estimate the instantaneous velocity.  I understand there are drift issues with inertia-based navigation but I'll worry about that later.  For now, I'm using Euler's approximation (and if it's reliable but flakey I'll move to a Runge Kutta but that's cart before horse.) which is

Code: [Select]

vel = vel + accel * timeslice
pos = pos + vel * timeslice


But I can't get timeslice to be reliable, so the calculations are all erratic.  The tutorial suggests using an ISR with an OUTI or a SETI instruction, but those only work with pins, not with C values.  I can't use those to measure a consistent time internally.  (Do-More is restricting my output choices to ones that physically exist; I can't run the ISR to, say, Y1023 or something like that.)   

I've tried:

• timers to measure the ms since the last iteration
• ISR with a repeated interval
• ENTASK triggers
• Tickms() with modulo in a math operation
• TMR with 5ms periods, both accumulating and individual, with flags, control blocks, etc.
• possibly others, I've become a little lost in the weeds.

Nothing seems to give a reliable time period. I understand how the PLC cycles and iterations work and how the cycle length is indeterminate depending on what other things are being done in that particular iteration. i.e. Cycle time will vary between less than a millisecond and (in this case) 5ms.   

I've got to be missing something obvious; what did I get wrong?

 

[franji1]

You don't need ISR - you just need accurate timing measurement.

If you need more precise timing between MATH instructions between each scan, use TICKus() (microsecond value) in your MATH.  1000 times more accurate than TICKms()

D0 Current scan's microsecond time stamp
D1 # of microseconds since last scan
D2 Previous scan's microsecond time stamp

MATH D0 "TICKus()" 
MATH D1 "D0 - D2"
MOVE D0 D2

Use D1 as your "timeslice" in your two MATH boxes below these (note that "timeslice" is now in MICROseconds, so you may need to divide by 1000.0 in your VEL and POS expressions ? ? ?)

[BobO]

What sample rate do you need from the sensor? The BX-08AD-2B isn't particularly fast. The internal analog is close to 1ms per sample, but the module is much longer than that.

[Zero Magnitude]

What sample rate do you need from the sensor? The BX-08AD-2B isn't particularly fast. The internal analog is close to 1ms per sample, but the module is much longer than that.

Ideally 2ms, but I can make do with what I have. 

I will not be able to justify buying a different model of PLC to get a faster sample rate. (If it's a limiting factor for production, yes, but not for prototyping.) 

[BobO]

how many inputs are you using?

[Zero Magnitude]

how many inputs are you using?

Analog x 2, RS-232 x 2 (although one is USB right now), 6 discrete.

[BobO]

If you are only using 2 channels, the BX-08AD-2B will update in about about 11ms...8 is 45-ish. The onboard analog updates in about 1.1ms. If the speed is critical, you are going to have to use the onboard. Not a faster PLC, faster analog channels.

The price of the analog module and CPU you are using is $476. The BX-DM1E-36ED23-D is $472...and you get an Ethernet port for programming.

[Zero Magnitude]

If you are only using 2 channels, the BX-08AD-2B will update in about about 11ms...8 is 45-ish. The onboard analog updates in about 1.1ms. If the speed is critical, you are going to have to use the onboard. Not a faster PLC, faster analog channels.

The price of the analog module and CPU you are using is $476. The BX-DM1E-36ED23-D is $472...and you get an Ethernet port for programming.

I'm already over budget on the prototype so I can't spend another $500 right now.  Also everyone's already concerned about the controller being too big, so that's going to be a logistics nightmare once I get to that issue. 

Is there a flag on the input so I know it's done measuring, or do I just have to hope it's not changing when I read it?  If I get the same value 5x when it's being read that's actually okay, the idea is to get data at the same interval as another sensor so the two can be mapped together.

It's not particularly the speed that the problem, it's with the reliability of timing so that I can get something other than nonsense out of the accelerometer.  I can read it fine, G values are within reason, but the position and velocity are essentially random numbers.  I mean, unless that's the same problem. 

[Zero Magnitude]

You don't need ISR - you just need accurate timing measurement.

If you need more precise timing between MATH instructions between each scan, use TICKus() (microsecond value) in your MATH.  1000 times more accurate than TICKms()


Use D1 as your "timeslice" in your two MATH boxes below these (note that "timeslice" is now in MICROseconds, so you may need to divide by 1000.0 in your VEL and POS expressions ? ? ?)

That did give better resolution, thank you.  I'm seeing between ~800 - ~3000 us after initial setup runs. 

My math is still not working though.  I feel like I'm taking crazy pills. 

[BobO]

Is there a flag on the input so I know it's done measuring, or do I just have to hope it's not changing when I read it?  If I get the same value 5x when it's being read that's actually okay, the idea is to get data at the same interval as another sensor so the two can be mapped together.

It's flagged internally, that's how the CPU knows the data has changed, but that isn't exposed to the program. The value never changes while the user program is running. That's done as part of the system overhead of the scan.

It's not particularly the speed that the problem, it's with the reliability of timing so that I can get something other than nonsense out of the accelerometer.  I can read it fine, G values are within reason, but the position and velocity are essentially random numbers.  I mean, unless that's the same problem. 

That was my concern. If you start with crunchy input data, the math may not produce good results. The need for precision timing would seem in conflict with a slow input.

Another consideration is step response of the input. In addition to how fast the input updates, you have to be aware of how fast it can change.

[Zero Magnitude]

It's flagged internally, that's how the CPU knows the data has changed, but that isn't exposed to the program. The value never changes while the user program is running. That's done as part of the system overhead of the scan.

My concern ... [is if] you start with crunchy input data, the math may not produce good results. The need for precision timing would seem in conflict with a slow input.

Another consideration is step response of the input. In addition to how fast the input updates, you have to be aware of how fast it can change.

That's excellent info, that it will fix the values during the ladder execution regardless of how fast I attempt to read.  I thought that was the case but I wasn't sure based on the different sample rates.  (i.e. if it takes 2ms to read and I take 900us to execute, what am I reading?)

I am still having trouble with the math when I slowed it down to 500ms sampling, it's weird.  I even did a sanity check that velocity is still equal to time * acceleration and distance is still equal to velocity times time. Let me try with a potentiometer and see if it's the sensor being funky. 

[BobO]

I am still having trouble with the math when I slowed it down to 500ms sampling, it's weird.  I even did a sanity check that velocity is still equal to time * acceleration and distance is still equal to velocity times time. Let me try with a potentiometer and see if it's the sensor being funky. 

Make sure you understand integer/float promotion rules in Do-more math. That's bitten many.

Another concern is that we are limited to 32 bit floats, so at the extremes you can get error. There are ways around this, but you may have to think it through, i.e. know what expected result of each operator is, and make sure it doesn't bump into the end of precision.

[Zero Magnitude]

Make sure you understand integer/float promotion rules in Do-more math. That's bitten many.

Another concern is that we are limited to 32 bit floats, so at the extremes you can get error. There are ways around this, but you may have to think it through, i.e. know what expected result of each operator is, and make sure it doesn't bump into the end of precision.

I think understand how to convert between int and float, but in case I don't, what should I read to make sure?  All I've got for a math guide is the list of functions.  (Don't worry about being too technical.)

The errors are probably not stemming from precision issues at the business end of 32-bit limitations.  It's more that it's not reading the acceleration and deceleration as equivalent events, so it doesn't read that the thing has stopped moving.   

[BobO]

I think understand how to convert between int and float, but in case I don't, what should I read to make sure?  All I've got for a math guide is the list of functions.  (Don't worry about being too technical.)

Promotion, not conversion. For instance 1/3 = 0, but 1.0/3 or 1/3.0 = 0.33. When you start mixing integer and float, be sure you are getting promotion to float as required.

The errors are probably not stemming from precision issues at the business end of 32-bit limitations.  It's more that it's not reading the acceleration and deceleration as equivalent events, so it doesn't read that the thing has stopped moving.   

That could easily come back to sample rate and aliasing effects. I should have asked this before, but have you disabled all channels you aren't using? Assuming that you have, you are sampling each channel ~6ms apart, so there will always be a disconnect between the two inputs. Additionally, since you are sampling each channel at ~11ms (plus 1/2 PLC scan on average) if the sample window shifts relative to the movement you are capturing, where the accel move is captured right at the leading edge, but the decel is captured 10ms delayed from the start, the sum of each half won't cancel. It probably won't ever, but the tighter the sample window the better the chance it's close.

[Zero Magnitude]

Promotion, not conversion. For instance 1/3 = 0, but 1.0/3 or 1/3.0 = 0.33. When you start mixing integer and float, be sure you are getting promotion to float as required.

Yes, I've definitely seeing decimal places and using toreal() when dividing by a fixed value.  (e.g. the 1,000,000 us to timeslice conversion)  I'm rounding to hundredths digit of acceleration, because anything smaller than that is going to just be the vibration on the desk.   

That could easily come back to sample rate and aliasing effects. I should have asked this before, but have you disabled all channels you aren't using? Assuming that you have, you are sampling each channel ~6ms apart, so there will always be a disconnect between the two inputs. Additionally, since you are sampling each channel at ~11ms (plus 1/2 PLC scan on average) if the sample window shifts relative to the movement you are capturing, where the accel move is captured right at the leading edge, but the decel is captured 10ms delayed from the start, the sum of each half won't cancel. It probably won't ever, but the tighter the sample window the better the chance it's close.

I've only got the two channels on, the rest are tied to ground.  Aren't they disabled by default?  I didn't set any of them up in the System Configuration except for the ones that I'm using (RX0 and RX1)   

Ohhh, I have an idea.  I'm going to try waiting for the timeslices to get longer than the minimum sample time, but use the variable length from the tickus() and see where that goes.  If that doesn't work I'm going to mail the parts to someone I don't like.