Mark Balla

Are you trying to write these input values to an INI file ? If so we talked about it in this thread. http://forums.lavausergroup.org/index.php?...ic=835&hl=openg

In February of 2005 around Valentines Day (icon color scheme Red & Pink) I was working on a project for work that now has approximately 1100 Vis in it. As the program expanded the block diagrams also start to expand so like a good little wire worker I start condensing the diagrams by creating subvis. Now being somewhat of a perfectionist concerning good looking code, I was unable to tolerate the mess that LabView leaves me when a SubVi is created. I found myself spending too much programming time fixing subvis. I was inspired by David Boyds Tunnel wiring wizard and how much time it saved. I had also been tinkering with scripting so I started building a tool that would do all the busy work for me. Thus the SubVI FIXER was bourn. The main purpose of the SubVI FIXER is to reduce the time it takes to cleanup a SubVI that is created by LabView. There are 3 major steps to accomplish this. 1: Wire controls to desired connector pane terminals. 2: automatically arrange front panel objects 3: Clean up. The primary assumption used by the FIXER is the front panel objects relative location is representative of how they are wired to the connector pane terminals. As shown above (error in) is located in the lower left corner and therefore wired to the lower left corner of the connector pane the other controls are also wired to their relative location and are arrange in the same orientation as the desired terminal pattern The Read me document explains all the steps in greater detail. Download File:post-584-1122094477.zip In Short the FIXER works like this. If we start with this The user arranges the front panel to look like this. Adds text for place holders Selects all controls and indicators. Presses Ctrl-Shift-SpaceBar and presses 5 buttons. The FIXER Generates this. Wired, Labels conformed, Front panel arranged, relinked and saved. What use to take me more than 3 minutes now takes me only 50 seconds. Only 1200 more subvis to go and this baby will have paid for itself. I had to seperate the program into 4 parts so I could transfer it to the site. all of the zip files should be extracted into the same folder. Download File:post-584-1122091741.zip Download File:post-584-1122091787.zip Download File:post-584-1122092205.zip Download File:post-584-1122092240.zip I tried to design the program structure to be easy to modify and adaptable. Any coments or feedback would be greatly appreaciated. I realy hope this saves people time.

I find I'm using tab controls more and more to do this sort of thing. No property nodes necessary to hide a control and you only have to change the tab control value. Another Idea would be to combine several control references into an array and use a for loop to set the visible property. and if you turn it into a subvi it will take up even less space. SubVi are our friends

Usually I try to do the data checking while the user in inputting the information. If they enter incorrect data I will erase the input box and ask them to try again. I've attached a basic serial number dialogue box that I use as a template. good luck. Download File:post-584-1121312835.vi It depends on how your code is structured. If you could post a vi I would be happy to look at it.

I can't resist helping someone who is able to combine two of my favorite things together LabView and Beer. :thumbup: :beer: I made some modification to your code that may help. I removed the digital input line vi and replaced it with the standard daq vi and then wired in the itteration input. It unclear what exactly the burp line does or how long it stays on. I added an option to trigger off the rising edge of the inputs so calculation will only be triggered once a cycle. Hope this helps if not give me some more details and I will be happy to help. Download File:post-584-1121312098.llb

Do you have any of the NI Vision tools? Also can you give a little more detail on what hardware you are using to aquire the picture.

I now understand LV2 globals and how they function but whenever I have used one I have only needed to use one instance of it. Now the case has arisen where I may want to have two instances of the same global, ie, two different data sets. The painful way to do it would be to make a copy of the LV2 VI and rename it two a second file. As I said though, I'm almost sure I've read a better way to do it... one where the same file can be instantiated or something of the sort, which would not require duplicate changes if the core functionality needed to be updated. 5073[/snapback] The idea of many of the same data sets or Objects is the reason GOOP was created. Try looking into the OpenG Goop. If not how about Instead of one Cluster in your LV2 global why not use an Array of them. Then create a terminal that specifies which element in the array to operate on.

