george seifert Posted February 23, 2007 Report Share Posted February 23, 2007 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 Quote Link to comment
Grampa_of_Oliva_n_Eden Posted February 23, 2007 Report Share Posted February 23, 2007 QUOTE(george seifert @ Feb 22 2007, 10:19 AM) 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 George, I have probed clusters in LV 8.2 within the last week using LV 8.2 and it worked fine. I have seen issue using the SDE in execution highlighting mode (which is just a fancy probe) if the VI was opened from the project but worked if not opened from the project. Could you post code that demonstrates this, please ? Ben Quote Link to comment
crelf Posted February 23, 2007 Report Share Posted February 23, 2007 QUOTE(george seifert @ Feb 23 2007, 01:19 AM) 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. A gray probe suggests that there's no data there? Try execution highlighting and confirm that the probe gets data. Quote Link to comment
george seifert Posted February 23, 2007 Author Report Share Posted February 23, 2007 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 Quote Link to comment
Michael Aivaliotis Posted February 23, 2007 Report Share Posted February 23, 2007 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. Quote Link to comment
george seifert Posted February 23, 2007 Author Report Share Posted February 23, 2007 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 Link to comment
crelf Posted February 23, 2007 Report Share Posted February 23, 2007 QUOTE(Michael_Aivaliotis @ Feb 23 2007, 02:35 AM) I find this hard to believe. Please post an example. I'm with Mike - this sounds kinda freaky - let's see some code... Quote Link to comment
george seifert Posted February 23, 2007 Author Report Share Posted February 23, 2007 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 Link to comment
crelf Posted February 23, 2007 Report Share Posted February 23, 2007 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... Quote Link to comment
Dave Graybeal Posted February 23, 2007 Report Share Posted February 23, 2007 After a bit of investigation ( and a ton of disconnecting type defs ).... it would appear that the gray cluster probe is caused by the probing of the daq cluster within the cluster. Attached is an even smaller vi that shows where the gray probe is comming from. I'm not sure what it is yet, but I figured that I'd post this breakdown in case someone else might be more familiar with this issue. Also attached is a picture that shows it. I hope this helps get this figured out. Dave Graybeal Quote Link to comment
george seifert Posted February 23, 2007 Author Report Share Posted February 23, 2007 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 Link to comment
Michael Aivaliotis Posted February 23, 2007 Report Share Posted February 23, 2007 Well, it appears to be a LabVIEW bug. I would report this to NI. When the VI is idle and you popup on it to use a generic probe the probe reference bubble is greyed out. I DID however manage to use a custom probe. That works fine. Typedefs or NOT, this is not normal. Typedefs can be probed. The image of the grey bubble was after I disconnected typdefs so this wasn't an issue in my test. Here is a LV 8.2 version which has this problem too. Download File:post-2-1172175648.vi Quote Link to comment
Dave Graybeal Posted February 23, 2007 Report Share Posted February 23, 2007 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. Anyone know where this constant came from? Dave Graybeal Quote Link to comment
Michael Aivaliotis Posted February 23, 2007 Report Share Posted February 23, 2007 QUOTE(Dave Graybeal @ Feb 22 2007, 12:17 PM) After a bit more research it appears to be caused by a Daqmx Device Constant.Good Job! :thumbup: Quote Link to comment
george seifert Posted February 23, 2007 Author Report Share Posted February 23, 2007 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 Link to comment
crelf Posted February 23, 2007 Report Share Posted February 23, 2007 QUOTE(Dave Graybeal @ Feb 23 2007, 06:17 AM) After a bit more research it appears to be caused by a Daqmx Device Constant. :thumbup: Nicely done! QUOTE(Michael_Aivaliotis @ Feb 23 2007, 06:17 AM) Typedefs or NOT, this is not normal. I agree - let NI know that you've found a bug. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.