Torque

Forums

Forums

Guest  

Show or hide header
Welcome Guest, posting in this forum require registration.




Torque » Torque OBD ECU Scanner » Torque Discussion / Ideas » An equation failure question for "piemmm"

Pages: [1]
Author Topic: An equation failure question for "piemmm"
F-150Torqued
Member
Posts: 369
Post An equation failure question for "piemmm"
on: January 3, 2018 (GMT)

I have a custom equation that occasionally fails (according to what I think it should do). The ‘latter’ may be the entire problem, but I suspect only piemmm can answer that.

My truck (2004 5.4L 3 valve) presents an IMRCM (Swirl Control butterfly) position Monitor reading on PID 1634 (2 bytes). A proper equation has been elusive. Monitoring, graphing, and observing the linkage with a bore scope has proven that when NO swirl control is desired or requested by the ECU, the high order bit of 1634 byte A is ‘ALWAYS TRUE’ (ie: negative). However periodically other bits in byte A become true (the meaning of which I _cannot_ determine). However, fortunately, When the swirl control is requested open, bytes A*256+B produces clean 512 (closed) to 0 (full open) – in eight increment resolution (ie 12.5º increments 0 to 90º, inverted). ??? I do not proposed to understand WHY the PCM is doing things in this way.?? But I can work with it.

My solution was to make EVERYTHING negative simply read Zero on my IMRC gauge. (Without availability of Boolean Arithmetic) — My method of accomplishing this by equation is: (1-(A>7)*(512-(A*256+B)))*(90/512)

The gauge (designed with min 0 / max 90) reads zero to ninety degrees in 12.5 degree increments perfectly. ///HOWEVER/// On occasion – the gauge displays a large negative number just as indicated in my testing ‘graphs’ – totally screwing up the gauge range and appearance. I added additional brackets to enclose both references to “A” – but doesn’t eliminate the occasional undesirable negative result.

The ONLY way this could happen – (I Think) – is if Torque Pro formula parsing routine polls the PID or ‘Retrieves’ byte A separately for the two references to “A” within the left set of brackets – and the byte has changed between the two samples. (This seems WRONG to me).

If I am right – I will have to create/set a separate variable containing — then can I shift or mask off the high bit within a psuedo PID / variable?

Also this would be another perfect situation for application of Boolean Arithmetic. ie: (A>0)*(512-(A*256+B))*(90/512). ///However/// if my above assessment is correct, this would not even fix my problem.

——————

54371019

cintakc
Member
Posts: 1106
Post Re: An equation failure question for "piemmm"
on: January 3, 2018 (GMT)

Hi, I did not quite understand, from your description, the logic of work you need, if you explain I will try to help you
but for now I can advise such a formula
(1-BIT(A:7))*(512-(A*256+B))*90/512

such an equation will not give you large negative values
(1-BIT(A:7))*(512-(A*256+B)&448)*90/512
or else with an extra pair of parentheses
(1-BIT(A:7))*(512-((A*256+B)&448))*90/512

F-150Torqued
Member
Posts: 369
Post Re: An equation failure question for "piemmm"
on: January 3, 2018 (GMT)

Thanks for the response @cintakc

The logic I need is a ‘Zero’ or ‘One’ from the bracket left of the ‘First’ multiply. THEN the ‘CONTENTS’ of A – CANNOT CHANGE TO NEGATIVE DURING PROCESSING THE REMAINDER OF THE FORMULA —— Or the whole formula fails. Example: If A:7 is Zero in the first half, it is a positive number and I’m going to multiply the latter half by “1” leaving it unchanged. HOWEVER – if A becomes negative before processing the second half – I get screwy negative number instead of the desired result of Zero.

What I want from the formula is a ZERO result for ALL Negative results of (A*256+B).

I use A:7 in many formulas and I think it should function the same as A>7 I am using in this case. It should produce a ‘One’ or ‘Zero’. (And it does.) However if “A” is positive when Torque processes the first portion of the formula – AND THEN becomes Negative before Torque processes the second half of the formula, my formula FAILS.

