AnsweredAssumed Answered

vrf Multi-VEE-ing capability

Question asked by VRFuser on Dec 16, 2001

Like • Show 0 Likes0
Comment • 14

Hi all.

> > The two VEE applications don't share the COM port, it's the HP I/O
> > library control that controls the com port. The two VEE applications

>There you go! Of course you're exactly right. In the end, I think the
>only 'egoistic' behaviour that VEE would have to be criticised for is
>that it somehow claims a lot of the available system performance 'just
>in case', so that whatever NON-VEE-application gets horribly slow. As

Well, then again this port was a really *huge* task to pull off. I'm not
privvy to the details, but they did produce a Windows version that does work
- nevermind my nit-picky complaints about look and feel.

If I'm right about the technique Agilent used (again, I don't know the
details so that's a big "if"), then what they did was to create an X-like
environment inside Windows to host VEE in. That is no small feat. It may go
so far as emulating some of UNIX itself. If either of these assumptions are
correct, I understand why VEE needs to grab so much.

Oh! I just thought of a *great* example: do any of you guys remember
Desq-View? For those that don't, the short story is that it was an early
pre-emptive multitasker for the PC. It used to be possible to run Real or
Standard mode Windows *inside* DV, and naturally the DV fans got a real kick
out of that. Windows would cooperatively multitask it's applications while
DV preemptively multitasked everything else you cared to run.

