Created Date: January 21,2003

Created by: brad

I am using the ramp/soak generator to control an analog output and I am concerned about the slope. According to the DirectSOFT help, the slope must be entered in the ramp/soak table as a value from 0 to 99.99 Least Significant Bit (LSB) increments per second. Here is my question:

Does this mean the maximum ramp slope 99.99 bits per second?

If yes, then it would take approximately 41 seconds to ramp from 0 to a full scale of 4095 bits. This ramp is clearly to slow for my application. Any suggestions? Thanks.

Created Date: January 21,2003

Created by: franji1

Yes, it would take 41 seconds to ramp the full range. You could program the ramp/soak functionality in ladders. The Ramp/Soak only automates the process. I would utilize a DOUBLE DECIMAL V location that stores the desired SP in HUNDREDTHS DECIMAL (e.g. 4095 would really be 409500), and do all the DOUBLE math on that SP, then divide by 100 and move it to the PID's ACTUAL SP location (you can even simulate rounding by adding K50 as part of your calculation before dividing by 100).

Created Date: January 22,2003

Created by: brad

I'm not sure I fully understand. (Please forgive me, I'm a novice at best.) You are suggesting that I utilize a DOUBLE DECIMAL V location for the desired SP and calculate the actual SP as well as the actual slope from this double decimal location. Then I should write these values to the R/S table.

I understand how to do the double math to get the actual SP. However, I don't see how this will change the slope. What am I missing?

Thank you for you time and help!

Created Date: January 22,2003

Created by: franji1

By doing it yourself, the slope can be great than 99.99. If you use double decimal, it can be like 4billion divided by 100 (so that's 40 million).

The point of having a separate storage for the SP in hundredths is to have proper resolution on your calculation. If you wanted the slope to be (for example) 1.5 units per second starting at 0, you would like the SP to be 0, 1.5, 3.0, 4.5, 6.0 etc. The SP in the PID loop does NOT support implied decimal points. So what you need to do is store a "high precision " SP in a separate V location, do ALL the math with this special location, then every scan, do a LD (special SP), ADDB K50, DIVB K100, OUT (PID's SP). You could even save a few CPU cycles if you did it all in BCD then convert it at the end...

LD special SP in BCD

ADD K50 (adding 50/100 or 1/2 for rounding)

SHFR K8 (move BCD number 2 digits to right, same as dividing by 100 BCD, but a LOT quicker!!!)

BIN (PID loop data is binary, not BCD)

OUT to PID SP