Emerson Exchange 365

In reply to DBacker:

Could it be that it only uses the first 8bits? Either way wider data type is always bad to convert to lower width.

In reply to Lun.Raznik:

If it simply masked the first 8 bits, there would be many numbers for each valid integer. and Masking bits would not work if the value was a floating point. And you are right that forcing a "wider data type" into a lower width can result in error.

As Denis points out, a Discrete data type has 255 valid choices. If you passed this parameter a value other than one of these, which value would the system assume? It's clear for boolean as only 0 is False. but should 1000 be read as 255? DeltaV has chosen to flag that as a transfer error.

It is always best to have your configuration aligned in terms of datatypes. In expressions, were an OUTx value will be a Float, you can explicitly force the value to your desired discrete value if the calculation goes out of bounds (if OUT1 > 255 then OUT1:= 255 endif), and 255 is your "Oops I did it again" result.

Andre Dicaire

In reply to Andre Dicaire:

This is a good point Andre : [but should 1000 be read as 255? DeltaV has chosen to flag that as a transfer error.]
The status is what I like at DeltaV and miss in PLC unless you program an own library with a struct of .CV/.ST as new datatype
On the other hand have to ask why have to write a bigger value into a smaller one, especially if the desired result shall be used as true or false.
If I store a value in an OUTx of a calc block , maybe due to usage as a critical value, I always build an expression like
OUTx := ( value > 0); DeltaV evaluate the expression with a result of boolean and convert this to float to 0 or 1.

BR Michael

In reply to Andre Dicaire:

Andre,
think you misunderstood me. I also don't want go back to Provox FST. I cut my teeth too, if I have to go through a Siemens PLC code.
DeltV is fine with some extras you need to deal with.
What I meant was that in Provox we had i.e. with the FST User Pocket Book (still have it ;-D ) very detailed information of every bit in a function including the execution time. I did some test with the load estimator program and was even surprised how different controller execute FB
But to do a SW fine tuning to reduce controller load on functionalities i.e. composite, there is no other way than experience and try and error what will be better at the end - FB-Logic, Calc-Expression or even a state machine as SFC. Depending on the logic it can be ether.
It where good to get more internal information how to write efficient expressions.
One is that forum here where I still learn sometimes new things by accident.
Another example, what I learned from another Austin Expert, is that the Integrator OUT shall be meanwhile a double precision (64Bit) but can't use it further due to the single precision limitation of the float type.
BR Michael

In reply to Michael Krispin:

If you do this in C++ (using unsigned char 8-bit byte), assigning 1000 to it would result to 232. 1000 base 10, is equivalent to 1111101000 base 2, but the assignment will get 11101000 base 2 or 232 base 10.

If you ask me, I would rather get a transfer error rather than silently getting 232.

In reply to Lun.Raznik:

I think during conversion DeltaV just simply put a mask of the target type of 8, 16, 32 Bit and cut therefore the higher numbers .
One question I hear very often is what is the difference of ( x <> y ) and ( x != y ) which one is more efficient in execution? I don't know.
It were good to know when exactly a possible type conversion happen ether to get the right result. Especially with the view of lost values during masking.
BR Michael

In reply to Lun.Raznik:

Confirm with the status transfer error. It is highlighted further to BAD_ACTIVE and shows very clear, the failure was done in front of the keyboard.
If you execute the same example with i.e. 257, you might take long time to find the reason due to the discrete value result = 1.
C++ is the most dirty language which provoke many mistakes like your conversion example due to the freedom in C++.
I just dig it out again for my new Arduino controllers. :-(
It is not always clever to do some because you can do.
BR Michael

In reply to Michael Krispin:

(Un)Fortunately DeltaV is implemented using C/C++, at least in this area from what I can see. I am actually pretty impressed that DeltaV flags overflow condition.

In reply to Michael Krispin:

Wait til you start playing with Live and find cases that in Java/Typescript where coders use = instead of == for a condition check and the logic actually will do the assignment as part of the condition. Its a legal statement because it checks if the write was successful so there is no warning or error! This happens a lot with the new interface/coders not use to syntax and sometimes very hard to find this depending on what is being written.

At one time I had 2 Provox FST handbooks! I was nice and passed one along (didn't get any money for it either and probably should have ) to someone as these are golden (especially with notes written in them as well!)

The != and <> should be exactly the same and you can tell by parsing expression and comparing the number of bytes used. This is also a way to learn about execution speed. I have seen a lot of code that is: If this, then a=x else do a=y which can be written as a := (this) ? x : y; which is actually executes faster (less bytes). I have also see the same logic with x being True and y being False which can just be a := (this); which is faster as well. Also seen a lot of FB configurations that will actually run faster in an Action block because you can nest the configuration and not execute "function block" logic if it isn't required. Another item is an ACT is less loading than CALC block because it doesn't support INs and OUTs and have the logic associated with reading to the internal variables when starting and writing the outputs when ending. Action blocks can also be turned off so they are not running decreasing the load on the controllers when not needed. Reading parameters multiple times takes time where if you read once and put in an internal variable this will also decrease the load as reading memory is faster than actually going and finding the value over and over again. So I think you have to design/implement based on requirements but there isn't anything really documented on the loading/execution speed unfortunately. Just have to "learn" these with testing to "sharpening the pencil" of configuration for good efficient running logic.

In reply to Matt Stoner:

Can't deny the value of the FST Handbook. It filled a void in documentation for Provox. I received my copy from one of the authors, ( Mike Reilly?) when I worked with him in Gold River BC prior to Emerson acquisition. They developed it and eventually Fisher/Emerson adopted it. Can some one post the names of the authors?

I'd say that other than experience, a forum like this one is the only way users can learn advanced information about DeltaV. KBA's are important but deal mainly with product and not application. White papers are useful but tend to avoid implementation details. This and Emerson Users Group.

Or was it Mike O'Reilly?

Andre Dicaire

In reply to Andre Dicaire:

So what about a presentation for the "virtual exchange" like "Everything you always wanted to know about module configuration (and coding) but were afraid to ask". You could fill a few slides just with the morsels in this thread . . .

In reply to Andre Dicaire:

I still use my Blue copy of the FST User Pocketbook often. The authors listed are Mike O'Leary and Steve Wolfe. With a special thanks to Greg Zabrecky. I'm still waiting for the day that Provox is history.

In reply to dewightrea:

Come on Provox is modern Does anyone remember dc2 the predecessor to Provox? I can still write FST's in my sleep especially on the continuous controllers when you had to fit everything into 250 steps by using loadable functions

Ed Smigo

In reply to dewightrea:

Thank you sir. Just thought we should throw some credit toward these guys for giving us a valuable tool that we still appreciate 30 years later.

Andre Dicaire

In reply to Andre Dicaire:

The Authors were Mike O'Leary and Steve Wolfe