It appears THAT is what is happening – even though infrequently. THAT Leads to my question – “Is the SAME COPY of “A” being used throughout processing the equation – or is a new value retrieved from OBDII at any time during processing?” Seems to me that “A” would be ‘pushed’ on the stack for use throughout the calculation. ??????

This one I haven’t tried. [ 1-BIT(A:7))*(512-(A*256+B)&448)*90/512 ] Are you sure we can “AND” a word size field. But in either case if A:7 is zero – I don’t want ANY NEGATIVE value to EVER result from the second half of the equation.

————–

54371019

cintakc
Member
Posts: 1106
Post Re: An equation failure question for "piemmm"
on: January 3, 2018 (GMT)

try the formula that suggested, it removes the influence of the sign in byte A, due to &448 in the second part of the formula
in the second part of the formula there will never be a negative value
(1-BIT(A:7))*(512-((A*256+B)&448))*90/512

F-150Torqued
Member
Posts: 369
Post Re: An equation failure question for "piemmm"
on: January 3, 2018 (GMT)

If we can perform word wide logical operations (ie: ‘&448’ ) I think that will prevent my gauge from going ‘crazy’. That is actually my objective. Even though the formula result will be incorrect for a brief second. The formula result would be within the range of +12.5º and +90º. I believe the crazy formula result occurs only ONE time briefly when something happens during the formula being parsed or calculated. Then things are back to normal and my formula is working correctly – But the minimum / maximum range on the gauge has been ‘WHACKED’.

I reviewed some of my log files – and the most common negative number is -128 (when the IMRC valve is closed or closing). I Have NO idea what it means to the ECU, but a borescope shows valve is ‘CLOSED’ while it is -128.

SO: the ‘&448’ would result :

1111111110000000 =-128
0000000111000000 = 448
_________________
0000000110000000 = 384 or 67.5º on my zero to 90 degree scale.

May not be the ‘correct’ answer for the brief moment – but would NOT ‘WHACK’ my gauge.

I will give this a try. Thanks MUCH @cintakc

————–

54371019

Capp777
Member
Posts: 2556
Post Re: An equation failure question for "piemmm"
on: January 3, 2018 (GMT)

Just curious… have you looked at your
values as a ((Signed(A)*256)+B)?

I thought 1634 returned volts?

((Int16(A:B)&448)>6)*(90/7)*(1-Bit(A:7))

F-150Torqued
Member
Posts: 369
Post Re: An equation failure question for "piemmm"
on: January 3, 2018 (GMT)

Yes.

