LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Serial communication with cRIO RS232

Solved!
Go to solution

Hi, JonSoucy,

 

The first thing that comes to my mind is the external power supply. It seems the NI 9870 didn't function normally.

Have you already connected the external power supply to the NI 9870?

20170125001.JPG

0 Kudos
Message 11 of 29
(3,348 Views)

First of all, is there a reason you're not just using the built-in RS232 port on your cRIO?  Is it already occupied?  Even if it is, a good way to test whether the issue is your code or your hardware would be to try it.  Too bad it's also not a DB9.

 

Second, the manual for the 9870 states that it is a terminal (DTE), and one assumes that the cable from NI would give you a standard DTE-DCE wiring.  You could easily test it with just a voltmeter by checking against the pinouts provided here (http://www.ni.com/datasheet/pdf/en/ds-276) and here (http://digital.ni.com/public.nsf/allkb/1EE0DD8AF67922FA86256F720071DECF).  For example, if you have continuity from pin 9 (RxD) on the RJ50 to pin 2 on the DB9, you have a normal straight through cable.  If you have continuity from pin 9 on the RJ50 to pin 3 (TxD) on the DB9, you have a null modem cable.

 

Third, I'm also using Labview 2015 on this computer, so I can't open your project and I'm going to ask a probably stupid question (so no offense--I routinely put VIs in the wrong place when I'm working on a new project).  You are running this code on the cRIO and not on the host computer, right?

 

Finally, you can also use Putty as a replacement for hyperterminal if you want to try to see commands from your module on your computer.  See here, for example: https://techawarey.wordpress.com/2013/06/20/serial-port-communication-in-windows-7-using-hyper-termi...

0 Kudos
Message 12 of 29
(3,336 Views)

WNM

Thank you, I will try that once the tester I order arrives.

I contacted NI and we determined that the s8 cable is a strait through connector RJ50(m)-DB9(m). The communication cable that came with the motor is a RJ11(m)-DB9(f); however, I am unsure if the motor is a DCE or DTE. I reached out to applied motion, but have not received a reply yet. Hopefully adding the null modem will just fix any issue once it arrives.

 

William1225

Yes, the power supply is connected properly

 

stephencox

That is a good idea to try that port for testing. Should I be able to use visa write with that connector? Currently my code using that function is the only one that I was able to get working to operate the motor, however, it was still connected to the computer’s come port and not the s8 cable.

And yes I believe this is the case as I contacted NI and they confirmed the S8 to be a through cable. However, that is another good suggestion to verify it with the volt meter. Hopefully the led breakout will be helpful in the future too.

Also yes I am running the code on the cRIO, I have to go through the complier every time.

What exactly would putty do for me? I’m a bit unclear on this. Would I be able to see the commands going to the motor running off the cRIO, PC, or both? The end goal is to run the motor from the cRIO with FPGA.

0 Kudos
Message 13 of 29
(3,324 Views)

Putty would just take the place of hyperterminal, which used to be a nice simple way to listen on serial connections using Windows.  The idea would be to watch what you are sending from the cRIO to check for problems with the commands themselves.  I doubt that it would help you too much in this case, though, since your code is working elsewhere.  I find doing things like that more useful when I have a working connection but the ascii commands I am sending to a particular instrument are having problems.  For example, it can be helpful to make sure you are actually sending the correct termination characters.

 

You should be able to open a VISA connection to the built-in port just like the ports on your module.  Try placing a VISA open in a VI on the cRIO and wiring a constant or control to the "VISA resource name" connector.  That should give you a dropdown list that includes the built-in serial port.  It should also be visiable in MAX.  I believe it should be called "ASRL1::INSTR" by default, but you can assign it a name that reminds you of what is connected to it in MAX.

0 Kudos
Message 14 of 29
(3,319 Views)

JonSoucy wrote:   I contacted NI and we determined that the s8 cable is a strait through connector RJ50(m)-DB9(m).

 "Straight through" is not a very precise way of talking about this cable since the pin numbers on the RJ50 end do not map to the pin numbers on the DB9P end in either the DTE or DCE case but I assume you mean that the cable does not have the transmit/receive pair does not undergo a "crossover" between the two connectors. This would agree with the use of the DB9P (DTE) connector on the cable and the assertion that stephencox made when he said he found that the 9870 with a cable that looks alot like the S8 would work as a DTE device.

 


JonSoucy wrote:  The communication cable that came with the motor is a RJ11(m)-DB9(f); however, I am unsure if the motor is a DCE or DTE. I reached out to applied motion, but have not received a reply yet. Hopefully adding the null modem will just fix any issue once it arrives.

As I said before, since the motor cable is working with a PC's COM port directly, it's very likely that it is operating as a DCE device so it really should work with a DTE/9870 without the use of a null modem.

 

While you are waiting for the null modem to arrive, you could try jumpering the transmit pin (#3) to the receive pin (#2) on the DB9P connector of the S8 cable and see if you can send out characters and have them loop back to you. This would require that you also setup a way to check the receive buffer on the 9870, but that should be easy enough to do if you only send/receive/check one character at a time.

0 Kudos
Message 15 of 29
(3,315 Views)

It occurred to me that at some point you could also connect the 9870 serial connection to the cRIO serial port to see if you can, as a test, move data between the two.  For this test you would most likely need a null modem because I think both ports are DTE.

 

I've attached a small serial-port monitor that I have occasionally used here. This copy of it is for LabVIEW 2015. It does run under Windows. It may run under the RT OS on a cRIO (if it doesn't, then it would not be hard to pare it down to something that would).

