Jump to content

Pablo Bleyer

Members
  • Posts

    17
  • Joined

  • Last visited

Profile Information

  • Gender
    Male

LabVIEW Information

  • Version
    LabVIEW 2009
  • Since
    1995

Pablo Bleyer's Achievements

Newbie

Newbie (1/14)

0

Reputation

  1. Hello group. My company is looking for an engineer to help us in the development of LabVIEW applications for the characterization and testing of electronic devices and electromechanical systems. Experience with PXI, CompactRIO, embedded systems and medical devices a plus. Must be local to the Miami area (South Florida) or willing to relocate. Position is a temp to hire. Please contact me at pbk[at]embedded.cl for more details. Thanks! Regards.
  2. Hello people. Our company, HeartWare Inc, is looking for an experienced LabVIEW sidekick consultant who can aid us in the development of our in-house projects. We are a medical device company based in South Florida that manufactures heart assist devices (VADs) and uses NI products extensively. If you don't live near us, you should feel comfortable working remotely, with everything that implies. The prerequisites are: Ability to understand R&D requirements, work with minimum supervision, estimate work amount appropriately and meet deadlines. Strong background in custom algorithm development, specially oriented towards statistical analysis, signal processing and data filtering. Document the applications and the development process properly, including the use of a version control system (we use plain SVN). Implement code testing and verification procedures. In particular, unit tests and regression tests. Our code is controlled by the FDA validation guidelines, but previous knowledge of them is not required. Write smart, simple and tidy LV 7.x and/or 8.x code. If you meet our needs and are interested, please send us your resume, fees and other relevant information (code snippets much appreciated) to: pbleyer@heartwareinc.com Thank you in advance. Best regards.
  3. QUOTE(John Rouse @ May 4 2007, 11:25 PM) IMHO, if you are not having major problems with 8.2, I'd suggest that you stick with it and avoid 8.2.1. One of my reasons to update to 8.2.1 was that rings didn't allow elements out of sequence, and it was a hassle to translate ids from/to case statements. Also there are other annoying problems with controls. I've found that 8.2 is far more stable than 8.2.1. Regards. QUOTE(Neville D @ May 4 2007, 06:38 PM) I meant the VI's that you have written might be corrupted, not the vi.lib VI's. Your comment about "LV recovered the VI backup" brings to mind a similar problem I had a while back. The so-called "recovered" VI from backup was the one that was corrupted in my case. It caused all sorts of strange crashes, till I replaced it with a same VI written from scratch. If you remember which of these "recovered" VI's you used, I would advise just re-writing them or else obtain a copy from some old backup and modify. I'm pretty sure thats your problem. Neville. I tried copying the VI contents to a new one and I still can replicate the problem. Don't know if copying everything would fix the issues, though, in the event that that is the case (maybe the error is sticky). But I don't think a corrupt VI is the problem, because I am working with several projects and have had crashes in all of them. I only used recovered backups once. Anyway, never seen this before, but... is there a way to inspect the contents of a VI and perform a consistency check? Regards. QUOTE(PJM_labview @ May 4 2007, 07:02 PM) I don't think it has anything to do with large data set. I was just creating a cluster (very simple) when LV 8.2.1 crashed with the same error. http://forums.lavag.org/index.php?act=attach&type=post&id=5736''>http://forums.lavag.org/index.php?act=attach&type=post&id=5736'>http://forums.lavag.org/index.php?act=attach&type=post&id=5736 Note: The cluster was not a type def yet. I've also had crashes on "ThEvent.cpp" and "memory.cpp", and yes, even with tiny VIs like yours. I guess 8.2.1 was not thoroughly tested. Regards.
  4. QUOTE(Val Brown @ May 4 2007, 04:34 PM) Are you working with big data sets (eg long multi-dimensional arrays, clusters)? For typical, medium sized applications I also don't have major problems. It is when I start loading relatively large amounts of data and processing (dsp filters, regressions, statistics) that it starts using a lot of memory and it crashes. Most of the time it frees the memory back to the system and my app works fine, but sometimes it just starts accumulating memory like crazy, so I guess there must be internal memory leaks or data corruption. I also think that is why I it crashes on the fpsane.cpp module generally. Regards. QUOTE(Neville D @ May 4 2007, 05:17 PM) Maybe some VI in your project got corrupted after the upgrade process? Is it really related to the size of your data file (doesn't crash with smaller files)? Go back to a previous backup of the VI or project and try to mass-compile/re-compile the project. See if it re-occurs. Nevile. Don't think so. Upgraded two different systems from 8.2 to 8.2.1 and a completely new install of 8.2.1 on another. Same behavior on the three machines. It is related to the size of the files in respect to the frequency of the problem. It *has* crashed a couple of times during development, like changing the properties of some controls, but I guess that is the regular crash behavior of any application these days :-/. LV recovered correctly the VI backup on that occasions, though. I even thought it was the version of DAQmx installed, but tried downgrading to 8.3 with the same troubles. I am also trying to avoid any express VI. They seem to use more resources than regular VIs and the crashes are more frequent when I use them. Cheers.
  5. Ok. I am starting to regret having upgraded to 8.2.1. It is crashing on my machines almost on a daily basis with my current applications. Before I submit a report to NI, is anybody else having problems processing *big* data files into LV and displaying it in graphs? (See attachment). After working with the resource hungry 8.0 and 8.2 series, I have a deep longing for the stability and reliability of the old LV versions... In fact, I am seriously considering downgrading to 7.1 at this point. Regards.
  6. QUOTE(crelf @ Apr 20 2007, 07:52 PM) I just dropped a waveform chart, resized the legend to accept more than one plot, and then tried to stack plots to start configuring it. It doesn't automatically show stacked plots unless you change the chart type to a 2D array or such wiring a correct object to it. I thought that just resizing the legend was enough to do the trick. I also thought that it was possible to have stacked plots with mixed axis configurations, it seems this is not so Regards.
  7. Is anyone having problems stacking plots? I can't seem to create stacked plots in waveform charts. Also, if I have a duplicate scale and I try to stack plots, my second axis goes away. This is happening both in 8.2 and 8.2.1. Regards.
  8. QUOTE(Thang Nguyen @ Apr 18 2007, 04:30 PM) I have also tried to put the subVI files --even the LSB itself-- under the project file list, and in different locations of the generated installation (eg. Startup VIs, Dynamic VIs and Support Files, etc.), but to no avail. Something funny I noticed: project explorer lists the LSB dependency without the lsb extension. This is different as for DLLs (Pperhaps because it is an internal resource of a subVI and not a file per se). Is this the expected behavior? Thanks. Cheers.
  9. Hello. I have an application that uses a subVI containing a CIN resource (LSB). The app works perfectly on my computer either under LV (8.2.1) or as an executable. However when I install it in another computer (exe + runtime), it complains that the LSB resource is missing and the app is unable to load the container subVI. The Project Explorer recognizes the dependencies correctly and I verified that it is including the subVI in the build (which in turns contains the LSB resource). Anyone has experienced the same problem? Warmest regards.
  10. QUOTE(Michael_Aivaliotis @ Apr 17 2007, 04:29 PM) Hmmm... Woot, woot. I think that was the missing link. ;-) Very nice article, indeed.
  11. Thanks for the info, rolfk and Aristos. Now everything is clearer now. I thought controller references weren't strict types, since there are times when LV seems to know more about them. ;-) Best regards.
  12. QUOTE(AdamRofer @ Apr 12 2007, 05:18 PM) Thanks for the reply but, yes, I already knew that and, again, it's not direct. I guess I was expecting LV to discover the correct value of my reference without casting. It seems since the data is variant that information is effectively lost and value operations can't be bijective (like a pointer to void in C/C++). LV keeps track of the correct type of other properties of references so I was expecting that it also kept track of the correct type of the value. Regards.
  13. QUOTE(Val Brown @ Apr 12 2007, 05:45 PM) My builds and VIs are not large. My data files are. (~400 CSV files, each consisting of a capture of 5-20 variables at a 20ms rate for a bunch of hours). Plenty of double array builds and preprocessing filters over them. Albeit optimised they obviously generate a lot of memory usage. I guess there must be internal memory leaks somewhere that are being triggered by my code. Regards.
  14. Hello. I've always wondered, is there a direct way of retrieving the value of a control given its reference? Always using variant to data (as shown in the attachment) is tedious and cumbersome. Thanks in advance. Best regards.
  15. I don't know if it is just me, but 8.2.1 is behaving far more unstable that 8.2, at least on one of my machines. IIRC I had one or two crashes with 8.2. Since I installed 8.2.1 this week, some minutes ago it just crashed for the 5th time. This has happened on different applications, however I am working with big data files and LV was usually using more than 500MB of memory then. Maybe that was the reason? I'm glad that 8.2.1 fixed some annoying GUI property update issues, though. Regards.
×
×
  • Create New...

Important Information

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