A BIG second on this Idea. I use the delete button so often that I made it one of my programable buttons on my mouse. Have you submitted this to NI?

Here you go.

Here is a Demo program that shows how I would approach this program. First separating the User interface from the Processes by using separate loops Next Use a state machine to separate out each process and Daq event. Finally tranfer commands between the 2 loops by using a Que. Download File:post-584-1117644639.llb Hope this isn't too far over your head. This is my favorite type of structure and I use it in various forms for all of my programs.

First make sure that that you are using Waveform Charts not Graphs. Graphs will only accept arrays or special clusters. Try this code to pull the data out of the subvi. Download File:post-584-1117597826.llb I would only do this if the subvi acquiring the data is slow >200 ms per reading. The reference method is useful for this type of application but it is not recommended for acquiring data fast.

Here is how you would do it using the event structure. Select Vi with the mouse up option Wire off of the button terminal for start or stop. The mouse cursor must be over the front panel when the mouse is clicked in order for the event structure to pickup the event. As for making it work in you attached vi thats another issue. You may want to consider using a state machine or other method to organize your code.

I assume you are refereing to an ENUM type

There may be a better way to do this but here is what I came up with. Download File:post-584-1116445688.llb Download File:post-181-1161869716.doc

Yes. in dqgoop it is done this way. Also "OpenGOOP Data Core.vi" does the opposite conversion. If you want you can make changes in the "_OpenGOOP_classtpt" folder. The wizard uses these vis to create classes.

There was another discussion about the OpenG goop here http://forums.lavausergroup.org/index.php?showtopic=1109&hl= It has some tips on avoiding issues that other programmers have run into.

Here is the latest Goop Ideas branching off of the dqClass. DQ3 uses a Que with 2 elements data is locked when only one item is in the Que to lock data one of the items is dequeued. to write new data the Que is flushed and two data items are enqueued. Download File:post-584-1115993086.zip I also created a possible core replacment for the OpenG template using the DQ3 Idea. Download File:post-584-1115994581.zip DQ4 uses a Que with 1 element and a lock bit bundled inside the Que data. Data is locked when lock bit is set true. to lock data the the data is dequeued the bit is set true and then data is enqueued. to write new data the data is dequeued and the new data is bundled with a false lock bit and enqueued. Download File:post-584-1115992930.zip DQ5 Uses two 1 item Ques one for the data and one for the lock bit. Data us locked when the lock Que is empty. to lock data the lock bit is dequeued. to write new data the data is dequeued and new data is enqueued and the lock bit is enqueued Download File:post-584-1115992961.zip All of the above allow the data to be read while the data is locked. The original dqclass did not. Here are my performance test results

Thankyou for mentioning this. Stan is acually the one responsible for getting me excited about Goop. I was first exposed to Goop when I attended his pesentation at NI week. I agree, It should be a core replacement and I've already done this with my OpenG Goop template. But I sometimes tend to jump on the band wagon too quickly and in the past have regretted not testing out new Ideas or ask for others opinion. In my initial post I didn't really ask anything so I'll do in now. Is this the next step in the goop evolution. Does anyone see any issues, preferences or ways to improve the DQ2 or DQ3 Ideas.

You could change the row and collum property node Is this what you are trying to do?

Taking The original dqClass I created a new class calling it DQ2 and modified it as I stated in my email. Download File:post-584-1114495781.zip Using the TestClassPerformance.vi I got the following results. Not exactly what I expected. The DQ2Class was much faster at creating and deleting than the openClass but it took twice as long to run the Modify Data vi. If any one has any ideas why this is so or got different results please let me know. Any way the times were not even close to the original dqclass so I created a new class that eliminated the Semaphores. Download File:post-584-1114500356.zip The 3 vis that changes were Create New getDataToModify setModifiedData And the performance results were much better. That is what I have so far. Does anyone have anything to add.

