> > Sounds like classic IRQ conflicts. Did people try different base addresses
> > and IRQ lines? We have no reports of anything beyond normal configuration
> > problems elsewhere.
>
> I believe that this was tried but I'll pass on the suggestion. If there
> was IRQ conflict why would the card work at all?
An IRQ conflict can do anything from absolutely nothing to garbling data to
locking up your machine.
> Stan
>
>
> ----------------------------------------------------------------------
> Stan Bischof Hewlett Packard Company 707-577-3994 stanb@sr.hp.com
> ----------------------------------------------------------------------
>
From: Greg Goebel <gvg@hpislsup.lvld.hp.com>
Subject: Re: Re[4]: HPIB on Gateway
To: stanb@hpnmrsb2.sr.hp.com (Stan Bischof)
Date: Sun, 25 May 97 9:50:28 MDT
> > Sounds like classic IRQ conflicts. Did people try different base addresses
> > and IRQ lines? We have no reports of anything beyond normal configuration
> > problems elsewhere.
>
> I believe that this was tried but I'll pass on the suggestion. If there
> was IRQ conflict why would the card work at all?
An IRQ conflict can do anything from absolutely nothing to garbling data to
locking up your machine.
> Stan
>
>
> ----------------------------------------------------------------------
> Stan Bischof Hewlett Packard Company 707-577-3994 stanb@sr.hp.com
> ----------------------------------------------------------------------
>
From: Greg Goebel <gvg@hpislsup.lvld.hp.com>
Subject: Re: Re[6]: HPIB on Gateway
To: stanb@hpnmrsb2.sr.hp.com (Stan Bischof)
Date: Sun, 25 May 97 9:58:50 MDT
> >
> > An IRQ conflict can do anything from absolutely nothing to garbling data to
> > locking up your machine.
>
> ahh.
>
> Sounds like it could indeed be the culprit.
>
> thanks for the feedback. Will let you know if anything helps.
I'll be out most of the week. Good luck.
> Stan
> ----------------------------------------------------------------------
> Stan Bischof Hewlett Packard Company 707-577-3994 stanb@sr.hp.com
> ----------------------------------------------------------------------
> > and IRQ lines? We have no reports of anything beyond normal configuration
> > problems elsewhere.
>
> I believe that this was tried but I'll pass on the suggestion. If there
> was IRQ conflict why would the card work at all?
An IRQ conflict can do anything from absolutely nothing to garbling data to
locking up your machine.
> Stan
>
>
> ----------------------------------------------------------------------
> Stan Bischof Hewlett Packard Company 707-577-3994 stanb@sr.hp.com
> ----------------------------------------------------------------------
>
From: Greg Goebel <gvg@hpislsup.lvld.hp.com>
Subject: Re: Re[4]: HPIB on Gateway
To: stanb@hpnmrsb2.sr.hp.com (Stan Bischof)
Date: Sun, 25 May 97 9:50:28 MDT
> > Sounds like classic IRQ conflicts. Did people try different base addresses
> > and IRQ lines? We have no reports of anything beyond normal configuration
> > problems elsewhere.
>
> I believe that this was tried but I'll pass on the suggestion. If there
> was IRQ conflict why would the card work at all?
An IRQ conflict can do anything from absolutely nothing to garbling data to
locking up your machine.
> Stan
>
>
> ----------------------------------------------------------------------
> Stan Bischof Hewlett Packard Company 707-577-3994 stanb@sr.hp.com
> ----------------------------------------------------------------------
>
From: Greg Goebel <gvg@hpislsup.lvld.hp.com>
Subject: Re: Re[6]: HPIB on Gateway
To: stanb@hpnmrsb2.sr.hp.com (Stan Bischof)
Date: Sun, 25 May 97 9:58:50 MDT
> >
> > An IRQ conflict can do anything from absolutely nothing to garbling data to
> > locking up your machine.
>
> ahh.
>
> Sounds like it could indeed be the culprit.
>
> thanks for the feedback. Will let you know if anything helps.
I'll be out most of the week. Good luck.
> Stan
> ----------------------------------------------------------------------
> Stan Bischof Hewlett Packard Company 707-577-3994 stanb@sr.hp.com
> ----------------------------------------------------------------------
from: Greg Goebel / HP-MXD
gvg@lvld.hp.com / 970-679-3030 / FAX 970-679-5971
to: Tom Sanders
date: Wednesday, 21 May 1997 1624 MDT
> That's true, but the userfunction's window is beneath the popup panel making
> it difficult to see. However after some more testing I have found that this
> works if the RUN button is pressed. In the past we always used multiple
> start objects instead of pressing RUN so that no CPU cycles were used when
> VEE was idle. Now that the confirm button is event driven this is no longer
> necessary.
My tests show the popup panel for the UserFunction to remain on top no matter
what I do. Do you have an example that shows what is happening here?
> I can get replace to work under some conditions but not others. For example
> replacing a UF with another UF works, as well as replacing a formula with a
> UF and vice versa. However replacing a formula with another formula or a
> formula with a user object doesn't.
Seems to work fine here ... do you have an example?
> Again this [execution window] only works when the RUN button is pressed not
> when a Start object is pressed.
Interesting ... I talked to the lab and they say that is because you are only
running a single thread, not an entire program -- if you had multiple threads
they might not all be running.
> It seems that the stack only works when the run button is pressed. If a
> Start object is used the stack always says "Stack Information Unavailable"
The problem here is that VEE has no way of knowing what level the Start
button was executed at or at what level to start tracing (since you can have
them at lower levels of UserFunctions and the like). The lab tends to regard
Start buttons as loose cannons and wants to tie them down.
> Most of the problems I have been having with VEE 4.0 go away when RUN is used
> instead of using Start buttons. This was not obvious to me from reading any
> of the documentation. Overall I would rate VEE 4.0 as a MAJOR improvement
> over previous versions and am quite happy with it. Keep up the good work.
> Now that I understand that pressing run has many desirable advantages in VEE
> 4.0 I converted several programs to use confirm buttons instead of start
> buttons so I could press run. In general this works well. The problem
> remains however that if I am debugging a problem and want to start at a lower
> level I must press a Start button within a user function. Once I do this I
> now have the problem that I lose the Call Stack and user functions are behind
> panels when editting. It sure would be nice if behavior was the same for
> each method of starting execution.
Likely not ... the new scheme tends to deemphasize Start buttons. I sense a
strong inclination on the part of the lab to discourage their use.
If you have more questions, let us know.
[<>] regards -- gvg