how do I access pxi-8433/4 ports from CVI?

[ashelly]

I have a PXI chassis, with a PXI-8186 controller running PharLap ETS Realtime, and two PXI-8433/4  RS422 cards.  I also have an CVI application which sends data over a null modem from 1 port to another other.    It works perfectly when I use the built-in COM1/COM2 pair on the controller.

But when I tried to switch to using RS422, it still seems like however I try to open the ports,  what gets opened is the COM1/COM2 ports on the controller.

MAX shows the ports on the RS422 cards as COM3 through COM10.  So I tried to open ports 3 and 4 using OpenComConfig(3,NULL, ...).  When that didn't work I tried OpenComConfig(3,"COM3", baud, ...)

And then I tried ports 5 and 6, both with the "COM5" string and without.  

And in every case - my application only continued to work if I had the null modem serial cable connected to COM1 and 2 on the controller, and stopped working as soon as I disconnected it.   It didn't make any difference if the null RS422 cable was connected or not.

Any ideas?  How do I open the ports on the RS422 card?

Thanks,

-Adam

[Sarah_R]

ashelly,

Thank you for contacting National Instruments.

If you go into Measurement & Automation (MAX) are you able to right click on the COM ports for the RS422 and choose Open VISA Test Panel? If so, you can do a loop back test to check what is being sent. Please reference the following KnowledgeBase: Pinout For Serial Ports for more information.

If your able to try the loop back test and it is a success, please try running a shipping example. These can be found at C:\Program Files\National Instruments\CVIXX\samples.

Please let me know the results of these suggestions.

[ashelly]

I wasn't able to do "Open VISA Test Panel" ... until I installed NI-VISA Server on the Realtime controller and added my desktop to the list .   After doing that, it appears that I can open the ports using the port numbers shown in MAX.  I modified the "RS-232RT\Messages" example to use the new RS422 port ID's and that worked correctly. 

Did I miss the documentation that says NI-VISA Server is required for NI-Serial port IDs to be assigned correctly?

Thanks for the help.

-Adam

[Sarah_R]

ashelly,

The only thing required is that the NI-Serial are deployed properly on the target machine. Glad everything is working.

Have a great day.

[Mert_A.]

Adam,

NI-VISA Server is not necessary, but the NI-VISA API is required to interface with the NI-Serial driver.  However, this should have been transparent to you, as the NI-Serial RT software has a dependency on NI-VISA.  You should be able to confirm this by selecting/deselecting the NI-Serial RT item in the Measurement & Automation Explorer (MAX) software installation wizard.

If you were able to successfully open the port, NI-VISA must have been installed, or you would have gotten a descriptive error popup (at least in debug mode).  It's possible the port mappings got edited or otherwise reassigned.

Mert A.
National Instruments

[ashelly]

I can open the ports, and the RT Serial example is working as I expect, so I guess I've got everything installed and configured on the RT chassis ok.  Maybe installing NI-VISA server was a red herring.

I did find one big source of confusion.   If I change my code, and click Debug Project, then CVI builds, downloads and runs my new code on the target.  But if I then reboot the RT chassis, wait until it has restarted, then click Debug Project - it seems like CVI runs some old version that I had previously installed on the target.   I finally found this out when I noticed that some new debugging printfs didn't always appear.

So sometimes when I thought I was running the new code trying to use the RS422 ports on COM 3 and 4, I was really running the old code using Com1 and 2.  

Is there a way to ensure that the current code is re-downloaded whenever you click 'Debug Project'?

If I can do that, then I can stop questioning my sanity, and start tracking down my current problem - which is that the ports open and start communicating, but then seem to freeze - I suspect a write timeout.

-Adam

[Mert_A.]

The CVI debugger downloads your DLL to a temporary directory (/ni-rt/cvi/download) which is cleared out when the the system starts up (or more acurately, when the CVI RT runtime engine DLL loads and initializes).  For "permanent" deployments of files, you can use the RT File Copy Utility, which also provides the option of setting a DLL as a "startup DLL", meaning that it automatically loads and runs when the system boots.  Is it possible that you have an old version of the DLL installed as a "startup DLL" which is causing confusion?  The RT File Copy Utility displays the startup setting for each file it has installed, or you can scan the "StartupDLLs" item of C:\ni-rt.ini on your target system for the path of your DLL.

Also, can you confirm that you see (ever so briefly) a popup dialog with a red progress bar when you begin debugging?  This indicates that the DLL is actually being FTPed to the target system.  If you don't see this, it may indicate that you are attaching the debugger to an already running (old) instance of the DLL.

Mert A.
National Instruments

[ashelly]

Sometime last week, I downloaded a version of my app as a "startup DLL".   At the beginning of this week, I used the file copy utility to "Toggle Startup DLL" - so that it was NOT marked startup.  But I left it in the NI-RT\CVI directory.   It seems like whenever I clicked debug while the dll on my development machine was up-to-date, it either did not download the newest dll, or it ran the one in the NI-RT\CVI directory first.  I'm not sure I always saw the download popup.  At some point I will try to reproduce this.

But for now, I have removed the dll from the NI-RT\CVI directroy, and now I am consistently debugging with my latest version.

So I'm back to being stuck on a communications issue.

I have an multi-threaded application, where one thread writes a command stream to a serial port, and another thread recieves the commands and sends back responses.  (The second thread is a simulator of our real hardware, at some point I will replace it with the actual item..).   This application works perfectly when I use COM ports 1 and 2 - which are RS232.   If I make one change - to use ports 3 and 4 - which are RS422 - the application runs for a second or two, then seems to freeze.  I suspect that it is hanging on the ComWrt function, but I'm not certain of that.

I know the connection between ports 3 and 4 is good - I was able to run a version of the "Messages" example which used both ports.  It worked using the same baud and other serial parameters as my application.

Any ideas about the differences between RS232 and 422 that would cause an application to freeze when doing RS422 writes?

Thanks for the help so far,

-Adam

[Mert_A.]

I know very little about RS-422/485, but a significant difference is that these interfaces support several different transceiver modes, which may change the way your application behaves. The ComSetEscape function can set the transceiver mode.  I would try explicitly setting the different modes, starting with WIRE_2_AUTO.  If the ports on the device are configured to use one of the DTR-controlled modes by default, then your program would be responsible for explicitly controlling the state of the DTR line (again, by using the ComSetEscape function).  If you didn't manage this line, then handshaking would cause all your writes to time out.

I would also suggest that if you're using an output queue (passing OpenComConfig an output queue length >= 0), you might try disabling it by passing -1.  Having a separate thread that is actually responsible for executing the writes -- this is what the output queue setting actually does -- often introduces timing issues that may not be accounted for by the code.

Mert A.
National Instruments