Negative presets on timers

Jcooli09 · Sep 24, 2020

I'm loading bulk tankers with dry powder using a 1769-L33ER. Product is fed through gates, and close to the end of the load the system jogs product to top off the tank. During this cycle, we open the gate for a few seconds and close the gate for a few seconds until the truck is full.

We labelled these parameters duration and interval, and operators have the ability to adjust them using numeric inputs in Factory talk to alter the presets of the timers that control this. The HMI input is multiplied by 1000 in Logix, and the destination for that instruction is the preset on the time that controls the activity.

Recently we've started faulting the processor, and what I'm finding is that the preset on one of these timers gets set to a negative number. I've set min/max on the HMI numeric inputs, so the operator shouldn't be able to enter a negative number. I'm scratching my head over this.

Has anyone ever seen this before, and what solutions did you come up with?

GaryS · Sep 24, 2020

It looks like the operators at entering the timer preset with a keyboard and not the HMI screen. the HMI is using the absolute value in the check so it passes it on through to the plc.
in the plc you should program to copy the received preset as an absolute value to a tag and then multiply it by 1000 to place it in the timer preset this should take care of the problem.

Gadelric · Sep 24, 2020

Jcooli09,

I was told one time, many years ago that some math functions can put things in a negative value.
The old timer was giving me huge details about it, but I was young and knew everything...
Long story short, his word of advice is "if your going to use a math function to figure out your preset you need to validate its value before you move it to the preset".
I have since always done a GEQ to 1 comparison on all math functions that adjust timer presets.

Fun thing to test

If you make two dints, put the max value the dint will hold (2147483647) and add those two dints together you will get -2 as an output.
I think this is caused by the math function value being too big for the register its being put into.

I would believe that your negative value is a result of your math function.
This is presuming your operators are using the HMI and not some other source of input that doesn't get filtered out by the HMI.

Gad

GaryS · Sep 24, 2020

I think the reason you are seeing that is with integer type the high order bit is the sign bit if it is set the plc will read the value as a negative number. this is for INT. DINT and Long integers for numbers that large you should be using a float data type. the plc treats int and float data typed differently.
just for perspective a preset of 2147483667 sec. would time out at 68 years I really don't see any program running that long

Lare · Sep 24, 2020

Gadelric said:
Jcooli09,

I was told one time, many years ago that some math functions can put things in a negative value.
The old timer was giving me huge details about it, but I was young and knew everything...
Long story short, his word of advice is "if your going to use a math function to figure out your preset you need to validate its value before you move it to the preset".
I have since always done a GEQ to 1 comparison on all math functions that adjust timer presets.

Fun thing to test

If you make two dints, put the max value the dint will hold (2147483647) and add those two dints together you will get -2 as an output.
I think this is caused by the math function value being too big for the register its being put into.

I would believe that your negative value is a result of your math function.
This is presuming your operators are using the HMI and not some other source of input that doesn't get filtered out by the HMI.

Gad

It is from DINT (Signed Dint) data type, it is data values -2147483647 to +2147483647 , if you add any number above +2147483647, result will go to negative number as 32bit is sign -/+.

If you are using UINTS and UDINT data types, then values are allways positive numbers.
0 to 65535 or 0 to 4294967295 range and it is inpossible that you get negative number anymore.
Or compare result and inhibit below zero numbers on int and dint numbers.

Phil Buchanan · Sep 24, 2020

GaryS said:
I think the reason you are seeing that is with integer type the high order bit is the sign bit if it is set the plc will read the value as a negative number. this is for INT. DINT and Long integers for numbers that large you should be using a float data type. the plc treats int and float data typed differently.
just for perspective a preset of 2147483667 sec. would time out at 68 years I really don't see any program running that long

If you are using DINT's that would be a Logix based controller in which the timers are milliseconds and not seconds so not 68 years more like 24 days and change.

GaryS · Sep 25, 2020

Phil
Here’s the math
2147483647
X 1000 = 2,147,483,647,000
Strip off the upper bits down to bit 31
4,294,966,296 ms

4,294,966,296 / 1000 = 4,294,966 Sec.
4,294,966 / 60 = 71,582 Min
71,582 / 60 = 1,193 Hours
1193 / 24 = 49 Days