0 Kudos
Message 16 of 29
(3,308 Views)

Thanks for all the suggestions, so here is what I've found out using a multimeter:

The motor->RJ11(m)->DB9(f)->DB9(m)->RJ50(m)->NI9870/RS232

RJ11-DB9 cable

  • 5RX-3TX
  • 3TX-2RX
  • 2Grd-5Grd

DB9-RJ50 cable

  • 3TX-8TX
  • 2RX-9RX
  • 5Grd-6Grd

Therefore I believe that the connection my motor is a crossover cable when plugged into the PC or cRIO. As the motor seems to work properly when connected to the DB9(m) on the PC (DTE), the motor would all be a DTE? I think this would mean I do not need a null modem?

 

Also I was able to make some progress with the built in RS232. I can drive the motor using vista write and scan mode with my current cable setup, so it must just be some programing in the FPGA I am having issue with. I did double check and my VI are in the cRIO directory, deploying before each run, and no luck there. However, even though I have made some progress in scan mode, I would like to use FPGA if possible as my end aplication will be running for 8+ hours at a time.

0 Kudos
Message 17 of 29
(3,291 Views)

@JonSoucy wrote:

Thanks for all the suggestions, so here is what I've found out using a multimeter:

The motor->RJ11(m)->DB9(f)->DB9(m)->RJ50(m)->NI9870/RS232

RJ11-DB9 cable

  • 5RX-3TX
  • 3TX-2RX
  • 2Grd-5Grd

DB9-RJ50 cable

  • 3TX-8TX
  • 2RX-9RX
  • 5Grd-6Grd

Therefore I believe that the connection my motor is a crossover cable when plugged into the PC or cRIO. As the motor seems to work properly when connected to the DB9(m) on the PC (DTE), the motor would all be a DTE? I think this would mean I do not need a null modem?

 

Also I was able to make some progress with the built in RS232. I can drive the motor using vista write and scan mode with my current cable setup, so it must just be some programing in the FPGA I am having issue with. I did double check and my VI are in the cRIO directory, deploying before each run, and no luck there. However, even though I have made some progress in scan mode, I would like to use FPGA if possible as my end aplication will be running for 8+ hours at a time.


It would mean the motor is DCE and a straight through cable would works.

 

The fact the motor cable is DB9 female and would connect directly to the NI cable's DB9 male is also a good indication they are meant to be used straight-through without a null modem.  However that is not necessarily a guarantee that someone didn't deviate from common practice.

 

When you connect two DTE devices (like 2 PC's), you need a null modem cable.  When you connect a DTE to a DCE (PC to a modem, serial printer, some other serial device), you use a straight through cable.

 

It is a little confusing in your case because the motor has an RJ11 to DB9 connector that accounts for the special pinouts on the motor, and the NI cable RJ50 to DB9 accounts for the special pinouts on the RJ50 connector of the cRIO.     On DB9 DTE connections, pin 3 is Tx,  pin 2 is Rx.  It is the opposite on the DCE connectors.  (Just to confuse things more on DB25 DTE,  pin 2 is Tx, pin 3 is Rx.  )

0 Kudos
Message 18 of 29
(3,280 Views)


It would mean the motor [when used with the cable supplied with it] is DCE and a straight through cable would work [when connecting that combination of parts to a DTE device].


 

0 Kudos
Message 19 of 29
(3,267 Views)

JonSoucy wrote:  Also I was able to make some progress with the built in [to the cRIO] RS232. I can drive the motor using vista write and scan mode with my current cable setup, so it must just be some programing in the FPGA I am having issue with. However, even though I have made some progress in scan mode, I would like to use FPGA if possible as my end application will be running for 8+ hours at a time.

The cRIO's serial port (when run under the RT OS of the cRIO) should be just as robust as are the serial ports on the 9870 hanging off the FPGA.  Some of the cRIO based systems I've fielded have run for months without skipping a beat and I would trust them all to do so when required. "8+ hours" is nothing so if there is no other reason for using the 9870, go for the built-in cRIO serial port and come back to the 9870 when you have time to tinker and explore.  If you are developing the messages sent through the 9870 in the RT LabVIEW instance running on the cRIO (since text string operations are not currently supported in FPGA LabVIEW) then you are using and depending on RT LabVIEW anyway.

 

With all that said, if it were me, I'd also want to know how to get the 9870 working properly just because I enjoy puzzle solving and often find the results useful.  Keep in mind that there are two ways to run the 9870 (& FPGA) from LabVIEW, either NI-9870 (Scan Interface) or NI-9870 (FPGA Interface). In my case I opted for not using the scan interface because there were some other high-speed FPGA I/O operations that needed to occur that were not going to work under scan mode.  You can read about the differences between the scan/fpga modes in this document: cRIO Developer's Guide

 

Have you found this example?

 

As a test of the hardware, you could first get the 9870 working using a scan interface since the 9870 ports should appear as VISA options under RT LabVIEW with the scan interface. Using the more familiar VISA calls you can get the communications and cabling sorted out so it all works. Then, if you need to forgo the scan interface, switch to a project that uses the FPGA interface and take a crack at getting code you write to work.

0 Kudos
Message 20 of 29
(3,263 Views)