Emerson Exchange 365

Hi,
only a Boolean is a boolean with only two states, True and False.
In programming languages, it is common that 0 is seen as false and any other value is true.
Discrete is a unsigned byte with status (which is btw a very powerful addition in DeltaV for my oppinuon).
I use the discrete type at an ACTION/IN_D not only to enable , disable that action, but also as step counter if I program a mini sequence or just different options of code inside the action.
Interesting is that the logic blocks of AND/OR etc use also discrete instead of real boolean type. I never tried out what happen if IN_D1 = 2 and IN_D2=3 what is the result at OUT_D as value. But both will evaluate as true and OUT_D will be any other than zero.
Same as discrete, you can convert any other numeric type in the same way into a boolean meaning.
I think , the expression of a boolean in any of Calc/Act/Cnd Block evaluate in opposite into a floating number equation.
That maybe Andre Dicaire or Matt Stone know more about, if they read it here
Best Regards,
Michael

I think you answered your question with the BOL explanation.

A Boolean can be True (1) or False (0).
A Discrete can be viewed as true or false, but normally a numerical value.

While the numerical value of a Boolean can be 0 or 1 only, the numerical value of a discrete can be 0, 1,2, 3, ...255 (not just 0 or 1).

In reply to Michael Krispin:

Hmm. Not sure what you are asking.

DeltaV will coerce the value to match the required type if it can. Bitwise Operators allow you to work with integers and extract bit values, shift and combine the integers without converting integers to floats.

The biggest problem with Floating point numbers is when one writes if (x+y) = z then... . The expression might skip Z as a valid answer. As "x" gest bigger, its Log portion gets bigger, which decreases the precision of the number. When you add "y", the number is expessed in the same logarithm range as the larger number and the reduced precision affects the result. For more robust code, check Floating point values for a limit threshold, or a range.

To preserve data type, store an integer into a module parameter especially a 32 bit float as this number exceeds the resolution of the float mantissa. If you store it in OUT1 or an internal register, it converts to a Float. Say you want to combine two 16 bit integers into a 32 bit integer. use one line to read both values, shifting one 16 positions to the left with a bitwise OR and write this to a 32 bit integer parameter:
'^/32BIT_VALUE.CV' := SHL('^/MSB_16BIT.CV', 16) | '^/LSB_16BIT.CV'

If you stored this result in OUT1 or an internal variable, it would convert to Float and would not be equal to "32BIT_VALUE.CV"

One last thing. The value in the above 32 bit parameter will not be available to the expression until the next scan of the module. Output writes from an expression occur at the end of the expression, and are available for any subsequent function block during that scan, and to the rest of the controller/system. If you need to work with intermediate values stored in parameters, split the work into two Calc blocks with the first one conditioning the data and the second one using it. Otherwise, your result is delayed by a module scan.

Andre Dicaire

In reply to Andre Dicaire:

Andre,
you are right in general with the floating point comparison, due to the rounding problem.
What I meant was that in expressions a boolean parameter might also be changed to a float into a comparison, due to that expression, what I learned up to know, always calculate in float. But this might become a bit too abstract for the initial question.
The main point is that a 0/zero is presented as false and any other value becomes true.
If I assign a value of 0.4 to a discrete Variable, the algorithm will round it to zero. Right now , I don't have a system online but I think if you do the same to a boolean parameter it will also be 0 - false.
So, the values will be transferred into the best possible equation from one data type to another.
I'm not sad about to have a discrete type of an ACT/IN_D but wonder why that is also for i.e. AND/OR/SR etc.
I struggled since beginning of DeltaV with things like that, understand the origin question from sNosman well, but meanwhile after 25Years ;-) learned how to handle in a good way.

In reply to Andre Dicaire:

Sorry clicked too early
Finally my question was is it right that expression convert to float or - as your example with SHL() shows - will be an expression keep the data type as long as it can and only at assignment it convert into the target datatype?
In C++ and also some PLC structure language according IEC61131-3 can find an explicit type converting by leading an (float) or (word) or (bool) phrase in front of an expression . DeltaV do those things however in the background

In reply to Michael Krispin:

My understanding is that data conversion happens when it needs to. In the example I gave, nothing converts to Float. On the Assignment to a parameter, the value will be coerced to match the destination. I mean the expression would fail if the 16 bit values were forced into a Float and then back to a 32 bit integer. What you learn is that programs don't necessarily do what you want, they do what you program. Sometimes we have to take time to understand some nuances to know how to get what we want. Looks like you've done that.

Andre Dicaire

In reply to Andre Dicaire:

I appreciate the feedback on this, you guys go the extra mile. If I have a 2 input AND gate, both its inputs are Discrete type, while its output is Discrete. I've always treated AND gates as purely Boolean. I understand any integer input in the range of 0-255 is valid, where 0=False and 1-255 is True. I suppose there's maybe a scenario where processing individual bits from a register, you will have exact integer values, hence using it as a discrete input as long as its in the range of 0-255. DeltaV allows for unlike parameter types to be connected, a new concept for me, I've been used to converting data types on other PLC's/DCS's I've worked on.

In reply to SNosnam:

Just to add that this is not specific to DeltaV. FFBus foundation uses similar concepts.

OPC UA uses Boolean as Byte - reference.opcfoundation.org/.../

In reply to Lun.Raznik:

I can only find FFBus documentation from NI - www.ni.com/.../371994g.pdf, see page 6-42 for data types used in FFBus. Boolean is defined as FFBOOLEAN (8bits).

In reply to Lun.Raznik:

That's a great point Lun. DeltaV was modeled after FF, in terms of following signal types, function blocks and most of all Status byte on every parameter. The decision to use Discrete versus Boolean on "discrete" logic was born out of the standards that guided FF.

Andre Dicaire

In reply to Andre Dicaire:

Thanks Andre.
I came from Provox and miss sometimes the clarity of assembler programming an FST which I had in Provox, also in DeltaV even after roughly 25years Deltav :-D
Therefore I ask sometimes a bit deeper to dig out the secrets of DeltaV expression evaluation. It is officially not published like here in such forum.

In reply to Michael Krispin:

I agree. The simplicity of a PROVOX FST is still my preference.

In reply to jwherwig:

I cut my teeth on Provox FST's, Computing controllers and IFC's. I don't really miss it. I don't agree that it was simpler. What is simple about doing a polynomial calculation by passing values through the accumulator multiple times in the right order to execute a simple expression?

And we can create multiple simple expressions each in their own CALC block rather than a monolithic FST, since you did not want to use up your point count on LCP's.

I would never go back to that level of programming. I think FST's were simpler because we avoided tackling problems we address today. But at the time, they were very enabling.

Andre Dicaire

In reply to Michael Moody:

As Michael stated, the DISCRETE can be wired from an integer from 0 to 255. This very important.

From my experience, if you pass an integer > 255 into the IN_D of most function blocks, it DOES NOT ALWAYS resolve as TRUE. Therefore, if you want to pass an integer to IN_D of a function block, you need to make sure it is no greater than 255.