It is actually 49 days still a long time to run a timer
If the input is in seconds and multiply by 1000 to get ms preset

But why not calculate the free fall ( material still in motion in the air when the gate close command is sent)
If you feed rate is constant and the distance from the gate to material in the truck is fairly constant the freefall should be constant.
I have done it that way many times truck loading, batching systems never a problem and the operators don’t have to make any adjustments.
You look at the final weight after the gate is closed and all material is on the scales. If the final weight is within the dead band no adjustment is necessary.
If the final weight is not within the dead band then calculate the difference and use that number to calculate the new gate close value. This can all be done in the back ground every time.

Phil Buchanan · Sep 25, 2020

GaryS said:
Phil
Here’s the math
2147483647
X 1000 = 2,147,483,647,000
Strip off the upper bits down to bit 31
4,294,966,296 ms

4,294,966,296 / 1000 = 4,294,966 Sec.
4,294,966 / 60 = 71,582 Min
71,582 / 60 = 1,193 Hours
1193 / 24 = 49 Days

It is actually 49 days still a long time to run a timer
If the input is in seconds and multiply by 1000 to get ms preset

But why not calculate the free fall ( material still in motion in the air when the gate close command is sent)
If you feed rate is constant and the distance from the gate to material in the truck is fairly constant the freefall should be constant.
I have done it that way many times truck loading, batching systems never a problem and the operators don’t have to make any adjustments.
You look at the final weight after the gate is closed and all material is on the scales. If the final weight is within the dead band no adjustment is necessary.
If the final weight is not within the dead band then calculate the difference and use that number to calculate the new gate close value. This can all be done in the back ground every time.

Gary

I did not read much into the application itself but recheck your math. It's 24 days.

To be exact with a DINT which is what Logix 5000 uses for timers the longest you can time is.

24 Days, 20 Hours, 31 Minutes, 23 Seconds, 647 Milliseconds.

drbitboy · Sep 25, 2020

Jcooli09 said:
...I've set min/max on the HMI numeric inputs, so the operator shouldn't be able to enter a negative number. I'm scratching my head over this.

Has anyone ever seen this before, and what solutions did you come up with?

What is the max limit you set for the value that can be entered in the hmi?

daba · Sep 25, 2020

For the OP's application, I doubt he'll want to time more than a few seconds.

What I would do is use LIM instructions in front of the MUL instructions (to convert to milliseconds), the desitinations of which are the timer presets. The parameters for the LIMS should match the upper and lower bounds in the HMI input fields.

Doing so would prevent any rogue values getting into the timers at all, and leave the timer presets what they were before. In the example code I have limits of 2 to 20 seconds, and a "rogue" value of 0 coming in from the HMI. The rimer preset is unchanged from it current value of 3.75 seconds.

OkiePC · Sep 25, 2020

daba said:
For the OP's application, I doubt he'll want to time more than a few seconds.

What I would do is use LIM instructions in front of the MUL instructions (to convert to milliseconds), the desitinations of which are the timer presets. The parameters for the LIMS should match the upper and lower bounds in the HMI input fields.

Doing so would prevent any rogue values getting into the timers at all, and leave the timer presets what they were before. In the example code I have limits of 2 to 20 seconds, and a "rogue" value of 0 coming in from the HMI. The rimer preset is unchanged from it current value of 3.75 seconds.

Do this always and every time you have a timer preset that is adjustable from an external device.

Once in a great while you might have to get online and edit the code to widen the window, but that is better than dealing with the consequences of a rogue entry taking down your process.

AkaHammer · Sep 25, 2020

Test Values in PLC

Test in PLC before using value in timers

Negative presets on timers

Jcooli09

Member

GaryS

Member

Gadelric

Member

GaryS

Member

Lare

Member

Phil Buchanan

Lifetime Supporting Member

GaryS

Member

Phil Buchanan

Lifetime Supporting Member

drbitboy

Lifetime Supporting Member

daba

Lifetime Supporting Member

OkiePC

Lifetime Supporting Member

AkaHammer

Member

Similar Topics