Jump to content

bbean

Members
  • Posts

    252
  • Joined

  • Last visited

  • Days Won

    9

Everything posted by bbean

  1. One other suggestion: Since your app and the db are on the same computer, use a "shared memory" protocol instead of TCP/IP if you haven't already. Also as mentioned above, 1) Separate DAQ and DB Loops 2) Initialize connections to DB outside loop 3) Use stored procedure for inserts Can you post a snapshot of the code? and a SQL script of the create database commands?
  2. QUOTE(Dean Mills @ Oct 15 2007, 04:25 PM) Dean's right. Don't forget to return settings to normal after your done debugging. Sometimes not having reentrancy on can screw up some events. I also use the attached tool to record event occurrences as they happen to a file.
  3. QUOTE(yen @ Sep 2 2007, 02:16 PM) Sorry Yen, Backsaving doesn't work.
  4. QUOTE(Neville D @ Aug 23 2007, 08:08 PM) BD and FP size are available during runtime but Data Size is not. BD and FP don't seem to change while the VI is running
  5. Is there a VI property/method or way to return the currnt memory usuage of a VI that is running? How does the profiler accomplish this? The reason I need to do this is that I want to monitor the memory usuage of template vi instances that I run. If I start the profiler before I run the application to track memory usage, the instances of the VIs are shown when they are opened, but they always show 0k for their use. I was also contemplating creating a graphical memory profiler....has this been done before in LV? B
  6. QUOTE(tcplomp @ Aug 21 2007, 12:56 PM) :ninja: I see
  7. QUOTE(tcplomp @ Aug 21 2007, 12:23 AM) Redraw event? I'm using LV8.2 and don't see it.
  8. QUOTE(MikaelH @ Aug 20 2007, 06:05 PM) Thats what I was afraid of.
  9. I want to capture when a user clicks the title bar and drags a front panel window to a new location. I only found a "Panel Resize" Event which doesn't fire when the user "moves" the front panel. Am I missing an easy way to do this?
  10. QUOTE(yen @ Aug 18 2007, 02:49 PM) Just what I was looking for. Thanks.
  11. Is there a way to get a cluster of all the properties for a graph? I would like to store most of the properties of a graph to file and then recall them later in. It seems like there should be an easier way than building a giant cluster manually and saving it to an INI file. I've found a "Plot Attributes" cluster that can be retrieved utilizing the event structure. http://forums.lavag.org/index.php?act=attach&type=post&id=6674 But I haven't found a way to pump this cluster back into the graph without unbundling the entire thing an manually wiring up each property to a giant plot property node. http://forums.lavag.org/index.php?act=attach&type=post&id=6675
  12. http://forums.lavag.org/index.php?act=attach&type=post&id=6526 I keep getting this error and even if I delete the file it mentions. It doesn't get fixed. Also I don't even think I have a "controls" pallete in the user.lib directory. :headbang:
  13. anyone ever seen this error caused by a registered activex event in LabVIEW 7.1: http://forums.lavag.org/index.php?act=attach&type=post&id=5856 It crashes the VI after execution and the error log says: D:\lvmerc\src\source\execsupp\eventoracle.cpp(392) : DAbort: panel-locking Event callback not in UI! The interesting thing is that only one of the registered events "cmdended" causes the crash, but the other one works fine. And, it does not crash in LabVIEW 8.2. I googled and looked at the NI boards, but nothing was very clear about how to fix the problem.
  14. Found the problem. Turns out even though the USB-6211 has 2 ctr outputs (Ctr0 and Ctr1), you can only use one at a time if you are doing a finite pulse generatation. If you set up one ctr as finite pulse generation it uses the other ctr output for a gate. So in my case, when I moved the stepper motor using ctr1, it sent ctr 0 (gate) high (causing unwanted strobe). As a work around I moved the strobe to an analog output and used square wave generation to fire the pulses.
  15. QUOTE(PJM_labview @ Apr 26 2007, 02:56 PM) I guess I'm suggesting abandoning storing numbers as strings and store them as their true type. I believe the only reason they are stored as strings in the OpenG is because config file format is a string. I guess I don't see why "float number format" is relevant to TDMS files, because you will probably never use a text editor to look at a TDMS file. If the numbers are stored in their native format, you can always use "format into string" primative to display in the "float number format" of your choice
  16. QUOTE(PJM_labview @ Apr 24 2007, 11:35 AM) I think it would work best by removing the "float number format" and adding three inputs on the original VIs.: 1) Group (string - optional): for the TDMS group. If blank chooses how to write based on 3). 2) Channel (string - optional): for the TDMS channel. If blank writes to the Group specified 3) Use cluster name for Group if group/channel blank (boolean - default true). If you set this to false and left channel and group blank, the VIs would read/write to the root of the TDMS file I believe you can remove the float number format since the number type is stored natively in the TDMS file (except the complex at this point).
  17. QUOTE(PJM_labview @ Apr 23 2007, 05:01 PM) I have already found a need for it. When I store multiple traces (channels) of data with peak detection, I store the cursor list cluster (peaks) to the channel's property. Then I can pull up all the channels and the peaks recorded during data acquisition and plop them on the graph pretty easily using the "TDMS File Viewer.vi" and the TDMS file. Its nice because it keeps everything in one file. What do you mean by more complex? Do you mean you have to specify the channel and group every time you write a cluster? I was thinking the "channel and group" write/read functionality would be additional VIs not replacements for the default option which would be to write/read everything automatically. Brian
  18. I have a USB6211 DAQ device I'm using to control a strobe and a stepper motor. The strobe is controlled by ctr 0 (a high pulse fires the strobe). ctr 0 is also jumpered to P0.0 (a digital input) to trigger acquisition of some analog signals. The stepper is controlled by ctr1 and Digital Input P0.1 is used to find a zero position on the stepper index (high is zero). http://forums.lavag.org/index.php?act=attach&type=post&id=5611 Everything seems to work fine most of the time, but sometimes the USB6211 gets in a weird state where every time the stepper zero input (P0.1) goes high or the ctr1 task for stepping starts, the strobe (ctr 0) fires. This undesirable behavior seems to happen after the user hits the stop/abort button and then restarts the program. Its almost as if there's crosstalk between the P0.1 and P0.0 inputs that gets fed back to the CTR0 output via the jumper. If I send a reset device command via max this behavior stops. Does anyone know what might be happening? Do I need an additional pulldown resistor on the ctr0 output to hold it low? Thanks, Brian
  19. QUOTE(Ben @ Apr 23 2007, 09:27 AM) Probably. But I haven't worked with Diadem at all. Attached is a modification to the library that contains a quick fix to the numeric problem. Keep in mind it was done quickly to check the option of storing the data natively. So there may still be bugs. As an extra bonus it also has a new example that saves clusters to specific group/channel. This is nice because you can place your cluster properties at any level in the TDMS format. Let me know what you guys think. Brian This post should probably be moved / combined with http://forums.lavag.org/index.php?showtopic=7486&st=0&p=28510entry28510' target="_blank">TDMS for big config clusters -- is there a better way?
  20. QUOTE(Herbert @ Apr 20 2007, 02:43 PM) I'm really excited about using these TDMS files and an OpenG variant config for TDMS. I started to implement the stuff from PJM :thumbup: . Thanks for all you help. When I added a numeric to the clusters I found it was not reading back properly. http://forums.lavag.org/index.php?act=attach&type=post&id=5604 I believe this results from the fact that the TDMS Write Key write the value as a string: http://forums.lavag.org/index.php?act=attach&type=post&id=5606 and try to read it back in using its native datatype. http://forums.lavag.org/index.php?act=attach&type=post&id=5607 Before I start working on improvements this brings up a few questions. 1) Should we formalize the development in OpenG and start tracking the version changes. 2) Should we store data in the TDMS file in its native datatype (dbl, u32, etc) when possible for compatibility with other software Diadem, etc or should we just store it as a string and convert it back to the data type when we do the read.
  21. QUOTE(Ben @ Apr 20 2007, 08:45 AM) Seems like the boolean data type is not supported directly by TDMS. I modified the Read TDMS Key (Variant)__TDMS.vi to use a string type and it seems to work. It was just a quick fix so I don't know if other issues exist. http://forums.lavag.org/index.php?act=attach&type=post&id=5562''>http://forums.lavag.org/index.php?act=attach&type=post&id=5562'>http://forums.lavag.org/index.php?act=attach&type=post&id=5562
  22. QUOTE The holiday was all skiing and beer in Canada. Highly recommend the Banff area for skiing, even in late March. QUOTE The idea of the dynamic create being able to choose the correct object based on the persist file is in interesting idea, I quite like it, I'm not sure yet how to correctly implement it. The demos I've put together that implement persistence are proofs of concept at the moment, I think there are better ways of achieving it, I need the time to tinker with some ideas and begin working it into the mechanics of the object. You are right, the persist file path doesn't really belong in the datamembers but probably in the object cluster, but this was the quick fix until I can create a GOOP template that provides it. It would be cool if you would like to participate in this. Sure. QUOTE I suppose the direction you take with this depends on the time you have to do your project. If you can tolerate having the persist file path in you data members then go with the architecture I've provided, however if you have the time to tinker then carry on, I don't think you are wasting your time, its just a matter of how much time you have, this stuff is fun after all. In the mean time I'll play with some ideas and post them up for discussion. BTW I posted up a built exe version in 8.2 of the DynamicPersistDemo that you would no doubt be interested in, see the following post. Question about making the Executable file with GOOP or download the code from here I saw that right after I posted the message. I'll take a look
  23. QUOTE Kurt, Got back from vacation and am starting to look over everything. Everything works great. After looking at your code I started to feel a little braver and wanted to revisit some of the approaches I tried before I saw your example (probably a bad idea). What I was trying to do with the GoopTemplate Pump Examples was implement the Factory pattern from LV8.2 shown here: See http://jabberwocky.outriangle.org/Factory_UsingVIs.zip and http://jabberwocky.outriangle.org/Factory_UsingClassRef.zip using the GoopTemplate in LV7.1. The motivation as i see it (may be wrong) behind using the Factory pattern is to seperate the Persist Path data member from the pump object because it doesn't seem like persist file path should be a member of the Pump object. Also the factory approach seems like a very flexible means of abstracting the creation of Pumps (or any other objects). Attached is half-hearted attempt to implement this pattern. The Pump Save.vi creates a digital pump object with a VISA Data IO member, then saves the object data to the ini file under the objects instance name as a section header. After that, I try to implement the pumpfactory to read the pump data from the file dynamically. http://forums.lavag.org/index.php?act=attach&type=post&id=5405 In the PumpFactory I attempt to determine the pump type by reading the "object type string" from the ini file header and then comparing it to the list of "Pump types" in "Pump Factory". Once the type is determined, I would like to dynamically call the appropriate Pump.Create (as opposed to creating a case statement with the hard coded Pump.*Create objects). I guess I'm stuck here and wonder if I'm wasting my time. http://forums.lavag.org/index.php?act=attach&type=post&id=5406 Thanks for all your help, Brian
  24. Thanks Kurt. Its going to take me a while to digest this. Unfortunately (or Fortunately) I'm going on vacation tomorrow for a week. I'll take a look in detail when I get back. I like what I see so far. One question: 1) Is there any reason you made the Persist Method private? It seems like it would be a candidate for a virtual function call. I realize its called in the virtual method of Destroy.
  25. QUOTE(SciWare @ Mar 22 2007, 02:38 AM) Thanks. I use the OpenG Variant package a lot for other projects. I was able to save the Pump.Digital data members to an ini file using the OpenG code. The attached file shows what I have so far. I didn't create the persist method for the DataIO member of the Pump Class because I couldn't determine how the Config File Reads would automatically determine the instance type of the DataIO object from the sections created by the Pump.Persist methods. For example, if one pump has a DigitalIO object that is a DataIO.FieldPoint.Digital and another pump has a DataIO.Datasocket.Digital. The "type" key in the "DataIO object" section of the ini file only says "DataIO" not the specific instance type. Also if I have a collection of pumps how do you distinguish them in the INI sections? Do you add the instance name to the section header? BTW I was going to post on the sciware forums ( http://sciware.com.au/forums/''>http://sciware.com.au/forums/' target="_blank">http://sciware.com.au/forums/ ), but they seem to be down. Thanks for your help. Brian
×
×
  • Create New...

Important Information

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