Jump to content

george seifert

Members
  • Posts

    399
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by george seifert

  1. QUOTE(JodyK @ Apr 11 2007, 05:29 PM) Me too. That problem consumed at least 2 days of hair pulling. This is fixed in LV 8.2.1 with DAQmx 8.5. George
  2. QUOTE(Herbert @ Apr 10 2007, 08:29 PM) Thanks for the confirmation and the workaround. Yesterday I upgraged to LV 8.2.1 and DAQmx 8.5. George I found another workaround. I attached my fix. I was taking the AI.CustomScaleName from the DAQmx Channel node and feeding it directly to the Set Attributes VI. I inserted the convert variant to string and it fixed the problem. http://forums.lavag.org/index.php?act=attach&type=post&id=5463''>http://forums.lavag.org/index.php?act=attach&type=post&id=5463'>http://forums.lavag.org/index.php?act=attach&type=post&id=5463 George
  3. QUOTE(lab @ Apr 10 2007, 02:55 PM) Apply a DC voltage to the motor and it will turn.
  4. I know this was working with LV8.2. I just downloaded 8.2.1 and it's not working. I've enclosed a simplified example. I get error -2513 when I run it. Possible reason(s):LabVIEW: LabVIEW does not support properties of the specified data type. First could someone who has 8.2 please confirm that it doesn't give an error? If I delete array elements 0 and 1 from the "data" control it works. If delete any other combination of elements I get the error. I tried deleting all the elements and created some new waveform elements without attributes and it worked. I can't see anything wrong with the existing attributes. Can anyone see what could be wrong? Thanks, George
  5. QUOTE(JohnRH @ Apr 6 2007, 09:01 AM) Could be. Somehow I have a 8.2.1 LV runtime engine on my system. NI thought maybe it came from DAQmx8.5. But I did install VISA 4.1. Maybe that's where it came from. George
  6. I've been at this LV thing for awhile now, but I must confess that I don't really understand when it's best to use an ENUM or a text ring. Text rings now seem to have the advantage of allowing nonsequential entries. Yet I find myself using ENUMs when I have a pull down list that I know doesn't have to be changed programatically. Are there any practical differences between the two? George
  7. QUOTE(torekp @ Apr 2 2007, 02:13 PM) That might work if all the controls were the same type, but remember I said that some could be be Boolean clusters (some are actually Enums too). George
  8. QUOTE(Louis Manfredi @ Mar 30 2007, 03:22 PM) I don't know for sure yet, but I think the delay will be too long. I don't have the hardware yet and I've never used this Corelis JTAG interface before. I wanted to have a backup plan. George
  9. I'm going to have up to 100 registers (just consider a register as a simple numeric control for this example but they could be boolean clusters) that need to be sent to a JTAG controller. The user may want to program any number of these registers at once. I'm trying to figure out the best way to interact with the user in this situation and program only those registers that need to be programmed. I think sensing which register(s) changed is not an option because the user might want to send a register as is. So far all I can think of is the obvious: 1) Put a Boolean next to each register that the user sets and then pushes one Send button. or 2) Put a Send button beside each register. Has anybody has a situation like this before? If so, how did you handle it? I'm afraid I'm stuck in a rut and am missing a clever trick. Now that I just typed that in I may have something along the lines of sensing which register changed. Clicking on the control could make it change colors. The color would change if a value was changed or if the user just clicked on it. Moving away and clicking again would revert it to it's original color (deselect). Only those controls with changed colors would be sent with a single Send button. I guess I can see a few problems with this, but it might work. George
  10. I sure hope someone can help. NI seems totally stumped. I don't know exactly what caused this but now I get this error when my executable (Windows XP, LV 8.2) tries to write to a TDMS file. I've run the debugger and I can see that the code gets past creating the TDMS file, but errors when trying to write to the file. I replaced the Set Porperties write with a different write to the TDMS file and still get the same error. This same error also happens on another executable that was built earlier. NI thought it might have something to do with DAQmx 8.5 so I replace that with DAQmx 8.3.1. No luck. So I removed MAX and it's components. This also seemed to remove LV 8.2 so I reinstalled that and MAX and DAQmx 8.3.1 and VISA 4.1. Still get the same error. I think this started when I had to go into the registry to remove an old reference to DAQmx 8.1 after installing DAQmx 8.5. My installer builder kept trying to find something in the DAQmx 8.1 installer directory even though it was no longer installed. My registry edit fixed that problem, but I fear it may have caused this other problem. Any suggestions? I'm dead in the water here and NI doesn't seem to have a lifejacket for me. George
  11. QUOTE(Dirk J. @ Mar 23 2007, 11:18 AM) Cool. Works for me too. Now I can enjoy the weekend. You guys are the best! George
  12. QUOTE(crelf @ Mar 23 2007, 09:47 AM) Here it is. Hopefully everything is in there. The main VI is JTAG_scan_dma6_old.vi (I've still got a lot of work to do on it). Here's one more thing. I copied the BD and put it in a new VI. When I first did that the Run arrow was OK. Then I tried to save it and I got a pop up that said this Compiler error. Report this problem to National Instruments Tech Support. reference to undefined label from:refPC=0xE0F I reported that to NI and they still had no clue what was wrong. Thanks for checking it out.
  13. I have a broken run error on my VI. When I try to run the VI I get the following error in the Error list: That's it. No error code or anything else to go on. No broken wires or anything obvious in my BD. I don't have a clue where to go with this. This is a VI that I have been making changes to. I inherited it from someone else who seemed to believe that sequences are to be used everywhere possible. So I'm doing a massive cleanup (I have to so I can try to understand what's going on). The original VI opens fine with no broken arror. NI is stumped so far. Any ideas? George
  14. There's a directory for LV711RTE and LV80RTE created by my LV 8.2 installer builder. They clearly deal with LV 7.1.1 and LV8.0 run time engines. I was wondering if anyone else has these directories in their installer directory. I can't understand why they would be needed. BTW, I have both LV 7.1.1 and LV 8.0 loaded. I just spent a day trying to figure out why the installer builder was looking in my DAQmx 8.1 installation dir when I have DAQmx 8.5 loaded (and it's the only DAQmx that shows up in MAX). It turns out there was an old entry in the registry. So I'm wondering if the same thing is going on with the old run time engines. However I don't want to wipe out those old copies of LV yet like I could with DAQmx. George
  15. QUOTE(crelf @ Mar 16 2007, 09:54 AM) I went back. It hurt my knees. George
  16. QUOTE(John Rouse @ Mar 15 2007, 11:11 AM) I switched to a trackball and it made a big difference. You also might want to check out these websites (no affiliation, but it did help me). http://www.aboutcts.com/ http://www.julstro.com/what_is_rsi.html George
  17. QUOTE(Dave Graybeal @ Feb 22 2007, 02:17 PM) Good catch. It came from the DAQmx Constants & Property nodes pallette. I took your VI and put another constant there directly from that pallette and it does the same thing. Sure seems like a bug to me. George
  18. QUOTE(crelf @ Feb 22 2007, 01:54 PM) Sorry about the type def thing. I forgot about that. I also noticed that I forgot to put in a way to get to the "OK" case. Bad day. I also had a major nose bleed all over my shirt earlier. I look like I got shot. Anyway, thanks to crelf, I tried disconnecting everything from the typedefs. Now it works. So I guess it must have something to do with the typedefs. However I can probe typedefs elsewhere in my VI. I don't see how this is any different. George
  19. QUOTE(crelf @ Feb 22 2007, 11:24 AM) OK, here's an example. Please excuse the nonsensical nature of the VI. I started with my working VI and ripped it to shreds to get down to the bare minimum. Put a probe on the wire in the upper loop connected to the shift register. Hopefully you'll see that the probe never gets loaded with data. George
  20. QUOTE(Michael_Aivaliotis @ Feb 22 2007, 10:35 AM) Nope, it's not reentrant. I just tried to create a quick example from scratch and it worked fine. I guess I'm going to have to pare down a VI that it happens on. Stay tuned, this could take a little while to get something I can post. George
  21. QUOTE(crelf @ Feb 22 2007, 09:29 AM) Yep, I've tried that. The wire definitely has data in it. If I connect an indicator to the wire that the probe is on, the indicator shows the data (I changed the data too to make sure it gets updated). BTW, this happens in all of my VIs and to all the wires that go to a shift register. So it's not just a quirk of this one VI. My memory may be off, but I don't remember this happening before LV 8.0. George
  22. When I put an error probe on a cluster that's connected to a shift register it stays gray and won't show any values. I've tried it with the probes in several places along the wire (inside my case structure and on either side of the structure). Probes on clusters that aren't connected to a shift register work fine. Has anyone else seen this? George
  23. I'm seeing it too although not quite as often. This never happened before rev 8.2. The "Save as" > "Rename" trick only works about half the time for me. Sometimes making a change will fix. Sometimes just waiting awhile will fix it. Sorry I don't have any clever fixes to offer. Actually I guess I have nothing to offer. George
  24. I've had this question on the LV forum for several days, but haven't gotten any replys that do what I need. I want to find out how many PFI lines are available on a given DAQ card are so I can then inform the user that the test can't be run with the available DAQ board if it's not suitable. The PFI line in particular I'm looking at is PFI12 (associated with CTR 0 out) that's not available on some older boards. If you look at a VI like DAQmx Connect Terminals, the "source terninal" control is populated with all the lines available on the board. It seems I should be able to get the same info from somewhere. The types of DAQ cards used could be changing so I'd rather not build a fixed list of boards that are OK to use. I thought about using the error, but getting the available lines is much cleaner. I've tried a whole bunch of DAQmx property nodes, but none of them list the PFI lines - just the other channel names.George
×
×
  • Create New...

Important Information

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