Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » 4DIAC - Framework for Distributed Industrial Automation and Control » Bug: LINT_TO_TIME, ULINT_TO_TIME, Signed Data Down Counters(64bit data type handling and need for signed counters)
icon5.gif  Bug: LINT_TO_TIME, ULINT_TO_TIME, Signed Data Down Counters [message #1754959] Fri, 24 February 2017 14:38 Go to next message
yuvaraj velumani is currently offline yuvaraj velumaniFriend
Messages: 15
Registered: April 2016
Junior Member
Hi,
I was trying to test some of the function blocks and noticed few of them are really not working as per their functional requirement states.

For example:
1) F_SINT_TO_TIME, F_INT_TO_TIME, F_DINT_TO_TIME, F_LINT_TO_TIME:
As these are used to convert a signed data variable to TIME data type, what is the real use case in converting negative value to TIME?

2) F_ULINT_TO_TIME:
Since it is converting 8 byte to TIME and the maximum OUT value which I receive is T#922372036000ms. But the maximum 8 byte data range is actually from 0 to 18,446,744,073,709,551,615 and shouldn't be the OUT range from T#0ms to T#18446744073709551615ms.

3) signed data down counters:
The Q output turns TRUE when CV become less than or equal to zero. So for all negative ranges the output remains TRUE. What is the purpose of having signed down counters? Shouldn't it be counting till its minimum value and then make Q output TRUE?

Re: Bug: LINT_TO_TIME, ULINT_TO_TIME, Signed Data Down Counters [message #1754961 is a reply to message #1754959] Fri, 24 February 2017 15:48 Go to previous messageGo to next message
Alois Zoitl is currently offline Alois ZoitlFriend
Messages: 1585
Registered: January 2014
Senior Member

Hi,

this is the defined behaviour according to IEC 61131-3. TIME is there defined as time duration. As something can happen before something else also negative time durations are possible. As we are currently storing the time duration values in 64Bit only a little bit more then +-9*10^18 are the max and min values. As we are storing internally typically µs or ns depending on the configuration of your FORTE this value goes even further down.

I hope this helps.
Re: Bug: LINT_TO_TIME, ULINT_TO_TIME, Signed Data Down Counters [message #1754981 is a reply to message #1754961] Fri, 24 February 2017 20:09 Go to previous messageGo to next message
yuvaraj velumani is currently offline yuvaraj velumaniFriend
Messages: 15
Registered: April 2016
Junior Member
Thanks,

What will be performance of E_DELAY, E_CYCLE function blocks if I provide those negative TIME values?
Re: Bug: LINT_TO_TIME, ULINT_TO_TIME, Signed Data Down Counters [message #1755017 is a reply to message #1754981] Sun, 26 February 2017 21:17 Go to previous message
Kirill Dorofeev is currently offline Kirill DorofeevFriend
Messages: 70
Registered: February 2016
Member
Since E_CYCLE is defined as event appeared after time you specified in DT input, if you provide there a negative value, I would expect 0 at EO. Negative DT means something to happen before your input events and nothing after.
Something similar for E_DELAY. Negative time will mean you wanna have your output event to appear before input. That will mean that this function block should somehow predict when the input will come and switch the output x time before that Smile
Haven't tried that though, but I would expect 0/0 at the EO of both blocks if you provide negative time as an input.
Previous Topic:paho mqtt on wago?
Next Topic:FORTE: OSCAT library
Goto Forum:
  


Current Time: Sat Apr 27 03:32:34 GMT 2024

Powered by FUDForum. Page generated in 0.03499 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top