Jump to content

Performing Serial Port Writes in parallel loops


Recommended Posts

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

Link to comment

QUOTE(BrokenArrow @ May 7 2007, 03:09 PM)

...no "wired" data dependancy, 1500+ global references...

Whoops, sounds like a lot of fun :wacko:

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

Link to comment

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
:wacko:

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

Link to comment

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?

Link to comment

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". :wacko:

Link to comment
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.
Link to comment

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

Link to comment

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". :nono:

Can't wait to shelf this project.

Thanks for the ideas.

Link to comment

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". :nono:

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

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.