AnsweredAssumed Answered

vrf AW: Strange Formula Call Behaviour

Question asked by VRFuser on Nov 17, 2002

Like • Show 0 Likes0
Comment • 2

Yes, I see. I probably had to spend a little more time for that...
According to Ralfs mail about stopping formula calls the only way is to use
a call object and build the function name with a formula- or a to string
object in advance, if necessary.

Hartmut

> -----Ursprngliche Nachricht-----
> Von: Paul.Fowler@raytheon.co.uk [mailto:Paul.Fowler@raytheon.co.uk]
> Gesendet: Freitag, 15. November 2002 14:40
> An: Hartmut.Gohdes@rfsworld.com
> Cc: vrf@it.lists.it.agilent.com
> Betreff: Re: AW: [vrf] Strange Formula Call Behaviour
>
>
>
>
> That still doesn't work for me, Hartmut........
>
> Anyway, my problem is that I have no control over the coding of the
> functions that I call, as they are test functions written
> over the last
> couple of years by various miscreants and malcontents who
> have long since
> crawled back under their respective rocks........
>
> Paul
>
>
>
>
>
>
>
>
>
>                     Hartmut.Gohdes@rfswor   To:
> Paul.Fowler@raytheon.co.uk, vrf@it.lists.it.agilent.com
>                     ld.com                  cc:
>
>                               15/11/02      Subject: AW:
> [vrf] Strange Formula Call Behaviour
>           13:21
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Hello Paul,
> did you want this behaviour?
> It was a problem of the OK-Button.
>
> Hartmut
>
> > -----Ursprngliche Nachricht-----
> > Von: Paul.Fowler@raytheon.co.uk [mailto:Paul.Fowler@raytheon.co.uk]
> > Gesendet: Freitag, 15. November 2002 13:45
> > An: VEE vrf
> > Betreff: [vrf] Strange Formula Call Behaviour
> >
> >
> > VEE Gurus.........
> >
> > Please help me out with the attatched, it's driving me nuts.
> >
> > Thanks
> >
> > Paul F.
> >
> >
> > (See attached file: Abort_Problem.vee)
> >
>
> (See attached file: Abort_Problem.vee)
>
>

---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@it.lists.it.agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".

No one else has this question

Outcomes

paul.fowler Nov 14, 2002 9:40 PM

That sounds likely, Bob......

Does anyone know a way round it, or any other way I can kill a function
from "outside" ??

Paul F.

                    Wirth_Robert@emc.com    To: Paul.Fowler@raytheon.co.uk
                              15/11/02      cc:
          13:28                             Subject: RE: [vrf] Strange Formula Call Behaviour

I think its because the UserFunction will not timeslice if the call is
pass to a formula object via the control pin. The Call function will
timeslice.
I use this "feature" to control some of my critical sections of code,
to ensure other threads stop running while i'm doing some timing tests,
etc.

This is buried in the Advanced Vee Techniques manual in chapter 11.

Bob W.

> -----Original Message-----
> From:         Paul.Fowler@raytheon.co.uk
[SMTP:Paul.Fowler@raytheon.co.uk]
> Sent:         Friday, November 15, 2002 7:45 AM
> To:           VEE vrf
> Subject:           [vrf] Strange Formula Call Behaviour
>
> VEE Gurus.........
>
> Please help me out with the attatched, it's driving me nuts.
>
> Thanks
>
> Paul F.
>
>
> (See attached file: Abort_Problem.vee) << File: Abort_Problem.vee >> <<
> File: footer >>

---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@it.lists.it.agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".

Actions

VRFuser Nov 14, 2002 10:21 PM

Hello Hartmut,

Some months ago i've made the same experience with aborting formula calls. Here
the answer of Scott Bayes

Hope it helps to understand the difference.

Regards
Ralf

A very interesting question, and deeper than it appears on the surface!

