I have multiple read and write serial ports in series, but whenever I write to one, another one reads it.

[mumu_akuatikus]

I'm writing a user interface for a reflectometer at a research lab for an internship, and just began to learn Labview. I am almost done with the user interface but I'm running into one (hopefully) final problem.

The reflectometer is connected to the program via two Serial ports (each control different axes). To summarize, I am using a sequence structure to first, automatically read the positions of the axes, and then afterwards the user has the option to send commands such as moving the axes. However, whenever the user decides to move an axes, the current positions read by the program disappear for an instance ("E 0 IPOS -20 ......." turns into "E 0"), which is very very strange since it is nowhere stated in the reflectometer manual that sending a command to retrieve the positions will only return a "E 0". However, whenever you send a command to move the axes, "E 0" is returned when all is good and there are no errors.

Reading the positions and sending commands to move the axes use separate read and write VISAs. I am suspecting that the data returned is sent to BOTH read VISAs, instead of just one. However, I tried testing this in a brand new VI using a simpler block diagram, and the two separate read and writes were successfully separated.

Has this issue ever been dealt with? Are there any possible solutions to this? Thank you 

[Dennis_Knutson]

Attach an image of your block diagram. It sounds like you may have miswired the VISA resources. I've never heard of any sort of bug that would cause this. A read from comx is separate from a read from comy.

[mumu_akuatikus]

Thanks for the offer Dennis_Knutson, but I think the problem is solved.

Once the time delay between read and write was changed, it began to work. It used to be 50 milliseconds for each but now it''s 100 milliseconds each. The hypothesis is that not enough time was given for the reflectometer to return the message to the VISA read, so it was being picked up by the next one. Some weird things happen I guess.

[Dennis_Knutson]

A delay is not necessary if the instrument sends a termination character and if you have enabled that. If s termination character is sent, you would not use a VISA Bytes at Serial Port either.

[billko]

---

@Dennis_Knutson wrote:
A delay is not necessary if the instrument sends a termination character and if you have enabled that. If s termination character is sent, you would not use a VISA Bytes at Serial Port either.

---

I agree.  In most cases, if you have to add a delay to get the communications to work, then you probably haven't totally understood how to communicate with the equipment.

[mumu_akuatikus]

If it won't cause me trouble in the future, I don't really mind the delay... Is it something that I shouldn't ignore?

[Dennis_Knutson]

It could cause problems and it certainly isn't very efficient. You could very well have to increase one delay or another. It would be better to code it right in the first place. It would actually simplify your code.

[mumu_akuatikus]

I voiced the concern with one of the people responsible for the project, and he believes that it may be an unusual problem with the controller. I suppose I can say this... The reflectometer I'm making the program for is actually the world's largest reflectometer. It is brand new so the components may not be perfect, and they may present slightly unusual problems. He thinks that this may be the cause of the problem. Although we don't know exactly why this happens, he is confident that there is a slight but significant lag between writing the command and reading the feedback. Since it could not be read completely by the first, it was read in the second text box. Some evidence for this is when I turned on "Highlight Execution" for debugging. When it was on, the problem did not occur, and I was honestly baffled and did not know what to do. Perhaps it's because the highlight made everything slower and gave the reflectometer enough time to respond.

Obviously, time is an issue and it is not the most efficient way of doing things, but we are prioritizing "It works" over "It's fast" at the moment. Although it definitely could be faster, time is not issue right now. I will save this link for future purposes if someone with more experience ever decides to upgrade the program.

I'm sorry this is such an unsatisfying response. Thank you everyone for helping out.

[Dennis_Knutson]

You don't have to satisfy me. The comments were made so you can do it right the first time and not have a problem some time down the road.

p.s. Yes, highlight execution does slow execution.

[billko]

---

@mumu_akuatikus wrote:

I voiced the concern with one of the people responsible for the project, and he believes that it may be an unusual problem with the controller. I suppose I can say this... The reflectometer I'm making the program for is actually the world's largest reflectometer. It is brand new so the components may not be perfect, and they may present slightly unusual problems. He thinks that this may be the cause of the problem. Although we don't know exactly why this happens, he is confident that there is a slight but significant lag between writing the command and reading the feedback. Since it could not be read completely by the first, it was read in the second text box. Some evidence for this is when I turned on "Highlight Execution" for debugging. When it was on, the problem did not occur, and I was honestly baffled and did not know what to do. Perhaps it's because the highlight made everything slower and gave the reflectometer enough time to respond.

Obviously, time is an issue and it is not the most efficient way of doing things, but we are prioritizing "It works" over "It's fast" at the moment. Although it definitely could be faster, time is not issue right now. I will save this link for future purposes if someone with more experience ever decides to upgrade the program.

I'm sorry this is such an unsatisfying response. Thank you everyone for helping out.

---

Hey, no need to apologize.  Sometimes the best solution isn't the most efficient one.  In the real world, oftentimes you don't have the time or the money to investigate doing it the right way, and you have to settle for a compromise.  Some people may chime in and say that it will cost you more down the road, but management decisions are like that a lot.