LabVIEW
VISA RS-232 Program Works on Computer but not on cRIO
Solved!
I have a simple LabVIEW program that interfaces with an instrument that has been working on my computer, but when i transfer it to my cRIO 9035 the program times out waiting for a VISA read. The setup is my instrument plugged into the RS232 RJ50 on the 9035 via a DB9-RJ50 cable. All the program is is a visa write, visa read, then parse the string into numbers for display and eventually writing to a CSV. I suspect the serial port is not being configured properly on the cRIO, though that is hard for me to prove. See attached from program and screen shot (apologies for spaghetti code). Any advice would be greatly appreciated, thank you.
You configure the serial port to terminate on byte code 13 aka carriage return on reads. Are you sure your device will respond with the ?LP command even if it is not terminated with a carriage return?
Some esoteric devices that use fixed size commands sometimes do, but generally almost every device I have worked with that uses text commands will happily sit there and wait if it sees its specific <end of message> termination character before it even tries to interpret any command.
I confirmed that the cable works using the MAX VISA Test Panel. I configured it as shown below and "?LP" is working as expected.
It seems that the termination character is working, and that termination character is not needed for reads. @roflk I don't really understand your point about carriage return on reads, the VISA Read op doesn't seem to have term character as an option, maybe I'm misunderstanding.
VISA Read will return when the number of bytes requested in byte count is read, the timeout occurs, OR the termchar is received, if configured to do so.
I'd recommend using "VISA Configure Serial Port" rather than manually using a handful of property nodes, because there are multiple settings to get right.
I am guessing your error is that you have enabled your Termchar, but didn't enable the Read function to stop on Termchar.
You're requesting 50 bytes but your device only ever sends back 31. You're not explicitly configuring your VISA task to have Termchar as an "End mode for reads"- it should set that automatically, but maybe it's not?
Anyway- try using VISA Configure Serial Port just once in the beginning instead of reconfiguring the port every loop. That will get all of the miscellaneous property nodes correct.
Also, check and see if you're getting ANY data back or just SOME data back but still getting the timeout error.
Also also, make sure your IO names are correct- Windows and the cRIO chassis will almost certainly name the ports different things.
(https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000015AHBSA2&l=en-US)
You seem to use Interactive Control tool to test your communication on Windows. But that is not exactly the same as using VISA functions in LabVIEW. The principle is the same since the underlaying VISA functions are the same, but a VISA session has quite a number of properties and the default value for these properties is slightly different in the Interactive Control since it is similar to a command line application.
In your LabVIEW program you set the termination character for the VISA session in the beginning of your loop with the properties TermChar En and TermChar. These properties do not need to be set over and over again, so you can move that entire block out of your loop, directly after the Open VISA Resource Node.
You enable TermChar En and set the character to byte value 13, which is Carriage Return. VISA Read stops on these conditions:
1) if an error occures in the underlaying driver
2) if the requested number of bytes/characters has been read
3) if the configured termination character is encountered if this is enabled
4) if the timeout in the connection timeout property expires
So your VISA Read will terminate if it sees a Carriage Return
Your Interactive Control configuration is also configured to use End Mode on Write set to TermChar. This means that each VISA Write will append the configured TermChar automatically. You could add that property to the LabVIEW program and enable it, but I find that not a good solution. It is almost always better to explicitly add the necessary termination characters to the actual command instead.
You can do that by right clicking on the string constant and select Visible->Display Style. This will show a small glyph on the left side of the string control or constant. Click on that glyph and select "'\'-Codes Display". Now you can append the \-coded character \r directly to your command string entering in fact "?LP\r".
But from your Interactive Control screen shot it is visible that the first character of the returned string is \n. This is most likely part of the termination character sequence from the previous answer. So your device really responds with \r\n as termination sequence. Therefore it is better to configure the TermChar to the property node from 13 to 10, so that the VISA Read will terminate on the New Line (\n) character instead on the Carriage Return (\r) character.
It may also be better/possible to enter "?LP\r\n" but you will need to try that out.
The program that was working last week on my computer is no longer working either, so progress? Not sure. Initially, the VISA Read was outputting the exact same string as the VISA Write input string ("?LP"). I assumed it was just outputting the input string as part of the erroring/timing out so I added a VISA Clear between the VISA Write and the VISA Read and now the output of the VISA Read is blank, so same symptoms as the cRIO. I made a more simple test program below.
The VISA Test Panel is still behaving properly, so wiring is correct and the port is working. As suggested I did rename the ports to avoid confusion so I am definitely using the correct port too (but I tried all of them just in case). Is there an easy way to test the VISA Write output through LabVIEW or would I need to plug a computer into the RS-232 port via a USB-RJ50 cable.
The VISA Clear after the VISA Write almost certainly makes things only worse. It can sometimes work but then you have to place it before the VISA Write.
And you have tried NONE of the points I mentioned in my previous post! They are more likely to help solve this problem than all the other things you tried so far.
Apologies, I had actually tried what I thought was every permutation of what you had recommended, I just didn't write it all down. As it turns out, what I did not try was every permutation of what you recommend and removing the VISA Clear. I removed the VISA Clear and changed the write buffer to include the codes display and now it is working on my computer once more.
Now, as before, when I transfer the program to the cRIO I get an error (-1073807343).
I searched for the error and was recommended to install the IVI Compliance Package, which I did (19.5.0), but that did not fix it. When I move the program to the cRIO I have to reestablish the path for the configure serial port VI (which I do).
I then see a warning which I then load with version 19.0.
and the VI seems to open properly (but has the same error as above). I bring this up because I wonder if the problem is driver related and this might be a related symptom. This is why I was using the Property Node instead of Configure Serial, because this way the VI loads properly (and of course, still errors).
Sorry again for not being as clear as I should have before.
From the image in one of your earlier messages that shows a \n at the beginning of the returned string it would seem that your device actually returns a response terminated with \r\n. Because of that it would be more useful to change the termination character constant to the Serial Port Configure VI from 13 to 10, so VISA Read will terminate on the \n character byte.
The problem with the insufficient location error is the name of the serial port. Your PC has some COM3, COM5 or similar port number which usually results in ASRL3::Instr or ASRL5::Instr as VISA resource name. Your cRIO by default has an ASRL1::Instr resource. You need to change that before you try to run the VI.
If you open the VI in the project from under the cRIO target you should be able to select from the available serial ports on the respective target rather than what your computer uses.
The IVI package install recommendation was most likely an AI generated red herring.