The point is that I *think* (meaning I don't know) that's pretty much what
Agilent has accomplished here, only in reverse. They've taken a little piece
of their HP-UX and made it work in Windows. Any way you look at it, it's one
heck of an accomplishment.
-SHAWN-

_________________________________________________________________
MSN Photos is the easiest way to share and print your photos:
http://photos.msn.com/support/worldwide.aspx

---------------------------------------------------------------------
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".
---------------------------------------------------------------------

No one else has this question

Outcomes

14 Replies

VRFuser Dec 13, 2001 11:18 PM
Mark Correct
Correct Answer
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"><HTML><HEAD><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"><META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.45"><TITLE>RE: vrf Multi-VEE-ing capability</TITLE></HEAD><BODY>Thomas,I'm quite interested in your comment about RS232 ports. We have not been able to resolve a problem with 2 applications trying to use the same Com port. While we can "Close" the port from the Vee application, there appears to be no way to reopen it after the other application (NOT VEE) releases it. I imagine it would be possible to replicat the other application in VEE, if absolutely necessary, but that would be a significant undertaking as there are a number of different combinations possible.Please advisePaul H. Rubin Staff Engineer Test Engineering Ericsson Amplifier Technologies, Inc. 49 Wireless Blvd. Hauppaugh, New York 11788 Phone: (631) 357-8513 E-Mail: paul.rubin@ericsson.com -----Original Message----- From: Thomas Vauderwange [<A HREF="mailto:Thomas@Vauderwange.de">mailto:Thomas@Vauderwange.de</A>] Sent: Friday, December 14, 2001 4:04 PM To: vrf@lvld.agilent.com Subject: vrf Multi-VEE-ing capability Hi Shawn,Indeed it is no problem at all to have several different VEE programs running on the same PC the same time. Even tricky stuff, like RS232-comms etc. My customers and the folks down in the production hall do this all the time with my software (Win98, NT4, W2K), and everybody's happy. This happened when I changed from good ol' VEE3-interpreter (where it did not work) to the one that came with VEE5. And: someone found out by coincidence by just mistakenly starting several processes. Even sharing one and the same COM-port (!!) worked without having been specified! All I had to do to make this a real feature is to specify different working directories where different config-files could be placed. And, of course, to allow for an identifier string in the left top of the temperature graph, because otehrwise nobody could tell the processes apart...Regards,ThomasShawn Fessenden schrieb:> Well thank you everybody for your comments! > > There are some real eye-openers there, especially Jens. While I strongly > disagree with VEE's affinity for "structured" code, I suspect that's simply > because we have different ideas of what structured code is but, "that's > probably a discussion more suited to a comp.programming group," (he said, > trying to stay on topic). > > On the other side of the fence, VEE's innate flowchart-like diagramatic / > execution model is definitely a godsend. In fact, whenever customers > explicitly request VEE this model is almost always the reason why. When I > first started using VEE, I just assumed customers wanted VEE because it was > an HP product. > > Anyway Jens, I found this particularly interesting: > > >2 VEE clients and the VEE-controller > >can run on the same PC or on different PCs. > > If I understand this correctly you can run *three* instances of VEE on *one* > computer? If this is the case, then my hat is off to you and I will > henceforth keep my mouth shut! > > Using NT 4.0 I've had terrible problems just keeping *one* instance going on > anything less than a PII 233! At the risk of boring everybody, let me > outline two of these problems. I really need to understand why it is I have > such awful problems and others do not. At the time, we had HP field > application engineers crawling all over what I did and their conclusion was > "It's fine, that's just the way it works". Ever since then I've been saying, > "well then it doesn't work right". > > These two problems are actually just different aspects of the same root > cause, CPU hogging: > > 1. Printing. Customer wants a simplistic graph of readings over time. Using > the Print Screen object, it took over 45 minutes to print one graph. This is > over a 100MB network. Spooler priority was set highest. I abandoned the > spooler and of course that speeded up the printing to a minute or two, but > the UI completely stops responding (of course) and that's unacceptable. I > wound up using Microsoft's DIBAPI to capture the screen myself & print it. > The catch was that this utility had to shift itself to HIGH_PRIORITY_CLASS > to produce a graph in under 5 minutes. This slowed down the UI some, but the > customer accepted the result as a necessary trade-off. > > 2. Browsing. The test scenario is a room full of some 100 UUTs. Test time > varies from 4 hours to three or four days sometimes. Data points consist of > samples of 6 channels every 30 seconds. The DAC box is an Agilent 34970, one > per UUT. Loading the test line is pretty simple. One plug for power, one for > 4 data channels. The other two channels are from sensors placed inside the > UUT by test personnel. A bar code is scanned and the test cycle begins. > > Now, the people who run the test system are union laborers, not engineers. > There are usually three people per test room. It takes all of about an hour > to get a full room under way and then they sit back and wait. It's no fun > sitting there staring at a graph or a summary of all running tests, so they > usually start playing solitare or browsing the web, looking for girly-pix. > Now granted that this isn't the ideal scenario, but realistically it's to be > expected. As soon as VEE is put in the background, problems develop. > > In the first place, after about 40 UUTs VEE starts having a hard time > keeping up with sampling data, updating 34970 displays, checking for card > swaps or entire 34970 swaps, verifying 34970 configuration, analyzing data > to decide on shifts in test phases, testing com ports for proper > communication, watchdog pinging other test computers to make sure they're > ok, etc. This is even with VEE in the bloody FOREGROUND. When it gets put in > the background, look out! > > Now I realize full well that I'm no VEE expert. Like I've said, 30 years of > programming doesn't mean a thing when it comes to VEE so we called in HP > experts for expert advice. After over half a year of tweaking and some > truely extraordinary efforts on the part of various HP engineers, the > customer was still dissatisfied and started threatening to pull out, and for > that I don't blame them. They dumped *huge* amounts of cash on hardware and > they couldn't even run at 50% capacity. > > Even then, memory leaks caused by the infamous error pins would, after only > a few days of continuous operation, cause VEE to reset it's heap (or > something) and all in-progress tests were lost. Granted, there was always a > current status backup stored on the drive, but this was updated every time > data changed on any DAC box and the moment VEE lost it's variables this file > was overwritten with emptyness. The individual data files themselves > remained, but without status information (current test phase, phase test > instructions, current machine state, state machine registers, etc.) the > state machine couldn't possibly continue. > > It was finally decided to move to a compiled language so I locked myself in > a closet for 14 weeks and re-wrote the entire thing in C++. And when I say > re-wrote, I mean exactly that. The C++ version is almost an exact duplicate > of the VEE version. VEE's failures in this instance were definitely not due > to software architecture. This application is currently buzzing happily > away, testing like crazy. There are no issues with printing graphs, playing > solitare or browsing the web. > > The *opinions* I express here are based largely on this one extraordinarily > negative experience. This was definitely the most detailed analysis I've > ever made of VEE on Windows in the wild, though I've had plenty of somewhat > negative experiences with it before. The icing on the cake was HP's own > conclusion that "yes, everything is fine. That's the way it works". Since > then I've recommended to those customers who want to use VEE that they then > should stick with HP-UX. Sometimes that's fine, and sometimes it's not > because Windows is a requirement. In that case, we use "Windows specific" > tools like Visual Basic, Visual C++, Delphi or C++ Builder. > > Now I challenge any of you to put yourself in my shoes: Put your life on > hold for 14 weeks of consecutive 16-20 hour days WITHOUT PAY, bear the whip > from management AND the customer, watch HP go over everything you've done > with a fine-tooth comb and shrug their shoulders, watch five years of your > life helping to build a company from a two-man operation to a small global > enterprise go down the drain as law suits and bankruptcy ensue and then have > anything positive at all to say about VEE. Here it is, on public record: > > IN SPITE OF ALL OF THIS I STILL LIKE VEE!!! > > So please, if anybody has anything to say to me personally about VEE bashing > then lets keep it off the list as it probably won't be productive at all and > I guarantee I'll respond to all flames with a blow-torch. > -SHAWN- > > _________________________________________________________________ > Join the world's largest e-mail service with MSN Hotmail. > <A HREF="http://www.hotmail.com" TARGET="_blank">http://www.hotmail.com</A> > > --------------------------------------------------------------------- > 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". > ------------------------------------------------------------------------------------------------------------------------------------------ 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". ---------------------------------------------------------------------</BODY></HTML>
Like • Show 0 Likes0
Actions
VRFuser Dec 13, 2001 11:53 PM
Mark Correct
Correct Answer
<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN"><HTML><HEAD><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"><META content='"MSHTML 4.72.3616.1301"' name=GENERATOR></HEAD><BODY><DIV>Thomas,</DIV><DIV> </DIV><DIV>Apparently you are only claiming that 2 _VEE_ programs can "share" a Com port. Correct? Have you ever succeeded in having VEE share a Com port with any other type application?</DIV>Paul H. Rubin Staff Engineer Test Engineering Ericsson Amplifier Technologies, Inc. 49 Wireless Blvd. Hauppauge, New York 11788 Phone: (631) 357-8513 E-Mail: paul.rubin@ericsson.com <DIV> </DIV><BLOCKQUOTE> <DIV class=OutlookMessageHeader>-----Original Message----- From: Thomas Vauderwange [mailto:Thomas@Vauderwange.de] Sent: Friday, December 14, 2001 4:35 PM To: vrf@lvld.agilent.com Subject: Re: vrf Multi-VEE-ing capability </DIV>Hi Paul, Well, found it hard to believe when I heard it. I was aware that VEE won't let the COM-port loose, once it got hold of it, so the idea to try COM-port-sharing with non-VEE-apps was abandoned. Then, that customer from over there in luvly North Carolina called one day, reporting a 'severe firmware bug' in our machine's microcontroller, as there were the two LEDs that indicate the two possible control modes of that machine blinking! In a very regular manner, the right one - the left one. As something like this was completely unheard of, I started the investigation and found out that my software, which he uses to control/monitor the machine from a PC had been started two times simultaneously on that PC. On the copy in the foreground, that customer had pushed the button that did send (via COM1) the signal to change control mode. The other instance did notice the deviation with its next data exchange and thus ordered the machine back in the other mode. Which led the copy in front of the screen to send another command... Anyway, it worked fine. Unfortunately, you need a real one of these machines to try my software out, which would otherwise be available as a free download from the company's website. But, in case you happen to need a heater-chiller circulator, then that company would be the right address. Thomas "Paul Rubin (AMT)" schrieb: <BLOCKQUOTE TYPE = CITE> Thomas, I'm quite interested in your comment about RS232 ports. We have not been able to resolve a problem with 2 applications trying to use the same Com port. While we can "Close" the port from the Vee application, there appears to be no way to reopen it after the other application (NOT VEE) releases it. I imagine it would be possible to replicat the other application in VEE, if absolutely necessary, but that would be a significant undertaking as there are a number of different combinations possible. Please advise Paul H. Rubin Staff Engineer Test Engineering Ericsson Amplifier Technologies, Inc. 49 Wireless Blvd. Hauppaugh, New York 11788 Phone: (631) 357-8513 E-Mail: paul.rubin@ericsson.com -----Original Message----- From: Thomas Vauderwange [<A href="mailto:Thomas@Vauderwange.de">mailto:Thomas@Vauderwange.de</A>] Sent: Friday, December 14, 2001 4:04 PM To: vrf@lvld.agilent.com Subject: vrf Multi-VEE-ing capability Hi Shawn, Indeed it is no problem at all to have several different VEE programs running on the same PC the same time. Even tricky stuff, like RS232-comms etc. My customers and the folks down in the production hall do this all the time with my software (Win98, NT4, W2K), and everybody's happy. This happened when I changed from good ol' VEE3-interpreter (where it did not work) to the one that came with VEE5. And: someone found out by coincidence by just mistakenly starting several processes. Even sharing one and the same COM-port (!!) worked without having been specified! All I had to do to make this a real feature is to specify different working directories where different config-files could be placed. And, of course, to allow for an identifier string in the left top of the temperature graph, because otehrwise nobody could tell the processes apart... Regards, Thomas Shawn Fessenden schrieb: > Well thank you everybody for your comments! > > There are some real eye-openers there, especially Jens. While I strongly > disagree with VEE's affinity for "structured" code, I suspect that's simply > because we have different ideas of what structured code is but, "that's > probably a discussion more suited to a comp.programming group," (he said, > trying to stay on topic). > > On the other side of the fence, VEE's innate flowchart-like diagramatic / > execution model is definitely a godsend. In fact, whenever customers > explicitly request VEE this model is almost always the reason why. When I > first started using VEE, I just assumed customers wanted VEE because it was > an HP product. > > Anyway Jens, I found this particularly interesting: > > >2 VEE clients and the VEE-controller > >can run on the same PC or on different PCs. > > If I understand this correctly you can run *three* instances of VEE on *one* > computer? If this is the case, then my hat is off to you and I will > henceforth keep my mouth shut! > > Using NT 4.0 I've had terrible problems just keeping *one* instance going on > anything less than a PII 233! At the risk of boring everybody, let me > outline two of these problems. I really need to understand why it is I have > such awful problems and others do not. At the time, we had HP field > application engineers crawling all over what I did and their conclusion was > "It's fine, that's just the way it works". Ever since then I've been saying, > "well then it doesn't work right". > > These two problems are actually just different aspects of the same root > cause, CPU hogging: > > 1. Printing. Customer wants a simplistic graph of readings over time. Using > the Print Screen object, it took over 45 minutes to print one graph. This is > over a 100MB network. Spooler priority was set highest. I abandoned the > spooler and of course that speeded up the printing to a minute or two, but > the UI completely stops responding (of course) and that's unacceptable. I > wound up using Microsoft's DIBAPI to capture the screen myself & print it. > The catch was that this utility had to shift itself to HIGH_PRIORITY_CLASS > to produce a graph in under 5 minutes. This slowed down the UI some, but the > customer accepted the result as a necessary trade-off. > > 2. Browsing. The test scenario is a room full of some 100 UUTs. Test time > varies from 4 hours to three or four days sometimes. Data points consist of > samples of 6 channels every 30 seconds. The DAC box is an Agilent 34970, one > per UUT. Loading the test line is pretty simple. One plug for power, one for > 4 data channels. The other two channels are from sensors placed inside the > UUT by test personnel. A bar code is scanned and the test cycle begins. > > Now, the people who run the test system are union laborers, not engineers. > There are usually three people per test room. It takes all of about an hour > to get a full room under way and then they sit back and wait. It's no fun > sitting there staring at a graph or a summary of all running tests, so they > usually start playing solitare or browsing the web, looking for girly-pix. > Now granted that this isn't the ideal scenario, but realistically it's to be > expected. As soon as VEE is put in the background, problems develop. > > In the first place, after about 40 UUTs VEE starts having a hard time > keeping up with sampling data, updating 34970 displays, checking for card > swaps or entire 34970 swaps, verifying 34970 configuration, analyzing data > to decide on shifts in test phases, testing com ports for proper > communication, watchdog pinging other test computers to make sure they're > ok, etc. This is even with VEE in the bloody FOREGROUND. When it gets put in > the background, look out! > > Now I realize full well that I'm no VEE expert. Like I've said, 30 years of > programming doesn't mean a thing when it comes to VEE so we called in HP > experts for expert advice. After over half a year of tweaking and some > truely extraordinary efforts on the part of various HP engineers, the > customer was still dissatisfied and started threatening to pull out, and for > that I don't blame them. They dumped *huge* amounts of cash on hardware and > they couldn't even run at 50% capacity. > > Even then, memory leaks caused by the infamous error pins would, after only > a few days of continuous operation, cause VEE to reset it's heap (or > something) and all in-progress tests were lost. Granted, there was always a > current status backup stored on the drive, but this was updated every time > data changed on any DAC box and the moment VEE lost it's variables this file > was overwritten with emptyness. The individual data files themselves > remained, but without status information (current test phase, phase test > instructions, current machine state, state machine registers, etc.) the > state machine couldn't possibly continue. > > It was finally decided to move to a compiled language so I locked myself in > a closet for 14 weeks and re-wrote the entire thing in C++. And when I say > re-wrote, I mean exactly that. The C++ version is almost an exact duplicate > of the VEE version. VEE's failures in this instance were definitely not due > to software architecture. This application is currently buzzing happily > away, testing like crazy. There are no issues with printing graphs, playing > solitare or browsing the web. > > The *opinions* I express here are based largely on this one extraordinarily > negative experience. This was definitely the most detailed analysis I've > ever made of VEE on Windows in the wild, though I've had plenty of somewhat > negative experiences with it before. The icing on the cake was HP's own > conclusion that "yes, everything is fine. That's the way it works". Since > then I've recommended to those customers who want to use VEE that they then > should stick with HP-UX. Sometimes that's fine, and sometimes it's not > because Windows is a requirement. In that case, we use "Windows specific" > tools like Visual Basic, Visual C++, Delphi or C++ Builder. > > Now I challenge any of you to put yourself in my shoes: Put your life on > hold for 14 weeks of consecutive 16-20 hour days WITHOUT PAY, bear the whip > from management AND the customer, watch HP go over everything you've done > with a fine-tooth comb and shrug their shoulders, watch five years of your > life helping to build a company from a two-man operation to a small global > enterprise go down the drain as law suits and bankruptcy ensue and then have > anything positive at all to say about VEE. Here it is, on public record: > > IN SPITE OF ALL OF THIS I STILL LIKE VEE!!! > > So please, if anybody has anything to say to me personally about VEE bashing > then lets keep it off the list as it probably won't be productive at all and > I guarantee I'll respond to all flames with a blow-torch. > -SHAWN- > > _________________________________________________________________ > Join the world's largest e-mail service with MSN Hotmail. > <A href="http://www.hotmail.com" target=_blank>http://www.hotmail.com</A> > > --------------------------------------------------------------------- > 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". > --------------------------------------------------------------------- --------------------------------------------------------------------- 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". ---------------------------------------------------------------------</BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>
Like • Show 0 Likes0
Actions
VRFuser Dec 14, 2001 12:02 AM
Mark Correct
Correct Answer
Shawn,
I am running Vee Pro6.0 on an HP Kayak XU800. As I am writing this I have 4
instances of the ForCount code that you mentioned running. I see no
degradation of computer performance at all. All four programs are humming
along with no problems. Perhaps I did not understand the test correctly?
Best Regards, Gary

Gary Nelson SPG Engineering Services
Agilent Technologies
Office: 408/435-4073 Fax: 408/435-5868
Pager: 408/589-6983
gary_nelson@agilent.com

-----Original Message-----
From: Shawn Fessenden [mailto:s_fessenden@hotmail.com]
Sent: Friday, December 14, 2001 2:31 PM
To: Thomas@Vauderwange.de; vrf@lvld.agilent.com
Subject: Re: vrf Multi-VEE-ing capability

Hallo Thomas!

>Indeed it is no problem at all
>to have several different VEE
>programs running on the same PC
>the same time.

I'm officially flabbergasted and will honor my pledge to remain silent on
the subject. Something is zinging right over my head. I can't imagine how
you're doing it. Let me set up a simple test and then I'm done.

ForCount to #H7fffffff->AlphanumericDisplay.

Start two instances of VEE and run this in each. Place them side by side and

watch. What I see is each one incrementing slowly. If I pop both VEEs down
and try to do something else... ANYTHING else, the computer has returned to
the days of trying to run Windows in Standard mode on a 286 with a 2M EMS
board: It takes forever to do anything at all and one gives up long before
there's any screen activity.

VEE is 5.01, disable debug is on, mode is standard. CPU activity is pegged
at 100% and shows no sign of letting up. Both VEEs are crawling and nothing
useful is possible. I just did it again and tried to start pview to check
working set size, but after a couple minutes pview still haddn't appeared
and I'm just too impatient to find out what the WSS is.
If I stop one, then the other picks up and flies like it should and my
computer is back to being only tollerably impared.

And that's a mystery too. I know Windows fairly well (I mean in detail, not
just it's operation but it's internals, quirks, trivia & sundry) and I'm at
a loss to explain how just running a program in even a single instance of
VEE can degrade performance to such a degree in the first place, yet it
does. When I'm running a VEE program, that's all I'm doing except maybe
typing in notepad. Even that's a hassle because it can't keep up with me.

