BrokenArrow

Since my job lately has been to debug existing code, I have found several race conditions. Sometimes I can spot these just by looking at the code, but often it's just by happenstance that I find them - usualy by doing things like initializing local variables with some bogus number or by drawing frames around code and throwing in a few delays here and there. IS there a trick to debugging race conditions? Speaking of (what I call) race conditions, is the attached picture a true race condition? On this VI, the error was occuring every 3rd or 4th entry into the VI. I fixed the issue by intializing the "Char Offset" to 0. A few moments later I moved the wire as shown and it fixed it, and got rid of the local I added. Since the problem was initially fixed by toying with a Local Variable, I defined this problem as a Race Conditions. Is it? Any advise for further reading? THANKS! Richard

Scenario of a given program I'm debugging: There's a file called Howdy.txt. It either has 7 characters in it or nothing. Parallel loops... Loop 1 writes to Howdy.txt file every 2 minutes to 30 minutes. Loop 2 opens up Howdy.txt every 1000mS and looks at it - to see if it's been written to. This happens all the time, 24/7. With this scenario, it appears there's a small chance the file can be open at the same time in two places. Is this common? Can it cause problems? The VI's are Write Characters To Fle and Read Characters From File. Thanks! Richard

While I agree that its likely the First Call function, it could also be a peace sign with a few pixels missing.

Greg, Simply grand. thanks!

QUOTE(GregHicks @ Jun 10 2007, 12:19 AM) WOW... 12:19 AM on a Sunday! Thanks, those are good ideas, if not a bit complicated (lots of VIs). Can you supply a "My VI" with lots of controls (including a cluster or two) showing how to use these VI's? -Richard

QUOTE(Darren @ May 18 2007, 11:18 AM) OH YES! How about the Express Vi delay thing? It has an error input. As for all my 5.1 projects, I could create one. :thumbup: Thanks for the memory jog!

Thanks Jim and Gary, That makes sense, that it's left over from debugging. Other than using a sequence, IS there a way to ensure that the delay in a loop is the last thing that runs before the loop starts over?

QUOTE(crelf @ May 3 2007, 09:50 AM) Crelf, what is the advantage of doing what's shown in the picture with the delay's output being wired to the loop? I've seen this a lot lately. Is this an attempt to get the delay to be the last thing that runs? I have read the LAVA Wiki article on timers in loops, and have learned that you don't have a lot of control as to WHEN the delay will take place. Thanks, Richard

QUOTE(EJW @ May 15 2007, 01:18 PM) Here's how you create "write only" variables in LabVIEW: 1) circa 1998: Mark writes a number to a Global called "LaserBias", so that 5 other VI's can use it. He then goes on to work at Lockheed. 2) circa 2001: Joe doesn't need the variable in two of the VI's because he cleaned up the code a bit. He dies tragically in a rice picking accident. 3) circa 2003: Nancy is bewildered by 2000+ globals, and the sharp lady she is, gets rid of many of them, but now the motor doesn't work. She's fired. 4) circa 2005: Fred gets rid of all of the global reads having to do with the "Laser" because the Laser is no longer used in the system since the motor doesn't work anyway. But who knows, we might need a laser again some day, so he leaves the global write in that one VI. 5) circa 2007: Richard comes on board to find out why the new Laser doesn't work. In a VI called "Init Systemr" is a DBL constant of 1250 written to a U32 global called "LaserBias". There's also 4 Property Nodes dedicated to Visible, Disabled, Boolean Text, and Caption Visible. No other references to that global exist. He finds 82 such "write only" variable and goes on to moan about it on LAVA. :beer: :beer:

QUOTE(crelf @ May 15 2007, 09:45 AM) I'm delighted that this is getting some giggles! :thumbup: :beer: :thumbup:

Rolf, I'm going to write your post in solder and melt it to the wall in the lab. Indeed, it IS the reads.

QUOTE(rolfk @ May 14 2007, 03:35 AM) Rolf, In the last sentence of my post, I tried to make a point that using a Property Node (over a Local) would NOT be the way to go.... and I mentioned that the Property Node manipulates the GUI, i.e. takes time. My first sentence; however, was off the hook and deserves any and all bashing you originally intended to dole out. :thumbup: Richard