I had a closely related support question a couple of months ago, and wrote
the following up in response. The upshot is that this is "expected"
operation (i.e. not a bug) no matter how UNexpected it may be when you first
encounter it. Wish we could do better, but solving this is an extremely deep
question that may not be even theoretically achievable (Church and Turing,
and Goedel, might have had something to say on the matter :-)

BTW, I got a note from R&D after they saw the posting. The "mental
maundering" was a reasonable interpretation and got a passing grade.

---

Hi xxxxx!

Some fairly deep magic here, but VEE is operating as expected according to
R&D, and I agree with them.

Breaking it up into pieces so it's easier to handle:

- VEE nowadays compiles programs (in most cases), and runs the compiled
code, rather than interpreting and reinterpreting the code as it used to in
pre-compiler days. It compiles as much of the program as it can, and leaves
the indigestible rest to the old interpretation mechanism. There is some
kind of thread scheduler that allows compiled threads and subthreads to
execute in parallel.

- for CALL boxes, VEE knows it is going to do a CALL of some type: a VEE
User Function, a Remote VEE function, or a DLL. It even knows which of the
above kinds of CALL it will be. So the only missing pieces are any
parameters on the input pins, and the particular Function Name that will
appear on the Control pin (in examples 2 and 4 that the customer sent). No
problem, this is a regular compile job, and VEE can interleave thread
execution because it is compiled code.

- for Formula boxes with the formula as a "literal" typed by the programmer
into the Formula box (example 3), VEE can precompile the formula, and feed
it any inputs from pins at runtime. No problem, it gets compiled and VEE can
interleave thread execution.

- for Formula boxes with the formula as a Control input (example 4), VEE has
no idea at compile time what the formula will look like when the code is
run. It might be typed in at runtime as text by a user, or glued together
from substrings like a ransom note! So VEE can't precompile it. Therefore,
at run-time, it will have to fall back to the old interpretation mechanism.

- the above came from R&D. This next part is my own mental maundering: VEE 6
has managed to glue the compiled and interpreted parts of the customer's
program together so they work together pretty smoothly and transparently.
This is an interesting magic trick in itself (IMHO as a sometime R&D
engineer). But one of the side effects of the magic is that VEE is now
confronted with not being able to use the compiled-code thread scheduler
during interpreted execution of the Formula in example 4. The interpreter
mechanism/source-code just doesn't have the "hooks" needed to interact with
the compiled-code thread scheduler. It's that thread scheduler that keeps
VEE's internal universe consistent and up-to-date as thread execution is
interleaved. So VEE has to make the interpretation of the formula an
"atomic" operation. Until this atomic operation completes, other VEE threads
have to wait, in case the interpreted thread causes any side effects or
other funkiness that they need to be concerned about. In classic computing
terminology, the other threads "block" till the interpreted thread completes
execution. As I say, this reasoning is guesswork, but I believe it's pretty
close to the mark.

So the upshot: a Formula box with the formula on a Control input has to
complete execution before other threads can continue: no interleaving. A
Call box with the function name on the Control input doesn't have this
limitation and can interleave.

I hope this helps the customer understand the limitation on interpreted
formulas. As to how to deal with the limitation, that will depend intimately
on the customer's application needs, and would be a consulting job, not a
Tech Support one.

Best Regards,

Scott Bayes

---

Scott Bayes
Software Technical Support

Agilent Technologies, Inc.
815 14th Street S.W.
Loveland, CO, U.S.A. 80537

970 679 3799 Tel
970 635 6867 Fax