With Brian's permission I would like to start a discussion on his new implementation of goop called dqGoop. For those of you that are not on the OpenG mailing list Brian Gangloff has developed an new way of doing goop using Ques here is his original zip file. Download File:post-584-1114495400.zip It contains 3 different implementations of goop. niClass(Endevo version of goop with locked BD ), openClass(OpenG's version of goop ) and dqClass(new version using ques ). Each of the class have vis that can be used to compare performance. After playing with the dqClass awhile I replied with some ideas and here was his response. Hi Mark and Jim, Thanks for looking at dqGOOP. Since Mark and Jim both brought up the same point, I will just reply to the one and copy everyone in. Brian Mark Balla wrote: > > Brian, > > I was playing around with the dqGoop this weekend. Very nice Idea Goop is probably my favorite LabView topic. > This approach looks much more elegant as well a smaller footprint. I am very interested in any information you have on performance > improvements with dqGoop vs. OpenGoop. > Did you download the zip file that that was mentioned in the email that you replied to (bottom of this one as well)? It has 3 test classes, they can be found in the respective ..\Testing directories. OpenGOOP does very well on get and set, but the create time is very slow. Please run the tests on your computer and let me know how dqGOOP compares. > I have a suggestion to help fix an issue I found. > > First the issue > Because the Modify Data vi removes the data from the Que this leaves the que blank. So any program that needs to only read the data can not > do so until the data is put back. This creates a bottle neck in Goop vis like mine where several loops only read the object data and only 1 or 2 > vis change it. If I have a Modify vi that takes 500 ms to update the data then all the read vis must wait that time before moving on. OpenGoop does > not have this issue because the semaphore only stops other programs from changing not reading. > It has been my opinion (and I could be wrong), that locking the data should do just that, lock it. Once the Modify VI gets the data, it is no longer valid data since the Modify VI is changing it. The question is then, when you want to get data do you want the latest data (wait for lock) or is old data OK. dqGOOP currently provides the mechanism for the first, but as you and Jim have pointed out there isn't a way for the second. The attached new template could provide a solution for some instances with only a few Modify methods, but could end up with a race condition if you had many Modify methods. I will have to think a bit on how to provide access to old (last before lock) data. I don't have the time to look at your example code, but from the description it sounds like too much overhead. If you haven't yet, read the first three topics in the help file. They give a good description of why I started to develop dqGOOP, but it all boils down to performance. I have applications that need to be able to create and access many GOOP objects quickly. > I think I found a way to avoid this issue with only a few changes to the core code. > Suggested Changes > > Create New Object Vi > Instead of a Que size of 1 use a size of 2. Most of the time there will > only be one data set in the que except when updating changed data. > > Get Data to Modify Vi > Acquire a Semaphore > Preview Que data. This will still allow others to read it also. > > Set Modified Data Vi > Enqueue the New Data > Dequeue the Old Data. This leaves only the new data remaining while never > forcing other vis to wait for data > Release Semaphore. > > I have example code that I've attached. > I will look at it but it probably won't be until next week since I will be out of the office this coming week and half of the next. > dqGoop may be the concept that brings Goop the the masses. > I hope so, but credit has to be given to Endevo for bringing it first and OpenGOOP for providing the first open source version. > I don't know if you are a LV8 beta tester or not but this approach > will fit very nicely with the new LVOOP classes. > No I'm not, but its good to hear. I like "LVOOP" class, is that NIs official terminology? > Can I request that you please create a post on Lava or OpenG or both > so we can start discussions with the LV community? > Yes, but probably not until I return. Or if you want to start one, I can join when I return. > Great concept and thanks for sharing it. > Thanks for looking > Mark Here is the example code that I attached. Download File:post-584-1114495473.zip I'll talk about my preformance findings in a later post.

Taking it to the next level Try these vis I have several time vis in my toolbox that I use all the time. I posted an explanation on the custom time probes here. http://forums.lavausergroup.org/index.php?...2359entry2359 Download File:post-584-1114183839.llb

Your Welcome Thanks for the feedback.

The simplest way is to convert the output to a bool array and then use index array to extract out each bit as shown. if you want to get a little more fancy check out this post http://forums.lavausergroup.org/index.php?...3969entry3969