george seifert

QUOTE(JodyK @ Apr 11 2007, 05:29 PM)

I had issues related to the 8.2.1 Runtime engine and an executable made in 8.20. The issues were directly related to the tdms storage. I dropped back to the last version of daqmx and the runtime engine 8.20 and everything was golden. NI support confirmed my issue.

-JodyK

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

QUOTE(Herbert @ Apr 10 2007, 08:29 PM)

George,

I have tried your VI and I can reproduce the problem. The root cause is that the data type of the "NI_ChannelName" property on some of your waveforms is "tag" instead of "string". My first thought would be that the change in data types was introduced by a new driver version. Did you recently update your drivers?

Sorry for the inconvenience,

Herbert

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

QUOTE(lab @ Apr 10 2007, 02:55 PM)

can any one help me in dc motor control, i hav to submit it tomorrrow

Apply a DC voltage to the motor and it will turn.

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

QUOTE(JohnRH @ Apr 6 2007, 09:01 AM)

I noticed that the LV Runtime engine that is included with NI-VISA 4.1, claims to be version 8.2.1. (NI-VISA 4.1 is available for download)

Could this be correct?

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

Thanks. That helps.

George

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

QUOTE(torekp @ Apr 2 2007, 02:13 PM)

How about a table with columns labeled Register# and Value. As soon as the user enters a new Register#, your VI automatically updates the Value column to that register's current value. If the user tries to enter an already-listed register number, you beep or flash, and move the cursor into the column where that register's value is listed.

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

QUOTE(Louis Manfredi @ Mar 30 2007, 03:22 PM)

Hi George:

Is there a great cost in not sending all the registers, even those the user hasn't changed, whenever the user wants to send even a single change?

Louis

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

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

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.

Error -2500 occurred at TDMS Set Properties in <my VI>.

Possible reasons:

LabVIEW: Storage VIs internal error.

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

QUOTE(Dirk J. @ Mar 23 2007, 11:18 AM)

This worked for me: move the tms_reset DLL call into a sub-vi, see screenshot.

The error message still doesn't make sense to me though...

good luck.

(found out by systematically removing stuff from the BD)

Cool. Works for me too. Now I can enjoy the weekend. You guys are the best!

George

QUOTE(crelf @ Mar 23 2007, 09:47 AM)

Hi George - can you upload it for us to have a look? Sounds corrupt at some level...

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

I reported that to NI and they still had no clue what was wrong.

Thanks for checking it out.

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:

Code could not be generated correctly for this VI.

An error occurred in compiling this VI.

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

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

QUOTE(crelf @ Mar 16 2007, 09:54 AM)

http://en.wikipedia.org/wiki/Kneeling_chair' target="_blank">Get one of these - they take a week or so to get used to, but you'll never go back...

I went back. It hurt my knees.

George

QUOTE(John Rouse @ Mar 15 2007, 11:11 AM)

Greetings,

After many weeks of marathoning in LabVIEW I am beginning to see signs of serious trouble in my right(mouse) hand.

What ergonomic advice could I get here from the hard core advanced architects?

Thanks in advance.

John

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

QUOTE(Dave Graybeal @ Feb 22 2007, 02:17 PM)

After a bit more research it appears to be caused by a Daqmx Device Constant. I'm not sure where this Daqmx Device Constant Came from, but it is the reason we are seeing this. Attached is a vi that shows the constant, as well as a picture.

http://lavag.org/old_files/monthly_02_2007/post-4149-1172175399.png' target="_blank">

Anyone know where this constant came from?

Dave Graybeal

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

QUOTE(crelf @ Feb 22 2007, 01:54 PM)

Firstly, you're missing these controls (I just disconnected them from the typedefs):

• EOS detect.ctl
  
• Setup data.ctl
  
• DAQ tasks.ctl
  
• Tescom.ctl
  
• Piston.ctl
  
• Aux input params element.ctl
  
• Aux input params.ctl
  
• Initialization_misc data.ctl
  
• Pulse paramteres.ctl
  

Secondly, it's not the USR that's the issue - probing after the constant in the init case never gets written too. Something very odd is going on here - if you remove an element from the cluster constant (just drag something out) then probe the wire as it comes out of the constant, then run the VI -> the probe closes...

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

QUOTE(crelf @ Feb 22 2007, 11:24 AM)

I'm with Mike - this sounds kinda freaky - let's see some code...

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

QUOTE(Michael_Aivaliotis @ Feb 22 2007, 10:35 AM)

I find this hard to believe. Please post an example.

Also, if you're probing a reentrant VI, make sure you are probing the correct instance.

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

QUOTE(crelf @ Feb 22 2007, 09:29 AM)

A gray probe suggests that there's no data there? Try execution highlighting and confirm that the probe gets data.

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

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

Hi

I am facing this error maybe 100 time a day (no kiddinig !!!) and afer 10 mails to NI I learned to live with it... when it happens, I do "save as" > "Rename" and let the sme location and rewrite..

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

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