The laptop is a slightly decreped HP Omnibook XE2 (PII 233), 128M W2K. The
desktop is a little better off: AMD K-Flex 6-2 500 256M W98. The best
compter I tried this on was a Compaq PIII 7something-or-other (733? 740?) NT

4.0. In every case, the result is the same.

I offer sincere apologies to everyone. I thought everybody saw the same
exact behavior. I understand now that's not the case.

I've tried this at least a hundred different ways on different
installations, different hardware, different Windows versions, all
non-essential processes are killed, - everything I could think of and the
result is always the same. I can't explain it at all given that you don't
have this problem.

I would really appreciate it if somebody could figure this out, but I have
pledged to remain publicly silent and so I will. Private communications are,

however, encouraged
-SHAWN-

_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com

---------------------------------------------------------------------
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".
---------------------------------------------------------------------
---------------------------------------------------------------------
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".
---------------------------------------------------------------------
Like • Show 0 Likes0
Actions
VRFuser Dec 14, 2001 12:31 AM
Mark Correct
Correct Answer
Hallo Thomas!

>Indeed it is no problem at all
>to have several different VEE
>programs running on the same PC
>the same time.

I'm officially flabbergasted and will honor my pledge to remain silent on
the subject. Something is zinging right over my head. I can't imagine how
you're doing it. Let me set up a simple test and then I'm done.

ForCount to #H7fffffff->AlphanumericDisplay.

Start two instances of VEE and run this in each. Place them side by side and
watch. What I see is each one incrementing slowly. If I pop both VEEs down
and try to do something else... ANYTHING else, the computer has returned to
the days of trying to run Windows in Standard mode on a 286 with a 2M EMS
board: It takes forever to do anything at all and one gives up long before
there's any screen activity.

VEE is 5.01, disable debug is on, mode is standard. CPU activity is pegged
at 100% and shows no sign of letting up. Both VEEs are crawling and nothing
useful is possible. I just did it again and tried to start pview to check
working set size, but after a couple minutes pview still haddn't appeared
and I'm just too impatient to find out what the WSS is.
If I stop one, then the other picks up and flies like it should and my
computer is back to being only tollerably impared.

And that's a mystery too. I know Windows fairly well (I mean in detail, not
just it's operation but it's internals, quirks, trivia & sundry) and I'm at
a loss to explain how just running a program in even a single instance of
VEE can degrade performance to such a degree in the first place, yet it
does. When I'm running a VEE program, that's all I'm doing except maybe
typing in notepad. Even that's a hassle because it can't keep up with me.

The laptop is a slightly decreped HP Omnibook XE2 (PII 233), 128M W2K. The
desktop is a little better off: AMD K-Flex 6-2 500 256M W98. The best
compter I tried this on was a Compaq PIII 7something-or-other (733? 740?) NT
4.0. In every case, the result is the same.

I offer sincere apologies to everyone. I thought everybody saw the same
exact behavior. I understand now that's not the case.

I've tried this at least a hundred different ways on different
installations, different hardware, different Windows versions, all
non-essential processes are killed, - everything I could think of and the
result is always the same. I can't explain it at all given that you don't
have this problem.

I would really appreciate it if somebody could figure this out, but I have
pledged to remain publicly silent and so I will. Private communications are,
however, encouraged
-SHAWN-

_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com

---------------------------------------------------------------------
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".
---------------------------------------------------------------------
Like • Show 0 Likes0
Actions
VRFuser Dec 14, 2001 1:29 AM
Mark Correct
Correct Answer
Hi Shawn,

You have a very interesting problem and I can see how frustrating this can
be. I have three instances of VEE running now with a ForCount object as you
described and they are all running well. In fact, sometimes it looks as
though it's running so fast that I can't read the display very well. I also
surfed the web to see if any of the three instances would slow down and none
did.

