Reading and saving data from two serial ports

[sifeet]

Hi, I've searched for similar questions in the forum but I didn't get an answer for my problem so I'm posting it here.

I would like to read and save data from two balances throgh serial ports. I have a drop-down menu in the VI from which I can choose the availabe ports on my pc. But it's always only one of them that works. So I only get data from one the scales.

I usually get 6 ports to choose, but only one of them works. So I'm wondering if this is something that has to do with my pc or the VI ?

I attach a screenshot of my VI.

Thanks 😃

[RavensFan]

What is going on with the subVI that has the default icon?  Is that some sort of action engine?  Can you attach it?

[sifeet]

Oh that's the VI where the communication with the balance happens.

I'll attach it.

[RavensFan]

That looks just like your first image except it is only one set of communication commands.

What is happening in the subVI with the default Icon?  The one you have Init and Ask wired up to?

[sifeet]

So sorry I attached the wrong one.... Here it comes.

[smercurio_fc]

All you've done is replace one action engine with another. We don't know what's happening inside the VI with the RS-232 icon. As far as I can tell, your "scale" does not appear capable of handling multiple serial ports. For example, I see no way to reference one serial port over another by, say, name. But I have no idea if the RS-232 VIs you have can. They could, for example, look at the VISA resource name and have an internal queue. Do they? Please upload the ACTUAL VIs. Do not post images or PDFs of images.

[RavensFan]

Okay that is better. But now the question is what is going on in the subVI called RS-232?  Where did you get that from?

My theory is that you are ultimately using a functional global variable or action engine to access a serial port.  You initialized a subVI with a port, then later when you use that subVI, to read or write, it just uses the port that is stored in an uninitialized shift register.

That would work fine when you are only using one port.  But when you try it twice in parallel, the data that was stored in one of the chains of command get used in both instances.

I don't think you need to use so much subdivision in your serial port code.  Use one subVI that does the heart of the communication, but don't let it be an action engine.  Just wire your VISA port reference through each chain of execution.

EDIT:  The problem is in your ASK case.  As soon as you run the subVI with the ASK condition, your false constant keeps the subVI running forever with the infinite loop you've created.

PS:  The word "Receive" is spelled wrong in your enum.  I before E, except after C.

[sifeet]

Thanks for both replies 😃

And sorry abt the image and pdf.

Anyway here is the RS232 VI. I haven't wrote that myself though.

[smercurio_fc]

---

@Ravens Fan wrote:

EDIT:  The problem is in your ASK case.  As soon as you run the subVI with the ASK condition, your false constant keeps the subVI running forever with the infinite loop you've created.

---

You actually want that to be False since you want to go from the Ask state to the Recieve [SIC] state and let that state decide whether to exit out.

The fundamental problem is that the RS-232 action engine is not designed to be used with multiple parallel ports. As suspected, the RS-232 action engine stores the VISA session in an uninitialized shift register. When you call it the first time via the scale VI from the one loop it initializes a VISA resource with the parameters you sent in, and saves it. Then when you call it again via the scale VI from the other loop it simply overwrites the saved VISA resource information.

The RS-232 VI would need to be rewritten to deal with multiple serial ports. A simple fix would be to modify both "scale" and the RS-232 VI so that you must always pass in the VISA resource on which to operate. The RS-232 would no longer use the unitialized shift register.

[JÞB]

Sub.vi 1 looks like one of those nice "Resource Modules". [Edit it is an RM] Unfortunately there appears to be only 1 instance so the VISA resource on the SR internally is only going to have 1 value.

A "Recource module" does have the limitation of not easilly scalling to handle multiple instances of a resource type. 

NOW, there is a way around it using 1 Resource Module. but it is not verry pretty it involves re-entreancy- and timed structures I don't think you want to go there.  A better way would be to create a class since you can have two instances of the class and keep the data of both instances seperate.  The simplest way though is to just make mutiple copys of the vi - 1 for each resource. Of course - reverting it to a Action engine- (remove the storage of the VISA session and require it as an input and output (as S_FC suggested) works well and scales well-