AnsweredAssumed Answered

vrf Problem with Serial communication-RS232

Question asked by VRFuser on Apr 25, 2008
Doug,
 
     The order of execution in Vee has not changed that I am aware of since version 4. I will try to outline the rules that Vee uses to execute and where sometimes the order can get messed up.
 
  Vee uses a data flow to control execution so following the data is what Vee does.
 
    First items to execute are all the unconstrained objects, meaning objects that are not using data inputs or the constraining pins are not connected. These normally execute from upper left to lower right but I have seen where moving an object to a new location does not mean it will fire in that order basically where it was originally placed is when it will go, although I have seen other times it will follow the above rule when an object is moved. Key thing here is if you do not care what order the unconstrained objects fire then you can leave them alone if you do care be sure to use the constrain input pin.
 
    Objects that have data inputs will only execute when valid data is at all the input pins use of a constraining input is usually not needed for this type of object.
 
    Objects that have the constrain pin used will fire when the object they are connected to is finished.
 
     Use of constraining pins should be minimized data flow is the way Vee is designed to flow so allowing the data to control execution is the way to go. For objects that have no data input the only way to ensure their sequence is with the constraining pin.
 
     You may also want to search the Vee web pages there is plenty of discussion on controlling program flow in Vee.
 
    One last thing is to use error pins as much as possible to ensure your program does not just crash and give an operator the red screen which in many cases means nothing to them. For example if the user has to input a value but they put in a value that is out of range you can capture this and redirect the user to input the correct value rather then allow the program to stop and generate a fatal error later on.
 
   Hope this helps.
 


Douglas Rudrow <drudrow@Aurora.com> wrote:

Greetings all,
 
I’ve got a dilemma. I wrote a very simple program to communicate with an optical polarization controller. While I was at lunch today, my boss copied it to a different computer. When he tried to run it, VEE threw an error that it couldn’t open the GPIB interface. When I got back from lunch, he had sent me this long e-mail about how he’s losing confidence in VEE and we need a robust platform in the lab. In this particular case, Windows had failed to configure the plug and play GPIB interface (NI USB-GPIB HS). Of course I explained that if the equipment is not connected to the computer, no language in the world can talk to it, VEE simply pointed out that there was no GPIB interface.
 
            The preface to this whole incident is: I have a much more complex test program that had worked for months on end with no problems, and then all of a sudden it stopped working with no changes to the test setup, the PC or the software. While troubleshooting this problem, I saw that the data and execution flow of the program was doing things I didn’t expect. Perhaps this is just a lack of true understanding of VEE program flow on my part, but I’ve been writing test code in VEE for over 13 years and I’d never seen this. In order to get the program running again, I had to revert back to a programming style I haven’t used since I was a rank amateur. I started using loads of variables instead of passing data through terminals. I know, it’s not efficient or elegant, but it’s working. My questions are: has anyone else run into problems like this? And has VEE program flow changed as operating systems and VEE have evolved?
 
Thanks in advance,
 
Doug
 
 
 
Douglas B. Rudrow
Systems Development Lab Technologist
Aurora Networks
2803 Mission College Blvd.
Santa Clara, California, 95054
U.S.A.
(408) 235-7000 Main
(408) 235 7084 Direct
HYPERLINK "mailto:rvilla@aurora.com"drudrow@aurora.com
 
 

---
You are currently subscribed to vrf as: sherekhan_kl@yahoo.com
To subscribe please send an email to: "vrf-request@lists.it.agilent.com" with the word subscribe in the message body.
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@agilent.com".
If you need help with the mailing list send a message to
"owner-vrf@it.lists.it.agilent.com".
Search the "unofficial vrf archive" at "http://www.vrfarchive.com/vrf_archive".
Search the Agilent vrf archive at "http://vee.engineering.agilent.com".


  _____  

Be a better friend, newshound, and know-it-all with Yahoo! Mobile. HYPERLINK "http://us.rd.yahoo.com/evt=51733/*http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ"Try it now. --- You are currently subscribed to vrf as: ming_meng@agilent.com To subscribe please send an email to: "vrf-request@lists.it.agilent.com" with the word subscribe in the message body. To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com". To send messages to this mailing list, email "vrf@agilent.com". If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com". Search the "unofficial vrf archive" at "http://www.vrfarchive.com/vrf_archive". Search the Agilent vrf archive at "http://vee.engineering.agilent.com".  

Outcomes