JDave

QUOTE(Ben @ Feb 21 2007, 09:13 AM) No, I just feel young and inexperienced. (At least I was born a little before 1979) I also didn't grow up with LabVIEW, since I started with 7.1.1, but I am very grateful to a friend here at work who introduced me and mentored me in LabVIEW. You just need to be able to recognize a good thing and then go with it.

I am glad that my Dad has excellent taste in music, allowing me to also grow up with Dire Straits. Now I want to go home and bring some Dire Straits in to work. :thumbup:

QUOTE(yen @ Feb 15 2007, 11:42 AM) Thank you for your comments. With my current implementation I am very close to what you are describing here for a DB. The refnum in my case was just to force the developer to Initialize the connection before any other actions on the PXI device. I could just output an error from any of these VIs if the Communications FG was uninitialized. Then I wouldn't have to wire the refnum all over my code. I definitely concur that if you need to manage something (connection, data, resources) then having a functional global wrap that up for me is very nice. I guess at this point I have a related question - For a collection of related functions where no storage is needed (or is provided by an internally called FG) is it advantageous to have a single FG with multiple operations, or to have multiple VIs clearly showing their function? QUOTE(yen @ Feb 15 2007, 11:42 AM) I would say that if there is a chance that you could have more than one instance of this, then you should use one of the GOOP frameworks and create a class for this. If you don't, going the FG way is more fun, but just be sure to mind your reentrancy (if you're calling the VIs in parallel). Good point. I will keep this in mind.

QUOTE(LV Punk @ Feb 15 2007, 05:39 AM) This is right up my alley. Thanks for pointing me over there, LV Punk.

I am developing a PXI chassis as an instrument and I was hoping to get some feedback on some design ideas I had. The PXI chassis will need to interface via both GPIB and Ethernet. The chassis has simple command and respond functionality (no synchronization or complex interaction). To accommodate for this dual form of communication, I thought of the following solutions. 1. Have a functional global. Initialize the FG to be communicating either GPIB or Ethernet, then keep that decision inside the FG. Make all calls to the PXI via this FG. 2. Have a series of VIs similar to DAQmx. The different functions of the PXI (Start, Stop, Setup, etc.) would each be handled in a separate VI. These VIs would be wired together with some sort of handle. 2a. Have a custom "handle" that contains whether we are talking GPIB or Ethernet and the appropriate refnum and VISA name. 2b. Have two separate versions of the VIs, one for GPIB and one for Ethernet. (I don't like the code duplication on this one...) Does anyone have any opinion of implementing #1 or #2? Or is there some other method that I should consider? GOOPy ideas are welcome. David

QUOTE(alfa @ Feb 11 2007, 03:47 AM) How did you prove it?

I have occasionally wanted to do exactly that, programmatically fire a built-in (non-user) event. This would be very interesting and useful, but I would imagine it would require a lot of care and know-how on the developers side to use it correctly and not cause bad side effects.

It only appears at edit time. If you run the VI the shadow goes away.

I should have provided better instructions. Thanks.

You can have it be the same control... Just have one ring but instead of placing it "on" the tab, place it hovering "over" the tab. Then every tab sees the same control.

Thanks for this!! I was extracting them in a much more painful manner.

Very very very very nice. These will be very nice. I am finishing up an app that is built around a tree and could have used many of these. Thanks for the contribution. David

Rexxar, If you are asking whether shift registers will work to keep the instrument handles during the whole program, the answer is yes. You might consider incorporating the handles in a functional global. There is a shipping example with LabVIEW called "Acquire-Analyze-Present.vi". This shows a simple version of what you want to do. Frankly the thread title (Simple Event-Driven Queued State Machine...) is a bit of a misnomer. It is simple compared to some techniques, to be sure, but it is the most complex "state machine" I have ever used. It is meant to be able to handle complex problems. It will certainly be able to solve your problem, and you could adapt the example I mentioned to the template. If your program is relatively simple (i.e. init instruments, take data, save data, analyze and present data) and you don't have much LabVIEW experience, it might be best to do the program modeled after the shipping example. You might have noticed that I was hashing the template out as of two months ago. So I don't have a lot of documentation nor examples of using the template. Without an example to point you to, I can't help much. I can't give very good suggestions without a pretty full knowledge of what you are attempting, and even then I would have to map out a good chunk of your application. If you are determined to use the pretty pattern (feel free to ), it will take a bit of work on your part. David

Stan, I hope you understand that the only reason I was playing around with the template is because I really admired the way that LabHSM worked. When you posted a simplified version that was different from a simplified version I had created, I wanted to see where the differences were and what could be improved on. I learned a lot about why you made the template the way you did. I don't want you to think I was offering mine as a 'superior' solution. I was only looking for an alternative solution that made more sense to me. This was for my own personal use and not as a way to see if more people preferred my version. (From the dearth of outside conversation while we conversed I gathered that no one was interested very much.) David The message queue is meant for other VIs running in parallel that want to communicate with each other. If you do not need this then you can safely delete the code dealing with the message queue. I was not documenting the template very much because Stan understood where I was going. I knew I would be changing things so I didn't document it each time. I added some more documentation to the Process Event VI with the example I am uploading here. The following example should illustrate this a bit more. Download File:post-1519-1169509991.zip David

Jim, You are right. I forgot when I played with this that I couldn't get it to work for a VI property. It also crashes LV for me when I try to typecast the App to a GObj and use it. Regarding a list of property indices, there was a post where I requested such a list Here. I never heard from anyone so I started compiling a list. I never finished, nor did I get very far.

You can do it by index. But then you have to hunt down the proper index....... :ninja: I would assume that the indices don't change from version to version, but I also assume that is not a safe assumption. David

Just tie all the channels you are not using to ground.

Why not modify #2 and instead of having a proxy VI, just use a case structure. Wire your constant or control to the case structure and place the appropriate subVIs in the appropriate cases. Note: In LV8.x you can use a Conditional Disable structure so that all switches of this nature are handled at the project level. David

I thought there was something I was missing... Thanks for the clarification. For the "if first load" step, you can use the "First Call?" block found under sychronization. After that it seems that the solution depends on what the .prt files look like. You have to address the case that default.prt does not exist, and if it does exist it needs to point to the correct file. Then you can remove default.prt from the list of .prt files, but load the parameters from the correct file. Is there some parameter in the .prt file that would allow a redirection to the correct file? Another way might be to save a copy of the .prt file with some prefix (~Tiny_Part5.prt). This would require you to maintain just one file with the prefix. Also you might save some settings in a separate file, such as an ini file. One of those settings would be "last part file". Once you know what the correct file is, you have two tasks mentioned. You need to load the file settings to the controls and you need to set the ring to the proper index. It seems that you know how to do this.

To get the file names you can use the "List Folder" function found in File I/O>>Advanced File Functions. Use *.prt as the pattern. You can do some simple string manipulation of the file names to get this. Just run the code to load the ring strings at the start of the VI. You can load the ring with a property node "Strings []". And keep an array of the file names that corresponds to that same array that you loaded the ring with. David

You can't convert a 1 D array directly to a 2D array because you need to specify the dimensions. Look at the "Reshape Array" function in the Array palette. First convert your 1D array slice to a 2D array of the proper dimension, then you can bundle it into the cluster.

Looking at the code, I am wondering how you would know how to parse out the different components at all. Some are arrays, so how do you parse it at all? If each piece was of the same size then you might find some way of doing what you want. But my intuition is that you will have to parse it out and bundle it individually. David

I really like the idea :thumbup: since it gives you the option of putting in little time or a lot of time depending on your situation and interest. It might make it a bit more difficult to judge entries, however. Those who did a little would have a hard time held up against someone who put in a lot of time. But what an app you could end up with!!! Definitely a different strategy for building an open source program... I was thinking it would be nice to have two parts of the Coding Challenge. One that is of necessarily short duration and one that is open ended like previous challenges. David

It sounds like he did peruse the readme. It doesn't talk about version problems. The solution is to go back to 7.1, then you will find everything available. Though there are some interesting workarounds if you look around LAVA a bit... David