This PID is ‘IMRCM’ Intake Manifold Runner Control Monitor, also known as ‘swirl control’. There are 4 wires attached to it – for both control (indicated by PID 1103 A:4. When 1103 A:4 is TRUE, the butterfly opens to some degree (per the bore scope). There seems to be NO rime or REASON to any negative numbers from PID 1634 other than -128 which is the reading when 1103 A:4 is “OFF” and the valve is closed. When it is HIGH, 1634 reads as a one word binary counter shifted left 7 bits. Ie:

0000000001000000
through
0000000111000000

When the valve closes (or IS CLOSING) — PID 1634 reads some odd negative numbers ( in the upper nibble) but stays at 1111111110000000

My gauge reads nicely zero to 90 degrees open. Only occasionally — in the middle of my formula processing – the high order bit changes between start to finish and I get a CRAZY display scale range. Until I reset Min / Max to fix the gauge.

EDIT: Had ‘description’ of 1103 A:4 state backwards. Corrected it.

—————–

54371019

cintakc
Member
Posts: 1106
Post Re: An equation failure question for "piemmm"
on: January 3, 2018 (GMT)

F-150Torqued
you can give the value of the answers 621634xxxx for 8 values from 0º to 90º

F-150Torqued
Member
Posts: 369
Post Re: An equation failure question for "piemmm"
on: January 3, 2018 (GMT)

Well, I’m smarter NOW. Following a thirty mile run across town with formula ((1-(A>7))*(512-((A*256+B)&448)))*(90/512) – I NOW KNOW THAT you can perform logical operations on two byte fields.

HOWEVER – Observations of the gauge running this equation exhibits the same phenomenon. Either byte “A” gets updated between processing of “A” in the first half of the Formula and processing the Second Half of the formula. OR, some read error on the CAN bus is producing a hugely erroneous value of (A*256+B) that has all the relevant bits (6,7 & 8) True when bit 15 is false. Those are the ONLY two possibilities. I would like to know if the first is the case – because it would have far reaching implications on constructing equations.

@Cintakc’s suggestion prevents the gauge ‘min/max’ scaling from getting torn up by ‘insuring’ there can NEVER be a result outside the zero to 90 scale. However, the gauge Maximum reading DID register 78.75º on a part of the trip where driving conditions NEVER called for more than 67.5 degrees swirl control.

Quote from Capp777 on January 3, 2018

I thought 1634 returned volts?

((Int16(A:B)&448)>6)*(90/7)*(1-Bit(A:7))

Some documentation I have seen DOES state ‘Volts’. IDK. If it is volts, it only returns 8 divisions with those three bits sitting across the boundary of “A” & “B”. I have tried all kinds of things to make sense of it the signal. Positive numbers make sense 0, 64, 128, 192, 256, 384, 448, 512. Negative numbers ??? DON’T. 8000, 8080 and FF80. This also makes NO sense as to the A/D Converter. I think the A/D converter is 1024 bit. But other PIDs appear to use 16384 and 32767 A/D counts.

But this device sits at FF80 in the idle state. That doesn’t look like anything related to volts.

I have considered ADDING 128 to A*256+B and treat it as one field of 0 to 640. But the negative readings are not proportional to the positive causing a skewed value low on the scale. ????

What would work Perfect is to use the High Order bit of “A” to FORCE the result to Zero – no matter what other bits were set, otherwise use (A*256+B).

————-

54371019

F-150Torqued
Member
Posts: 369
Post Re: An equation failure question for "piemmm"
on: January 3, 2018 (GMT)

Quote from cintakc on January 3, 2018
F-150Torqued
you can give the value of the answers 621634xxxx for 8 values from 0º to 90º

Are you talking about the ‘lookup’ function. I didn’t think that was implemented yet.

And @Capp777, this ‘((Int16(A:B)&448)>6)*(90/7)*(1-Bit(A:7))’ has a stuff, and combinations, in it I didn’t know were functions of Torque.

I’m just a ‘babe’ still learning, ya know. :-)

———————

54371019

Capp777
Member
Posts: 2556
Post Re: An equation failure question for "piemmm"
on: January 3, 2018 (GMT)

Beta version 1.8.190

which also has the Lookup function.

cintakc
Member
Posts: 1106
Post Re: An equation failure question for "piemmm"
on: January 4, 2018 (GMT)

F-150Torqued, try this formula
(1-BIT(A:7))*(448-((A*256+B)&448))*90/448

F-150Torqued
Member
Posts: 369
Post Re: An equation failure question for "piemmm"
on: January 4, 2018 (GMT)

I will give it a try. I think it will work as did the previous equation you suggested.

Revisiting my log files, I notice something else that could further clarify WHAT the ECU is doing. It may be a 1024 bit A/D offset by -128. I need to add a field to my spreadsheet and ADD 128 to each row and treat it as 1024 instead of 512 field and see how it comes out. I think that would also eliminate the effect of the negative numbers I am trying to force to Zero.

However – this does drift away from my initial question. I am still curious WHY my original Equation fails. If it is due to A being updated or changed during parsing / calculations of the formula, it is still a significant issue – for other calculations as well. I plan a test (storing a memory copy of A*256+B) at the beginning and do ALL the original manipulation on THAT copy to see if it exhibits the same problem.

—————

54371019

piemmm
Administrator
Posts: 6045
Post Re: An equation failure question for "piemmm"
on: January 5, 2018 (GMT)

Hi!

Remember to force the order of the calculation using brackets () or the parser may do a + before a /(etc)

Variables don’t change when the equation is being parsed – it’s most likely an issue with the order of calculation (the ‘test function should show you each step)

I’ve added a min(x:y) and max(x:y) function in the coming beta update (which is imminent) so if you want to prevent something going to negative you can simply do max(0,a) where a is the variable – the function will choose the larger of the two numbers. The min function is the opposite and will choose the smaller of the two numbers given

