BrokenArrow Posted May 8, 2007 Report Share Posted May 8, 2007 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 Link to comment
Mellroth Posted May 8, 2007 Report Share Posted May 8, 2007 QUOTE(BrokenArrow @ May 7 2007, 03:09 PM) ...no "wired" data dependancy, 1500+ global references... 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 Quote Link to comment
crelf Posted May 8, 2007 Report Share Posted May 8, 2007 QUOTE(BrokenArrow @ May 7 2007, 11:09 PM) 1500+ global references Holy crap - that's got to be some kind of record! Quote Link to comment
BrokenArrow Posted May 8, 2007 Author Report Share Posted May 8, 2007 QUOTE(crelf @ May 7 2007, 11:26 AM) Holy crap - that's got to be some kind of record! 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 Quote Link to comment
crelf Posted May 8, 2007 Report Share Posted May 8, 2007 QUOTE(BrokenArrow @ May 8 2007, 01:53 AM) "Search Aborted. Too many search objects were found" That's real purdy _ I've never seen that one before. Quote Link to comment
Michael Aivaliotis Posted May 9, 2007 Report Share Posted May 9, 2007 Well, it doesn't matter that you are using different com ports. The core comm VI is the same so you probably have a blocking situation. I would create a different named comm VI for each loop - along with all the associated subvi's. Quote Link to comment
Aristos Queue Posted May 9, 2007 Report Share Posted May 9, 2007 QUOTE(BrokenArrow @ May 7 2007, 10:53 AM) If something is more than a few inches away or in a different frame, a local variable was used. That suggests an idea: Could you write something using scripting to find all local variables for a given FPterm, display them in a list, allow the user to order that list, and then create a wire from one write local to the next read local, then delete the locals? Quote Link to comment
BrokenArrow Posted May 9, 2007 Author Report Share Posted May 9, 2007 QUOTE(Michael_Aivaliotis @ May 7 2007, 10:32 PM) ....... I would create a different named comm VI for each loop - along with all the associated subvi's........ 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 Link to comment
Michael Aivaliotis Posted May 9, 2007 Report Share Posted May 9, 2007 QUOTE(BrokenArrow @ May 8 2007, 05:44 AM) ...but ultimately the Serial Port Write.vi is unchanged. Should that be renamed per loop?This is testing my memory since it's been a while with 5.1. I had it installed here but took it off for lack of HD space. I would rename the Serial Port Write.vi, per loop, see what happens. I agree that you shouldn't bother with massive cleanups at this point. Actually, that might cause even more problems. It sounds like a complete re-write is in order, if anything. I feel your pain, having been down that road too many times myself. I wish I was there beside you to help out... :thumbup: . Hang in there. Quote Link to comment
BrokenArrow Posted May 9, 2007 Author Report Share Posted May 9, 2007 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 Link to comment
Rolf Kalbermatter Posted May 15, 2007 Report Share Posted May 15, 2007 QUOTE(BrokenArrow @ May 7 2007, 10:53 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) R Ohhh my god! My current projects are around 800 Vis easily, contain probably less than 20 globals, and also less than that in sequences (most of them being single frame sequences to enforce some dataflow dependency). Your problem is likely some serial port timing. If you have VIs that do some waiting inside and use that same VI for something else that something else won't be able to run before the first operation has stopped. However I thought the Serial Port Write.vi you mention was set to be reentrant so that should not be a problem. If it isn't making a copy with your own name and setting it to be reentrant will save you some time since you won't need to create individual VIs for each place. A reentrant VI really executes the same when used in multiple places like the same amount of individually named copies of that VI. The drawback of reentrant VIs is that you can not debug them well before LabVIEW 8 and basically not at all before LabVIEW 7. Rolf Kalbermatter Quote Link to comment
BrokenArrow Posted May 16, 2007 Author Report Share Posted May 16, 2007 QUOTE(rolfk @ May 14 2007, 03:57 AM) ....I thought the Serial Port Write.vi you mention was set to be reentrant so that should not be a problem. 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. Quote Link to comment
Rolf Kalbermatter Posted May 16, 2007 Report Share Posted May 16, 2007 QUOTE(BrokenArrow @ May 14 2007, 08:09 PM) 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. I just checked in a 5.1 installation and yes it is not set reentrant. The write in itself may not be a big problem I would expect more trouble with the read in fact. Your boss probably will be in your neck again next time production tells him this application is not working and they can't meet the target with such an ugly beast. Then you should tell him to either reserve time for a proper redesign or at least a through clean up (I would at least expect a few weeks of work) or forget it as that application is simply unmaintainable and never can be made to work reliably without that. Rolf Kalbermatter Quote Link to comment
BrokenArrow Posted May 16, 2007 Author Report Share Posted May 16, 2007 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 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.