Visa communication error

[Dragonrider]

Last picture

[JimB.]

The subVIs in your screenshot look custom to me, so I'm not sure what's going on in there, but the issue is more likely how the port is being initialized. That has already happened at that point.

You're (most likely) looking for where this is called:

https://www.ni.com/docs/en-US/bundle/labview-api-ref/page/vi-lib/instr/visa-llb/visa-configure-seria...

It would also be helpful to see a screenshot of the PuTTY configuration settings if that is still working.

"Am I wrong or should the data from the read actually show real text? What I am seeing is garbage. Any thoughts?"

If it normally sends back data you can read in PuTTY then yes, I'd expect it to be readable text. That said, this is device and protocol specific. Some devices communicate using a binary protocol which usually does look like garbage if viewed as a text string.

[Dragonrider]

Thank you for your response. I believe that yes it should be sending back information that is readily readable because as I stated earlier and you might be able to see in the screenshot, it is comparing the data from the read to a constant text which is u-boot. 

I have added three more screenshots which again will probably have to be posted separately. One is of putty and the serial port configuration which matches exactly what is set in the program and also on the port on the computer. Another screenshot is a combination of the command prompt window and the putty window. In that you will see a manually executed command that begins with SB-Loader.exe... It then returns three status lines that show what happened. At that point if you look at the putty window below it you will see the u - b o o t prompt. At that point you would then execute other commands to complete the setup of the board under test.

The third picture is of the labview program which shows the three responses that are returned after the command is executed from the embedded command prompt in the program and they are identical to the ones that are shown in putty. Below that you will see verifying communications or something like that and that is where the program ends because it does not get the U-BOOT response. If the response is not received the action engine goes to shut down and the program ends.

I know I have said this already multiple times but it's simply makes no sense that multiple computers suddenly are not working with the exact same executable that worked for months on end with no issues. I am the one who has been using them and for the life of me I cannot think of anything at all that I am doing differently or not connecting. There are only two connections to the board. One cable allows you to execute the SB-LOADER command through the command prompt and the other one is the communications connection via a TTL r232 3v3 cable. To me it is utterly mind-numbing that this is no longer working for no apparent reason. I have updated all drivers. I have updated multiple dell functions. I have reinstalled Visa. Nothing makes sense. Frankly I have very little hair left to pull out lol.

I really appreciate all the help. Here are the photos. Thanks again.

[Dragonrider]

Last 2 pictures 

[JimB.]

The settings in PuTTY aren't quite the same. They show flow control being set to None, but your probe display shows it as XON/XOFF.

Have you tried changing that?

[Dragonrider]

My apologies for not responding sooner but I was the only with some medical issues. I took a look at the code to see how the comport was being set up and it is being set up with x o n / x o f f just like it is in putty. I truly am stumped. Since my initial goal was to get this program installed on a different laptop to ship to a contract manufacturer I decided to concentrate on that one.

 To that end I used the original installer that was used on the laptop I had been using for months with no issue. The installer includes n i - v i s a, the runtime engine, and 488.2. It also includes.net install. No joy.

I wish I could explain better about this board that is being tested. As I stated previously there is a TTL serial cable and a USB mini cable. Also on the board is a slot for a microSD card. The microSD card contains an executable that loads a program onto the board. That program is executed via a command prompt command from within the labview program. This works with no problem and the response on the screen within the software is correct.

Immediately after that it tries to establish communication via the TTL serial cable and that is where it fails in the program stops due to the error.

I did find something very interesting today though. I should point out before saying this that I have tried multiple boards. Anyway at the point to tries to establish communication, the microSD card is inserted into the slot per the prompts. I don't know why but immediately after the command prompt execution was completed I ejected the microSD card and placed it back in. Low and behold communication worked and it started executing commands and then failed. The failure is most likely due to the card not having been in there constantly. After discovering this I went ahead and created a new microSD card with the proper files on it hoping that that was the issue but it still would not work as it's supposed to. I don't know what else to do and I'm at a total loss. All the com settings are exactly the same as putty. All the software required for operation is installed. There is no antivirus software running and I even disabled any other security I could find. Nothing seems to work.

This system is now more than a month overdue and management is screaming for it but I don't know what to do next. Why would the program suddenly stop working on a computer that it has worked for months with absolutely no issue. Multiple boards, multiple cables, multiple microSD cards and nothing has helped. I think it is going to turn out to be something stupid simple but for the life of me I have no idea what.

Thanks for all the help in suggestions so far. If anyone can think of anything else I'll try it no matter how bizarre. The code itself is pretty straightforward as far as the communication it's concerned. One of the files on the microSD card is the one that basically says okay you are ready to go and it should return prompt on the screen. Tomorrow I will upload a screenshot of what the test looks like when running so this will probably make more sense. I hope.

[JimB.]

---

@Dragonrider wrote:

I took a look at the code to see how the comport was being set up and it is being set up with x o n / x o f f just like it is in putty.

---

That's not what your screenshots show though.

PuTTY (20240215_155959.jpg) has the flow control set to None.

LabVIEW (20240215_133347.jpg) has it set to Xon/Xoff.

[Dragonrider]

You are correct. My bad. I will try changing it in the code but the factory remains that the code has not been modified in the last 2 years and the system was working up until 3 to 4 weeks ago with no issues and worked every time. 

In a previous response someone said that the area code I am seeing that I posted means that it is a valid resource but that it cannot be accessed. I guess I don't quite understand that. I've been probing the code today on the original development laptop. It returns how many bytes are in the buffer but the data returned is all garbage. It should return a single word: u-boot. This indicates that the board has initialized properly. I have tested known good boards multiple times and have now gone to almost a dozen different boards all with the same results. Why would it suddenly stop working with no changes to the code and no changes to the computer? I have never come across anything like this before. I'm going to run more tests with probes and I will go ahead and modify the code to get rid of the flow control setting and see what happens. Thanks again.

[AnalogKid2DigitalMan]

Something about a valid resource but cannot be accessed regarding COM ports rings a bell from long long ago.

I had a similar issue- diving down into Windows Device Manager/COM Ports showed valid and some invalid COM ports. In use was a USB-Serial adapter.

I forget what IT did specifically but I think the jist was deleting ports (EDIT: in Windows it is Uninstall), rebooting, and letting Windows re-enumerate them. Somehow a phantom had taken over a COM port permanently refusing to let any other programs access it.

-AK2DM

[Kevin_Price]

In Device Manager try going to View->Show Hidden Devices.   I'm not sure I remember correctly, but you *might* need Admin rights to get rid of old stale hidden devices.

-Kevin P