F-150Torqued
Member
Posts: 369
Post Re: An equation failure question for "piemmm"
on: January 5, 2018 (GMT)

Thanks for the reply and in no way whatsoever to challenge anything, only present a result curious to me. My career programing experience taught me there is ALWAYS an explanation for EVERYTHING a microprocessor does.

I can see the upcoming min / max function would resolve the surface problem (by limiting calculation output to protect integrity of the gauge span). However, I urge: My original formula, (1-(A>7)*(512-(A*256+B)))*(90/512), DOES work, and SHOULD do the identical thing as min(x:y) can do. It has been verified by the “test function”, and with brackets around various elements. Obviously brackets in some places cause it to not work. Clearly the 1-(A>7) produces a Zero when the high order bit of A is true. ONCE THAT HAPPENS, everything else should be ZERO – no matter what happens right of the first ‘*’.

It is NOT ‘ALWAYS’ doing that. On occasion, (I believe it happens -right- at the instant the OBDII result changes to FF80). The formula produces 11407.5 when A*256+B is equal to $FF80. That is the result of the last half of the formula multiplied by “1” (as should happen ONLY when the high order of byte A is a zero. And when it happens – just once – it is destructive to the gauge range(s) – or I would have never noticed it.

Except for the limitations of my active version 1.8.178 — the formulas suggested by @cintakc (masking off all but 3 bits with &448) works to preserve integrity of the gauge, but logging indicates it suffers from the SAME PHENOMINOM. Right when the OBDII result changes from positive numbers to FF80 – the formula produces an erroneous result ONE TIME.

It just as though an interrupt or something allowed the value of A changes during processing first and last half of the formula.

My not understanding what is happening leaves me (and perhaps Torque) vulnerable to being ‘bit’ elsewhere when least expected, and possibly in a worse way.

—————-

54371019

F-150Torqued
Member
Posts: 369
Post Re: An equation failure question for "piemmm"
on: November 7, 2018 (GMT)

Hey guys (@cintakc, @capp777 and everybody) especially @piemmm – The perceived FAILURE was in my head – NOT VARIABLES CHANGING during calculations. MY APOLOGIES

@piemmm. I struggled and struggled with the two bytes from Mode 2 reads of PID # 1634 (Intake Manifold Runner Control Monitor) on my 2004 F150 5.4l Triton. All formulas I tried (and those suggested) would all fail, periodically / produce crazy erroneous data. What I learned was unexpected, and might benefit someone else at some point.

The PID is designated “IMRC MONITOR”, and the logs clearly indicate positioning of the IMRC actuator – but a workable EQUATION was elusive – because I did not understand the data representation. The OBDII system has a ‘separate’ indicator for PCM’s OPEN and CLOSED command [PID/Mode 221103, bit(A:4)] This bit indicates ECU commands IMRC ‘OPEN’ (1) , or ‘CLOSED’ (0).

I noted that Byte ‘A’ of IMRC MONITOR generally operates in binary negative territory while the valve is commanded closed or closing and generally zero when the valve is open.

I noted that Byte ‘B’ of IMRC MONITOR generally operates in binary positive territory when the valve is commanded open or opening – BUT always Hex 80 ( negative zero ????) when the valve is closed.

I decided that it might be the two bytes should be “TWO’s Complement” sum instead of the usual A*256+B formulation.

I created a formula for TWO’s Compliment Addition of response Bytes ‘A’ and’B’ – and everything immediately fell perfectly in line without confusing or erroneous results. The two’s compliment sum produces results ranging from -128 to +127 in equal incremental steps. Fully closed is -128. Fully open is 127. All responses fall within those boundaries.

For a 90º open gauge reading ZERO when closed, and 90º when open.

—- EDIT 11/18/2018 I found the formula worked better treating the range as 0-100% instead of 0-90 degrees and simplified the formula.

Mode/Pid 221634
Int(50.4+((100/255)*(Signed(A)+Signed(B))))

————–
I have found that many sensors – even across different manufacturers – use common formulas. I thought this discovery might be useful to someone if you are having trouble finding a proper formula for some sensor.

Pages: [1]
WP-Forum by: Fredrik Fahlstad, Version: 2.4
Page loaded in: 0.128 seconds.

  Follow me on twitter