QUOTE(dsaunders @ May 14 2007, 12:50 PM) I second that! I never knew that property node existed (the first one on the left that gets the VI's). I would love to have a wall chart of ALL the Propery Nodes available in LabVIEW. It'd be a big one. Laminated. I'd pay money for it.

QUOTE(Submeg @ May 13 2007, 07:43 PM) I have a similar issue where I need a photo-resist plasma etcher to self-tune the RF voltage through a feedback loop until it reaches 5% over-etch, then purge with argon gas until a pinkish glow is detected through chemiluminessence ... in LabVIEW. oh, and my son needs picked up at karate by 6:00.

QUOTE(rolfk @ May 14 2007, 03:57 AM) Oddly they aren't set to reentrant. I'm not sure what they were set at out of the shrinkwrap, but on this they are not reentrant. I may try that. By placing timers here and there and renaming VI's, I've gained a few more minutes of operation before sync errors occur. Boss pretty much says "wrap it up, I'll take it". Can't wait to shelf this project. Thanks for the ideas.

Many thanks Michael. That's my next trick. I just got word today that one of the machines has a "serial port problem once every two weeks or so".... :beer:

QUOTE(Michael_Aivaliotis @ May 7 2007, 10:32 PM) That would explain why the name change in one loop fixed something. The original programmer has different names for the different TOP LEVEL com port vi's (where's he's counting bytes or concatenating strings) but ultimately the Serial Port Write.vi is unchanged. Should that be renamed per loop? This program is completely insane! I APPRECIATE THE HELP !!! :beer: Richard QUOTE(Aristos Queue @ May 7 2007, 10:53 PM) Could you write something using scripting to find all local variables for a given FPterm...... That is something that I would do given the time, but the attitude is "get it working" and damn the torpedoes. Hence the state of this program. And I'm just stirring the soup and adding my global spices willy nilly like everybody else, and the boss wonders why a particular front panel indicator is "flickering".

QUOTE(crelf @ May 7 2007, 11:26 AM) You have no idea.... I just ran some stats of this "program"... The following searches gave a "Search Aborted. Too many search objects were found".... Globals: >2000 Locals: >2000 Front Panel Terminals: >2000 and... 347 VI's 594 sequences 1368 Attribute Nodes (old term for Property Node I guess) This project is a morph of something that was started 10 years ago, has had 5 or so programmers in it, with almost weekly additions. There's almost no wires. If something is more than a few inches away or in a different frame, a local variable was used. There are hundereds of "read only" variables, and even "write only" variables !!! Ultimately, the machine works, so I'm not going to get the boss to comit to more than a few days here and there of development time. :headbang: ANYHOOOOO... any advice on multiple loops & serial writes??? QUOTE(JFM @ May 7 2007, 09:32 AM) Whoops, sounds like a lot of fun It might be possible to open up all VIs, then save the Serial Port Write.vi under a different name (e.g. mySerialWrite.vi), and finally re-save all VIs that linked to the Serial Port Write.vi (not the VIs in vi.lib though ) Then you could replace the internals of the mySerialWrite as you want. I don't know if this would solve your issues, but at least you would have more control. /J Good idea JFM. I think one of the many previous developers had that idea, because some of the serial routines have dedicated names depending on the loop they are in. I have noticed that simply renaming one of the VI's fixed a problem - so that it had a unique name compared to the VI in another loops. I have no clue what that's all about, beacuse ultimately they use the antiquated Serial Port Write.vi deep within!!! R

Hello all! I have been debugging an older 5.1 program that has five or so parallel loops. Most of the parallel loops contain the old Serial Port Write.vi (not VISA). At some time or another, there's GOING to be dual instances of that VI running; however, the COM Ports are different per loop, so you'd think it's OK. Well, low and behold, when I stopped some of the other Serial Port Writes in Loop 2 talking to COM 2, my problems with Loop 1 talking to COM 1 went away. I can't really tell exactly where the error is coming from, due to the scattered nature of the program (no "wired" data dependancy, 1500+ global references, 350+ VI's, etc). Of course, what I'd like to do is rewrite it all in 8.2.1 using VISA with full error checking, but that isn't going to happen on this project. Any ideas?... or suggestions of COM Port usage in parallel loops? Thanks, Richard

QUOTE(Jim Kring @ May 3 2007, 03:00 PM) Good to know. On aside: I've often wondered why NI deosn't provide the LVRTE on a separate disk (and for the extra money for the app builder, that doesn't seem like a lot to ask). My upgrade was easy, and the mass compile feature works well (my projects average 300 VI's not including labview VI's). All my settings and stuff carried through just fine.

QUOTE(chrisdavis @ Apr 30 2007, 11:02 AM) Looks a bit more involved than I want. I basically just want to avoid opening the 5.1 VI's with 8.2, or at least have a warning screen.

Hello all, I have 5.1 and 8.2 on my computer. Is there a way to get windows to know that a file is 5.1 and open it with 5.1, without having to use "Open With...". ?? Probably requires a registry trick (?). Thanks, Richard

QUOTE(EJW @ Apr 25 2007, 03:56 PM) Aren't modern computers so fast and have so much memory, and recent versions of LabVIEW are so good at compiling for run-time, that the whole "avoid Local Variables and Property Nodes" mentality is no longer valid -- aisde from creating race conditions? (I can see the foaming-at-the-mouth LabVIEW gurus now ). Deciding between a Node and a Local, to me, comes down to the fact that a Node has the added benefit of GUI manipulation, otherise I don't know why you'd use a Node over a Local. Richard

QUOTE(gleichman @ Apr 9 2007, 03:51 PM) Seems long since a fresh 8.2 install (not an upgrade) takes like 30 minutes. Did that time include mass compiling all your old VIs? Does the install give you the option to mass compile, or does it recommend it when you start 8.2.1 for the first time? :beer: Richard

QUOTE(Aristos Queue @ Apr 10 2007, 01:18 AM) Great idea. I've pasted things like pictures of equipment, wiring dograms or connectors, etc, and always wondered when the file would go *poof* - but it never does. Of course, don't knock C too much... after all, what was LV written in?