Like Gary, I'm running VEE 6.0 but on an HP Kayak XU6/450, Windows NT 4.0.
Could the problem you're seeing be a bug with VEE 5.0? Did earlier versions
of VEE cause the same problem? I don't have a version 5.0 of VEE, otherwise
I would try it. If you ever find out what's causing it, I would be very
interested in reading about it.

Regards,
Andie

-----Original Message-----
From: Shawn Fessenden [mailto:s_fessenden@hotmail.com]
Sent: Friday, December 14, 2001 2:31 PM
To: Thomas@Vauderwange.de; vrf@lvld.agilent.com
Subject: Re: vrf Multi-VEE-ing capability

Hallo Thomas!

>Indeed it is no problem at all
>to have several different VEE
>programs running on the same PC
>the same time.

I'm officially flabbergasted and will honor my pledge to remain silent on
the subject. Something is zinging right over my head. I can't imagine how
you're doing it. Let me set up a simple test and then I'm done.

ForCount to #H7fffffff->AlphanumericDisplay.

Start two instances of VEE and run this in each. Place them side by side and

watch. What I see is each one incrementing slowly. If I pop both VEEs down
and try to do something else... ANYTHING else, the computer has returned to
the days of trying to run Windows in Standard mode on a 286 with a 2M EMS
board: It takes forever to do anything at all and one gives up long before
there's any screen activity.

VEE is 5.01, disable debug is on, mode is standard. CPU activity is pegged
at 100% and shows no sign of letting up. Both VEEs are crawling and nothing
useful is possible. I just did it again and tried to start pview to check
working set size, but after a couple minutes pview still haddn't appeared
and I'm just too impatient to find out what the WSS is.
If I stop one, then the other picks up and flies like it should and my
computer is back to being only tollerably impared.

And that's a mystery too. I know Windows fairly well (I mean in detail, not
just it's operation but it's internals, quirks, trivia & sundry) and I'm at
a loss to explain how just running a program in even a single instance of
VEE can degrade performance to such a degree in the first place, yet it
does. When I'm running a VEE program, that's all I'm doing except maybe
typing in notepad. Even that's a hassle because it can't keep up with me.

The laptop is a slightly decreped HP Omnibook XE2 (PII 233), 128M W2K. The
desktop is a little better off: AMD K-Flex 6-2 500 256M W98. The best
compter I tried this on was a Compaq PIII 7something-or-other (733? 740?) NT

4.0. In every case, the result is the same.

I offer sincere apologies to everyone. I thought everybody saw the same
exact behavior. I understand now that's not the case.

I've tried this at least a hundred different ways on different
installations, different hardware, different Windows versions, all
non-essential processes are killed, - everything I could think of and the
result is always the same. I can't explain it at all given that you don't
have this problem.

I would really appreciate it if somebody could figure this out, but I have
pledged to remain publicly silent and so I will. Private communications are,

however, encouraged
-SHAWN-

_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com

---------------------------------------------------------------------
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".
---------------------------------------------------------------------
---------------------------------------------------------------------
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".
---------------------------------------------------------------------
Like • Show 0 Likes0
Actions
VRFuser Dec 14, 2001 2:08 AM
Mark Correct
Correct Answer
I tried Shawn's experiment on Win 2k, P3 400MHz, Matrox Millenium graphics.

Started one program (background), then started the other (foreground) and
timed with a stopwatch for 20 seconds

Result display: 33000

Then I stopped the background VEE, and re-ran the experiment with the
stopwatch on the foreground VEE

Result display: 39000

Then I quit the background VEE process and timed the foreground one for 20
seconds

Result display: 39000

The numbers are rough because the experiment is rough.

Another somewhat subjective point I noted: the foreground (window focus) VEE
process went fast, while the background one went noticeably slower. Not what
I'd called dead slow or stalled, but maybe "sluggish". When I clicked the
background process, it sped up as soon as it popped to the front, and seemed
to run at about the 39000 speed (subjective estimate)

So, it looks like two VEEs share the processor "reasonably", but not
"fairly". Putting a processor intensive VEE program in the background while
another processor intensive VEE program runs in foreground probably
decreases the speed of the background considerably, possibly as much as an
order of magnitude.

Disclaimers (but not legal ones, just commonsense ones)
I'd hesitate to extrapolate to 3 or more VEEs without further experiments.
I'd want to check with other programs than VEE as the background process, if
that's what my production system did. Better experiments could easily be
devised (hey, it's Friday afternoon!). This experiment attempts to
characterize only a processor-intensive VEE programs, with a
processor-intensive background VEE. I/O or other "shared resources" could
change results considerably. You'd need to test with your own proposed mix
or a reasonable simulation before you could be confident that results
predicted your performance. More complex programs, say with lots of threads,
for example, might show wildly different results.

But running more than one VEE at a time for many kinds of tasks is not
necessarily infeasible.

Sincerely,

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: Shawn Fessenden [mailto:s_fessenden@hotmail.com]
> Sent: Friday, December 14, 2001 3:31 PM
> To: Thomas@Vauderwange.de; vrf@lvld.agilent.com
> Subject: Re: vrf Multi-VEE-ing capability
>
>
> Hallo Thomas!
>
> >Indeed it is no problem at all
> >to have several different VEE
> >programs running on the same PC
> >the same time.
>
> I'm officially flabbergasted and will honor my pledge to
> remain silent on
> the subject. Something is zinging right over my head. I can't
> imagine how
> you're doing it. Let me set up a simple test and then I'm done.
>
> ForCount to #H7fffffff->AlphanumericDisplay.
>
> Start two instances of VEE and run this in each. Place them
> side by side and
> watch. What I see is each one incrementing slowly. If I pop
> both VEEs down
> and try to do something else... ANYTHING else, the computer
> has returned to
> the days of trying to run Windows in Standard mode on a 286
> with a 2M EMS
> board: It takes forever to do anything at all and one gives
> up long before
> there's any screen activity.
>
> VEE is 5.01, disable debug is on, mode is standard. CPU
> activity is pegged
> at 100% and shows no sign of letting up. Both VEEs are
> crawling and nothing
> useful is possible. I just did it again and tried to start
> pview to check
> working set size, but after a couple minutes pview still
> haddn't appeared
> and I'm just too impatient to find out what the WSS is.
> If I stop one, then the other picks up and flies like it
> should and my
> computer is back to being only tollerably impared.
>
> And that's a mystery too. I know Windows fairly well (I mean
> in detail, not
> just it's operation but it's internals, quirks, trivia &
> sundry) and I'm at
> a loss to explain how just running a program in even a single
> instance of
> VEE can degrade performance to such a degree in the first
> place, yet it
> does. When I'm running a VEE program, that's all I'm doing
> except maybe
> typing in notepad. Even that's a hassle because it can't keep
> up with me.
>
> The laptop is a slightly decreped HP Omnibook XE2 (PII 233),
> 128M W2K. The
> desktop is a little better off: AMD K-Flex 6-2 500 256M W98. The best
> compter I tried this on was a Compaq PIII 7something-or-other
> (733? 740?) NT
> 4.0. In every case, the result is the same.
>
> I offer sincere apologies to everyone. I thought everybody
> saw the same
> exact behavior. I understand now that's not the case.
>
> I've tried this at least a hundred different ways on different
> installations, different hardware, different Windows versions, all
> non-essential processes are killed, - everything I could
> think of and the
> result is always the same. I can't explain it at all given
> that you don't
> have this problem.
>
> I would really appreciate it if somebody could figure this
> out, but I have
> pledged to remain publicly silent and so I will. Private
> communications are,
> however, encouraged
> -SHAWN-
>
>
> _________________________________________________________________
> Send and receive Hotmail on your mobile device: http://mobile.msn.com
>
> ---------------------------------------------------------------------
> 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".
> ---------------------------------------------------------------------
>
---------------------------------------------------------------------
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".
---------------------------------------------------------------------
Like • Show 0 Likes0
Actions
VRFuser Dec 14, 2001 3:56 AM
Mark Correct
Correct Answer
Hi Andi. I CCed my reply to Gary to you also. To answer your questions real
quick, no, it's not a bug in VEE, it's a bug in me somewhere
I first noticed in 3.12, however it went away for everybody but me by VEE 4.
If and when I figure out exactly what's going on, I'll make sure to let
everybody know.
-SHAWN-

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. 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".
---------------------------------------------------------------------
Like • Show 0 Likes0
Actions
VRFuser Dec 14, 2001 4:10 AM
Mark Correct
Correct Answer
Since Scott was kind enough to share these findings, I'll risk a short
comment:

>So, it looks like two VEEs share
>the processor "reasonably", but not
>"fairly".

