labviewman

I have 2 identical Agilent DMMs that are connected to the tester via USB. I can easily detect them via 'Find VISA Resource' using USB?*::0x0957::0x0618::?*::INSTR for the search item. Since the serial#'s of the DMMs are not fixed (DMMs will be replaced with identical equipment when calibration is needed), I can't use them (w/o some code to prompt the user to decide...which I hate do allow to make a decision) to determine which DMM I am talking to. Since part of the output of the 'Find VISA Resource' gives the USB board it is plugged into I figured for $30 I can easily determine which DMM to use for function A (i.e. if the response is USB1, than I know DMM1 is connected to that USB port), but, it still returns back USB0. I now have 2 USB cards for a total of 8 USB ports, but 'Find VISA Resource' returns the same info on each port, and if I compare all the VISA properties I read on each USB port (with the DMM plugged-in), they are all identical. I checked NI's site, but something is going on to their site...can't get into much of the knowledgebase and the forums are not working well. I'm sure I'm not the first one to come across this, so I'm am hoping someone else can offer some advice. Thanks, Todd

QUOTE(labviewman @ Feb 13 2007, 10:30 AM) I found it here: <http://forums.lavag.org/index.php?act=atta...ost&id=2056>

QUOTE(Jeff Plotzke @ Feb 2 2007, 03:39 PM) Mine doesn't work either. Apparently someone has a newer version than what Jeff and I have, so please share with us where we can find the latest and greatest that works with LV 8.20. Thanks, Todd

Here is NI's response: ------- R&D have identified your issue as a bug and it will be fixed in the next release/patch for LabVIEW. Please let me know if you have any other questions about this issue. -------

A big question is why is this happening in the first place? Can we ever trust queued state machines again using typedef enums? NI is looking into it; I will provide and update here when I get an answer.

I tried that before and it didn't work. I even re-created the type-def completely, and it didn't work. What did work was to replace the 'enqueue element' at the problem location in the code. Watch how tnhe constant changes during execution...then changes back when the program stops! It didn't take long to track down this problem since the code from this was taken is quite simple.

I have a simple .vi that uses a queued state machine using typedef enum constants. A very common technique in a state machine. What I didn't expect was the typedef enum constant (yes, a constant!) to change during execution. Quite a serious bug. This was originally LV7.0 code, converted it to LV7.1 but the problem exists. I have not tried LV8.0 (haven't even taken it out of shrink wrap yet). NI is looking into this, issue #7105073. Todd Download File:post-2108-1140486925.zip