04-27-2011 05:12 PM
Hi guangdew1,
As previously stated, you must wire through all cases. If you would like to see specific documentation on this, LabVIEW Help can be very useful. Go to Help-> LabVIEW Help-> Case Structures-> Failing to wire a tunnel in all cases. I have also attached the description below. As described below, you may have defaulted unwired cases to wire automatically. In which case, even if you did not manually do this, they are still wired through as they should be.
A common error with Case structures, Conditional Disable structures, Diagram Disable structures, and Event structures is neglecting to complete the wiring in all the cases. When you wire to an object outside the structure, an error results if you do not connect a source in all the cases.
Consider configuring the tunnels to wire the input and output tunnels automatically in unwired cases.
Best Regards,
Jackie
04-28-2011 12:32 PM
Hi Jackie_B,
Thank you for your help.
I think I know now what is the proper way to do it, but I still don't feel very comfortable doing it this way. Like in my program, the event structure has over 20 cases and I only need the Visa resource name in few of the cases. What I'm doing right now is that I wire the Visa resource name around the event structure. I also wire it into the event structure because I still need it in few of the cases but I do not wiring it out. Please let me know whether it is the proper way to do it without wiring it through every case.
Best regards,
04-28-2011 01:15 PM
Two points I would like to add-
the Properties of a given VISA resource can change By wiring into the main event loop on a tunnel any changes that you make do not get passed on to the rest of the cases so in effect, you can naver "do anything" with the properties. Many drivers use User Data to maintain device information and this practice WILL byte you someday.
Why does the event structure need to know ANYTHING about a resource that is used in a few cases? Thinking it through the event structure isnt acting on the VISA session only the driver vis for the specific IO device need to know anything about it and you are only going to do a limited number of things with that device.
Typically: Init, config, read, close. A very managable short list for most devices that can be enumerated briefly.
For most IO I have developed a tendancy to use a construct like this:
Type def the controls (and / or write wrappers for the individual actions) and the code really screams when its time to debug or change equipment models ! the event structure isn't cluttered with info it does not need and some very interesting error handeling can be added if desired.
04-28-2011 04:27 PM
Hi Jeff Bohrer,
Thank you for your help, even though I do have problem understanding the example you provided. It reminded me something, such as this serial port, is it possible that after we configure it, we don't wire it anywhere, we use the constant COM1 wherever we need it, I don't know whether it will be just as configured. I'll try it later, I don't know whether it will have some potential problem that we couldn't foresee.
My main thought here is that for things that doesn't change during run time, is it okay that we don't wire them out of event structure, we wire around it for later needs. We wire it into the event structure so we can use it in certain cases, but we don't wire it out, so we don't have to wire every case.
Best regards,
04-28-2011 07:16 PM
@guangdew1 wrote:
Hi Jeff Bohrer,
Thank you for your help, even though I do have problem understanding the example you provided. It reminded me something, such as this serial port, is it possible that after we configure it, we don't wire it anywhere, we use the constant COM1 wherever we need it, I don't know whether it will be just as configured. I'll try it later, I don't know whether it will have some potential problem that we couldn't foresee.
My main thought here is that for things that doesn't change during run time, is it okay that we don't wire them out of event structure, we wire around it for later needs. We wire it into the event structure so we can use it in certain cases, but we don't wire it out, so we don't have to wire every case.
Best regards,
Glad to help,
With the serial port DEFINATELY all you need to do is <init, write, read, close> "What" to write can be passed into an Action Engine construct like this. What was read could be passed out! the VISA session can stay on the shift register in this "module" and does not need to be wired through the callers AT ALL
the caller just needs to call the module with and provide the "Action" <Init, Read, Write, Close> and any parameters that are needed for that action (String to write, Timeout value)
Similar constructions are mentioned in Ben's famous Action Engine nugget (click my profile > look at my tags> select "Required Reading", OR find a post by Ben and click the "trouble with race conditions? link in Ben's signature) and some applications of similar modules are contained in (and still being discussed ) in the examples in "Community nugget series: Application development installment 2: there is a link to the series currently floated to the series at the top of the LabVIEW board.