> -----Original Message-----
> From: ralf.eichele@smart-gmbh.de [mailto:ralf.eichele@smart-gmbh.de]
> Sent: Wednesday, March 13, 2002 1:12 AM
> To: VEE Reflector
> Subject: vrf VRF: Stop fomula calls
>
>
> SMART Electronic Development GmbH - Germany
>
> Von: Ralf Eichele@SMART GMBH am 13.03.2002 09:12
>
>
> An: VEE Reflector <vrf@lvld.agilent.com>
> Kopie:
> Thema: VRF: Stop fomula calls
>
> Hello all,
>
> I've got problems with aborting fomula calls. When I abort a
> formula call it
> works only when i entry the function name directly in the
> Formula. When I entry
> the name of the function over a formula input pin, i can not
> stop this function.
> Look in the example. Is it a bug or feature and why the
> difference (same
> behavior in VEE 5 and VEE 6? Any solutions how to solve the problem?
>
> (See attached file: RestartLoop.vee)
>
> Greetings
>
> Ralf Eichele
>
---------------------------------------------------------------------
This is the "vrf" maillist, managed by Majordomo. To send messages to
this maillist, just email to "vrf@lvld.agilent.com". Subscriptions and
unsubscriptions are done through the address "vrf-request@lvld.agilent.com".
If you need details, just send a message containing the text "help"
to "vrf-request@lvld.agilent.com".
---------------------------------------------------------------------

---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@it.lists.it.agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".

Actions

2 Replies

paul.fowler Nov 14, 2002 9:40 PM
Mark Correct
Correct Answer

That sounds likely, Bob......

Does anyone know a way round it, or any other way I can kill a function
from "outside" ??

Paul F.

                    Wirth_Robert@emc.com    To: Paul.Fowler@raytheon.co.uk
                              15/11/02      cc:
          13:28                             Subject: RE: [vrf] Strange Formula Call Behaviour

I think its because the UserFunction will not timeslice if the call is
pass to a formula object via the control pin. The Call function will
timeslice.
I use this "feature" to control some of my critical sections of code,
to ensure other threads stop running while i'm doing some timing tests,
etc.

This is buried in the Advanced Vee Techniques manual in chapter 11.

Bob W.

> -----Original Message-----
> From:         Paul.Fowler@raytheon.co.uk
[SMTP:Paul.Fowler@raytheon.co.uk]
> Sent:         Friday, November 15, 2002 7:45 AM
> To:           VEE vrf
> Subject:           [vrf] Strange Formula Call Behaviour
>
> VEE Gurus.........
>
> Please help me out with the attatched, it's driving me nuts.
>
> Thanks
>
> Paul F.
>
>
> (See attached file: Abort_Problem.vee) << File: Abort_Problem.vee >> <<
> File: footer >>

---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@it.lists.it.agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".
Like • Show 0 Likes0
Actions
VRFuser Nov 14, 2002 10:21 PM
Mark Correct
Correct Answer
Hello Hartmut,

Some months ago i've made the same experience with aborting formula calls. Here
the answer of Scott Bayes

Hope it helps to understand the difference.

Regards
Ralf

A very interesting question, and deeper than it appears on the surface!

I had a closely related support question a couple of months ago, and wrote
the following up in response. The upshot is that this is "expected"
operation (i.e. not a bug) no matter how UNexpected it may be when you first
encounter it. Wish we could do better, but solving this is an extremely deep
question that may not be even theoretically achievable (Church and Turing,
and Goedel, might have had something to say on the matter

BTW, I got a note from R&D after they saw the posting. The "mental
maundering" was a reasonable interpretation and got a passing grade.

---

Hi xxxxx!

Some fairly deep magic here, but VEE is operating as expected according to
R&D, and I agree with them.

Breaking it up into pieces so it's easier to handle:

- VEE nowadays compiles programs (in most cases), and runs the compiled
code, rather than interpreting and reinterpreting the code as it used to in
pre-compiler days. It compiles as much of the program as it can, and leaves
the indigestible rest to the old interpretation mechanism. There is some
kind of thread scheduler that allows compiled threads and subthreads to
execute in parallel.

- for CALL boxes, VEE knows it is going to do a CALL of some type: a VEE
User Function, a Remote VEE function, or a DLL. It even knows which of the
above kinds of CALL it will be. So the only missing pieces are any
parameters on the input pins, and the particular Function Name that will
appear on the Control pin (in examples 2 and 4 that the customer sent). No
problem, this is a regular compile job, and VEE can interleave thread
execution because it is compiled code.

- for Formula boxes with the formula as a "literal" typed by the programmer
into the Formula box (example 3), VEE can precompile the formula, and feed
it any inputs from pins at runtime. No problem, it gets compiled and VEE can
interleave thread execution.

- for Formula boxes with the formula as a Control input (example 4), VEE has
no idea at compile time what the formula will look like when the code is
run. It might be typed in at runtime as text by a user, or glued together
from substrings like a ransom note! So VEE can't precompile it. Therefore,
at run-time, it will have to fall back to the old interpretation mechanism.

- the above came from R&D. This next part is my own mental maundering: VEE 6
has managed to glue the compiled and interpreted parts of the customer's
program together so they work together pretty smoothly and transparently.
This is an interesting magic trick in itself (IMHO as a sometime R&D
engineer). But one of the side effects of the magic is that VEE is now
confronted with not being able to use the compiled-code thread scheduler
during interpreted execution of the Formula in example 4. The interpreter
mechanism/source-code just doesn't have the "hooks" needed to interact with
the compiled-code thread scheduler. It's that thread scheduler that keeps
VEE's internal universe consistent and up-to-date as thread execution is
interleaved. So VEE has to make the interpretation of the formula an
"atomic" operation. Until this atomic operation completes, other VEE threads
have to wait, in case the interpreted thread causes any side effects or
other funkiness that they need to be concerned about. In classic computing
terminology, the other threads "block" till the interpreted thread completes
execution. As I say, this reasoning is guesswork, but I believe it's pretty
close to the mark.

So the upshot: a Formula box with the formula on a Control input has to
complete execution before other threads can continue: no interleaving. A
Call box with the function name on the Control input doesn't have this
limitation and can interleave.

I hope this helps the customer understand the limitation on interpreted
formulas. As to how to deal with the limitation, that will depend intimately
on the customer's application needs, and would be a consulting job, not a
Tech Support one.

Best Regards,

Scott Bayes

---

Scott Bayes
Software Technical Support

Agilent Technologies, Inc.
815 14th Street S.W.
Loveland, CO, U.S.A. 80537

970 679 3799 Tel
970 635 6867 Fax

> -----Original Message-----
> From: ralf.eichele@smart-gmbh.de [mailto:ralf.eichele@smart-gmbh.de]
> Sent: Wednesday, March 13, 2002 1:12 AM
> To: VEE Reflector
> Subject: vrf VRF: Stop fomula calls
>
>
> SMART Electronic Development GmbH - Germany
>
> Von: Ralf Eichele@SMART GMBH am 13.03.2002 09:12
>
>
> An: VEE Reflector <vrf@lvld.agilent.com>
> Kopie:
> Thema: VRF: Stop fomula calls
>
> Hello all,
>
> I've got problems with aborting fomula calls. When I abort a
> formula call it
> works only when i entry the function name directly in the
> Formula. When I entry
> the name of the function over a formula input pin, i can not
> stop this function.
> Look in the example. Is it a bug or feature and why the
> difference (same
> behavior in VEE 5 and VEE 6? Any solutions how to solve the problem?
>
> (See attached file: RestartLoop.vee)
>
> Greetings
>
> Ralf Eichele
>
---------------------------------------------------------------------
This is the "vrf" maillist, managed by Majordomo. To send messages to
this maillist, just email to "vrf@lvld.agilent.com". Subscriptions and
unsubscriptions are done through the address "vrf-request@lvld.agilent.com".
If you need details, just send a message containing the text "help"
to "vrf-request@lvld.agilent.com".
---------------------------------------------------------------------

---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@it.lists.it.agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".
Like • Show 0 Likes0
Actions

vrf AW: Strange Formula Call Behaviour

Outcomes

Related Content

Recommended Content