Jump to content

bbean

Members
  • Posts

    252
  • Joined

  • Last visited

  • Days Won

    9

Everything posted by bbean

  1. How fast can you run your acquire and processing loop if you do not display? So passing the imaq reference to a display loop with a notifier doesn't work because you are afraid you may be overwriting the "displayed" image in the notifier loop?
  2. Can you share your code? Are you doing any image processing? Can you drop frames on the image processing?
  3. Threw together some quick code using an Express VI (GASP) to test the theory. Haven't run or debugged other than with my webcam. The Queue should prevent race conditions and provide a little margin on processing. Not sure how many data copies of the images will exist. Don't have time to investigate. Bean BufferTest.llb
  4. does anyone know if the code for the Edit Format String dialog box is written in LabVIEW and is it available somewhere in the LabVIEW directory?
  5. Yes. We had a similar experience using VISA but with USB Raw calls in parallel to an FTDI chip on a NI RMC running LabVIEW 2012 RT (no virtual comm port). We ended up having to remove the parallel loop and could not determine the root cause.
  6. Not sure if this is relevant to the conversation, but I wonder if the FIFO.Acquire Read Region DVR to TDMS technique discussed here: http://lavag.org/topic/15335-why-tdms/?p=109716 would help with your scenario if you need to push performance. See also: http://zone.ni.com/reference/en-XX/help/371599J-01/lvfpgahost/fpga_method_fifo_acqread/
  7. Is your database located remotely on a network? If so I would implement my first recommendation to open the connection to the database separately and leave the connection open all the time. That way you don't have to re-establish the connection each time to access the DB. Now you will have to add error checking and loops to re-establish the connection if it goes down. My guess is you are seeing some network latency or some type of issue related to the nagle algorithm bunching your packets together.
  8. The DB toolkit is really just a wrapper for the activex methods and properties you are using. One thing you could try is opening the connection to the database separately first (see DB Tools Open Connection.vi), executing a query with a forward only cursor on the connection (see DB Tools Execute Query.vi), and then "fetch" the recordset (DB Tools Fetch Recordset) like they do in the DB toolkit. This way you can separate connection problems to the database from querying problems of a large recordset.
  9. I am working on an RT app and hardware that uses more than 50 USB devices connected via USB hubs to an NI rackmount computer. After a hard reboot of the rack mount computer, the USB devices and hubs take more than 5 minutes to enumerate. I am looking for a way to verify all the USB devices have enumerated. Polling VISA Find Resources appears to cause the entire system to lockup if we start it immediately in RT app. If we manually delay for 10 minutes or so in the application and then call VISA Find Resources, it appears to work OK as long as all of the devices have successfully enumerated. A hard-coded 10 minute delay is not optimal because on soft reboots, the delay is unnecessary. Are there any other ways to get the state of system USB enumeration other than VISA Find Resource? During reboots, the NI boot loader takes a minute or so to "Enumerate USB devices" but it appears it only enumerates each USB hub before it completes and moves on. PS. I know there are latency issues using USB on an RT system. We chose to use the RT platform for stability (no windows updates, etc) vs determinism. This may or may not be a good reason, but its what we have now.
  10. why not mouse events associated with the graph?
  11. For the first time in my career I may need to compile LabVIEW code so it runs stand-alone on a MAC. Can anyone point me to a "compiling LabVIEW on a mac for windows dummies" article or webpage? A quick google search yielded limited results. My development machine is Win7 and I have VMware. I assume the process goes something like this: Obtain Proper Mac OS $$? and Install as a Virtual Machine in Vmware (I have VMware, don't have the Mac OS disks) Obtain LabVIEW for Macintosh with Application Builder $$? (I have a LabVIEW Professional license windows, can I just download/install LabVIEW for Mac on the VM and use my license) Install LabVIEW for Mac on Mac VM Copy VIs from windows development machine to Mac VM Press Easy button on LabVIEW for Mac and compile VIs to mac executable and build installer. Install on mac machine Profit The application uses serial port (any issues here with VISA?) for communication to a few instruments but no data acquisition. BTW my Mac experience is pretty limited...I can move the mouse around and click things but I still haven't figured out how to right-click . Any pointers or suggestions for avoiding common pitfalls are welcome. Thanks.
  12. Version V100_LV2012

    187 downloads

    This Quick Drop (QD) plugin complements the functionality of the built-in QD plugin (CTL-Space-CTL-D) by wiring between selected controls, indicators, constants, and SubVIs. Default Shortcut - [W] Normal Operation Wires selected nodes in left to right order. Attempts to connect any common unwired terminals in between the far left and right nodes by checking the datatype, Name, or Caption. Holding Shift and the Shortuct: Wires controls to unwired far left Node terminals and indicators to unwired far right node terminals. This is just something I put together as my first attempt at a Quick Drop plugin. Something similar has been done previously to wire the corners of subVIs using the right click framework by user JCC_(SK): RCF Plugin - Wire Nodes by Corner - https://decibel.ni.com/content/docs/DOC-8386 . Code for this plugin was developed prior to knowledge of the JCC_(SK) RCF code and probably doesn't function as well since it hasn't been tested thoroughly. However this plugin is for quick drop and has some added capability to wire up all like terminals but can suffer from potential overzealous wiring. Just delete extra wires if necessary. Thanks to the NI guys for creating the QD template with good instructions. Someone may have done this already but I'm putting this out for comment anyway. <a href="http://www.screencast.com/t/PZhMafM2">WireAndConnectVideo</a> http://www.screencast.com/t/PZhMafM2
  13. Name: Wire And Connect Quick Drop Plugin Submitter: bbean Submitted: 03 Apr 2013 Category: *Uncertified* LabVIEW Version: 2012 License Type: BSD (Most common) This Quick Drop (QD) plugin complements the functionality of the built-in QD plugin (CTL-Space-CTL-D) by wiring between selected controls, indicators, constants, and SubVIs. Default Shortcut - [W] Normal Operation Wires selected nodes in left to right order. Attempts to connect any common unwired terminals in between the far left and right nodes by checking the datatype, Name, or Caption. Holding Shift and the Shortuct: Wires controls to unwired far left Node terminals and indicators to unwired far right node terminals. This is just something I put together as my first attempt at a Quick Drop plugin. Something similar has been done previously to wire the corners of subVIs using the right click framework by user JCC_(SK): RCF Plugin - Wire Nodes by Corner - https://decibel.ni.com/content/docs/DOC-8386 . Code for this plugin was developed prior to knowledge of the JCC_(SK) RCF code and probably doesn't function as well since it hasn't been tested thoroughly. However this plugin is for quick drop and has some added capability to wire up all like terminals but can suffer from potential overzealous wiring. Just delete extra wires if necessary. Thanks to the NI guys for creating the QD template with good instructions. Someone may have done this already but I'm putting this out for comment anyway. http://www.screencast.com/t/PZhMafM2 Click here to download this file
  14. Do you know if NI support ever run the app with win debugging tools AND the LabVIEW symbol files (which they hold very closely)? Did you get to NI tech support directly (ie. 800 number or email) or through your local sales staff? I had a nasty bug (random labview crashes, random blue screens, random black reboots) that I spent weeks debugging. I finally escalated it through my local sales staff indicating how much money they would lose from my customer (hardware wise) if I couldn't get the problem fixed. They were very helpful and knew the right people in Austin to contact for help. Long story, but it took another week of debugging the code with an NI programmer using Win debug and the LabVIEW symbol files to find out it was a hardware problem (memory chips). Our customer purchased the 4GB memory chips for the PXI racks from a reputable manufacturer, but they were not the 400$ a pop NI certified 4GB RAM memory chips that are coupled with PXI hardware. It sounds like your app is running on a desktop or laptop but does this crash always happen on all Windows 7 64 bit machines you've tested it on? If it doesn't always happen on all machines it could be hardware related (other than the 64 bit processor). Have you tried running Prime95 on the 64bit machines that crash? http://files.extremeoverclocking.com/file.php?f=205
  15. For me it seems to be when I try to download from a link (only some not all). For instance, clicking on "click here to download this file" on this CR: http://lavag.org/topic/16360-cr-messenging/ i.e. this link: http://lavag.org/files/file/220-messenging/ causes this error:
  16. I'm still having this problem.
  17. I think you hit the nail on the head here. After pestering the customer, it turns out they are calling from an unmanaged Hamilton interface Interesting I'll have to check this out Not going there at this point Thanks for your help
  18. For the project I'm working on we created a LabVIEW build spec to create an interop dll that exports interfaces for several of our VI's. When we give the interop dll to 3rd parties that need to call the dll, they claim that they need to create a "wrapper dll" to call our interop.dll. They indicate that the exported interfaces are "static" and that they can't call the interopdll directly. They were also asking if there a way to make the interfaces of an interop dll created in LabVIEW "COM Visible"? Are we building the interop dll improperly in LabVIEW? Do we need to embed a manifest file for them to call the interop dll directly? Is it possible that they cannot call the dll directly because they forgot to include the reference to the NationalInstruments.LabVIEW.Interop.dll? Sorry for the barrage of questions. This is the first time I've worked with interop dll's in LabVIEW
  19. Here is an interesting talk by Bret Victor. He has designed experimental UI concepts for Apple and others. To me its interesting to see how text based languages could catch up to LabVIEW's graphical style and even exceed it with instant visual feedback. Its also interesting to see how the IDE in any language could be improved. The video goes much deeper than programming languages and delves into life principals. Well worth the watch.
  20. Here's a potential hack to retry the connection if you get an error. If you create a LV2 style global / action engine to store your TCP/IP connection info, you can place that VI inside your MB query and reset the connection if you get an error 66 or 56 or whatever. I can't compile it down to 7.1 but included in the zip file as 8.6 if someone else can down convert it. TCP Connection LV2.zip
  21. I'm using them both and they work as advertised. I think Subversion on the server and TortoiseSVN on the client side are a little more refined for windows use than Trac. I found that setting up Trac was a bit cumbersome because its mainly command line based. It also has a lot of prequiste software that also needs to be installed (apache,python, etc). But if your comfortable with Python, etc it will be easy. The one thing I wish trac had was the ability to create tickets with deadlines that could be displayed in a Gantt chart on the web interface. Its great for bug tracking though. The other experience I had with Trac was on the customer side. When I first installed Trac, I set up customers with access to the web interface and the capability to add bugs etc. Turns out they mostly want to just send emails or right down bugs on a piece of paper and hand it to me to enter into Trac.
  22. I have an instrument class that uses serial comm to talk to a single instrument. Lets call it Instr. I created another class that has multiple instances of Instr. Lets call it Group. Each of the methods in Instr is duplicated in Group. I need to execute the methods for each Instr in the Group at roughly the same time in parallel. Currently all the methods of instument are re-entrant (preallocate) and also some of the subvis like "serial packet send receive.vi", "wait for operation complete.vi",etc . The problem I'm seeing now is that there are hundreds of "serial packet send receive.vi" instances and lots of instances of the method vis. None of the reentrant VIs maintain state so I'm going to try to switch to shared reentrancy and see if there are any improvements. But I was wondering, does shared reentrancy create a "pool" of instances where it only opens up as many as are needed for parallel execution at one point in time or does an instance get allocated every time the VI is executed. For instance, say in my Instr class i have a method called "eject" (set as reentrant shared) and in the Group "eject" method the vi executes 8 instrument "ejects" in parallel. If i also call the Group "eject" in multiple places is: # of Inst "eject" instances = 8 or # of Inst "eject" instances = n x Group "eject"s x 8 Is there a better way to do this. I really only need one "serial packet send receive.vi" per Instr since all communication is executed serially. One thought I had was to open a reference to the "serial packet send receive.vi" and store the reference in the class, then just call this referenced VI every time. The other thought i had would be to move all of the method executions into the process vi for the class. thanks for any help.
  23. People have been going through the code found in the hacked files and have found numerous examples of "tricks" to manipulate the data. Granted the people looking over the files are climate change "deniers" but if you look at the examples they present from a programming standpoint something smells fishy. http://www.americant...mategate_r.html Example 2 In two other programs, briffa_Sep98_d.pro and briffa_Sep98_e.pro, the "correction" is bolder by far. The programmer (Keith Briffa?) entitled the "adjustment" routine “Apply a VERY ARTIFICAL correction for decline!!” And he or she wasn't kidding. Now IDL is not a native language of mine, but its syntax is similar enough to others I'm familiar with, so please bear with me while I get a tad techie on you. Here's the "fudge factor" (notice the brash SOB actually called it that in his REM statement): yrloc=[1400,findgen(19)*5.+1904] valadj=[0.,0.,0.,0.,0.,-0.1,-0.25,-0.3,0.,-0.1,0.3,0.8,1.2,1.7,2.5,2.6,2.6,2.6,2.6,2.6]*0.75 ; fudge factor These two lines of code establish a twenty-element array (yrloc) comprising the year 1400 (base year, but not sure why needed here) and nineteen years between 1904 and 1994 in half-decade increments. Then the corresponding "fudge factor" (from the valadj matrix) is applied to each interval. As you can see, not only are temperatures biased to the upside later in the century (though certainly prior to 1960), but a few mid-century intervals are being biased slightly lower. That, coupled with the post-1930 restatement we encountered earlier, would imply that in addition to an embarrassing false decline experienced with their MXD after 1960 (or earlier), CRU's "divergence problem" also includes a minor false incline after 1930. And the former apparently wasn't a particularly well-guarded secret, although the actual adjustment period remained buried beneath the surface. Plotting programs such as data4alps.pro print this reminder to the user prior to rendering the chart: IMPORTANT NOTE: The data after 1960 should not be used. The tree-ring density records tend to show a decline after 1960 relative to the summer temperature in many high-latitude locations. In this data set this "decline" has been artificially removed in an ad-hoc way, and this means that data after 1960 no longer represent tree-ring density variations, but have been modified to look more like the observed temperatures. Others, such as mxdgrid2ascii.pro, issue this warning: NOTE: recent decline in tree-ring density has been ARTIFICIALLY REMOVED to facilitate calibration. THEREFORE, post-1960 values will be much closer to observed temperatures then (sic) they should be which will incorrectly imply the reconstruction is more skilful than it actually is. See Osborn et al. (2004).
  24. GA_googleFillSlot("news_story_left_sidebar"); LONDON (AP) - Britain's University of East Anglia says the director of its prestigious Climatic Research Unit is stepping down pending an investigation into allegations that he overstated the case for man-made climate change. http://www.breitbart.com/article.php?id=D9CAM0VG0&show_article=1
×
×
  • Create New...

Important Information

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