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

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

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

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

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?

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

Beta version 1.8.190

which also has the Lookup function.

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

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