This is exactly how it should work. What we see here is Windows' task
scheduler divying up time to applications. On W2K systems, these ratios can
be altered in the Control Panel-> System applette: on the Advanced tab,
click the Performance button. There you'll find two radio buttons that
change how the task scheduler works. On NT 4 systems, the option was in the
same general location but there was a slider called "Foreground Application
Boost". This slider performed basically the same function.
-SHAWN-

_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com

---------------------------------------------------------------------
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".
---------------------------------------------------------------------
Like • Show 0 Likes0
Actions
VRFuser Dec 14, 2001 6:04 AM
Mark Correct
Correct Answer
Hi Shawn,

Indeed it is no problem at all to have several different VEE programs running on
the same PC the same time. Even tricky stuff, like RS232-comms etc. My customers
and the folks down in the production hall do this all the time with my software
(Win98, NT4, W2K), and everybody's happy. This happened when I changed from good
ol' VEE3-interpreter (where it did not work) to the one that came with VEE5.
And: someone found out by coincidence by just mistakenly starting several
processes. Even sharing one and the same COM-port (!!) worked without having
been specified!
All I had to do to make this a real feature is to specify different working
directories where different config-files could be placed. And, of course, to
allow for an identifier string in the left top of the temperature graph, because
otehrwise nobody could tell the processes apart...

Regards,

Thomas

Shawn Fessenden schrieb:

> Well thank you everybody for your comments!
>
> There are some real eye-openers there, especially Jens. While I strongly
> disagree with VEE's affinity for "structured" code, I suspect that's simply
> because we have different ideas of what structured code is but, "that's
> probably a discussion more suited to a comp.programming group," (he said,
> trying to stay on topic).
>
> On the other side of the fence, VEE's innate flowchart-like diagramatic /
> execution model is definitely a godsend. In fact, whenever customers
> explicitly request VEE this model is almost always the reason why. When I
> first started using VEE, I just assumed customers wanted VEE because it was
> an HP product.
>
> Anyway Jens, I found this particularly interesting:
>
> >2 VEE clients and the VEE-controller
> >can run on the same PC or on different PCs.
>
> If I understand this correctly you can run *three* instances of VEE on *one*
> computer? If this is the case, then my hat is off to you and I will
> henceforth keep my mouth shut!
>
> Using NT 4.0 I've had terrible problems just keeping *one* instance going on
> anything less than a PII 233! At the risk of boring everybody, let me
> outline two of these problems. I really need to understand why it is I have
> such awful problems and others do not. At the time, we had HP field
> application engineers crawling all over what I did and their conclusion was
> "It's fine, that's just the way it works". Ever since then I've been saying,
> "well then it doesn't work right".
>
> These two problems are actually just different aspects of the same root
> cause, CPU hogging:
>
> 1. Printing. Customer wants a simplistic graph of readings over time. Using
> the Print Screen object, it took over 45 minutes to print one graph. This is
> over a 100MB network. Spooler priority was set highest. I abandoned the
> spooler and of course that speeded up the printing to a minute or two, but
> the UI completely stops responding (of course) and that's unacceptable. I
> wound up using Microsoft's DIBAPI to capture the screen myself & print it.
> The catch was that this utility had to shift itself to HIGH_PRIORITY_CLASS
> to produce a graph in under 5 minutes. This slowed down the UI some, but the
> customer accepted the result as a necessary trade-off.
>
> 2. Browsing. The test scenario is a room full of some 100 UUTs. Test time
> varies from 4 hours to three or four days sometimes. Data points consist of
> samples of 6 channels every 30 seconds. The DAC box is an Agilent 34970, one
> per UUT. Loading the test line is pretty simple. One plug for power, one for
> 4 data channels. The other two channels are from sensors placed inside the
> UUT by test personnel. A bar code is scanned and the test cycle begins.
>
> Now, the people who run the test system are union laborers, not engineers.
> There are usually three people per test room. It takes all of about an hour
> to get a full room under way and then they sit back and wait. It's no fun
> sitting there staring at a graph or a summary of all running tests, so they
> usually start playing solitare or browsing the web, looking for girly-pix.
> Now granted that this isn't the ideal scenario, but realistically it's to be
> expected. As soon as VEE is put in the background, problems develop.
>
> In the first place, after about 40 UUTs VEE starts having a hard time
> keeping up with sampling data, updating 34970 displays, checking for card
> swaps or entire 34970 swaps, verifying 34970 configuration, analyzing data
> to decide on shifts in test phases, testing com ports for proper
> communication, watchdog pinging other test computers to make sure they're
> ok, etc. This is even with VEE in the bloody FOREGROUND. When it gets put in
> the background, look out!
>
> Now I realize full well that I'm no VEE expert. Like I've said, 30 years of
> programming doesn't mean a thing when it comes to VEE so we called in HP
> experts for expert advice. After over half a year of tweaking and some
> truely extraordinary efforts on the part of various HP engineers, the
> customer was still dissatisfied and started threatening to pull out, and for
> that I don't blame them. They dumped *huge* amounts of cash on hardware and
> they couldn't even run at 50% capacity.
>
> Even then, memory leaks caused by the infamous error pins would, after only
> a few days of continuous operation, cause VEE to reset it's heap (or
> something) and all in-progress tests were lost. Granted, there was always a
> current status backup stored on the drive, but this was updated every time
> data changed on any DAC box and the moment VEE lost it's variables this file
> was overwritten with emptyness. The individual data files themselves
> remained, but without status information (current test phase, phase test
> instructions, current machine state, state machine registers, etc.) the
> state machine couldn't possibly continue.
>
> It was finally decided to move to a compiled language so I locked myself in
> a closet for 14 weeks and re-wrote the entire thing in C++. And when I say
> re-wrote, I mean exactly that. The C++ version is almost an exact duplicate
> of the VEE version. VEE's failures in this instance were definitely not due
> to software architecture. This application is currently buzzing happily
> away, testing like crazy. There are no issues with printing graphs, playing
> solitare or browsing the web.
>
> The *opinions* I express here are based largely on this one extraordinarily
> negative experience. This was definitely the most detailed analysis I've
> ever made of VEE on Windows in the wild, though I've had plenty of somewhat
> negative experiences with it before. The icing on the cake was HP's own
> conclusion that "yes, everything is fine. That's the way it works". Since
> then I've recommended to those customers who want to use VEE that they then
> should stick with HP-UX. Sometimes that's fine, and sometimes it's not
> because Windows is a requirement. In that case, we use "Windows specific"
> tools like Visual Basic, Visual C++, Delphi or C++ Builder.
>
> Now I challenge any of you to put yourself in my shoes: Put your life on
> hold for 14 weeks of consecutive 16-20 hour days WITHOUT PAY, bear the whip
> from management AND the customer, watch HP go over everything you've done
> with a fine-tooth comb and shrug their shoulders, watch five years of your
> life helping to build a company from a two-man operation to a small global
> enterprise go down the drain as law suits and bankruptcy ensue and then have
> anything positive at all to say about VEE. Here it is, on public record:
>
> IN SPITE OF ALL OF THIS I STILL LIKE VEE!!!
>
> So please, if anybody has anything to say to me personally about VEE bashing
> then lets keep it off the list as it probably won't be productive at all and
> I guarantee I'll respond to all flames with a blow-torch.
> -SHAWN-
>
> _________________________________________________________________
> Join the worlds largest e-mail service with MSN Hotmail.
> http://www.hotmail.com
>
> ---------------------------------------------------------------------
> 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".
> ---------------------------------------------------------------------

