My VI works fine with debug light bulb, but not at full speed

[lockheed_eng]

I am using LV 10 for the first time for porting my LV 8 working code into the new LV.  My existing code is for handshaking and error checking instruments (specifically in this case, a Sorensen DLM40-15 power supply).  The Handshake VI calls a subvi to associate a GPIB address, a VXI Logical address or an PXI Instrument definition to a particular word string.  in other words, It takes any of those three inputs, looks up the approprate global and then outputs a string associated with that instrument.  for example, if I input GPIB address 21, it outputs "<DLM40-15_2>.  I then use that output to send to a case selection frame in the calling VI to determine if the VI should execute or not.  if the GPIB address does not find a match in the global, then that subvi will send "ERROR" instead of "<DLM40-15_2>" and the case selection will then not execute the code.

if I leave the light bulb ON on the Handshake VI (the calling VI) then the code executes correctly.  if I run full speed then the output of the subvi sends EMPTY STRING instead of ERROR or "<DLM40-15_2>".  since it sends an empty string and the case selection needs a correct match to execute, then the case selection chosen is the default, which is not to execute the handshaking code.

here are screen shots of my 2 VI's.  you can see in the first one where the case selection is made based on the subvi's string output.  in the 2nd one, I've only included the frame which executes for this particular scenerio.  I'm currently only dealing with GPIB address 21 & 22 (2 sorensens) and both give the same results. 

as I said, this code has worked fine in previous versions of LV (7 & 8 at least).  and this is the first driver I have started working on.

any help would be greatly appreciated.

[Ben]

Hi Reece,

You have not shown me enought for me to be bale to point you at the actual issue but you did show enough for me to venture a guess based on statistics.

Most of the time we see question with a title with "works fine in light buld not at full speed" the issue ends up being a race condition (see the link in my signature, this is soo common).

So here is the birds-eye-view

LV is multithreaded and race condtions have to be avoided. Local variables as well as global variables are often at the root of the race condition. In light bulb mode the code runs as if it is single threaded so again a race condition is suspect.

So to proceed I first invite you to read the thread on Action Engines ("Trouble with a Race condition?") and then review your code and fix the races.

If you can't spot the races post up your code (prepare for feed-back because stacked sequences are not cool around here) and maybe we can spot the issue in your code.

Just trying to help,

Ben

[Ben]

And to the point "it worked fine in earlier versions"...

When LV is updated the code is re-compiled and unless you have explicit code forcing proper execution order, the re-compile can result in different execution order.

Ben

[vt92]

Anytime that you use globals, there is a danger of "race conditions".  Are you sure the global isn't being modified somewhere else?  The difference in LV versions could effect the execution sequence or speed.  It is always best to follow a wire-flow architecture and avoid globals if at all possible.

[Dennis_Knutson]

You are committing two major sins. The stacked sequence structure and the local variables should go. By single stepping, you are slowing execution down and essentially doing it sequentially. That indicates a race condition and that you were just plain lucky it did not show up before.

Why don't you look at the instrument driver standards and rewrite your code based on that?

[lockheed_eng]

Ben,

thank you very much I will look at the information you suggested.

as far as working in previous versions, I think previous versions may have been all executed on single cores, no hyperthreading, so that could account for this problem not occuring previously.

[lockheed_eng]

vt92 - thanks for your help.  yes, I'm sure the global is not being modified elsewhere.  the globals only get written to ONCE at the very beginning of starting the equipment, then they are constantly read each time an instrument is to be used.

[lockheed_eng]

Dennis - thank you for your info, but I don't understand what you mean by "The stacked sequence structure and the local variables should go."

you mean that I shouldn't use stacked sequence or local variables?  can you explain that in more detail why that's a problem?  we have tons and tons of LV code that use this very scheme there's no way we could change it to remove sequences and local variables.

which instrument driver standards are you referring to?  can you point me to it, please?

[smercurio_fc]

---

@lockheed_eng wrote:

Dennis - thank you for your info, but I don't understand what you mean by "The stacked sequence structure and the local variables should go."

---

Stacked sequences hide code. They are an anathema to graphical programming that works by dataflow. That's not to say that they don't have their use, but in most cases you can write a LabVIEW program without ever using them. Programmers who come from a text-based background often rely on them.

Local variables are the number 1 cause of race conditions. Again, they have their use, but we often find them simply being abused/misused. Don't believe me? Check out the Local Variables thread. Fun reading.

As has been mentioned, the most likely cause of your issue is a race condition. Where this might be is impossible to tell just from those pictures, so posting the actual code will help in determining where the issue is.

---

which instrument driver standards are you referring to?  can you point me to it, please?

---

There are tons of instrument drivers in the Instrument Driver Network. You should check there first to see if an instrument driver is available for your specific instrument. You will note that the design uses VISA, so I'm not sure why you're not using VISA to allow you to specify an interface and address. From LabVIEW you can also create an instrument driver template. There are also several KnowledgeBase articles on writing instrument drivers.

P.S. I used to work for Lockheed Martin in the mid-90's. Just a side-note.

[lockheed_eng]

smercurio_fc,

thanks for your response.

I am aware that stacked sequences can hide code and we have found hidden code in VIs we have used from other companies (including NI!), but I am 99.9999999% certain (an engineer's 100%!) that there is no hidden code what I've written.  I'm pretty meticulous about that kind of thing.

if that's the only concern with stacked sequences then I will continue to use them. 

local variables, however, I do see where they can cause race conditions with multiple threads - which, as I noted above, we've never had before.  this is the first computer to my knowledge that we've used with multiple cores.  We've had hyperthreading on previous machines, but I turned HT off on them because they were causing LV to lock up.  looking back - that's probably the same kind of problem.

re: drivers, what I'm actually doing is creating a "higher level" driver than the ones you are referring to here.  these drivers USE those types of drivers to control the instruments, they are basically user interface shells.  that way we can swap similar instruments which use different drivers and these "Common Drivers" will select the correct driver to use.  they also limit the user to specific functions so that problems don't occur.

as far as using visa, yes, I do use VISA, but not for GPIB and the Common Drivers have to be compatible with both.

---

@smercurio_fc wrote:

P.S. I used to work for Lockheed Martin in the mid-90's. Just a side-note.

---

so did I!