Jump to content

konroh

Members
  • Posts

    17
  • Joined

  • Last visited

    Never

Everything posted by konroh

  1. QUOTE(silmaril @ Aug 14 2007, 10:43 AM) page seems to work in my firefox, you can also install IE Tab (https://addons.mozilla.org/en-US/firefox/addon/1419) and open any page you want in firefox including things like Exchange webmail.
  2. QUOTE(orko @ Aug 6 2007, 01:41 PM) there was a coersion dot...but this is the first time I have seen it cause a problem editing, I know it slows down execution to some extent, but in this case execution was fine, editing was horribly slow. Like I said, I tried to recreate the issue from a blank vi with no luck, so it must be related to how deeply in the code this was buried. There is no noticable delay in editing any more, where there was a 1-5 seconds delay before.
  3. QUOTE(orko @ Aug 6 2007, 12:11 PM) I found the problem. I couldn't get it to reproduce in a small VI, but the constant circled above was a SGL, changing it to a DBL fixed everything...the type coersion where it was connected to the shift register on the for loop seemed to be causing the problem...
  4. QUOTE(Ben @ Aug 6 2007, 09:53 AM) I read that thread, looks like this is a somewhat common problem, I do have typedefs, case structures, and event structures in this code. I have checked each subVI and they all seem fast, I will keep checking various things that appear in that posting... QUOTE(silmaril @ Aug 6 2007, 09:55 AM) I remember this kind of effects from a 25 MB VI with > 6000 front panel elements in LV 7.1. (No! I didn't write that one! ) Can you post your VI? It's really hard to guess what might be wrong without looking at it. One thing you can try quickly: Hold down Ctrl-Shift while pressing the run button with the mouse. This causes LV to recomile the VI hierarchy. Maybe you are lucky and the VI gets broken, which would show you the culprit. I did try re-compiling the vi (several times actually!) I can't really post this program, as it's the top level vi of a fairly large program, although of about 6 active projects, this is the smallest one and for some reason it's the only one with this problem! I have other vi's that are much larger and more complex that don't show this behaviour. At this point, and from looking at the posting referenced above on the NI forums, I think I have a typedef or a case structure that is misbehaving...it would be nice if there was an easy way to find it! QUOTE(crelf @ Aug 6 2007, 09:59 AM) Hey Doug - is it in a format that you can post to the thread? hey Chris, I will see if I can re-create the issue with a stripped down version of this VI, but I doubt it...and unfortunately I can't really post the entire program... ok, after deleting case by case and checking the edit speed, it seems that I have a problem with an xy graph. If i delete the graph the edit speed vastly improves (almost no noticable delay), if I replace it with another xy graph however, everything slows back down. if I create a new xy graph, and wire everything in it also slows down again...I will have to keep digging, but I think something is messed up with my xy graphs or at least the way I am using them.
  5. Hi Jeff, i had a lot of problems with writing to disk in LVRT 7.x destroying the determinism of my application, and finally just started streaming the data to my host program. However, I recently upgraded to LVRT 8.2, and now, using the same code, I have no problems streaming data directly to the hard drive of my RT controller.
  6. ok...all is working now...I found on the NI forums, someone said to just delete the data folder in max, then restart the computer...you lose any custom tasks or channels, but at least everything opens now! So reinstalling everything was a big waste of time, but at least I know now...and projects open just fine now. Apparently projects are tied closely to MAX, but you would think an error would appear letting you know why LabVIEW just disappeared! Anyway, thanks for all the help guys! I appreciate it!
  7. Well, now the problem appears to be with MAX and with LabVIEW. And I am thinking it was MAX all along When I open MAX, and try to expand a tab (Software, Data Neighborhood, etc...) I get a dialog saying "MAX Database Connection Error"...I searched on ni.com and found 2 possible solutions, neither worked, so now I am going to search here. I already re-installed MAX once, but it didn't fix it. This time I am going to remove everything, then delete the National Instruments folder in Program Files, and then re-install. Anything else I should try first? Thanks! The problem seems to be happening with every project I have, so I doubt they were all somehow corrupted at once. See above, it seems I have a MAX problem, which I am guessing broke my projects...
  8. Well, for now I am going to try to re-install when I get time...I have been pretty busy today! I'll let you guys know if it fixes the problem. Thanks for the help!
  9. Hey Chris - the problem is occurring with all my project files...so I think it's definately something with my installation of LabVIEW. I am going to reinstall if I can't figure it out soon, and hopefully that will fix it, but I would like to know what happened so I can avoid having it happen again in the future... Jimi - tried what you suggested - no change. It's strange, since I can work with individual VI's, but as soon as I try to open a project, LV is instantly gone, no warnings or errors or anything...and it was working perfectly at 5:00 last night when I shut the computer down.
  10. Just tried that...closed LV, deleted LavVIEW.ini, restarted LV, still can't open any projects I am still getting the exact same behavior...
  11. Hey Guys, I did some searching around the forum and at NI.com and didn't see anyone else that had posted about this...if anyone has please direct me to the thread... Yesterday I created a LabVIEW 8.20 project based on an old 7.1 program I had been working on. Everything was fine. At the end of the day I made sure everything was saved, and all seemed fine. Today when I came in I loaded up LabVIEW, went to open my project...and... nothing...LabVIEW just closes, no error, no prompt...and it does it for any project file I have created. I can open the VIs for my projects just fine, but anytime I try to open a project LabVIEW just disappears. Everything was working fine yesterday afternoon... Any idea how to fix this?!? Thanks! Doug
  12. You have a ton of options...Dearborn Group (dgtech.com) has the gryphon, Intrepid (intrepidcs.com) has the NeoVI. And there are many others.
  13. What do you want to do? You can monitor the bus with an NI-CAN card (and many other bus tools), or use an off the shelf reader to get the DTCs (Diagnostic Trouble Codes) or monitor various vehicle parameters.
  14. Just finished adding the code to stream the data over TCP...and after several minutes of continuous logging the largest loop rate I observed was ~1100 uSec. (as opposed to 7000-8000 using file write) and most were much closer to 1000usec. Is file writing just not able to be done deterministically? And yes, I have one pink cluster, but it's only read from once when I start a certain mode, other than that it just sits and is not written to or read from...oh, and the error cluster...everything else is pre built arrays, or single elements, few subvi's, no globals, few locals, and lots of shift registers. I tried to grab some screen shots, but like I said, the code is too large to see anything meaningful in one screen capture... As of now I am happy with the performance, just disappointed the 30gig hard drive on the PXI is just about useless for my application...oh well... thanks for the help!
  15. I tried to flush the file more often, and it made no difference...does realtime use the flush command the same way as windows? Relf, the code is pretty much just one huge block diagram (real time type code) so a screen shot would only show a small portion of the diagram. JFM, TCP/IP streaming sounds like a good idea, i am going to try it now, I'll let you all know how it works out. thanks!
  16. An update: if I comment out "Write File" I can run my application for minutes at a time without a single loop finishing late, and the longest loop time I observed was 1079 uSec. Everything else is happening, including FIFO communication between the loops, just no actual write to file, the file itself is even open. Anyone know an efficient way to write data to disk without disrupting loop times? thanks!
  17. Hi All, I am using LabVIEW 7.1.1 with a realtime program running on a PXI chassis and a host program running on a laptop. My code consist of three main timed loops. I have a low priority communication loop for communicating with the host program running at a 50ms loop rate. I have a low priority logging loop running at 2 ms while logging, and 10 ms when idle. And I have a high priority main loop that does most of the work, running at a 1 ms loop rate (using 1Mhz clock, and 1000uSec loop time). All my loops are pretty solid when not logging (the main loop runs at about 960-1040 uSec, and the other two loops never finish late). When I start logging data (5khz data, 23 channels, averaged every 1 ms - 5 scans - by the main loop whether logging or not) I see the occasional (once every 10 seconds or so) loop that runs as high as 7-8ms. I have the main loop running PID control on a hydraulic actuator, and this size jitter is unnacceptable. The main loops loads the data into an RT FIFO buffer every time I have an even 512byte block size (23 channels * 8 bytes per channel * 64 iterations = 11776 block size). I have no build arrays anywhere in my target code, I initialize all arrays at startup and just use replace subset. The logging loop writes each chunk of data to file using the regular LabVIEW write file. Any ideas? I have tried all the simple ideas I could find and read up on the forums here and at NI on possible casuses for excess jitter and nothing I have tried has made any difference. Let me know if I need to give any more information. Thanks! Doug
×
×
  • Create New...

Important Information

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