---------------------------------------------------------------------
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".
---------------------------------------------------------------------
Like • Show 0 Likes0
Actions
VRFuser Dec 14, 2001 6:24 AM
Mark Correct
Correct Answer
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"><HTML><HEAD><META content="text/html; charset=iso-8859-1" http-equiv=Content-Type><META content="MSHTML 5.00.2614.3500" name=GENERATOR><STYLE></STYLE></HEAD><BODY bgColor=#ffffff><DIV>The two VEE applications don't share the COM port, it's the HP I/O library control that controls the com port. The two VEE applications are both talking to HP I/O library control, which in turns talks to the com port. Ergo, only one application actually accesses the com port.</DIV><DIV> </DIV><DIV>Cheers</DIV><DIV> </DIV><DIV>Gerard Geurts</DIV><DIV>G Squared Ltd</DIV><DIV> </DIV><DIV> </DIV><DIV> </DIV><DIV>----- Original Message ----- </DIV><BLOCKQUOTE style="BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px"> <DIV style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black">From: <A href="mailto:Paul.Rubin@am1.ericsson.se" title=Paul.Rubin@am1.ericsson.se>Paul Rubin (AMT)</A> </DIV> <DIV style="FONT: 10pt arial">To: <A href="mailto:'Thomas@Vauderwange.de'" title=Thomas@Vauderwange.de>'Thomas@Vauderwange.de'</A> ; <A href="mailto:vrf@lvld.agilent.com" title=vrf@lvld.agilent.com>vrf@lvld.agilent.com</A> </DIV> <DIV style="FONT: 10pt arial">Sent: Friday, December 14, 2001 9:53 PM</DIV> <DIV style="FONT: 10pt arial">Subject: RE: vrf Multi-VEE-ing capability</DIV> <DIV> </DIV> <DIV>Thomas,</DIV> <DIV> </DIV> <DIV>Apparently you are only claiming that 2 _VEE_ programs can "share" a Com port. Correct? Have you ever succeeded in having VEE share a Com port with any other type application?</DIV> Paul H. Rubin Staff Engineer Test Engineering Ericsson Amplifier Technologies, Inc. 49 Wireless Blvd. Hauppauge, New York 11788 Phone: (631) 357-8513 E-Mail: <A href="mailto:paul.rubin@ericsson.com">paul.rubin@ericsson.com</A> </BLOCKQUOTE></BODY></HTML>
Like • Show 0 Likes0
Actions
VRFuser Dec 14, 2001 6:34 AM
Mark Correct
Correct Answer
<!doctype html public "-//w3c//dtd html 4.0 transitional//en"><html>Hi Paul,Well, found it hard to believe when I heard it. I was aware that VEEwon't let the COM-port loose, once it got hold of it, so the idea to tryCOM-port-sharing with non-VEE-apps was abandoned.Then, that customer from over there in luvly North Carolina called oneday, reporting a 'severe firmware bug' in our machine's microcontroller,as there were the two LEDs that indicate the two possible control modesof that machine blinking! In a very regular manner, the right one - theleft one. As something like this was completely unheard of, I started theinvestigation and found out that my software, which he uses to control/monitorthe machine from a PC had been started two times simultaneously on thatPC. On the copy in the foreground, that customer had pushed the buttonthat did send (via COM1) the signal to change control mode. The other instancedid notice the deviation with its next data exchange and thus ordered themachine back in the other mode. Which led the copy in front of the screento send another command...Anyway, it worked fine. Unfortunately, you need a real one of thesemachines to try my software out, which would otherwise be available asa free download from the company's website. But, in case you happen toneed a heater-chiller circulator, then that company would be the rightaddress.Thomas"Paul Rubin (AMT)" schrieb:<blockquote TYPE=CITE> Thomas,I'm quite interested in your comment about RS232 ports.We have not been able to resolve a problem with 2 applications trying touse the same Com port. While we can "Close" the port from the Vee application,there appears to be no way to reopen it after the other application (NOTVEE) releases it. I imagine it would be possible to replicat the otherapplication in VEE, if absolutely necessary, but that would be a significantundertaking as there are a number of different combinations possible.Please advisePaul H. Rubin
Staff Engineer
Test Engineering
Ericsson Amplifier Technologies, Inc.
49 Wireless Blvd.
Hauppaugh, New York 11788
Phone: (631) 357-8513
E-Mail: paul.rubin@ericsson.com
-----Original Message-----
From: Thomas Vauderwange [<a href="mailto:Thomas@Vauderwange.de">mailto:Thomas@Vauderwange.de</a>]
Sent: Friday, December 14, 2001 4:04 PM
To: vrf@lvld.agilent.com
Subject: vrf Multi-VEE-ing capabilityHi Shawn,Indeed it is no problem at all to have several differentVEE programs running on
the same PC the same time. Even tricky stuff, like RS232-commsetc. My customers
and the folks down in the production hall do this allthe time with my software
(Win98, NT4, W2K), and everybody's happy. This happenedwhen I changed from good
ol' VEE3-interpreter (where it did not work) to the onethat came with VEE5.
And: someone found out by coincidence by just mistakenlystarting several
processes. Even sharing one and the same COM-port (!!)worked without having
been specified!
All I had to do to make this a real feature is to specifydifferent working
directories where different config-files could be placed.And, of course, to
allow for an identifier string in the left top of thetemperature graph, because
otehrwise nobody could tell the processes apart...Regards,ThomasShawn Fessenden schrieb:> Well thank you everybody for your comments!
>
> There are some real eye-openers there, especially Jens.While I strongly
> disagree with VEE's affinity for "structured" code,I suspect that's simply
> because we have different ideas of what structuredcode is but, "that's
> probably a discussion more suited to a comp.programminggroup," (he said,
> trying to stay on topic).
>
> On the other side of the fence, VEE's innate flowchart-likediagramatic /
> execution model is definitely a godsend. In fact, whenevercustomers
> explicitly request VEE this model is almost alwaysthe reason why. When I
> first started using VEE, I just assumed customers wantedVEE because it was
> an HP product.
>
> Anyway Jens, I found this particularly interesting:
>
> >2 VEE clients and the VEE-controller
> >can run on the same PC or on different PCs.
>
> If I understand this correctly you can run *three*instances of VEE on *one*
> computer? If this is the case, then my hat is off toyou and I will
> henceforth keep my mouth shut!
>
> Using NT 4.0 I've had terrible problems just keeping*one* instance going on
> anything less than a PII 233! At the risk of boringeverybody, let me
> outline two of these problems. I really need to understandwhy it is I have
> such awful problems and others do not. At the time,we had HP field
> application engineers crawling all over what I didand their conclusion was
> "It's fine, that's just the way it works". Ever sincethen I've been saying,
> "well then it doesn't work right".
>
> These two problems are actually just different aspectsof the same root
> cause, CPU hogging:
>
> 1. Printing. Customer wants a simplistic graph of readingsover time. Using
> the Print Screen object, it took over 45 minutes toprint one graph. This is
> over a 100MB network. Spooler priority was set highest.I abandoned the
> spooler and of course that speeded up the printingto a minute or two, but
> the UI completely stops responding (of course) andthat's unacceptable. I
> wound up using Microsoft's DIBAPI to capture the screenmyself & print it.
> The catch was that this utility had to shift itselfto HIGH_PRIORITY_CLASS
> to produce a graph in under 5 minutes. This sloweddown the UI some, but the
> customer accepted the result as a necessary trade-off.
>
> 2. Browsing. The test scenario is a room full of some100 UUTs. Test time
> varies from 4 hours to three or four days sometimes.Data points consist of
> samples of 6 channels every 30 seconds. The DAC boxis an Agilent 34970, one
> per UUT. Loading the test line is pretty simple. Oneplug for power, one for
> 4 data channels. The other two channels are from sensorsplaced inside the
> UUT by test personnel. A bar code is scanned and thetest cycle begins.
>
> Now, the people who run the test system are union laborers,not engineers.
> There are usually three people per test room. It takesall of about an hour
> to get a full room under way and then they sit backand wait. It's no fun
> sitting there staring at a graph or a summary of allrunning tests, so they
> usually start playing solitare or browsing the web,looking for girly-pix.
> Now granted that this isn't the ideal scenario, butrealistically it's to be
> expected. As soon as VEE is put in the background,problems develop.
>
> In the first place, after about 40 UUTs VEE startshaving a hard time
> keeping up with sampling data, updating 34970 displays,checking for card
> swaps or entire 34970 swaps, verifying 34970 configuration,analyzing data
> to decide on shifts in test phases, testing com portsfor proper
> communication, watchdog pinging other test computersto make sure they're
> ok, etc. This is even with VEE in the bloody FOREGROUND.When it gets put in
> the background, look out!
>
> Now I realize full well that I'm no VEE expert. LikeI've said, 30 years of
> programming doesn't mean a thing when it comes to VEEso we called in HP
> experts for expert advice. After over half a year oftweaking and some
> truely extraordinary efforts on the part of variousHP engineers, the
> customer was still dissatisfied and started threateningto pull out, and for
> that I don't blame them. They dumped *huge* amountsof cash on hardware and
> they couldn't even run at 50% capacity.
>
> Even then, memory leaks caused by the infamous errorpins would, after only
> a few days of continuous operation, cause VEE to resetit's heap (or
> something) and all in-progress tests were lost. Granted,there was always a
> current status backup stored on the drive, but thiswas updated every time
> data changed on any DAC box and the moment VEE lostit's variables this file
> was overwritten with emptyness. The individual datafiles themselves
> remained, but without status information (current testphase, phase test
> instructions, current machine state, state machineregisters, etc.) the
> state machine couldn't possibly continue.
>
> It was finally decided to move to a compiled languageso I locked myself in
> a closet for 14 weeks and re-wrote the entire thingin C++. And when I say
> re-wrote, I mean exactly that. The C++ version is almostan exact duplicate
> of the VEE version. VEE's failures in this instancewere definitely not due
> to software architecture. This application is currentlybuzzing happily
> away, testing like crazy. There are no issues withprinting graphs, playing
> solitare or browsing the web.
>
> The *opinions* I express here are based largely onthis one extraordinarily
> negative experience. This was definitely the most detailedanalysis I've
> ever made of VEE on Windows in the wild, though I'vehad plenty of somewhat
> negative experiences with it before. The icing on thecake was HP's own
> conclusion that "yes, everything is fine. That's theway it works". Since
> then I've recommended to those customers who want touse VEE that they then
> should stick with HP-UX. Sometimes that's fine, andsometimes it's not
> because Windows is a requirement. In that case, weuse "Windows specific"
> tools like Visual Basic, Visual C++, Delphi or C++Builder.
>
> Now I challenge any of you to put yourself in my shoes:Put your life on
> hold for 14 weeks of consecutive 16-20 hour days WITHOUTPAY, bear the whip
> from management AND the customer, watch HP go overeverything you've done
> with a fine-tooth comb and shrug their shoulders, watchfive years of your
> life helping to build a company from a two-man operationto a small global
> enterprise go down the drain as law suits and bankruptcyensue and then have
> anything positive at all to say about VEE. Here itis, on public record:
>
> IN SPITE OF ALL OF THIS I STILL LIKE VEE!!!
>
> So please, if anybody has anything to say to me personallyabout VEE bashing
> then lets keep it off the list as it probably won'tbe productive at all and
> I guarantee I'll respond to all flames with a blow-torch.
> -SHAWN-
>
> _________________________________________________________________
> Join the world's largest e-mail service with MSN Hotmail.
> <a href="http://www.hotmail.com" TARGET="_blank">http://www.hotmail.com</a>
>
> ---------------------------------------------------------------------
> 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 containingthe text "help"
> to "vrf-request@lvld.agilent.com".
> ------------------------------------------------------------------------------------------------------------------------------------------
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 thetext "help"
to "vrf-request@lvld.agilent.com".
---------------------------------------------------------------------</blockquote></html>
Like • Show 0 Likes0
Actions
VRFuser Dec 14, 2001 6:00 PM
Mark Correct
Correct Answer
<!doctype html public "-//w3c//dtd html 4.0 transitional//en"><html><body bgcolor="#FFFFFF">There you go! Of course you're exactly right. In the end, I think the only'egoistic' behaviour that VEE would have to be criticised for is that itsomehow claims a lot of the available system performance 'just in case',so that whatever NON-VEE-application gets horribly slow. As soon as thereare several VEE-mates, sharing the resources seems to work as expected.And they also seem to have no difficulties to share one and the same COM-port,probably just as if you're programming several threads within one VEE-application,that are all making use of that port.
To answer Paul's question: No, I don't remember that actually morethan two VEE-applications did share the same COM-port. So, in spite thatI'd expect it to work, I think Scott makes a point in his statement thatthe extrapolation of that idea to more than two instances would be up toan experiment.Regards,Thomas Vauderwange

