Jump to content

Michael Aivaliotis

Administrators
  • Posts

    6,196
  • Joined

  • Last visited

  • Days Won

    103

Everything posted by Michael Aivaliotis

  1. With all this talk lately of subpanels and how they compare to "true" child windows, I decided to see if i could create this same effect with the new sub-panels in LV7. In the LabVIEW examples, there is a VI that shows how you can dynamically register events and click+drag a front panel object. Using this same approach, I tried to do the same with subpanels. The only drawback is that when you register the subpanel event, you lose the ability to click on the subpaneled VI. I thought it would be nicer if you were limited to dragging the titlebar (just like child windows). I then proceeded to edit the subpanel frame and make it "look" like it had a titlebar. Oops, editing the sub-panel frame is forbidden! I then decided to embed the subpanel in a cluster along with a boolean. the boolean would simulate the titlebar. This approach seems to work well. The only thing left to do is track when the mouse is on the edge of the cluster and perform resizing (like child windows). Too bad resizing subpanels and dragging isn't automatic. :roll: Download File:post-15-1073110865.llb
  2. Someone emailed me the following: Some more discussion at NIWeek is expected...
  3. Someone asked me how would I pass data back to the caller. Well, it is really simple since you would use the user parameter. I've attached a modified version with data sent back to caller. This would be the easiest method, however you can wire anything into this even a queue reference if you please. then data can be tossed onto a queue. Download File:post-15-1073111204.llb
  4. In another post, Jim Kring suggested using callback vi's in his own development.:
  5. Yes well, i'm trying to build an installation package for my LV7 executable using installshield so I'm collecting the files necessary for this. So far I've noticed that there are merge modules that you can use in installshield. These are the same ones that the LV7 install utility uses during build time. So far, by poking around, i've found that there are several dll's that you can install to give you support for specific hardware. For example: serial: NiViAsrl.dll gpib: NiVi488.dll ethernet: NiViEnet.dll all need: NiViSv32.dll This means that when you click the check-box: incude serial support, all that happens is the installer calls the merge module which specifies the dll's required. I just wish all of this was documented better or at least give us the resources to selectivly install support for the required hardware. If i can check-off serial why can't I check-off GPIB? Also, to this day I haven't used the built-in LV install creator. Call me stubborn but I just like the flexibility and power that installshield provides. If only NI would publish information on these merge modules and how to use them.
  6. ok, serpdrv has been removed from the shared run-time folder in 7.0. Where has it gone and do I still need it for distributions?
  7. Yes, I just noticed this. Another curious thing... if you run the execution state property on the vi , right after the static reference, it shows the vi running. Is this because it is set for re-entrant run? This means you can run a vi that is running? I guess tis only works for reentrant vi's right? Well, i still don't understand the point of this static reference.
  8. OK, can someone please explain how the static vi reference helps me in LV7? I mean you can drag a vi into it and it gives you a reference but is it really just for property nodes? The online help says: The Static VI Reference acts as a subVI and appears in the VI hierarchy of the top-level VI. You cannot use the Call By Reference node, Run VI method, or any other method to run a VI inside the Static VI Reference node. You also cannot use the Abort VI, Revert VI, Make Current Values Default, Export VI Strings, or Import VI Strings methods on the Static VI Reference node. To avoid recursion, you cannot have a reference to the top-level VI that the Static VI Reference is in. How boring... NI, why do you give us crippled capabilities?
  9. With dynamic events, I was wondering if there was a way to have controls with multiple functions. A good example would be a START button that would change into a STOP button. It would be great to have one event case per funtion and determine dynamically which case will execute for the specified button press. I was thinking that you would have to register the control for each individual function you wanted. Then the question arrises, how do you switch registration over to another event case. Any suggestions?
  10. I don't know how i did it but here it is: Download File:post-15-1073110288.llb
  11. I create a strict-type indicator of enum datatype. I place it on the front panel of a VI. I right-click on the diagram terminal and select "create constant". The diagram constant is a strict-type as well. This is correct, however if you notice the wire connection to the indicator has a coercion dot. Why? Also, on another note. Before (in lv6.1), if you right-clicked on a strict-typed control, you would have the option of "Update From Type def.". Now in 7 this menu item is still there but greyed out. Why?
  12. Actually, you can do this right now. You have to hover over the horizontal scroll bar of the vi panel. Then when you use the scroll wheel it will scroll in the horizontal direction.
  13. I agree on this one. It seems I always place the labels on the left side.
  14. Are you interested in working on an open-source test executive? There has been some interest expressed by myself and others on the openg site but it hasn't progressed much. I have built my own test executive as well but my approach is different. I use the OpenG variant Data tools vi's from the OpenG site. Instead of linking my data to the front panel controls, I define it in a datatype that is built into a Variant Cluster and passed allong a data queue. Each test module has it's own VCluster that is added to this data queue. Also, a test module does not necessarily mean 1 VI. The test module can consist of a group of vi's such as a configuration vi, a test vi, a data presentation vi and a data save vi. Each of these sections will run in a parallel engine and accept requests via a queue. This data queue will also contain the data which will be passed from the test engine. Now with LV7 this becomes easier because of embeded panels. :idea:
  15. Remove VI - Unloads the VI in the subpanel control. If no references to the VI remain, LabVIEW removes the VI from memory. If references to the VI remain and the VI stays in memory, this method does not change the state of the VI. Thanks Jim for pointing that out. There were other things going on in my project that was causing the VI to abort so It wasn't the remove panel method. That's what happens when you're debugging at 3am. :cry:
  16. Ya but if the subpanel is closed already, it generates an error. I guess i should turn off that pesky internal autoerror dialog...
  17. Someone from NI sent me this: This could be the answer since I DO have German environment settings enabled on my computer. However, I was definitly in English mode when this happened. Maybe LV picked the wrong setting on startup?
  18. When using subpaneled VI's the need always arises to send a message to it telling the subpaneled VI to stop execution. This apparently is not required when you run the "remove VI" method. Labview automaticaly aborts execution of the subpaneled vi. This might be a problem if you wan the subpaneled vi to exit gracefully. I guess you could send a message via a queue mechanism but if you run the "remove VI" method after that, there is no way to know for sure if the subpaneld Vi has finished execution. Any suggestions to perform synchronization? It would be nice to have the "remove VI" method contain a switch that you could set to have it "wait until vi completes".
  19. I'm in a situation where I want to probe a subpaneled VI while it's running. While the subpaneled VI is idle, I probe it and run the calling VI. I get the message: Error 1144 occurred at Invoke Node in ...Possible reason(s):LabVIEW: Cannot insert VI in a subpanel control because VI is already open. Doh! Oh well. I then decide to probe the diagram after the Vi has been subpaneled. This seems to work provided you have acces to the diagram. You can do this if you have the vi on the diagram of another VI and then ctrl+dbl-click the icon. This takes you to the diagram. Does anyone know of a better way to initiate a probing session on a subpaneled VI?
  20. I constantly have the need to see if my loop is running. I end up having to stop the vi and wire a small connection from the loop iteration terminal to the wall of the for or while loop. I can then probe the wire to see the iteration counts. It would be nice to have this built-in. All I would have to do is right-click on the node and select probe.
  21. That's interesting, it's not in my full version... Anyone else to confirm this? Since we're on the topic of hiding controls. I think I found a related bug that will cause other problems. You can create a strict-type control, save it, and then place it on the diagram. Now if you goto the diagram you can right-click on the strict-type control and select>advanced>hide control. You will see that the control cannot be hidden, it is still there but you cannot select it or right-click on it either. The image is there only...
  22. I think NI anticipated that subpanels should not be hidden from a right-click option because it is NOT there. They can be hidden via a property node though. I wonder if this is intentional... It wouldn't be too hard to build a utility that would reveal all hidden subpanels if they exist. It would be nice to have a utility that would list all the hidden objects and then you could selectivly perform actions on them. Once an object has been selected from a list, you could run a subvi in your utility to reveal it (or do other stuff on it). Here's some code to display a visible subpanel.
  23. I guess a nice feature to have would be a "show hidden objects" switch available from the menu. Then the objects would appear in a different color to indicate that they are actually hidden (greyed out?).
  24. Well, I got it working. Apparently NI changed the default action for the options input on the "open VI reference" function. Previously you could leave the Options input unwired and LV would instantiate a VI from a template if the template was NOT already In memory. If it was in memory then it would just open a reference to the actual template. In LV7 you have to specify the options bit set in one mode or another. Otherwise it will error out if you try to open a reference to a template vi and it is always in memory. You have to specify: 0x02 | Open templates for editing. Another little thing to watch for when migrating to LV7. :wink:
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.