Gerard Geurts schrieb:<blockquote TYPE=CITE><style></style>Thetwo VEE applications don't share the COM port, it's the HP I/O librarycontrol that controls the com port. The two VEE applications are both talkingto HP I/O library control, which in turns talks to the com port. Ergo,only one application actually accesses the com port. Cheers GerardGeurtsG Squared Ltd -----Original Message -----<blockquote style="BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px"><div style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black">From:<a href="mailto:Paul.Rubin@am1.ericsson.se" title="Paul.Rubin@am1.ericsson.se">PaulRubin (AMT)</a></div><div style="FONT: 10pt arial">To: <a href="mailto:'Thomas@Vauderwange.de'" title="Thomas@Vauderwange.de">'Thomas@Vauderwange.de'</a>; <a href="mailto:vrf@lvld.agilent.com" title="vrf@lvld.agilent.com">vrf@lvld.agilent.com</a></div><div style="FONT: 10pt arial">Sent: Friday, December 14, 2001 9:53PM</div><div style="FONT: 10pt arial">Subject: RE: vrf Multi-VEE-ing capability</div> Thomas,Apparentlyyou are only claiming that 2 _VEE_ programs can "share" a Comport. Correct? Have you ever succeeded in having VEE share a Com port withany other type application?PaulH. Rubin
Staff Engineer
Test Engineering
Ericsson Amplifier Technologies, Inc.
49 Wireless Blvd.
Hauppauge, New York 11788
Phone: (631) 357-8513
E-Mail: <a href="mailto:paul.rubin@ericsson.com">paul.rubin@ericsson.com</a></blockquote></blockquote></body></html>
Like • Show 0 Likes0
Actions
rsb Dec 14, 2001 6:30 PM
Mark Correct
Correct Answer
Hmm

Just fired up 4 VEE 6.01 sessions on my PII 450, NT4 SP6 system
and with all 4 running the loop indicated I see 80% load factor
in task manager , fairly evenly shared at 20% and other applications
are a trifle slow but nothing serious.

When I am using VEE I almost _always_ have at least two
copies running since I deal with lots of libraries.

Are you perhaps running into swap? I could certainly see
slowdown in that case.

Or if you were running one of the consumer-grade OS's
(9x, ME).

If not- and you are staying in RAM and aren't running funny
in the background (like a resource hog like Netscape)
then sorry but I have no idea why you would see a slowdown
like you mention.

I have various systems to play with. If you can specify
what sort of OS/processor/ram/swap/patch levels/etc you have I'll
see if I can reproduce what you are seeing.

regards

Stan
---------------------------------------------------------------------
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".
---------------------------------------------------------------------
Like • Show 0 Likes0
Actions
VRFuser Dec 16, 2001 5:50 PM
Mark Correct
Correct Answer
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"><HTML><HEAD><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"><META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.45"><TITLE>RE: vrf Multi-VEE-ing capability</TITLE></HEAD><BODY>Rob,Actually, we found it does release it, but cannot reopen it. Regardless, we can't use it with another app that tries to open & close it. For that reason, we have started an evaluation of an alternate solution (i.e. not use VEE).Paul H. Rubin Staff Engineer Test Engineering Ericsson Amplifier Technologies, Inc. 49 Wireless Blvd. Hauppaugh, New York 11788 Phone: (631) 357-8513 E-Mail: paul.rubin@ericsson.com -----Original Message----- From: ramarquardt@ra.rockwell.com [<A HREF="mailto:ramarquardt@ra.rockwell.com">mailto:ramarquardt@ra.rockwell.com</A>] Sent: Monday, December 17, 2001 9:54 AM To: Paul Rubin (AMT) Subject: RE: vrf Multi-VEE-ing capability I think it's a known VEE bug. VEE doesn't release the resource even if you execute a CLOSE. We don't even try to do this anymore. If pressed, however, we could funnel it through VEE via a TCP/IP socket or use two ports and a remote control switch |at least until this gets fixed>.RobRob Marquardt System Test Engineering Rockwell Automation / Allen-Bradley 1201 So. 2nd Street Milwaukee, Wisconsin, 53204-2496, USA 414-382-3098 Phone 414-382-4820 FAX RAMarquardt@ra.Rockwell.com "Paul Rubin (AMT)" |Paul.Rubin@am1.ericsson.se>@lvld.agilent.com on 12/14/2001 03:53:10 PMSent by: owner-vrf@lvld.agilent.com To: "'Thomas@Vauderwange.de'" |Thomas@Vauderwange.de>, vrf@lvld.agilent.com cc:Subject: RE: vrf Multi-VEE-ing capability Thomas,Apparently you are only claiming that 2 _VEE_ programs can "share" a Com port. Correct? Have you ever succeeded in having VEE share a Com port with any other type application?Paul H. Rubin Staff Engineer Test Engineering Ericsson Amplifier Technologies, Inc. 49 Wireless Blvd. Hauppauge, New York 11788 Phone: (631) 357-8513 E-Mail: paul.rubin@ericsson.com-----Original Message----- From: Thomas Vauderwange [<A HREF="mailto:Thomas@Vauderwange.de">mailto:Thomas@Vauderwange.de</A>] Sent: Friday, December 14, 2001 4:35 PM To: vrf@lvld.agilent.com Subject: Re: vrf Multi-VEE-ing capability Hi Paul,Well, found it hard to believe when I heard it. I was aware that VEE won't let the COM-port loose, once it got hold of it, so the idea to try COM-port-sharing with non-VEE-apps was abandoned.Then, that customer from over there in luvly North Carolina called one day, reporting a 'severe firmware bug' in our machine's microcontroller, as there were the two LEDs that indicate the two possible control modes of that machine blinking! In a very regular manner, the right one - the left one. As something like this was completely unheard of, I started the investigation and found out that my software, which he uses to control/monitor the machine from a PC had been started two times simultaneously on that PC. On the copy in the foreground, that customer had pushed the button that did send (via COM1) the signal to change control mode. The other instance did notice the deviation with its next data exchange and thus ordered the machine back in the other mode. Which led the copy in front of the screen to send another command...Anyway, it worked fine. Unfortunately, you need a real one of these machines to try my software out, which would otherwise be available as a free download from the company's website. But, in case you happen to need a heater-chiller circulator, then that company would be the right address.Thomas"Paul Rubin (AMT)" schrieb:Thomas,I'm quite interested in your comment about RS232 ports. We have not been able to resolve a problem with 2 applications trying to use the same Com port. While we can "Close" the port from the Vee application, there appears to be no way to reopen it after the other application (NOT VEE) releases it. I imagine it would be possible to replicat the other application in VEE, if absolutely necessary, but that would be a significant undertaking as there are a number of different combinations possible.Please advisePaul H. Rubin Staff Engineer Test Engineering Ericsson Amplifier Technologies, Inc. 49 Wireless Blvd. Hauppaugh, New York 11788 Phone: (631) 357-8513 E-Mail: paul.rubin@ericsson.com -----Original Message----- From: Thomas Vauderwange [<A HREF="mailto:Thomas@Vauderwange.de">mailto:Thomas@Vauderwange.de</A>] Sent: Friday, December 14, 2001 4:04 PM To: vrf@lvld.agilent.com Subject: vrf Multi-VEE-ing capabilityHi Shawn,Indeed it is no problem at all to have several different VEE programs running on the same PC the same time. Even tricky stuff, like RS232-comms etc. My customers and the folks down in the production hall do this all the time with my software (Win98, NT4, W2K), and everybody's happy. This happened when I changed from good ol' VEE3-interpreter (where it did not work) to the one that came with VEE5. And: someone found out by coincidence by just mistakenly starting several processes. Even sharing one and the same COM-port (!!) worked without having been specified! All I had to do to make this a real feature is to specify different working directories where different config-files could be placed. And, of course, to allow for an identifier string in the left top of the temperature graph, because otehrwise nobody could tell the processes apart...Regards,ThomasShawn Fessenden schrieb:> Well thank you everybody for your comments! > > There are some real eye-openers there, especially Jens. While I strongly > disagree with VEE's affinity for "structured" code, I suspect that's simply > because we have different ideas of what structured code is but, "that's > probably a discussion more suited to a comp.programming group," (he said, > trying to stay on topic). > > On the other side of the fence, VEE's innate flowchart-like diagramatic / > execution model is definitely a godsend. In fact, whenever customers > explicitly request VEE this model is almost always the reason why. When I > first started using VEE, I just assumed customers wanted VEE because it was > an HP product. > > Anyway Jens, I found this particularly interesting: > > >2 VEE clients and the VEE-controller > >can run on the same PC or on different PCs. > > If I understand this correctly you can run *three* instances of VEE on *one* > computer? If this is the case, then my hat is off to you and I will > henceforth keep my mouth shut! > > Using NT 4.0 I've had terrible problems just keeping *one* instance going on > anything less than a PII 233! At the risk of boring everybody, let me > outline two of these problems. I really need to understand why it is I have > such awful problems and others do not. At the time, we had HP field > application engineers crawling all over what I did and their conclusion was > "It's fine, that's just the way it works". Ever since then I've been saying, > "well then it doesn't work right". > > These two problems are actually just different aspects of the same root > cause, CPU hogging: > > 1. Printing. Customer wants a simplistic graph of readings over time. Using > the Print Screen object, it took over 45 minutes to print one graph. This is > over a 100MB network. Spooler priority was set highest. I abandoned the > spooler and of course that speeded up the printing to a minute or two, but > the UI completely stops responding (of course) and that's unacceptable. I > wound up using Microsoft's DIBAPI to capture the screen myself & print it. > The catch was that this utility had to shift itself to HIGH_PRIORITY_CLASS > to produce a graph in under 5 minutes. This slowed down the UI some, but the > customer accepted the result as a necessary trade-off. > > 2. Browsing. The test scenario is a room full of some 100 UUTs. Test time > varies from 4 hours to three or four days sometimes. Data points consist of > samples of 6 channels every 30 seconds. The DAC box is an Agilent 34970, one > per UUT. Loading the test line is pretty simple. One plug for power, one for > 4 data channels. The other two channels are from sensors placed inside the > UUT by test personnel. A bar code is scanned and the test cycle begins. > > Now, the people who run the test system are union laborers, not engineers. > There are usually three people per test room. It takes all of about an hour > to get a full room under way and then they sit back and wait. It's no fun > sitting there staring at a graph or a summary of all running tests, so they > usually start playing solitare or browsing the web, looking for girly-pix. > Now granted that this isn't the ideal scenario, but realistically it's to be > expected. As soon as VEE is put in the background, problems develop. > > In the first place, after about 40 UUTs VEE starts having a hard time > keeping up with sampling data, updating 34970 displays, checking for card > swaps or entire 34970 swaps, verifying 34970 configuration, analyzing data > to decide on shifts in test phases, testing com ports for proper > communication, watchdog pinging other test computers to make sure they're > ok, etc. This is even with VEE in the bloody FOREGROUND. When it gets put in > the background, look out! > > Now I realize full well that I'm no VEE expert. Like I've said, 30 years of > programming doesn't mean a thing when it comes to VEE so we called in HP > experts for expert advice. After over half a year of tweaking and some > truely extraordinary efforts on the part of various HP engineers, the > customer was still dissatisfied and started threatening to pull out, and for > that I don't blame them. They dumped *huge* amounts of cash on hardware and > they couldn't even run at 50% capacity. > > Even then, memory leaks caused by the infamous error pins would, after only > a few days of continuous operation, cause VEE to reset it's heap (or > something) and all in-progress tests were lost. Granted, there was always a > current status backup stored on the drive, but this was updated every time > data changed on any DAC box and the moment VEE lost it's variables this file > was overwritten with emptyness. The individual data files themselves > remained, but without status information (current test phase, phase test > instructions, current machine state, state machine registers, etc.) the > state machine couldn't possibly continue. > > It was finally decided to move to a compiled language so I locked myself in > a closet for 14 weeks and re-wrote the entire thing in C++. And when I say > re-wrote, I mean exactly that. The C++ version is almost an exact duplicate > of the VEE version. VEE's failures in this instance were definitely not due > to software architecture. This application is currently buzzing happily > away, testing like crazy. There are no issues with printing graphs, playing > solitare or browsing the web. > > The *opinions* I express here are based largely on this one extraordinarily > negative experience. This was definitely the most detailed analysis I've > ever made of VEE on Windows in the wild, though I've had plenty of somewhat > negative experiences with it before. The icing on the cake was HP's own > conclusion that "yes, everything is fine. That's the way it works". Since > then I've recommended to those customers who want to use VEE that they then > should stick with HP-UX. Sometimes that's fine, and sometimes it's not > because Windows is a requirement. In that case, we use "Windows specific" > tools like Visual Basic, Visual C++, Delphi or C++ Builder. > > Now I challenge any of you to put yourself in my shoes: Put your life on > hold for 14 weeks of consecutive 16-20 hour days WITHOUT PAY, bear the whip > from management AND the customer, watch HP go over everything you've done > with a fine-tooth comb and shrug their shoulders, watch five years of your > life helping to build a company from a two-man operation to a small global > enterprise go down the drain as law suits and bankruptcy ensue and then have > anything positive at all to say about VEE. Here it is, on public record: > > IN SPITE OF ALL OF THIS I STILL LIKE VEE!!! > > So please, if anybody has anything to say to me personally about VEE bashing > then lets keep it off the list as it probably won't be productive at all and > I guarantee I'll respond to all flames with a blow-torch. > -SHAWN- > > _________________________________________________________________ > Join the world's largest e-mail service with MSN Hotmail. > <A HREF="http://www.hotmail.com" TARGET="_blank">http://www.hotmail.com</A> > > --------------------------------------------------------------------- > 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". > ------------------------------------------------------------------------------------------------------------------------------------------ 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". --------------------------------------------------------------------- </BODY></HTML>
Like • Show 0 Likes0
Actions

vrf Multi-VEE-ing capability

Outcomes

Related Content

Recommended Content